Files
blog/Gitee方案评估.md
T
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

7.2 KiB
Raw Blame History

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 数据全部境内存储,实名是硬要求(这是它拿政府/信创订单的前提)。

但落到你身上,风险评估是低的

理由三条:

  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 实测,非估算。