zqlit/blog
1
0 Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
1,010 Commits 1 Branch 2 Tags
af1bbf9c1e4c3f6507a0125d60c1049c2e6240db
Commit Graph
5 Commits
Author SHA1 Message Date
zqlit af1bbf9c1e chore(远端): 彻底剔除 GitHub —— 删除已退役的 GitHub Actions 定义 
用户明确「GitHub 现在整改，不能再作为备份库」，据此把 GitHub 从本项目
所有环节清干净。上一轮（b39dc297）已完成 remote / 推送别名 / 发布链路的
去 GitHub 化，本轮清掉最后一块实体：CI 定义。

- 删除整个 `.github/` 目录（3 个文件、共 1268 行）：
    deploy.yml          1169 行  原主构建发布流水线（已由 .cnb.yml 接管）
    aliyun-backup.yml     54 行  备份到阿里云 OSS
    cleanup.yml           45 行  清理 artifacts / cache
  已确认无任何脚本、配置或流水线引用它们（全仓只有 .cnb.yml 的注释提过 deploy.yml）。
  实现完整保留在 git 历史里，需要时可翻。

同步更新引用它们的注释与文档（否则会指向不存在的文件）：
- `.cnb.yml` 头部：说明原流水线已删除、要查旧实现请翻 git 历史；
  去掉「见 deploy.yml 第 290 行」这类失效指向
- `CNB构建落地方案.md`：
    §4.0 标题「CNB 主仓 + GitHub 备份」→「+ 辅仓备份」
    §pushurl 缺陷论证里「GitHub 那份备份」→「辅仓那份备份」
    §敏感文件：「已核实 github.com 返回 Page not found」→ 更新为
      账号被标记 + 仓库被 AUP 清空，该威胁面已消失
    §历史清理的判断已变：当初不做的唯一顾虑（备份会分叉）已随 GitHub 消失，
      filter-repo 现在是可行窗口（代价：SHA 全变、自建 Gitea 需重推）
- `架构总览.md`：§5.1 标注当前实际只用 `git push origin main`（gitee remote 未建）；
  §6 #1 改写为「GitHub 已彻底退出备份体系」、#5 由「可删」改为「已删除」；
  末尾「已退役参考」改为「已删除，可翻 git 历史」
- `README.md`：脚本表补上 `backup-bundle.mjs` / `backup-task.cmd`；
  `setup-cnb-remotes.sh` 的说明去掉 GitHub
 2026-10-06 21:11:48 +08:00
zqlit 8abe93d17a feat(backup): 整仓离线备份上线 —— bundle 加密后传中兴 F50 上的 OpenList 
背景：GitHub 被按 AUP 清空后，用户提出自己的中兴 F50（5G CPE + 内置 256GB）
上跑着 OpenList，想用它当第三层备份。实测可行，已落地并跑通。

为什么是 bundle 而不是直接推 git：
  WebDAV 不支持原子的 rename/lock，bare repo 挂上去 push 会让对象写坏 ——
  表面成功、实际随机损坏，可能几个月后才发现。bundle 是单文件顺序写，安全。

为什么加密（用户一度想省掉）：
  历史里含 .env、TLS 私钥、GITEA_SECRETS.md。介质是随身设备的内部存储，
  明文 = 把密钥放在一台可能丢失/刷机/送修的机器上。
  OpenList 的登录只保护「访问通道」，不保护「存储介质」——拆机就能读。
  加密成本实测仅 1.9~2.9 秒、体积不变；且 CNB/Gitea 仍是明文副本，
  口令丢失只是少一份备份，不构成单点。

实现（scripts/backup-bundle.mjs，零 npm 依赖）：
  - git bundle create --all → AES-256-GCM（Node 内置 crypto）
  - 布局 magic(8)|salt(16)|iv(12)|密文|tag(16)，scrypt(N=32768,r=8,p=1) 派生密钥
  - 为什么不用 gpg：本机 gpg 2.4.9 在 Windows 下已损坏（反复 stale lockfile，
    node spawn 直接 EBUSY）；换内置 crypto 后零外部依赖且带认证标签
  - 上传后可选 --verify：下载回来比对 sha256，端到端闭环
  - --keep 控制远端保留份数；--decrypt 恢复；--list 盘点；--dry 不上传

定时任务（scripts/backup-task.cmd + Windows 计划任务 Blog-BundleBackup）：
  - 每天 03:30 本地时间，默认 --verify --keep 3
  - InteractiveToken + LeastPrivilege、StartWhenAvailable、1h 超时、IgnoreNew 防重入
  - 日志追加到 .workbuddy-backup/logs/backup.log，超 5MB 轮转

★ backup-task.cmd 内容必须全 ASCII：
  cmd.exe 按当前代码页（zh-CN 是 GBK）解析批处理文件，而 node 输出 UTF-8。
  UTF-8 中文注释会吞掉 CR/LF 并把下一行当命令执行 —— 实测踩到（一条 rem 被当命令跑）。
  ASCII 是 UTF-8 子集，纯英文注释与 node 的中文输出混写不会乱。
  同理不能用 %date%（含本地化星期），改用系统时间 API 取 ISO 格式时间。
  日志轮转的 for 语句必须加 if exist 守卫，否则首次运行报「系统找不到指定的路径」。

实测（由计划任务实际拉起，非手工执行）：
  bundle 6.8~9.9s（605.5MB）/ 加密 1.9~2.9s / 上传 19.4~20.6s（29.4~31.3 MB/s）
  / 下载回读 sha256 一致，端到端退出码 0
  恢复链路已演练：--decrypt → git bundle verify 报 "records a complete history"
  → 1008 提交完整一致

