{"release":{"tag":{"name":"0.2.2","path":"/sofqi/SyncHub/tags/0.2.2","tree_path":"/sofqi/SyncHub/tree/0.2.2","message":"","commit":{"id":"1f189bb2f71f5320bca1159a7bbb479a92202c4c","short_id":"1f189bb","title":"feat(sync): 面板每一行加「放弃更改」","title_markdown":"feat(sync): 面板每一行加「放弃更改」","description":"\n用户原话：「插件侧边栏面板中的更改，应该提供恢复的按钮，等于放弃更改」。\n\n这正好补上上一轮那个缺口的反面：面板曾经**只有**「暂存」这类**不生效**的动作，\n却**没有**一个「把改动退回去」的**真动作**。\n\n## 一个动作覆盖两种场景\n\n`git restore --source=HEAD --staged --worktree` —— 它们在 git 眼里是同一件事：\n\n- **改坏了想退回**：工作区那份被上次提交的版本覆盖；\n- **误删了想找回**：工作区里没有这个文件，于是它被**重新写出来**（最值钱的那一半）。\n\n**两个 `--` 都要给**：只给 `--worktree` 的话索引里那份改动还在，下一次 `git status`\n会显示「已暂存的更改」—— 而用户点的是「放弃更改」，他期待的是彻底回到原样。\n分批下发（与 `untrack` 同一个理由：一次几千个路径会撞上命令行长度上限）。\n\n## 两类行不给这个入口\n\n1. **未跟踪的新文件** —— 没有「上次提交」可退（`git restore` 会以\n   「pathspec did not match」失败），而「放弃」对它们实际等于**删掉一个新文件**：\n   丢的东西一点退路都没有，不该混进这个入口。\n2. **冲突行** —— 冲突区已经有「放弃本次合并」；而且面板看不到文件内容，\n   在这里替用户决定「用哪一边」正是不该做的事。\n\n## 唯一会丢用户编辑的动作，所以确认不能省\n\n放弃的编辑**从来没被提交过**，不在 git 里，`git fsck` 也找不回来 —— 本插件别的\n破坏性动作（退出跟踪、停止跟踪本地状态文件、深度清理）都还能退，只有这一个不能。\n`ConfirmDiscardChangesModal` 因此：列出**具体哪几个文件**（不是一句「确定吗」）、\n把「不可逆」写在正文里、确认按钮 `setWarning()`。文案里顺带提一句\n「文件恢复若开着可能还有快照，但别指望它」—— 那是用户此刻唯一的退路，\n而它按 5 分钟节流，**不能承诺**。\n\n## 验证\n\n真仓库三条（退回改动 + **找回误删** + 只动传进去的路径，证明一次误伤就是丢内容）、\n服务层两条（走队列、索引与工作区**两处**都退）、面板两条（哪些行有按钮 /\n点下去先弹确认且弹窗列出文件名）。`pnpm check` 八项全过、`typecheck`、`lint:review`、\n`pnpm test` **93 文件 1982 用例全绿**、`build:both` 部署两库（三产物 SHA256 一致）、\n`verify:mobile` 无加载期抛错。","description_markdown":"用户原话：「插件侧边栏面板中的更改，应该提供恢复的按钮，等于放弃更改」。 这正好补上上一轮那个缺口的反面：面板曾经\u003Cstrong\u003E只有\u003C/strong\u003E「暂存」这类\u003Cstrong\u003E不生效\u003C/strong\u003E的动作，\n却\u003Cstrong\u003E没有\u003C/strong\u003E一个「把改动退回去」的\u003Cstrong\u003E真动作\u003C/strong\u003E。\n## 一个动作覆盖两种场景\n\u003Ccode\u003Egit restore --source=HEAD --staged --worktree\u003C/code\u003E —— 它们在 git 眼里是同一件事：\n- \u003Cstrong\u003E改坏了想退回\u003C/strong\u003E：工作区那份被上次提交的版本覆盖；\n- \u003Cstrong\u003E误删了想找回\u003C/strong\u003E：工作区里没有这个文件，于是它被\u003Cstrong\u003E重新写出来\u003C/strong\u003E（最值钱的那一半）。\n\u003Cstrong\u003E两个 \u003Ccode\u003E--\u003C/code\u003E 都要给\u003C/strong\u003E：只给 \u003Ccode\u003E--worktree\u003C/code\u003E 的话索引里那份改动还在，下一次 \u003Ccode\u003Egit status\u003C/code\u003E\n会显示「已暂存的更改」—— 而用户点的是「放弃更改」，他期待的是彻底回到原样。\n分批下发（与 \u003Ccode\u003Euntrack\u003C/code\u003E 同一个理由：一次几千个路径会撞上命令行长度上限）。\n## 两类行不给这个入口\n1. \u003Cstrong\u003E未跟踪的新文件\u003C/strong\u003E —— 没有「上次提交」可退（\u003Ccode\u003Egit restore\u003C/code\u003E 会以\n「pathspec did not match」失败），而「放弃」对它们实际等于\u003Cstrong\u003E删掉一个新文件\u003C/strong\u003E：\n丢的东西一点退路都没有，不该混进这个入口。\n2. \u003Cstrong\u003E冲突行\u003C/strong\u003E —— 冲突区已经有「放弃本次合并」；而且面板看不到文件内容，\n在这里替用户决定「用哪一边」正是不该做的事。\n## 唯一会丢用户编辑的动作，所以确认不能省\n放弃的编辑\u003Cstrong\u003E从来没被提交过\u003C/strong\u003E，不在 git 里，\u003Ccode\u003Egit fsck\u003C/code\u003E 也找不回来 —— 本插件别的\n破坏性动作（退出跟踪、停止跟踪本地状态文件、深度清理）都还能退，只有这一个不能。\n\u003Ccode\u003EConfirmDiscardChangesModal\u003C/code\u003E 因此：列出\u003Cstrong\u003E具体哪几个文件\u003C/strong\u003E（不是一句「确定吗」）、\n把「不可逆」写在正文里、确认按钮 \u003Ccode\u003EsetWarning()\u003C/code\u003E。文案里顺带提一句\n「文件恢复若开着可能还有快照，但别指望它」—— 那是用户此刻唯一的退路，\n而它按 5 分钟节流，\u003Cstrong\u003E不能承诺\u003C/strong\u003E。\n## 验证\n真仓库三条（退回改动 + \u003Cstrong\u003E找回误删\u003C/strong\u003E + 只动传进去的路径，证明一次误伤就是丢内容）、\n服务层两条（走队列、索引与工作区\u003Cstrong\u003E两处\u003C/strong\u003E都退）、面板两条（哪些行有按钮 /\n点下去先弹确认且弹窗列出文件名）。\u003Ccode\u003Epnpm check\u003C/code\u003E 八项全过、\u003Ccode\u003Etypecheck\u003C/code\u003E、\u003Ccode\u003Elint:review\u003C/code\u003E、\n\u003Ccode\u003Epnpm test\u003C/code\u003E \u003Cstrong\u003E93 文件 1982 用例全绿\u003C/strong\u003E、\u003Ccode\u003Ebuild:both\u003C/code\u003E 部署两库（三产物 SHA256 一致）、\n\u003Ccode\u003Everify:mobile\u003C/code\u003E 无加载期抛错。","message":"feat(sync): 面板每一行加「放弃更改」\n\n用户原话：「插件侧边栏面板中的更改，应该提供恢复的按钮，等于放弃更改」。\n\n这正好补上上一轮那个缺口的反面：面板曾经**只有**「暂存」这类**不生效**的动作，\n却**没有**一个「把改动退回去」的**真动作**。\n\n## 一个动作覆盖两种场景\n\n`git restore --source=HEAD --staged --worktree` —— 它们在 git 眼里是同一件事：\n\n- **改坏了想退回**：工作区那份被上次提交的版本覆盖；\n- **误删了想找回**：工作区里没有这个文件，于是它被**重新写出来**（最值钱的那一半）。\n\n**两个 `--` 都要给**：只给 `--worktree` 的话索引里那份改动还在，下一次 `git status`\n会显示「已暂存的更改」—— 而用户点的是「放弃更改」，他期待的是彻底回到原样。\n分批下发（与 `untrack` 同一个理由：一次几千个路径会撞上命令行长度上限）。\n\n## 两类行不给这个入口\n\n1. **未跟踪的新文件** —— 没有「上次提交」可退（`git restore` 会以\n   「pathspec did not match」失败），而「放弃」对它们实际等于**删掉一个新文件**：\n   丢的东西一点退路都没有，不该混进这个入口。\n2. **冲突行** —— 冲突区已经有「放弃本次合并」；而且面板看不到文件内容，\n   在这里替用户决定「用哪一边」正是不该做的事。\n\n## 唯一会丢用户编辑的动作，所以确认不能省\n\n放弃的编辑**从来没被提交过**，不在 git 里，`git fsck` 也找不回来 —— 本插件别的\n破坏性动作（退出跟踪、停止跟踪本地状态文件、深度清理）都还能退，只有这一个不能。\n`ConfirmDiscardChangesModal` 因此：列出**具体哪几个文件**（不是一句「确定吗」）、\n把「不可逆」写在正文里、确认按钮 `setWarning()`。文案里顺带提一句\n「文件恢复若开着可能还有快照，但别指望它」—— 那是用户此刻唯一的退路，\n而它按 5 分钟节流，**不能承诺**。\n\n## 验证\n\n真仓库三条（退回改动 + **找回误删** + 只动传进去的路径，证明一次误伤就是丢内容）、\n服务层两条（走队列、索引与工作区**两处**都退）、面板两条（哪些行有按钮 /\n点下去先弹确认且弹窗列出文件名）。`pnpm check` 八项全过、`typecheck`、`lint:review`、\n`pnpm test` **93 文件 1982 用例全绿**、`build:both` 部署两库（三产物 SHA256 一致）、\n`verify:mobile` 无加载期抛错。\n","message_markdown":"feat(sync): 面板每一行加「放弃更改」\n用户原话：「插件侧边栏面板中的更改，应该提供恢复的按钮，等于放弃更改」。\n这正好补上上一轮那个缺口的反面：面板曾经\u003Cstrong\u003E只有\u003C/strong\u003E「暂存」这类\u003Cstrong\u003E不生效\u003C/strong\u003E的动作，\n却\u003Cstrong\u003E没有\u003C/strong\u003E一个「把改动退回去」的\u003Cstrong\u003E真动作\u003C/strong\u003E。\n## 一个动作覆盖两种场景\n\u003Ccode\u003Egit restore --source=HEAD --staged --worktree\u003C/code\u003E —— 它们在 git 眼里是同一件事：\n- \u003Cstrong\u003E改坏了想退回\u003C/strong\u003E：工作区那份被上次提交的版本覆盖；\n- \u003Cstrong\u003E误删了想找回\u003C/strong\u003E：工作区里没有这个文件，于是它被\u003Cstrong\u003E重新写出来\u003C/strong\u003E（最值钱的那一半）。\n\u003Cstrong\u003E两个 \u003Ccode\u003E--\u003C/code\u003E 都要给\u003C/strong\u003E：只给 \u003Ccode\u003E--worktree\u003C/code\u003E 的话索引里那份改动还在，下一次 \u003Ccode\u003Egit status\u003C/code\u003E\n会显示「已暂存的更改」—— 而用户点的是「放弃更改」，他期待的是彻底回到原样。\n分批下发（与 \u003Ccode\u003Euntrack\u003C/code\u003E 同一个理由：一次几千个路径会撞上命令行长度上限）。\n## 两类行不给这个入口\n1. \u003Cstrong\u003E未跟踪的新文件\u003C/strong\u003E —— 没有「上次提交」可退（\u003Ccode\u003Egit restore\u003C/code\u003E 会以\n「pathspec did not match」失败），而「放弃」对它们实际等于\u003Cstrong\u003E删掉一个新文件\u003C/strong\u003E：\n丢的东西一点退路都没有，不该混进这个入口。\n2. \u003Cstrong\u003E冲突行\u003C/strong\u003E —— 冲突区已经有「放弃本次合并」；而且面板看不到文件内容，\n在这里替用户决定「用哪一边」正是不该做的事。\n## 唯一会丢用户编辑的动作，所以确认不能省\n放弃的编辑\u003Cstrong\u003E从来没被提交过\u003C/strong\u003E，不在 git 里，\u003Ccode\u003Egit fsck\u003C/code\u003E 也找不回来 —— 本插件别的\n破坏性动作（退出跟踪、停止跟踪本地状态文件、深度清理）都还能退，只有这一个不能。\n\u003Ccode\u003EConfirmDiscardChangesModal\u003C/code\u003E 因此：列出\u003Cstrong\u003E具体哪几个文件\u003C/strong\u003E（不是一句「确定吗」）、\n把「不可逆」写在正文里、确认按钮 \u003Ccode\u003EsetWarning()\u003C/code\u003E。文案里顺带提一句\n「文件恢复若开着可能还有快照，但别指望它」—— 那是用户此刻唯一的退路，\n而它按 5 分钟节流，\u003Cstrong\u003E不能承诺\u003C/strong\u003E。\n## 验证\n真仓库三条（退回改动 + \u003Cstrong\u003E找回误删\u003C/strong\u003E + 只动传进去的路径，证明一次误伤就是丢内容）、\n服务层两条（走队列、索引与工作区\u003Cstrong\u003E两处\u003C/strong\u003E都退）、面板两条（哪些行有按钮 /\n点下去先弹确认且弹窗列出文件名）。\u003Ccode\u003Epnpm check\u003C/code\u003E 八项全过、\u003Ccode\u003Etypecheck\u003C/code\u003E、\u003Ccode\u003Elint:review\u003C/code\u003E、\n\u003Ccode\u003Epnpm test\u003C/code\u003E \u003Cstrong\u003E93 文件 1982 用例全绿\u003C/strong\u003E、\u003Ccode\u003Ebuild:both\u003C/code\u003E 部署两库（三产物 SHA256 一致）、\n\u003Ccode\u003Everify:mobile\u003C/code\u003E 无加载期抛错。","detail_path":"/sofqi/SyncHub/commit/1f189bb2f71f5320bca1159a7bbb479a92202c4c","commits_path":"/sofqi/SyncHub/commits/1f189bb2f71f5320bca1159a7bbb479a92202c4c","tree_path":"/sofqi/SyncHub/tree/1f189bb2f71f5320bca1159a7bbb479a92202c4c","author":{"name":"烛知知","email":"790493242@qq.com","username":"sofqi","user_path":"/sofqi","enterprise_user_path":null,"image_path":"https://foruda.gitee.com/avatar/1792083584838973630/10322477_sofqi_1792083584.png!avatar30","is_gitee_user":true,"is_enterprise_user":null,"widget_url":""},"committer":{"name":"烛知知","email":"790493242@qq.com","username":"sofqi","user_path":"/sofqi","enterprise_user_path":null,"image_path":"https://foruda.gitee.com/avatar/1792083584838973630/10322477_sofqi_1792083584.png!avatar30","is_gitee_user":true,"is_enterprise_user":null,"widget_url":""},"authored_date":"2026-10-10T03:00:04+08:00","committed_date":"2026-10-10T03:00:04+08:00","signature":null,"build_state":null},"archive_path":"/sofqi/SyncHub/repository/archive/0.2.2","signature":null},"operating":{"edit":false,"download":true,"destroy":false,"enterprise_forbid_zip":false},"release":{"title":"0.2.2","path":"/sofqi/SyncHub/releases/tag/0.2.2","tag_path":"/sofqi/SyncHub/tree/0.2.2","project_id":50398986,"created_at":"2026-10-10T03:06:27+08:00","is_prerelease":false,"description":"这一版做两件事：**别让大文件进 git**（两层预防），以及**已经大了怎么办**（清理）。\n起因是一次实测：一个 159 次提交的笔记库有 460 MB 的 `.git`，其中插件构建产物 319 MB、\n字体 186 MB、向量库缓存 84 MB，而真正的 markdown 只有 63 MB —— 仓库体积失控几乎从来\n不是笔记造成的。而 **git 的历史不可逆**：大文件一旦提交进去，事后清理要重写全部提交，\n那是一件按提交数计时的重活。所以预防建在「它进历史之前」，清理则是一套独立的、\n把代价说在前面的动作。\n\n\u003E 还有一条**独立的轴**：重写历史的开销**只吃提交数**，与每个提交改了多少字节无关 ——\n\u003E 20 MB 但有 10000 个「只改一行」的提交，重写要几小时；500 MB 但只有 200 个提交，\n\u003E 只要十几分钟。所以「本地状态文件」（光标位置缓存、工作区布局）进 git 的代价\n\u003E **不是体积，而是每个同步周期白多一个提交**。大文件拦截防不了这一条。\n\n### 新增\n\n- **清理：体检 / 回收 / 深度清理**（设置页「仓库同步」的**清理**一节）。三层风险递增，\n  每一层都说清代价：\n  - **体检**（只读）—— 按**目录**汇总历史里占空间最多的部分，外加最大的单个对象。\n    按目录而不是按文件，是因为**剔除的单位就是目录**：报告里的每一行正好是一个\n    可以拿去执行的动作。库根目录的文件只报账、不提供勾选（剔掉它们等于清空整个库）。\n  - **回收空间** —— `git gc --prune=now`。安全，但**常常一点也回收不到**：大文件基本\n    都在可达的历史里，只有重写才能清掉。这句话写在描述里，免得你把「没变小」当成功能坏了。\n  - **深度清理**（**不可逆**）—— 把选中的路径从**全部历史**里剔除（重写每一个提交）。\n    动手前会把三件事摆出来：**所有提交的哈希都会变**（远端要强制推送、其他设备要重新\n    clone）、**已经推到远端的旧历史清不掉**、以及**预计耗时**（按提交数算，实测约\n    3.5 秒/提交 —— 一个 159 提交的库约 10 分钟，期间请不要关闭 Obsidian）。\n    执行前**先建一个备份引用**（`refs/obsync-backup/\u003C时间戳\u003E`），失败或后悔都能退回去；\n    执行后**自动把那几条路径写进 `.gitignore`**，否则它们会在下次提交时原样回来。\n  - **丢弃备份并回收** —— 重写之后空间**不会立刻变小**（备份还拉着旧对象，这是刻意的：\n    先让你确认库还能用，再丢退路）。确认无误后点它，才真正释放空间。**不可逆。**\n- **提交前的大文件拦截**（设置页「仓库同步」的**大文件阈值**，默认 **5 MB**，填 `0` 关闭）。\n  提交 / 立即同步时，待提交文件里**超过阈值**的会被拦下、**弹窗问一次**，整条链路停在\n  那里 —— 不会出现「同步完成」而那个文件其实没提交。弹窗把两个选择各自的**代价**都写清楚了：\n  **仍然提交**（它以后每次改动都会在历史里再存一份完整副本）或**退出跟踪并忽略**\n  （不再有版本历史、本地文件保留；**历史里已有的副本不会消失**，仓库体积不会因此变小）。\n  关掉弹窗 = 取消。**自动同步不弹窗**，改为发一条通知告诉你「同步已暂停、去哪处理」。\n- **「补齐推荐的忽略规则」按钮**（设置页「仓库同步」的 `.gitignore` 一节）——\n  把字体（`ttf/ttc/otf/woff/woff2`，大小写各一条）、Office / LibreOffice 临时文件\n  （`~$*`、`.~lock.*#`）、**本地状态文件**（`workspace.json`、`workspace-mobile.json`、\n  `workspaces.json`、`*-position-cache.json`）这几类规则并进 `.gitignore`。\n  **只追加缺的那些，你自己写的规则一行都不动**，可以随手点（幂等）。\n  它与那个**覆盖式**的「填入默认内容」是两回事。\n- **「停止跟踪本地状态文件」按钮**（同一节）—— 光加忽略规则**对已经跟踪的文件没用**\n  （`.gitignore` 只管未跟踪的），而已经同步了一阵子的库恰恰是最需要它的。这个按钮\n  把已跟踪的那几个从索引里摘掉（**本地文件不动**），并补上忽略规则。会先让你看见\n  要摘哪几个再确认。\n- **「忽略插件目录」开关**（默认**关**）—— 打开后把整个插件目录也加进推荐规则。\n  插件是仓库体积最大的单一来源，但**忽略之后换设备 clone 时插件不会自动就位**，得重新装。\n  这是个取舍，所以做成开关交给你，而不是替你选。\n- **面板每一行的「放弃更改」**（仓库同步面板的「更改」列表，2026-10-10）——\n  一键把那个文件退回上次提交的样子。两种场景共用一个动作，因为它们在 git 眼里是同一件事：\n  **改坏了想退回**、以及**误删了想找回**（被删的文件会从上次提交里重新写出来）。\n  它是本插件**唯一会丢用户编辑**的动作，而且**不可逆**（放弃的编辑从来没被提交过、\n  不在 git 里），所以：确认弹窗会**列出具体哪几个文件**、把「不可逆」写在正文里、\n  确认按钮用警示色。两类行**不给**这个入口：**未跟踪的新文件**（它们没有「上次提交」\n  可退，而「放弃」对它们等于删掉一个新文件 —— 丢的东西一点退路都没有）、\n  **冲突行**（冲突区已经有「放弃本次合并」，而面板看不到文件内容，\n  在这里替用户决定「用哪一边」正是不该做的事）。\n- **「文件恢复关着」的警告框**（仓库同步页**最上方**，**只在它关着时才出现**）——\n  Obsidian 的「文件恢复」核心插件默认每 5 分钟给每个改过的文件存一份快照、保留 7 天，\n  存在 IndexedDB 里，**完全不碰 git**。它才是「高频防丢失」该用的机制：git 的恢复粒度是\n  **全库提交**，用它做高频恢复会让提交数等于编辑次数。所以想靠缩短同步间隔来防丢数据时，\n  这个警告框会先把你指到那里。（第一版是塞进「注意事项」的一条，太不显眼 ——\n  它讲的是数据安全，现在有独立的警告配色与标题。）\n\n### 变更\n\n- **定时同步的默认周期 10 分钟 → 30 分钟**（只影响新装的库与缺这个字段的库，\n  已经存过这个值的库不受影响）。理由：高频保护已经明确交给「文件恢复」，定时同步剩下的\n  职责是「云端新鲜度」与「跨设备」，而灾难恢复本身要花几小时 —— 丢 30 分钟与丢 5 分钟\n  没有实际差别。反过来，间隔越短提交数越线性增长，而重写历史的开销只吃提交数。\n  想让云端更实时请用「立即同步」（命令 / 面板 / 功能区都有）。\n- **去掉了仓库同步面板上的逐文件暂存**（「暂存此文件 / 取消暂存」与「全部暂存 /\n  全部取消暂存」）—— 它们**做不到看起来在做的事**：SyncHub 的「提交」是 `git add -A`，\n  手动暂存了什么**对最终提交毫无影响**；更要紧的是**定时同步到点会把它们一起提交掉**，\n  也就是说这个按钮**连「暂时不提交」都做不到**。用户暂存 A 想只提交 A，结果 B 一起进去了。\n  **SyncHub 不做选择性提交** —— 它的定位是「把整个库同步上去」。按暂存状态的**分组**保留\n  （冲突文件落在「已暂存」那一组）。\n- **自动同步被大文件拦下时会给一条通知**（以前是静默停住）。只要那些文件还在，自动同步\n  就一直停着 —— 这条通知是它唯一的表现，所以每次到点都会提示一次。\n- **文案口径改了**：「已经写进历史的图片 / 文件不会让仓库变小」那几处，以前一律接\n  「本插件不做重写历史」—— 现在指向设置页「清理」里的**深度清理**。\n\n### 修复\n\n- **设置页里 `.gitignore` 代码框的全宽失效了。** 它那条 `width: 100%` 被 CSS 解析器\n  **整条丢弃**：上面那句注释里写了 `` `**/` 递归 ``，而 `**/` 里的 `*/` **提前结束了注释**，\n  剩下的文字被当成下一条规则的选择器，于是规则连同它一起被丢掉 —— 不报错、样式就是不生效。\n  代码框因此只有 173px 宽（容器 660px）。同一段注释里 `min-height`、`white-space`、\n  `padding` 也一起失效了。\n  `pnpm check` 新增第 8 项**CSS 注释完整性**守住这类问题：现有「CSS 类覆盖」那一项拦不住它\n  （被丢弃的规则在文本上仍然「有定义」）。","author":{"name":"烛知知","username":"sofqi","path":"/sofqi","avatar_url":"https://foruda.gitee.com/avatar/1792083584838973630/10322477_sofqi_1792083584.png!avatar30"},"attach_files":[{"download_url":"/sofqi/SyncHub/attach_files/3351518/download/main.js","name":"main.js","cli_download_url":"https://gitee.com/sofqi/SyncHub/releases/download/0.2.2/main.js","censor_failed":false,"censor_tip":null},{"download_url":"/sofqi/SyncHub/attach_files/3351519/download/manifest.json","name":"manifest.json","cli_download_url":"https://gitee.com/sofqi/SyncHub/releases/download/0.2.2/manifest.json","censor_failed":false,"censor_tip":null},{"download_url":"/sofqi/SyncHub/attach_files/3351520/download/styles.css","name":"styles.css","cli_download_url":"https://gitee.com/sofqi/SyncHub/releases/download/0.2.2/styles.css","censor_failed":false,"censor_tip":null}],"zip_download_url":"/sofqi/SyncHub/releases/tag/0.2.2.zip","tar_download_url":"/sofqi/SyncHub/releases/tag/0.2.2.tar.gz"}}}