muse2api 是一个把 Muse（muse.ai）逆向封装为 OpenAI 兼容接口的开源项目，支持对话、文生图、文生视频，并内置多账号池轮转与 48 小时自动续期。它的隐私设计哲学非常克制：全部数据（账号凭据、任务记录、生成的图片视频）都持久化在你自己服务器的本地data/目录中，不依赖任何第三方遥测或外部中转服务。本文带你逐层拆解这套"零数据外泄"架构的实现细节。

一、数据都去哪了？全量落在本地 data/ 目录

很多同类工具的"黑箱"在于你不知道数据存在哪。muse2api 的做法是把一切都摊在桌面上：

• 账号池：data/accounts.json—— 存你导入的 Muse 账号 Cookie 与状态；
• 任务记录：data/tasks.json—— 生图、生视频、对话任务的队列与历史；
• 生成媒体：data/media/—— 所有产出的 MP4、WebP 文件，通过/v1/media/{filename}接口对外提供。

目录结构在 config.py 中统一定义：data_dir、media_dir、download_dir全部派生自本地路径，没有任何"云端目录"的概念。账号数据的字段格式可以参考仓库内的示例文件 data/accounts.example.json。

使用 Docker 部署时，持久化同样直白：docker-compose.yml 中只挂载了一个卷./data:/app/data，Dockerfile 里对应的VOLUME ["/app/data"]声明意味着——删掉容器，数据无损保留在宿主机上。备份？cp -r data/ backup/一行命令的事，数据完全在你手里。

二、原子写入：断电也不会写坏账号池

账号池里存的是登录态 Cookie，属于最敏感的数据，一旦文件损坏就前功尽弃。muse2api 在存储层 store.py 用了一个经典的"原子写"套路：

1. 先用tempfile.mkstemp()在同一目录创建临时文件；
2. 完整写入新内容；
3. 用os.replace()原子替换目标文件。

同一目录的临时文件保证了os.replace是同分区操作（跨分区的 rename 不是原子的），因此任何时刻accounts.json要么是旧的完整内容、要么是新的完整内容，不存在写一半的中间态。配合全库级别的线程锁（store.py顶部的_LOCK），多账号并发调度时的读写也不会互相踩坏数据。

任务侧同理：store.py 中每次创建或更新任务都立即落盘tasks.json。服务异常重启时，启动钩子（app.py）会扫描出未完成的生图/生视频任务并明确标记为failed，而不是悄悄丢失或悄悄重复生成——这种"宁可报错也不静默"的策略，本身就是对数据可靠性的尊重。

三、Bearer Key 鉴权：一把密钥守住所有接口

muse2api 所有受保护接口（API 与/admin/*管理端点）都走同一套 Bearer 鉴权，实现在 app.py：

Authorization: Bearer m2a_xxxx...

这套密钥机制有几个值得注意的安全细节：

• 启动即安全：如果部署时没配MUSE2API_KEY，服务启动时会自动用secrets.token_hex(24)（Python 的密码学安全随机数）生成一个m2a_开头的密钥并写回.env（app.py），不存在"默认空密码"这种隐患；
• 一键换锁：管理面板提供/admin/apikey/rotate接口（app.py），用secrets模块生成新 Key、原子写回.env并立即生效，旧 Key 同步作废。发现泄露？点一下按钮 30 秒换锁；
• 管理面板不靠 Cookie 会话：面板访问链接是/admin?key=<你的KEY>，鉴权完全不依赖浏览器 Cookie（app.py 有专门注释说明这一点），从机制上规避了 CSRF 类攻击面。

💡部署建议：无论 Docker 还是裸机，第一件要做的就是修改MUSE2API_KEY。密钥是你整台服务唯一的"门禁钥匙"，请妥善保管，不要写进公开文档。

四、Cookie 防泄露：三个设计细节

账号 Cookie 是整条数据链中最敏感的一环，项目在三处做了防护：

1. 接口层主动剥离敏感字段。列出账号池的接口 store.py 中有一行关键代码：返回结果会显式剔除cookies字段，只回传 ID、标签、额度、过期时间等元信息。也就是说，即使有人拿到管理 API 权限去"看"账号池，看到的也只是账号画像，而非登录凭据本体。

2. 核心凭据最小化校验。store.py 定义了ESSENTIAL_COOKIES——决定账号"生死"的只有hatch_sess、hatch_vml、hatch_native_auth_device三条。系统围绕最小必要集管理账号生命周期，而不是无差别囤积一切 Cookie 元数据。

3. 浏览器沙箱级隔离。多账号并行时，基于 Chromium 原生Target.createBrowserContext隐身容器执行，每个账号的 Cookie、Session、缓存 100% 隔离绝不串扰。账号 A 的登录态物理上不可能"漏进"账号 B 的上下文。

另外，官方推荐的导入方式也不是手工复制 Cookie：配套的 extension/ Chrome 导号扩展在本地浏览器中读取登录态并直推你的服务地址，全程不经过任何第三方中转。

五、唯一出口：请求直连 muse.ai，无遥测、无中转

所谓"零数据外泄"，核心在于服务与外界的通信面被压到了最小。梳理整条数据流：

你的客户端 ──Bearer Key──> muse2api（你的服务器）──CDP/会话──> muse.ai

• 你的对话内容、生成结果，只在"你的客户端 ↔ 你的服务器 ↔ muse.ai"之间流动；
• 会话自动续期由后台心跳协程直连muse.ai 的/api/session完成续签，不经过任何第三方中继；
• 代码中不存在任何统计上报、版本收集、错误回传一类的隐藏外发通道——整个数据面就是 data/ 目录 + 对 muse.ai 的直连。

换句话说，隐私边界完全由你自己掌控：服务部署在哪台机器、MUSE2API_KEY发给谁、data/目录备份到哪，答案都在你手里。

六、生产部署安全清单

综合以上机制，给出一张落地清单：

总结

muse2api 的安全与隐私设计可以概括为三句话：数据全在本地data/目录，接口用单一 Bearer Key 门禁，敏感 Cookie 在接口层默认不可见。原子写入保证账号池不会因断电损坏，沙箱容器保证多账号零串扰，直连架构保证没有隐藏的数据出口。对于希望在自有服务器上把"多模态生成能力 + 数据主权"握在自己手里的用户来说，这套架构是一个值得参考的"本地全量持久化"样本。

⚖️ 合规提示：本项目仅供技术交流、自动化运维研究与自动化测试，请勿用于违反 Muse 平台服务条款或相关法律法规的用途。