- 决策文档:架构总览 / 代码源与构建平台选型 / 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/(工作数据不入库)
7.2 KiB
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 只当"构建用的镜像"。
# 思路(务必先在副本上试,不要直接动主仓库)
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 数据全部境内存储,实名是硬要求(这是它拿政府/信创订单的前提)。
但落到你身上,风险评估是低的
理由三条:
- 你的内容是技术博客 —— Android 模块化魔改、K3s、Docker、自建服务。这类内容不在敏感区间。
- 把仓库设为私有。审查压力的大头在公开仓库上(2022 那次动的就是公开仓库)。 你要用 EdgeOne 构建,私有仓库完全可以(授权访问即可)。
- 国内平台在"政策风险"上对你反而是加分项 —— 你 GitHub 账号被标记, 正说明境外平台对你有不确定性。Gitee/CNB 的规则是明确、可预期的: 别传违禁内容就不会出事,而不是"不知道哪天被风控"。
六、三个国内/境外代码源横向对比
| Gitee | CNB(cnb.cool) | GitLab.com | |
|---|---|---|---|
| 仓库容量 | 500 MB ⚠️ 需瘦身 | 100 GiB ✅ 不用动 | 2 GB ✅ |
| EdgeOne Pages 官方支持 | ✅ 明确支持 | ✅(有官方插件文档) | ✅ 明确支持 |
| 构建额度消耗 | 不消耗(构建在 EO 侧) | 不消耗 / 或用它自己的 160 核时 | 不消耗 |
| 登录 | 实名注册 | 微信扫码 | 邮箱 |
| 国内推送速度 | 快 | 快 | 跨境,588MB 首次推送慢 |
| 内容审查 | ⚠️ 有实锤事件 | ⚠️ 官方明写"平台级内容安全审查" | 无(但美国平台) |
| 政策风险 | 低(国内合规) | 低 | ⚠️ 与 GitHub 同源风险 |
| 与 EdgeOne 的距离 | 第三方 | 同为腾讯体系 | 第三方 |
排序建议
- CNB —— 100GiB 不用瘦身,零改造,和 EdgeOne 同属腾讯、有官方集成文档
- Gitee —— 官方支持、国内快,但要先做一次历史瘦身(一次性工作,可接受)
- 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 环节。
八、前置动作(按顺序)
- 先备份:整仓
cp -r一份(或git bundle create全量) - 在副本上做瘦身,验证
.git能压到 500MB 以下 - 注册 Gitee,建私有仓库,首次推送验证体积
- 在 EdgeOne Pages 里接 Gitee 仓库,跑一次构建
- 确认无误后,才把主仓 remote 切过去
第 1、2 步不做,其余都别动。
本文档基于 2026-10-04 实测数据与官方文档。仓库体积为 git count-objects -vH 实测,非估算。