zqlit
7abef4ac13
用户四问：「把项目文件全部理一遍 还有readme文件」「gitea 后面可能还要迁移 帮我写一个迁移文档」
「证书管家做完了吗」「感觉现在架构还是复杂了」
一、文档梳理：根目录 15 个 md → 2 个
根目录只留 README.md（入口）+ 架构总览.md（现状唯一事实源），其余全部归位：
docs/
├── README.md ← 新增：文档地图（入口 / 当前有效 / 历史归档 三层）
├── 证书管家.md ← 原「函数版证书管家-方案.md」改名
│ （它早已是「现状+沿革」文档，标题名不副实 —— 签发早已不在 CF Worker）
├── Gitea迁移指南.md ← 新增
├── 架构精简候选.md ← 新增
├── CNB构建落地方案.md / GITEA_SECRETS.md
└── archive/{平台与选型,功能与修复,主题与内容}/ ← 32 份
- 32 个归档文档统一加 `> 📦 本文档已归档` banner，并指向架构总览
—— 这个仓库历史文档里全是「权威口径」，混看很容易拿废弃结论当现状
- gitea-backup/ → deploy/gitea/（原名「backup」不准，它是部署包；与其它 deploy 单元并列）
- 新增 md 链接校验（python 脚本，中文路径用 sed 不安全）→ 首轮 18 处断链
（多一层目录要让 banner 里的相对路径补一个 ../）→ 修正后 0 断链
二、新增 docs/Gitea迁移指南.md（★ 有死线：境外 VPS 11 月到期）
★ 核心价值是「指出迁移面已大幅缩小」：仓库原有的 deploy/gitea/迁移前检查清单.md
（2026-10-04）是为「Gitea + act_runner + 又拍云同步 *整套* 搬迁」写的，**那个前提已经不存在**——
构建归 CNB，runner / upyun-sync / 中转机 / COS 都不需要了。迁移实际只剩「搬数据卷 + 改地址」。
★★ 全文最重要：本仓有 9 处写死了旧地址，按易漏程度排序（1-3 本机，4-5 线上）
1 本机 .git/config 的 gitea remote
2 scripts/setup-cnb-remotes.sh 的 GITEA_URL 默认值
3 deploy/editor-api/bootstrap.sh 的 GITEA_URL 默认值
4 ★ /srv/editor-api/.env 的 GITEA_URL ← 漏了会「持续报错但只警告不阻断」，没人发现
5 ★ /srv/blog 的 gitea remote ← 同上
6 docs/GITEA_SECRETS.md
7-9 架构总览.md / README.md / editor-api/README.md
（不用改：docker-compose.editor.yml、server.mjs、pushall 别名 —— 只引用 remote 名字）
另含：建议新实例改用域名而非 IP（以后搬机器只改 DNS；⚠️ Gitea 28 起只读 ROOT_URL 不读
[server] DOMAIN）；rsync 而非 dump（属主必须 uid/gid 1000）；切换顺序「先建新的→验证→再拆旧的」；
验证清单强调 `git push gitea --dry-run`；第九节给出「干脆不留这个辅仓」的选项与判断依据。
顺带修掉两个硬伤：
- deploy/gitea/docker-compose.yml 的镜像 tag `1.28.0-rootless` 根本不存在
（Gitea 28 起去掉 1. 前缀）→ 改 28.0.0-rootless（pin 死，不用 latest）
- deploy/gitea/.gitignore 漏了 backups/（跑一次备份就会把含 secrets 的 dump 写进历史）
三、证书管家核实（结论：已上线运行，2 个遗留）
线上实测：容器 Up (healthy)；/preflight 7/7 全过；3 组域名；下次自动续期 04:10。
遗留 ① writeapi.usj.cc 证书没纳管（真问题）：nginx 配置在 /www/conf.d/writeapi.usj.cc.conf，
不在 /www/sites/ 管理树里 → 1Panel 的 ssl/upload+sslID 物化碰不到它。
实测仍是 RSA / CN=usj.cc / 到期 2026-12-07，本项目续期不会更新 → 12 月会断。
遗留 ② dnsapi.usj.cc 没上 HTTPS。
（澄清假问题：200181.xyz 公网看到的 LE 证书是 CF 自家边缘证书，与本项目无关）
四、新增 docs/架构精简候选.md（回应「架构还是复杂了」）
结论：复杂度不在件数，在「跨 6 个环境，其中 4 个要自己维护」。国内机 9 个容器里属于本项目的
只有 3 个，能动的只有 2 个。5 个候选 + 建议执行顺序：
1 停 certimate 容器（工作流已全停用）——先 stop 观察，别急着删
2 cn-dns-helper 大概率已是遗留（「Worker 侧签发」时代产物；现在签发在国内机且自带 dnsprovider，
/preflight 显示 CF 凭据可读；Worker 侧 dnsremoted.ts 已无任何引用）
3 Gitea：迁 or 不留
4 两套写作前端收敛（本轮不动，先看使用频率）
5 writeapi.usj.cc 证书纳管（12 月死线）
并明确列出 6 项「必要复杂度，不建议动」。
五、架构总览补齐证书管家子系统（★ 之前完全缺席）
一个完整子系统在「事实源文档」里一个字都没有 —— 这本身就是文档债。补：
- §0 一句话（四→五个子系统）、§1.1 子系统表、§1.2 地址地图两行
- **新增 §5.7 证书管家**：职责划分 / 为什么非要这么分（Worker 免费版 CPU 10ms）/
三条不能破的红线（Worker 不得签发 · 证书路由只认 Bearer 会话 · 角色必须正着枚举放行）/
纳管域名表 / 与 certimate 的关系 / 已知遗留
- .cnb.yml 行数 284 → 337（数字漂了）；头部更新时间 → 2026-10-06；附录表改指 docs/
- §6 待办：#13（证书遗留）、#14（复杂度盘点）新增；#7 改写为「Gitea 11 月到期，★ 有死线」
六、记忆
.workbuddy/memory/MEMORY.md 新增「文档结构」「Gitea 迁移死线」两节；证书管家节补实测与遗留。
160 lines
7.4 KiB
Markdown
160 lines
7.4 KiB
Markdown
> 📦 **本文档已归档**（2026-10-06）。它记录的是**当时的评估与方案**，其中的结论可能已被后续决策推翻。
|
||
> **请勿据此判断当前架构** —— 现行架构唯一事实源是 [`架构总览.md`](../../../架构总览.md)。
|
||
|
||
# Gitee 方案评估
|
||
|
||
> 回答：**「Gitee 算不算一个替代方案？」**
|
||
>
|
||
> **结论**：算，而且它是唯一一个**官方支持作为 EdgeOne Pages 代码源**的国内平台。
|
||
> 但有一道硬门槛 —— **Gitee 免费版单仓库上限 500MB，你的 `.git` 实测 588MB，超了 17.6%**。
|
||
> 好消息是：**这道门槛跨得过去**（见第四节）。真正要权衡的是另一件事 —— **内容审查**。
|
||
|
||
---
|
||
|
||
## 一、实测数据（刚量的，不是估算）
|
||
|
||
| 指标 | 实测值 |
|
||
|---|---|
|
||
| `.git` 总体积 | **588 MB** |
|
||
| `git count-objects` size-pack | **580 MB**（对象净体积，说明已经打包过了） |
|
||
| 提交总数 | 955 |
|
||
| **HEAD 中被跟踪文件合计** | **372.9 MB / 2427 个文件** |
|
||
| HEAD 中 >1MB 的文件 | 65 个，合计 143.9 MB |
|
||
|
||
**关键推论**：`580MB(pack) − 373MB(HEAD) ≈ 207MB` 是**历史里的旧版本 / 已删除对象**。
|
||
也就是说，**光留当前状态只需要 373MB** —— 这一条决定了瘦身可行。
|
||
|
||
---
|
||
|
||
## 二、四条硬指标逐项核对
|
||
|
||
Gitee 官方配额（help.gitee.com/account/usage-quota）：
|
||
|
||
| Gitee 免费版限制 | 官方值 | 你的情况 | 判定 |
|
||
|---|---|---|---|
|
||
| 单仓库容量 | **≤ 500 MB** | 588 MB | ❌ **超限 17.6%** |
|
||
| 单文件大小 | ≤ 50 MB | 最大 12.8 MB（mp4） | ✅ 安全 |
|
||
| 用户总仓库容量 | 5 GB | 588 MB（瘦身后 373 MB） | ✅ 安全 |
|
||
| 私有仓库协作人数 | 5 人 | 个人 | ✅ 无关 |
|
||
| 仓库数量 | 1000 个 | 1 个 | ✅ 无关 |
|
||
|
||
**只有一条不过：仓库体积。** 而且它刚好卡在一条"能解"的线上。
|
||
|
||
---
|
||
|
||
## 三、一个被大多数人算错的点：Gitee 方案**不消耗** Gitee Go 的额度
|
||
|
||
Gitee Go 免费额度很小（单仓库 200 分钟永久 + 每月 500 分钟）。**但这跟你的方案无关** ——
|
||
|
||
因为你走的是 **EdgeOne Pages 的 Git 集成**：代码放 Gitee，**构建跑在 EdgeOne 侧**（4 核 6GB，500 次/月）。
|
||
Gitee 在这里**只当代码网盘**，一次构建都不消耗它的 CI 分钟。
|
||
|
||
> ⚠️ 同理：**不要用 Gitee Pages**。它的构建能力和额度都远不如 EdgeOne，
|
||
> 而且 2022 年那次全站审查的触发点之一就是 Pages。
|
||
|
||
---
|
||
|
||
## 四、唯一的硬伤与解法：588MB → 500MB 以下
|
||
|
||
`.git` 588MB，其中 **207MB 是历史垃圾**（旧版本 + 已删除文件）。三种解法：
|
||
|
||
### 方案 A：只保留当前状态（最彻底，推荐）
|
||
重建一个只有 HEAD 的仓库 → `.git` 降到 **≈ 373MB**，**留 25% 余量**。
|
||
|
||
代价：**955 个提交历史会丢**。
|
||
但这在你这儿几乎无损失 —— 历史仍在自建 Gitea 那边完整保留，Gitee 只当"构建用的镜像"。
|
||
|
||
```bash
|
||
# 思路（务必先在副本上试，不要直接动主仓库）
|
||
git checkout --orphan clean-tmp
|
||
git add -A && git commit -m "squash: 当前站点状态"
|
||
git branch -D main && git branch -m main
|
||
git reflog expire --expire=now --all && git gc --prune=now
|
||
```
|
||
|
||
### 方案 B：保留历史，只清理历史中的大文件
|
||
`git filter-repo --analyze` 先定位占空间的历史大文件，再针对性剔除。
|
||
体积介于 373–580MB 之间，**需要实测才知道能不能压到 500MB 以下**，不保证成功。
|
||
|
||
### 方案 C：升级 Gitee 付费版
|
||
标准版单仓库 ≤ 1GB，1298 元/年起 —— **为了一个博客每年花 1300，不值得**。
|
||
|
||
**结论：只有方案 A 是确定可行的，而且可接受。**
|
||
|
||
---
|
||
|
||
## 五、真正要权衡的：内容审查（这条比 500MB 更重要）
|
||
|
||
Gitee 不是中立的文件存储，它有**实名认证 + 内容审查体系**。有实锤的历史：
|
||
|
||
- **2022-05-19，Gitee 把全部约 1000 万个公开仓库临时私有化，做强制审核**，合规的才恢复。
|
||
开发者必须逐个提交申请、人工复核。有用户 24 个仓库里被恢复了 22 个。
|
||
- 审查范围包括仓库名、注释、变量名 —— 有开发者抱怨"写代码时还要想这个词会不会触发敏感词列表"。
|
||
- 常见封号原因：仓库含违规内容（赌博/诈骗/侵权/涉政）、批量建仓被判滥用、开 Pages 发不合规内容。
|
||
- Gitee 数据全部境内存储，实名是硬要求（这是它拿政府/信创订单的前提）。
|
||
|
||
### 但落到你身上，风险评估是**低**的
|
||
|
||
理由三条：
|
||
|
||
1. **你的内容是技术博客** —— Android 模块化魔改、K3s、Docker、自建服务。这类内容不在敏感区间。
|
||
2. **把仓库设为私有**。审查压力的大头在**公开仓库**上（2022 那次动的就是公开仓库）。
|
||
你要用 EdgeOne 构建，私有仓库完全可以（授权访问即可）。
|
||
3. **国内平台在"政策风险"上对你反而是加分项** —— 你 GitHub 账号被标记，
|
||
正说明境外平台对你有不确定性。Gitee/CNB 的规则是**明确、可预期**的：
|
||
别传违禁内容就不会出事，而不是"不知道哪天被风控"。
|
||
|
||
---
|
||
|
||
## 六、三个国内/境外代码源横向对比
|
||
|
||
| | **Gitee** | **CNB（cnb.cool）** | GitLab.com |
|
||
|---|---|---|---|
|
||
| 仓库容量 | 500 MB ⚠️ **需瘦身** | **100 GiB** ✅ 不用动 | 2 GB ✅ |
|
||
| EdgeOne Pages 官方支持 | ✅ 明确支持 | ✅（有官方插件文档） | ✅ 明确支持 |
|
||
| 构建额度消耗 | 不消耗（构建在 EO 侧） | 不消耗 / 或用它自己的 160 核时 | 不消耗 |
|
||
| 登录 | 实名注册 | 微信扫码 | 邮箱 |
|
||
| 国内推送速度 | 快 | 快 | 跨境，588MB 首次推送慢 |
|
||
| 内容审查 | ⚠️ 有实锤事件 | ⚠️ 官方明写"平台级内容安全审查" | 无（但美国平台） |
|
||
| 政策风险 | 低（国内合规） | 低 | ⚠️ **与 GitHub 同源风险** |
|
||
| 与 EdgeOne 的距离 | 第三方 | **同为腾讯体系** | 第三方 |
|
||
|
||
### 排序建议
|
||
|
||
1. **CNB** —— 100GiB 不用瘦身，零改造，和 EdgeOne 同属腾讯、有官方集成文档
|
||
2. **Gitee** —— 官方支持、国内快，但**要先做一次历史瘦身**（一次性工作，可接受）
|
||
3. **GitLab.com** —— 容量够，但**美国平台，和 GitHub 同类风险**，且首次推送跨境 588MB 很慢
|
||
|
||
**Gitee 输给 CNB 的唯一一点就是那 500MB**，如果你不想动仓库历史，选 CNB；
|
||
如果你更信任 Gitee 这个老牌子、也愿意做一次瘦身，Gitee 完全可用。
|
||
|
||
---
|
||
|
||
## 七、Gitee 方案的完整形态
|
||
|
||
```
|
||
write-server / 本地 hugo → push Gitee（私有仓库）
|
||
→ EdgeOne Pages Git 集成自动构建（4核6G，500 次/月，不消耗 Gitee CI 额度）
|
||
→ EdgeOne 国际站（境外解析） + EdgeOne 国内站 Makers（境内解析，绑备案域名）
|
||
```
|
||
|
||
砍掉：act_runner、广州中转机、sync.sh、COS、Gitea artifact 链、8 处 Gitea 兼容分支、
|
||
又拍云、多吉云、两套冗余通知。
|
||
**3 台机器 → 0 台；7 环节 → 3 环节。**
|
||
|
||
---
|
||
|
||
## 八、前置动作（按顺序）
|
||
|
||
1. **先备份**：整仓 `cp -r` 一份（或 `git bundle create` 全量）
|
||
2. **在副本上做瘦身**，验证 `.git` 能压到 500MB 以下
|
||
3. 注册 Gitee，建**私有**仓库，首次推送验证体积
|
||
4. 在 EdgeOne Pages 里接 Gitee 仓库，跑一次构建
|
||
5. 确认无误后，才把主仓 remote 切过去
|
||
|
||
**第 1、2 步不做，其余都别动。**
|
||
|
||
---
|
||
|
||
*本文档基于 2026-10-04 实测数据与官方文档。仓库体积为 `git count-objects -vH` 实测，非估算。*
|