# 参考仓库分析记录

## 仓库一：dreammis/social-auto-upload

- 地址：<https://github.com/dreammis/social-auto-upload>
- 本地：`references/social-auto-upload`
- HEAD：`1c66b7d`
- 许可证：MIT（`LICENSE`）
- 形态：Python CLI + Playwright/Patchright uploader，Web 不是当前主线。
- 可借鉴：文件/时间校验、平台参数契约、二维码处理、profile/cookie/upload 抽象。
- 不能直接照搬：依赖版本、账号路径、全局配置和平台选择器必须经过 workspace/account/task 隔离。

## 仓库二：DevilJie/social-auto-upload-web-ui

- 地址：<https://github.com/DevilJie/social-auto-upload-web-ui>
- 本地：`references/social-auto-upload-web-ui`
- HEAD：`85e783c`
- 许可证：MIT（`LICENSE`）
- 形态：Vue 3 + Element Plus + Flask + SQLite + 本地任务 worker + SSE；19 平台 Registry。
- 可借鉴：统一平台接口、Registry、`/login` SSE、Cookie 导入四步状态机、异步 `/postVideo`、任务状态轮询、草稿批量发布和分片上传。
- 关键调用链：`backend/app.py:672-708` 登录 SSE；`backend/app.py:719-847` Cookie 导入与 stream；`backend/impl/base_platform.py:188-355` 解析→临时文件→sync_profile→写账号；`backend/app.py:961-1154` 视频入队/状态查询；`backend/services/publish_executor.py:1-170` 单 worker；`backend/ext_api/task_queue.py:28-55,161-330` v2 多 worker；`backend/blueprints/uploads_bp.py:100-430` 可续传分片；`backend/ext_api/__init__.py:831-975,1219-1375` 草稿与批量发布。
- 风险：单 worker 状态有内存 TTL，v2 是另一套队列；二维码消息格式不统一；图文接口同步执行且缺资源可能占位成功；素材删除的 storage backend 选择不一致；TaskCenter 的中文状态过滤与英文后端状态可能不匹配。EveryPublish 只借鉴协议/状态思想，统一到 MySQL Task/TaskEvent 和 Go dispatcher。

## 仓库三：funfan0517/MediaPublishPlatform

- 地址：<https://github.com/funfan0517/MediaPublishPlatform>
- 本地：`references/MediaPublishPlatform`
- HEAD：`0813236`
- 许可证：MIT（`LICENSE`，版权归 funfan0517）
- 形态：Flask + SQLite + Playwright + Vue 3/Element Plus + Pinia；这是用户描述的“Media/Medium Publish Platform”候选仓库。
- 后端入口：`sau_backend/sau_backend.py`。文件 `/uploadSave`，素材 `/getFiles`，账号 `/getAccounts`/`/getValidAccounts`，登录 `/login`（SSE），发布 `/postVideo`、`/postVideosToMultiplePlatforms`，记录 `/getPublishTaskRecords`，重试 `/retryPublishTask`，取消 `/cancelPublishTask`。
- 上传核心：`newFileUpload/baseFileUploader.py` 统一处理 profile/cookie、文件类型、标题/正文/标签/封面/地点/定时；`multiFileUploader.py` 按文件→平台→账号串行尝试，账号失败后切换下一个账号。
- 平台配置：`newFileUpload/platform_configs.py` 以字典保存 URL、选择器和功能开关；新增平台主要改配置，但选择器仍是平台强耦合代码。
- 登录：`myUtils/login.py` 启动可视 Chrome，等待 URL 离开 login 页面后保存 `storage_state`；线程 + `Queue` 通过 SSE 推送状态。
- 数据模型：`db/createTable.py` 只有 `user_info`、`file_records`、`publish_task_records`，没有 workspace、角色、幂等键、状态事件或凭据加密层。
- 不能直接复制：全局 CORS、SQLite 并发限制、cookie 明文文件、错误 `code` 不统一、简单路径检查、发布记录与执行状态分离。EveryPublish 只借鉴页面信息架构、参数契约、profile、SSE 状态思想和平台配置表。

## 真实缺陷清单（参考代码审计）

| 项目 | 缺陷 | 当前迁移策略 |
|---|---|---|
| MediaPublishPlatform | 无鉴权、CORS 全开、Cookie/文件接口可越权 | JWT + workspace 条件 + 加密凭据，绝不返回 Cookie |
| MediaPublishPlatform | URL 离开 login 即判登录成功、SSE 无可靠断开 | adapter 明确状态码/响应 schema，context 可取消，挑战持久化 |
| MediaPublishPlatform | 同步 Playwright、retry/cancel 只改数据库、批次粗粒度成功 | Dispatcher context + TaskEvent + 逐账号结果 |
| 两个参考项目 | 定时参数类型/位置错位、平台 schedule feature 常关闭 | 当前任务使用毫秒时间戳，adapter 明确支持/拒绝 |
| social-auto-upload-web-ui | 单线程内存队列和 v2 队列并存 | EveryPublish 只保留一个持久化任务状态机 |
| social-auto-upload-web-ui | 纯字符串/JSON 混合 SSE、图文缺资源仍可能成功 | Browser WS envelope + 非空结果/错误分类硬校验 |

## 三个参考系统的关系

```text
dreammis/social-auto-upload
  └─ 平台 uploader、Playwright、cookie/profile、CLI 参数
       ├─ DevilJie/social-auto-upload-web-ui
       │    └─ Flask Registry、SSE 登录、异步发布任务和 Web 页面
       └─ funfan0517/MediaPublishPlatform
            └─ 统一 BaseFileUploader、批量账号轮换、定时发布、发布记录

EveryPublish Web-only V1
  └─ Go REST/JWT/GORM + MySQL/Redis + Browser WS
       ├─ 统一平台参数和浏览器 profile 思路
       ├─ SSE 状态转换为 DB Challenge + Browser WS
       ├─ SQLite 任务记录转换为 Task + TaskEvent 状态机
       ├─ 批量账号轮换/定时参数进入任务请求和调度器
       └─ 每个平台 adapter 独立实现和测试
```

## 合并策略

```text
参考仓库（只读）
   ├─ 平台参数/登录/上传思路 ──> PlatformAdapter 接口
   ├─ SSE/任务队列思路 ────────> Browser WS + DB 状态
   ├─ 批量账号轮换/定时参数 ───> 当前任务请求和调度器
   └─ 页面信息架构 ────────────> 当前 React + TDesign 页面
```

不会把 Vue/Flask/SQLite 整套替换当前工程；这会造成三套认证、数据模型和部署入口。当前工程只吸收可验证的领域逻辑，并在每个 adapter 的文件头标注来源和 MIT 许可。真实平台选择器必须经过用户授权和人工扫码验收，不能用 mock 结果代替真实成功。