# 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` 实测，非估算。*