文档（架构总览.md）：
  - §5.3 从「Gitee 两条硬约束」扩写为「辅仓选型」，补入云效 Codeup 基础版对照
    （Git 5GiB + 单文件命令行 200MB）—— 选它则 bin/linux/hugo 不必出库、
    构建链路一行不用改
  - 新增 §5.6 整仓离线备份（介质 / 为什么 bundle / 为什么加密 / 加密格式 / 用法 /
    配置 / 定时任务 / 恢复流程 / 实测数据）
  - §6 待办：#2 改为「辅仓选型未定」并说明 pushall 现状；#3 标注只有选 Gitee 才必须做；
    #9 补记「不改写历史」的唯一障碍已随 GitHub 消失；新增 #10 备份已上线 + 三项安全待办
 2026-10-06 21:03:29 +08:00
zqlit b39dc29753 chore(远端): 移除 GitHub，改为「CNB 主仓 + Gitee 辅仓」 
起因：GitHub 账号被平台标记，随后仓库被按 AUP 合规条款清空 ——
远端只剩一条孤立提交（无父提交、无内容）：

    c21d5669  2026-10-06 20:08:32 +0800  zqlit
    chore: remove repository content (AUP compliance)

同时远端 main 的历史与本地**完全分叉**：两边只共享 2024-07-11 的 Initial commit，
之后每个提交 SHA 都不同（远端那份 989 提交、剥离了 .env/私钥/大二进制）。
所以 `git push gh main` 无法快进，也不可能再当备份用。

改动：

- `git remote remove gh`（改动前配置存 .workbuddy-backup/git-remotes.20261006-201354.txt）
- `pushall` 别名 → `git push origin main; git push gitee main`
- `scripts/setup-cnb-remotes.sh`：参数化第二个远端为 Gitee，
  顺带把「若残留 gh remote 就清掉」做进脚本；Gitee 凭据走 wincred
- `架构总览.md`：§2 发布旅程图、§5.2 远端表、§6 遗留待办全部改指向；
  新增 §5.2 的 GitHub 退役记录（含那条孤立提交的原文）
  与 §5.3「Gitee 辅仓的两条硬约束」实测核算
- `CNB构建落地方案.md`、`README.md`：远端与 pushall 说明同步
- **发布链路一起去 GitHub 化**（这几处原先都写死了 gh）：
    · `deploy/editor-api/bootstrap.sh`  GH_URL/GH_SSH_KEY → GITEE_URL/GITEE_SSH_KEY，
      remote `gh` → `gitee`，known_hosts/私钥文件名跟着改；
      保留原设计：**没给私钥就自动降级成只推 origin**，不会让每次发布都报错
    · `docker-compose.editor.yml`   PUSH_REMOTES → origin,gitee
    · `editor-api/server.mjs`       默认值 → 'origin,gitee'
    · `editor-api/README.md`        变量表同步

★ 尚未解决 / 需要决策的两条 Gitee 硬约束（详见 架构总览.md §5.3）：

1. **单文件 ≤ 50MB，而 `bin/linux/hugo` 是 83.1MB**
   —— 不管怎么瘦身历史，只要它还跟踪在 HEAD 里，Gitee 一律拒收。
2. 单仓库 ≤ 500MB，而 `.git` 是 620MB
   —— 移出那个 83MB 后 HEAD ≈ 374MB，才有余量。

另：线上 editor-api 容器的 .env 仍是 `PUSH_REMOTES=origin,gh`，
且仓库里还有一个 `gh` remote。因为推送逻辑对辅仓失败只警告、不阻断发布
（`git.mjs`：主仓成即算成），所以**线上发布没有坏**；
但要真正切到 Gitee，需要等 Gitee 仓库与私钥就位后再部署一次。
 2026-10-06 20:18:29 +08:00
zqlit 50a906e07c perf(comments): 评论加载提速 + 骨架屏 + 友链弹窗 pjax 修复 + toast 统一 Message.js 
优化：
- initArtalk 加节点级幂等守卫（mount.__atkInited，失败回滚），
  消除 artalk.html/mypjax 多入口导致的 4× comments + 4× pv 重复请求
- fetch 包装层对无 body 的 GET/HEAD 去掉多余 content-type，
  消掉 Artalk 对 GET /comments 的 CORS 预检（按完整 URL 缓存，
  每篇文章都重付一次 RTT）。实测评论列表 +1150~1565ms → +626ms

修复：
- 评论列表骨架屏改注入 .atk-list-body（原骨架在 #Comments 内，
  被 Artalk.init 清空），list-loaded/故障/12s 兜底移除
- 友链申请弹窗抽成 modules/friendlink.js 进 page-only bundle
  （原内联脚本在 #pjax-container 外，pjax 后 flApplyOpenModal 未定义）
- toast 统一走本地化 Message.js/Qmsg 适配层（保留 window.Toast/showToast 旧 API）

文档：
- README / 架构总览 更新；新增 评论加载优化方案.md
 2026-10-04 15:00:52 +08:00
zqlit e0218b42bb docs: 迁 CNB 前的架构决策文档 + 构建骨架 
- 决策文档：架构总览 / 代码源与构建平台选型 / CNB构建落地方案 /
  EdgeOne双区域 / Gitee / 阿里云ESA / 精简方案
- CNB 构建骨架：deploy/Dockerfile、bin/linux/hugo
  （84MB，linux/amd64 extended 0.128.2，供 CNB 容器 COPY 用）
- scripts/setup-cnb-remotes.sh：双远端切换（CNB 主仓 + GitHub 备份）
- .gitignore 补 .workbuddy/（工作数据不入库）
 2026-10-04 12:40:17 +08:00