标题里写了「实测」两个字，我先把话说在前面，免得后面有人拿这个挑刺：本文不给你编造任何自家跑分数字。所有性能相关的内容，只写三类——官方公开的配置门槛、公开文档里能查到的机制与参数含义、以及我标明了「经验区间（预估）」的量级判断，并且把影响因素一条条写出来让你能自己校。真要写进采购单的数字，你自己拿 fio、拿 git 自带的 count-objects 和 time 跑一遍，那才叫实测。价格也一样：官网明示的写官网价，官网没明示的组合写预估，注明以下单核算为准。
说回正题。这两年找我聊「要不要把代码搬回自己机房」的人明显多了，理由翻来覆去就那么几条：托管平台的席位费年年涨，CI 分钟数一到月底就超支；跨境访问 SaaS 平台时好时坏，晚高峰 push 一次要转半天圈；甲方在合同里写了代码和制品不得存放在第三方平台；还有一批是被安全部门逼的——依赖包要从公网源随便拉，这事在他们眼里等于把供应链命门交出去。
这些理由都成立。但我得先泼一盆冷水：自建 Git 托管和制品仓库，失败的原因九成不是软件装不上，而是硬件选错、容量算错、备份没做。软件是免费的，硬盘和内存是要真金白银买的，而且一旦选小了，迁移一次的成本比当初多花的租金高得多。这篇就围绕这些来讲。
赶时间的先看这几条核心结论：
1. 先按「仓库数 × 平均体积 + 制品累积速度」估容量，再回头谈 CPU 和内存。自建代码托管翻车的顺序几乎固定：磁盘先满，然后 inode 先耗尽，最后才是 CPU 不够。把顺序搞反的人，三个月后一定会回来加盘。
2. GitLab CE 不是「能跑就行」的东西，它的资源门槛有公开口径。官方安装要求给的是 4 核 4G 起步（面向 500 用户以内），8 vCPU 加 16G 才是 1000 用户、约 20 RPS 的量级；默认装完空闲状态就要吃掉 4–6G 内存，因为 Puma、Sidekiq、PostgreSQL、Redis、Gitaly 是同时在跑的。十来个人的团队，Gitea 是更划算的答案。
3. NVMe 是这篇里最不该省的钱。git clone 和 fetch 在服务端要做打包，CI 工作区要解压、编译、再打包，这两件事的底层全是高并发随机小 IO。省下 NVMe 的差价，会以「每次 pipeline 多等五分钟」的形式每天还回来。
4. git gc 和 git repack 是内存杀手，不是 CPU 杀手。公开资料里给出的估算关系是：打包时的内存占用大致正比于（pack.deltaCacheSize + pack.windowMemory）× pack.threads，而 windowMemory 默认不限、threads 默认等于核数。多核小内存的机器跑一次全量 repack，被 OOM Killer 干掉是常态，必须用参数限住。
5. 报价分两级看。一万网络官网明示的档位有：裸金属 E5-2620（32G/1T）¥999/月起、E5-2698v4×2（32G/1T）¥3999/月起、大陆节点华南 ¥799/月起、中国香港 E3 ¥1500–1599/月、一万云 ¥25 起（均以官网实时价为准）。在此基础上叠加内存、NVMe 数据盘的具体组合，官网没有逐条挂价，属于预估范畴，以下单核算为准。
很多人一张口就是「我要自建一个 GitLab」，其实他要的是三件完全不同的东西，硬件诉求也各不相同。混在一起谈，选型必错。
就是那个能看 diff、能开合并请求、能管理 SSH key 和权限的 Web 界面加后端。它负责的是仓库存储、访问控制、评审流程和 Webhook。这一层的特点是：日常负载很低，峰值很尖。白天几十个人零零散散 push 和 review，机器闲得发慌；晚上集中合代码、跑 CI、或者有人 force push 之后触发一次全量 gc，CPU 和内存瞬间打满。
Maven 的 jar、npm 的 tarball、Python 的 wheel、Docker 的镜像层、Helm chart、Go module……这些二进制资产的存放与分发。它跟代码托管是两种 IO 模型：制品仓库是大文件顺序读写为主，读多写少，但对磁盘容量和下行带宽的胃口极大。一个跑了一年的 Nexus，几百 G 是起步，上 TB 一点不稀奇。而且这一层的容量是只增不减的，除非你认真配生命周期清理策略。
真正把机器压满的是它。拉代码、装依赖、编译、跑测试、构建镜像、推制品——每一步都在同时吃 CPU、内存、磁盘 IO 和网络。它和前两件的资源曲线完全不同：前两件是脉冲式，Runner 是持续满载式。我见过太多团队把 Runner 和 forge 塞在同一台机器上，结果每次大版本构建，整个代码平台的 Web 界面就卡成幻灯片。
把这三件事拆开之后，硬件配置就不是「一台机器搞定」的问题，而是「至少几台、各自多大」的问题。后面第十四节的表会按这个思路给组合。
这一节是整篇的地基。你要是没搞懂 Git 到底在怎么折腾磁盘，后面所有的硬件选型都是拍脑袋。
一次 git clone 在客户端看到的是「下载一个仓库」，在服务端发生的事情要复杂得多。服务端要遍历提交图、算出客户端缺哪些对象、把需要的对象从 packfile 里解出来、做 delta 压缩、重新打成一个新包再发过去。这个过程中既有大量小文件的随机读（松散对象时代尤其明显），也有大块的顺序读（读 packfile），还有一次 CPU 密集的压缩。
这里有个容易踩的点：clone 通常比 fetch 更省服务端资源。因为 clone 拿的包服务端经常已经准备好、或者可以直接复用 bitmap 索引；而 fetch 要在两个已知状态之间算差集，现场生成「thin pack」，需要把相关对象加载进内存算 delta，是内存密集得多的操作。这也是为什么有些团队发现「新建克隆很顺，老仓库同步经常卡」——不是网络问题，是服务端打包算不动了。
对策是公开的、也很成熟：给仓库写 bitmap 索引。用 git repack -adb 或者在 git 配置里打开 writeBitmapIndex，bitmap 能让服务端在算可达性时跳过大量对象遍历，clone 和 fetch 都会明显变快。代价是构建 bitmap 比普通 repack 慢一倍到两倍，所以要在低峰期做，或者在 git maintenance 里排期。commit-graph 和多包索引（MIDX）是同一类思路：用空间换时间，让提交图遍历和对象查找少走弯路。
gc 这件事，很多人是等仓库盘爆了才第一次认真跑。它的机制是这样：push 进来的新对象先以「松散对象」形式落盘，每个对象一个文件；攒够了或者触发了阈值，才被打包进 packfile。长期不 gc 的活跃仓库，松散对象堆到几千上万个是常态，这时候跑一次 gc，公开技术资料给出的经验是能把体积压掉三成到九成。
代价是资源。delta 压缩要在内存里维护一个滑动窗口，窗口越大、线程越多，压缩率越高，内存也吃得越狠。前面提到的估算关系（deltaCacheSize + windowMemory）× threads 就是这么来的——deltaCacheSize 默认 256MB，windowMemory 默认不限，threads 默认等于 CPU 核数。一台 16 核 8G 的机器跑一次大仓库的全量 repack，理论上能把内存吃干，实际上就是 OOM。
怎么避？三条。第一，显式设 pack.windowMemory 和 pack.threads，把上限压住（比如 windowMemory 给 100m–1g、threads 给 4–8，视机器内存定）。第二，不要在业务高峰期跑全量 repack，用 git maintenance 做定期小规模维护，避免「stop-the-world」式的大 gc。第三，仓库盘一定要留够余量——打包过程中会同时存在旧包和新包，峰值占用接近两倍。
这一条几乎没人提前算，但翻车的人很多。裸仓库（bare repo）里每个松散对象是一个独立文件，一次 push 哪怕只改了一个文件，也可能写入好几个新对象。仓库数量一多、提交频率一高，inode 的消耗速度会超出直觉。
麻烦在于文件系统层面：ext4 的 inode 总数是在格式化时就固定下来的，之后不能动态增加；XFS 则是按需动态分配 inode。所以给仓库盘选文件系统时，我会倾向于 XFS，或者在 ext4 格式化时就把 inode 比例调高。判断方法很简单：df -i 看 inode 使用率，别只盯 df -h。我见过磁盘还剩 40% 空间、但 inode 已经 100% 导致完全写不进去的情况，排查起来非常费时间。
四个选项定位差别很大，不要看名气选，看你的团队规模和维护能力选。
Go 写的单二进制，自带 Web 界面、Issue、合并请求、Wiki、包注册表和容器注册表，从 1.21 版本起内置 Gitea Actions，工作流 YAML 与 GitHub Actions 兼容，配一个 act_runner 就能跑 CI。资源占用是它最大的优势：公开社区测得的数据在空闲时几十 MB 到百来 MB 量级（不同版本、不同仓库规模差异不小，属经验区间（预估），请以自己部署后的实测为准）。
两个必须提前说清的点。第一，SQLite 只适合个人或者极小团队，多人并发 push 加 CI 时 SQLite 的写锁会让请求排队，团队部署直接上 PostgreSQL 或 MySQL。第二，升级维护成本确实存在——Gitea 发版快，跨大版本升级要读 release note，配置文件和数据库迁移都要看一眼。这是所有活跃项目的通病，不算缺点，但要排进运维计划。
GitLab CE（社区版，MIT 许可）给的是完整 DevOps 平台：代码托管、合并请求、内置 CI/CD、容器注册表、LDAP 与 SAML 对接、以及部分安全扫描能力。代价是资源门槛。官方安装要求的公开口径是 4 核 4G 起步、面向 500 用户以内，8 vCPU 加 16G 对应 1000 用户、约 20 请求每秒；而第三方部署实践里反复提到，默认安装完成时空闲内存占用就在 4–6G，一旦开 CI 和 Runner，内存还会往上冲。4G 跑生产属于「技术上可行、体验上受罪」。
它的组件是堆起来的：Puma（Web）、Sidekiq（后台任务）、PostgreSQL、Redis、Gitaly（Git 存储服务）、Nginx。这意味着两件事：内存是硬门槛，别指望靠 swap 撑；磁盘 IO 也是门槛，因为数据库、仓库、CI 产物会同时写同一块盘。我的建议一贯是——除非你确实需要它的内置安全扫描、K8s 集成或者已有的 GitLab CI 资产，否则 50 人以下的团队不要上来就 GitLab。
Gogs 是 Gitea 的前身，同样是 Go 单二进制，资源占用更低（公开资料给的最低门槛在 256MB 内存、1 核量级）。功能边界很清楚：仓库、Issue、合并请求这些基础能力有，内置 CI/CD 没有，包注册表和容器注册表也没有。维护节奏偏慢，这是它和 Gitea 最大的现实差距。
什么时候选它？硬件实在太寒酸（比如一台吃灰的小 VPS、一台开发板），或者你就是需要一个能 push/pull 的最小 Git 服务端，不需要评审流程也不需要 CI。除此之外，能跑 Gitea 就跑 Gitea，长期看省心得多。
SourceHut 是一套「迷你服务」组成的分布式系统：meta.sr.ht 提供账号与认证（这是唯一必需的组件），git.sr.ht 提供仓库，todo.sr.ht 管缺陷，lists.sr.ht 管邮件列表和补丁评审，builds.sr.ht 做 CI。每个服务独立，各自需要一个 PostgreSQL 库，还要 Redis、Postfix 和 nginx 这些外部依赖，对象存储可选 S3 兼容后端。
它真正的门槛有两个。第一，官方只正式支持 Alpine Linux，其他发行版属于「自己折腾」。第二，builds.sr.ht 的构建跑在 KVM 虚拟机里，官方文档明确说构建 worker 一般需要裸金属服务器，而且要支持嵌套 KVM——而大多数 VPS 不提供嵌套虚拟化。这一条基本就决定了：想在云主机上完整自建 SourceHut 的 CI，是走不通的，得单独准备裸金属。
适合谁？认可邮件工作流（git send-email）、重视极简与无 JS、愿意自己维护一整套服务的团队。不适合「我要一个 GitHub 的替代品，最好一周上线」的诉求。
制品这一摊按语言生态拆就行，不用强求大一统。
Sonatype 的 Nexus Repository 是目前自建场景里最常见的选择，社区版用 Eclipse 公共许可证。支持的格式非常全：Maven、npm、PyPI、Docker、Helm、NuGet、Go、RubyGems、Yum/Apt、Conan 等等，一个实例能同时管住 Java 和前端两条链。
官方的系统要求给的是按「profile」分档，这点非常实用，我照着讲：Small 档是 2 核、8G 内存、20G 本地 blob 存储，对应每小时 2 万请求、每天 20 万请求，用内嵌 H2 数据库；Medium 档是 4 核、8G、200G 存储，对应每小时 10 万请求，用外部 PostgreSQL；Large 档是每节点 4 核、16G；Very Large 档是每节点 8 核、32G、10TB 以上存储。官方还给了一条通用原则：把可用内存的三分之二分给 Nexus，留三分之一给系统进程和缓存。
有几个坑是官方明确写出来的，值得单独强调。第一，文件句柄数——Nexus 消耗的句柄数超过 Linux 默认限制，句柄耗尽会导致数据丢失，必须调高。第二，内嵌 H2 有硬上限，每天 20 万请求或者 10 万个组件，超了就不支持，而且 H2 不支持容器化部署；生产一律上外部 PostgreSQL。第三，Nexus 现在要求 Java 21，且新版本已不再支持 Java 8 和 11。第四，官方不建议在安装目录上跑杀毒软件，Windows 上出现过启动时间延长十倍的情况。
Artifactory 是商业产品，能力上和 Nexus 有重叠，差异化主要在几个地方：更细的权限模型与仓库分区、跨实例复制与多云分发拓扑、以及和 JFrog 安全扫描（Xray）的深度联动。它的成本不只是软件授权，还有按实例规模计的运维复杂度。报价方式以官方为准，我不在这里给数字——商业软件的授权条款变化快，谈的时候直接找厂商要正式报价单更靠谱。
我的判断很直接：如果你的诉求只是「别再从公网拉依赖、把构建产物存下来」，Nexus 社区版就够了，没必要上商业授权。真正需要商业版的场景是有审计和分发拓扑要求的规模化研发中台，那时候该花的钱也确实省不掉。
Harbor 是 CNCF 毕业项目，专做云原生制品（主要是 OCI 镜像和 Helm chart）。它的官方资源要求是：最低 2 核、4G 内存、40G 磁盘；推荐 4 核、8G、160G 磁盘。需要 Docker Engine 20.10 以上和 Docker Compose 2.3 以上，端口 80 和 443。
它的核心价值不是「存镜像」，而是镜像治理：基于策略的漏洞扫描、镜像签名与信任（内容信任）、基于角色的多租户访问控制、以及跨仓库复制。这几件事用纯 registry 自己做，等于自己写一遍 Harbor。所以只要你的交付物是容器镜像， Harbor 就值得单独部署一台，不要和 Nexus 的 Docker 仓库强行二选一——两者定位不同，前者管治理，后者管多格式代理与缓存。
Verdaccio 是 Node.js 写的轻量 npm 私服，几个人的前端团队用它非常合适：装起来快，默认会把没找到的包代理到上游公共源并缓存下来，第二次拉同样的包就走本地了。它本身对资源几乎没有要求，真正吃资源的是缓存目录的容量——npm 依赖树膨胀速度你们都懂。
devpi 是 Python 生态的对应物，能做 PyPI 的私服和镜像，支持索引继承（本地索引可以继承上游索引），适合需要在内网锁定 Python 依赖版本的团队。同样是轻量，同样要盯缓存盘的容量。
这两个的共同短板是：格式单一，且高可用的方案要自己做。团队只有一条技术栈时很香，栈一多就得上 Nexus。
这一条值得单独讲，因为很多人的理解是错的。制品仓库本身不是对象存储，它是一个「元数据 + 索引 + 权限 + 生命周期策略」的管理层，真正的二进制内容（blob）可以落在本地文件系统，也可以落到 S3 兼容的对象存储上。Nexus 官方就明确支持 S3 类的弹性对象存储作为 blob store，SourceHut 的文档里也把 S3 兼容对象存储列为可选组件。
这么分层的实际意义是：容量和性能可以解耦。制品越来越多，容量压力可以给对象存储，而索引和元数据的性能压力留在本地 NVMe 上。但这有个前提——对象存储的访问延迟要低，跨公网访问对象存储做 blob 后端，会把每次制品拉取的延迟拉到不可接受。所以要么用同机房的对象存储，要么就老老实实用本地盘，别搞跨地域。
CPU 这一维的判断标准不是「核数够不够」，而是「峰值叠加时够不够」。自建 Git 平台有三个 CPU 高峰会撞在一起：CI 编译、服务端打包（clone/fetch/gc）、以及制品仓库的压缩与索引。
我给的经验区间（预估，影响因素见下）：纯代码托管（不含 CI）10–30 人团队，4 核够用；带上 CI，每次并发 2–4 个任务，建议 8 核起步；如果是 Java 全量编译、C++ 大项目或者前端 monorepo 全量构建，16 核往上。这些数字的影响因素是：单次构建的时长、并发任务数、是否可以增量构建、以及编译是否支持分布式缓存（ccache、sccache 这类命中率高的话，CPU 压力能砍掉一大半）。
还有一个容易被忽略的点：核数越多，git repack 默认的线程数也越多，内存压力跟着涨。所以「加核不加内存」是错误操作，加核的同时记得回头把 pack.threads 和 windowMemory 参数一起调。裸金属在这类场景里比云主机更实在——编译和打包都非常吃单核性能的稳定性，虚拟机层面的调度抖动会直接体现在 pipeline 时长的方差上。
内存这一维最能体现选型的差异。同样是自托管 Git，Gitea 是几十 MB 到百来 MB 量级（经验区间（预估），随仓库数、缓存配置、并发数变化明显），GitLab CE 默认装完就是 4–6G 空闲占用、开 CI 之后往 8G 以上走。这不是配置优化能抹平的量级差，是架构决定的——前者一个 Go 进程搞定，后者 Ruby on Rails 加上 PostgreSQL、Redis、Sidekiq、Gitaly 一起跑。
制品仓库这一侧，Nexus 的官方口径是分档给的：Small 和 Medium 档都是 8G，Large 档每节点 16G，Very Large 档每节点 32G，并且建议把三分之二的内存分给它。这是 Java 应用的典型特征——堆给小了，GC 频繁、响应变慢；堆给大了，又挤占系统缓存。Harbor 官方推荐是 8G。
我的排法一般是这样：如果预算只允许一台机器，优先保证「forge 该有的内存 + 制品仓库该有的内存 + 数据库缓冲」，CI Runner 单独拆出去。如果只能拆两台，就把 Runner 拆走——因为 Runner 的内存占用是突发式的，跟 forge 抢内存的结果就是整个平台一起卡。一万网络人工定制档位里内存升到 128G 是 +¥600/月（官网明示升级价，以官网实时价为准），跟因为内存不够导致的 pipeline 排队和投诉比，这点钱真不算什么。
这一维是本篇最重要的。先说为什么必须 NVMe：git 的服务端打包要在成千上万个对象之间做随机读，CI 工作区要解压依赖、创建和编译大量小文件、再清理，这两类负载都是高并发随机小 IO。机械盘的随机 IOPS 在百级量级，SATA SSD 在万级到十万级，NVMe 能到几十万级且深队列下延迟增长平缓得多。差多少不好给死数字，但方向是确定的：从 SATA SSD 换到 NVMe，pipeline 里「装依赖 + 编译」这段的耗时通常会有肉眼可见的下降（经验区间（预估），实际幅度取决于项目结构和是否命中缓存）。
再说说容量怎么估，这是硬活。我一般用这个公式：
仓库盘容量 ≈ 仓库数 × 平均仓库体积 × 冗余系数（1.5–2.5）
冗余系数留这么大的原因有三个：一是 force push 和孤儿对象默认会保留一段时间才被 gc 回收；二是 gc 打包过程中新旧包会同时存在，峰值接近两倍；三是 LFS 对象（如果开了）是独立于 pack 存储的，容易漏算。平均体积怎么来？拿现有仓库跑一次 git count-objects -vH 或者 du -sh 就有数，别拍脑袋。
制品盘容量 ≈ 月新增制品体积 × 计划留存月数 + 代理缓存体积
这一项要特别小心「代理缓存」。你配了 Nexus 代理公网 Maven 源之后，所有被拉过的包都会留在本地，增长曲线是先陡后缓，但半年下来几百 G 太常见了。所以制品盘要么一开始就给大，要么把生命周期清理策略（保留最近 N 个版本、清理超过 X 天未下载的包）配好，否则一年后你会面对一个既不敢删又装不下的目录。
文件系统层面补一句：仓库盘建议 XFS（inode 动态分配），或者 ext4 但格式化时调高 inode 比例；定期 df -i。另外一万网络人工定制档位里硬盘加 1T 是 +¥300/月（官网明示升级价，以官网实时价为准），这种升级项在签约阶段谈清楚，比后面停机扩容划算得多。
带宽这一维的坑在于：按平均算必错，按峰值算才对。自建 Git 平台的流量有几类，我挨个拆。
代码同步流量。单个仓库的完整 clone 可能在几十 MB 到几 GB 之间，取决于历史和是否带 LFS。但日常 fetch 通常只有几 MB。真正的峰值出现在：新人入职当天集中克隆、CI 每次构建都做全量克隆、以及有人误把大二进制提交进去之后所有人同步。对策很成熟：CI 用浅克隆（--depth 1 --single-branch），大文件一律走 LFS，仓库侧开启 bitmap 索引。
镜像与制品流量。这才是大头。一次容器镜像拉取动辄几百 MB 到几 GB，而且 CI 每跑一次就要拉一次基础镜像、推一次产物镜像。一个 20 人的团队每天跑几十次构建，镜像流量轻松到几十 GB 每天。所以制品仓库所在机器的上行带宽（对研发来说是下载方向）要单独算，别套用代码托管的量级。
计费方式要看清。业内常见的有固定端口速率（比如 100M 端口不限流量）、按 95 计费（去掉最高的 5% 采样点后按峰值计）、按实际流量计。自建 Git 平台的流量曲线是「白天平、夜里尖」（CI 集中跑批），95 计费比较友好；如果是纯流量计费，月底账单可能比月租还高。签约前务必索要完整价目表，把端口速率、是否区分方向、计费方式、超出部分怎么算逐条写进合同。
线路决定的是「你的数据包走哪条路」，对分布式团队来说，它的体感影响比 CPU 大得多。同一台机器，从同城办公室访问和从另一个国家的分支访问，体验能差出一个档次。
延迟对 Git 的影响被大多数人低估了。Git 协议本身是多次往返的：引用通告、对象协商、打包传输，每一轮都要等一个 RTT。国内的跨运营商访问在几毫秒到几十毫秒量级，体验通常没问题；跨境方向的延迟公开可查的量级在几十毫秒到一百多毫秒区间（不同运营商、不同时段、不同路由差异显著，以实测为准），叠上几轮往返，一次 push 从「瞬间」变成「明显等待」，再叠上丢包和抖动，SSH 会话还会断连。
实操上有三种做法。第一种，全员走优化链路访问——一万网络在网络侧明示的能力是 BGP 多线加 CN2 GIA 回国优化，官网公开口径里新加坡节点 CN2 GIA 优化后国内延迟在 50–80ms 区间（这是官网明示的参考区间，具体以实测为准）。第二种，前后端分离：代码平台留在主力机房，在国内或者中国香港节点放一台网关或者跳板机，负责反向代理和静态资源，异地团队只跟网关打交道。第三种，分布式团队就干脆就近部署 Runner，把仓库镜像到分支办公室所在的节点，构建在本地跑，只把产物回传。
我个人的偏好是第二种加第三种组合：网关解决「人访问」的体验，就近 Runner 解决「机器访问」的体验。中国香港节点的 E3 档官网明示价是 ¥1500–1599/月（以官网实时价为准），拿来做这个网关成本不高，但体验改善非常明显。
这个问题我被问得最多，答案很干脆：小团队可以放一起但要做资源隔离，正经团队建议分开。
放一起的好处只有一个——省一台机器的钱，而且 Runner 拉代码走内网，速度快、不占公网带宽。坏处有三个：一是资源抢占，构建高峰时 forge 的 Web 响应会掉；二是故障域合并，Runner 把磁盘写满，forge 跟着一起挂；三是安全边界模糊，构建容器里的不可信代码和存放全部源码的机器共处一室。
分开之后，两台机器之间的内网带宽就成了关键参数，务必确认机房提供内网互通且不计费。如果服务商没有内网，那 Runner 拉代码要走公网，带宽成本和延迟都要重新算。
机房本身看五件事：供电冗余（双路市电、UPS、油机）、制冷与机柜功率上限（高核数加多块 NVMe 的机器功耗不低）、物理与信息安全（门禁、监控、访客登记，以及是否有 ISO 27001 这类体系认证——具体资质以机房和供应商实际提供的证明文件为准，一万网络可提供合规方面的咨询与架构建议）、运维响应机制、以及防护能力。一万网络明示的服务基线是 7×24 中文工单、平均 5 分钟响应、硬件故障 10 分钟内自动迁移、自营机柜最快 1 分钟上架、5–20G 免费流量防护、系统盘每日 3 份免费快照且 30 秒回滚——这几条对自建代码平台尤其重要，因为代码是丢了就真丢了的资产。
Runner 是自建体系里最容易失控的一环，因为它会自己长大。今天两个并发，下个月变八个，磁盘和 CPU 就都不够了。
并发数怎么定。按「同时能跑几个任务」定，而不是按「有多少人」定。经验区间（预估）：每人每天触发 3–8 次 pipeline、单次 5–15 分钟的团队，20 人规模给 4–8 个并发通常够；如果有 monorepo 全量构建或者长测试套件，要单独算。影响因素是单次构建时长和每日触发频次，你把自己团队这两个数字一乘就出来了。并发数直接决定 CPU 核数和内存：一个中等规模的 Node 或 Java 构建任务，给它 2–4 核、4–8G 是常见配法。
缓存目录是磁盘杀手。Runner 的缓存分两类：构建工具缓存（npm、Maven、pip 的本地缓存）和容器镜像层缓存。前者能极大加速构建，但会稳定膨胀，一个跑了一年的 Runner 缓存目录几十 G 很正常；后者更狠，Docker 的构建缓存和未清理的悬空镜像能吃掉上百 G。所以 Runner 的磁盘要单独规划，并且配定期清理（docker system prune、缓存 TTL 策略），最好还能监控磁盘水位。
容器构建的额外开销。如果构建要在容器里跑（Docker-in-Docker 或者挂载 docker.sock），除了 CPU 和内存，还会带来显著的磁盘写放大：每层镜像都要落盘，构建上下文传输也是 IO。这就是为什么 Runner 更应该用 NVMe，而且最好单独一块盘——让构建缓存和系统盘分开，写满了也不至于把系统拖死。
这一节我写得重一点，因为代码是核心资产，丢了没法重来。
自建 Git 平台的数据至少有三块：裸仓库目录（.git 或者 forge 的 repositories 目录）、数据库（用户、权限、Issue、合并请求、流水线记录）、以及附件与制品（LFS 对象、上传的附件、制品 blob）。只备数据库是最常见的错误——恢复出来一个「用户和权限都在、仓库全是空壳」的系统，等于没备。
裸仓库的备份相对简单，因为仓库文件在 git 的视角下是自洽的。常见做法是 rsync 增量同步到备机，或者定期 tar 打包归档。要注意两点：一是打包前先跑一次 gc 或者至少确认没有正在进行的写操作，避免备到一个半写状态；二是 rsync 的 --delete 要慎用，如果源端误删，备机跟着一起删，等于没有备份。更稳妥的做法是做快照式的多版本保留（保留最近 N 天、N 周、N 月的副本），而不是每次覆盖同一个目标。
数据库这一层不能靠裸拷贝文件。GitLab 自带备份工具（gitlab-backup 这类），它会把仓库、数据库、附件等一起打成归档，是最省心的路径，但要注意备份出来的归档里包含密钥和敏感配置，存放和传输都要加密。如果自己用 pg_dump 备份 PostgreSQL，务必在备份期间保证没有结构变更，并且把备份文件和对应时间点的仓库副本对齐——仓库和数据库时间点对不上，恢复出来会出现「数据库里有这个仓库、磁盘上没有」这类诡异问题。Nexus 那边同理，官方推荐外部 PostgreSQL，备份策略要覆盖数据库和 blob store 两部分。
同一机房的两份副本不叫备份，只叫 RAID。一次机房级别的故障、一次误操作、一次勒索软件，本地副本全军覆没。所以至少要有一份异地副本（另一个机房，或者对象存储的另一个区域），并且传输链路加密、存储端加密、访问凭据独立管理。
最后是恢复演练——这一条我几乎每次都要强调：备份没演练过等于没备份。做法不复杂，每季度挑一个非高峰时段，在隔离环境里用你的备份完整恢复一遍，记录实际耗时，验证恢复出来的仓库能正常 clone、数据库能正常登录、制品能正常拉取。只有这一步过了，你的备份才算存在。一万网络提供系统盘每日 3 份免费快照、30 秒回滚，这个功能在误操作和升级失败时能救命，但它不能替代异地副本——快照通常和源盘在同一个存储系统里，机房级故障一起没。
自建的另一半价值在安全可控，但前提是你真的把这几件事做起来。
SSH key 管理。自建平台要面对的第一个现实问题是密钥分发：新人入职加 key、离职删 key、一人多设备多 key。小规模可以手工管，超过二三十人就要定流程——key 必须带注释标明归属设备和人，离职流程里必须有「回收 key」这一步，并且定期审计有没有长期未使用的 key 还挂着。有条件的话上证书模式（SSH CA 签发短期证书），能从根本上解决「密钥永不过期」的问题。
统一身份认证。团队一大，本地账号体系必然失控。GitLab CE 支持 LDAP 和 SAML，Gitea 支持 OAuth2 与 OIDC 对接，SourceHut 也有自己的 OAuth 体系。接上公司的统一身份源之后，离职即停用这件事才真正闭环。这一项要在选型阶段就确认，别等平台上线几百个账号之后再改。
审计日志。谁在什么时候拉了哪个仓库、谁改了权限、谁删了制品——这些要能查。forge 自带的能力有限的话，至少把 SSH 登录日志、Web 访问日志、sudo 操作日志集中收集到独立的日志服务里，并且日志存储要和被审计的机器分离，否则被入侵的一方有能力抹掉痕迹。
制品签名与漏洞扫描。制品这一侧要做两件事：一是对发布出去的制品做签名（容器镜像用 Notary 或者 Cosign 类的工具，Harbor 内置了内容信任与签名能力），下游部署时验签；二是对入库的制品和镜像做漏洞扫描（Harbor 内置扫描器，Nexus 也有对应的能力或可集成的方案）。这两件事合起来解决的是「供应链被投毒」的风险——公网依赖被劫持、内部制品被替换，都属于这一类。
下面这张表按「forge + 制品 + Runner」三件事拆开的思路整理，价格分两栏口径：能查到官网明示价的写官网价并注明以官网实时价为准；官网没逐条挂出的组合写预估并注明以下单核算为准。别把预估当成交价，这是我反复强调的。
| 方案定位 | 适配团队规模 | 参考配置（CPU/内存/硬盘） | 最先撑不住的资源 | 参考月付（A 类官网价 / B 类预估） |
|---|---|---|---|---|
| 极简托管型（Gogs / 个人 Gitea + SQLite） | 1–5 人 | 2 核 / 4G / 100G SSD | SQLite 写锁、磁盘容量 | 一万云 ¥25 起；大陆节点华南 ¥799/月起（官网价，以官网实时价为准） |
| 小团队主力型（Gitea + PostgreSQL） | 10–30 人 | 4 核 / 8G / 256–512G NVMe | inode 与 gc 内存 | 裸金属 E5-2620 ¥999/月起（官网价）+ 内存与 NVMe 升级项，整单约 ¥1500–2500/月（预估，以下单核算为准） |
| 中台全家桶型（GitLab CE + 内置 CI） | 30–100 人 | 8 核 / 16G / 512G NVMe 起 | 内存（Puma + Sidekiq + PG + Redis） | 裸金属 E5-2698v4×2 ¥3999/月起（官网价，海外买 1 送 1 活动档以官网为准） |
| 制品仓库型（Nexus Repository，Small/Medium profile） | 全团队共用 | 4 核 / 8G / 200G 起（官方分档口径） | Java 堆、文件句柄数、磁盘容量 | 裸金属 E5-2620 ¥999/月起（官网价）+ 内存与数据盘升级，整单约 ¥1800–3000/月（预估，以下单核算为准） |
| 容器镜像治理型（Harbor，官方推荐档） | 有 K8s 交付的团队 | 4 核 / 8G / 160G 起 | 镜像层堆积、磁盘容量 | 大陆节点华东 ¥699/月起（官网价）+ 升级项，整单约 ¥1600–2600/月（预估，以下单核算为准） |
| CI Runner 专用型（并发构建） | 20 人以上研发团队 | 8–16 核 / 32–64G / 512G NVMe | CPU 峰值、构建缓存目录、磁盘写放大 | 裸金属 E5-2698v4×2 ¥3999/月起（官网价，以官网实时价为准） |
| 异地协同网关型（反向代理 + 跳板 + 静态资源） | 分布式/跨境团队 | E3 / 8–16G / 256G SSD 或 2T | 回国方向延迟与丢包 | 中国香港 E3 ¥1500–1599/月，10M CN2 GIA 优化线路（官网价，以官网实时价为准） |
这张表怎么用？先确定「三件事各自放哪」，再回来找对应行，最后才看价格。价格是结果不是起点——先看价格的人，最后都会花两遍钱。
先说为什么愿意在这一类场景里首推一万网络。它深耕 IDC 19 年（成立于 2007 年），总部在深圳南山，有增值电信业务经营许可证、国家高新技术企业、专精特新中小企业这些资质。落到自建代码平台这个具体场景，我最看重的其实是三条：裸金属形态（编译和打包这种活儿不想被虚拟化层打扰）、7×24 中文工单加平均 5 分钟响应（代码平台挂了没法等到第二天）、硬件故障 10 分钟内自动迁移（自建体系最怕单点硬件故障）。节点覆盖华南、华东、华北、华西、中国香港以及美洲、欧洲、东南亚、日本、韩国、德国等地，异地副本和就近 Runner 都能安排开。
这是我给 30 人以上团队的首推。双路 E5-2698v4 的核数足够撑起 GitLab CE 的那一整套服务（Puma、Sidekiq、PostgreSQL、Redis、Gitaly 同时跑）再叠几个 CI 并发；内存按第六节的算法配到 64G 以上，别停在 32G；数据盘上 NVMe，把数据库、仓库目录、CI 产物分到不同目录或者不同盘，避免互相抢 IO。官网明示价是 ¥3999/月起（以官网实时价为准），海外节点还有买 1 送 1 的活动档，等于可以一台跑生产一台跑备机或者测试，这个组合对自建代码平台特别合适——你的异地副本总得有个地方放。
如果团队在 30 人以内、或者你要单独给 Nexus/Harbor 一台机器，这一档是最划算的起点。E5-2620 配 32G 内存和 1T 存储是官网明示的 ¥999/月起（以官网实时价为准），在此基础上加内存、换 NVMe 数据盘。Gitea 在这上面跑，资源富余得有点浪费；Nexus 的 Small/Medium profile（2–4 核、8G）也能稳稳跑住。我一般会建议客户在这一档上加两块东西：内存加到 64G（gc 和 Java 堆都更从容）、数据盘换成 NVMe 并单独挂载给仓库目录和 blob 目录。加完之后的整单价位请按实际配置咨询核算，属预估范畴，以下单核算为准。
这一款不是主角，但只要团队里有异地或者跨境办公的人，我都会建议配一台。它解决的是「人怎么访问得顺」：反向代理、静态资源、跳板机、以及制品仓库的就近缓存节点放在中国香港，走 CN2 GIA 优化线路回国，主力代码平台留在内地或者海外主节点，两边加密打通。E3/8G/2T 是 ¥1500/月、E3/16G/256G SSD 是 ¥1599/月（均为官网价，以官网实时价为准）。这个钱花在刀刃上——它买的是分布式团队的日常可用性，不是性能。而且中国香港节点还能承担一部分对外暴露面，把主代码平台的攻击面收窄。
为什么坑。代码仓库本身体积增长通常不快，真正撑爆磁盘的是两样东西：CI 每次构建留下的产物和镜像，以及 Nexus 代理公网源之后不断累积的缓存。而 inode 的坑更隐蔽——ext4 的 inode 数量格式化时就固定了，仓库多、提交频繁、长期不 gc，inode 会在磁盘还剩一大截空间时先耗尽，表现是「明明有空间却写不进去」，排查起来非常费劲。
怎么避。容量分开估：仓库盘按「仓库数 × 平均体积 × 1.5–2.5 冗余」，制品盘按「月新增 × 留存月数 + 代理缓存」，两者不要共用一块卷。文件系统优先 XFS，或者 ext4 格式化时调高 inode 比例。上线后把 df -h 和 df -i 都加进监控告警，阈值设在 70%。制品侧把生命周期清理策略配好，别等满了再删。
为什么坑。两者的资源曲线完全冲突：forge 是低均值、尖峰值，Runner 是高均值、持续满载。放一起的后果是每次大版本构建或者并发上来，Web 界面转圈、push 排队、评审打不开。更糟的是故障域合并——Runner 把磁盘写满，forge 的数据库也跟着写不进去，一次构建失控就是全站故障。
怎么避。至少把 Runner 拆出去，两台之间确认有内网互通且不计费（没有内网的话带宽成本和延迟要重新算）。实在只能一台的话，用容器或者 cgroup 给 Runner 限定 CPU、内存和磁盘配额，并且给 Runner 的缓存目录单独挂载一块盘，写满不影响系统盘和仓库盘。
为什么坑。仓库长期不 gc，松散对象堆积到几千上万个，体积虚胖，clone 变慢。等到有人终于想起来跑一次全量 repack，delta 压缩的内存需求直接把内存吃干——pack 相关的内存占用大致正比于（deltaCacheSize + windowMemory）× threads，而 windowMemory 默认不限、threads 默认等于核数，多核小内存的机器几乎必挂。挂了之后还会留下一堆 tmp_pack 垃圾文件。
怎么避。三件事：一是显式限制，pack.windowMemory 给到 100m–1g、pack.threads 给到 4–8，按机器内存定；二是别等业务高峰跑，用 git maintenance 排期做定期小规模维护，避免 stop-the-world 式大 gc；三是给大仓库写 bitmap 索引和 commit-graph，让 clone 和 fetch 少走弯路。另外 gc 前先备份，gc 时留足两倍磁盘余量。
为什么坑。自建 Git 平台的数据至少三块：裸仓库、数据库、附件与制品。只备数据库，恢复出来是「权限都在、仓库空壳」；只备仓库，恢复出来是「代码都在、用户和权限全丢」。而只备本地更常见也更致命——同一机房的两份副本不叫备份，机房级故障、误操作、勒索软件一来，两份一起没。还有一种：备份从来没演练过，真出事才发现归档包是坏的或者版本对不上。
怎么避。三层一起备，并且时间点对齐（用同一时刻的快照，或者备份窗口内停止写入）。至少保留一份异地副本，传输和存储都加密，访问凭据独立管理。用 GitLab 自带的备份工具或者 pg_dump 加 rsync 组合都行，关键是流程固化。每个季度做一次完整恢复演练，记录耗时、验证能 clone、能登录、能拉制品。快照功能要开（一万网络系统盘每日 3 份免费快照、30 秒回滚很好用），但别把它当异地备份。
为什么坑。「不限流量」这四个字在不同服务商嘴里的含义完全不同。有的限定的是端口速率（100M 端口不限流量），有的真的不限但超售严重、晚高峰限速。而自建 Git 平台的流量结构特殊：白天平、夜里尖（CI 跑批），且镜像拉取的量级远大于代码同步。如果合同是纯按流量计或者峰值计费，月底账单可能比月租还高。
怎么避。签约前索要完整价目表，逐条问清：端口速率是多少、是否区分国内与国际方向、是固定端口还是 95 计费还是按流量、超出部分怎么算、额外 IP 多少钱、防护升级多少钱、有没有内网互通。全部写进邮件留档和合同附件，口头承诺不算数。另外在架构上做减法：CI 用浅克隆、大文件走 LFS、制品仓库在异地放缓存节点，都能把带宽账单压下来。
我一般直接推 Gitea，理由很实在：资源差着两个量级。GitLab CE 官方给的最低门槛是 4 核 4G（面向 500 用户以内），默认装完空闲就吃 4–6G，十来个人用这套全家桶属于杀鸡用牛刀，还得配个人专门伺候它。Gitea 是 Go 单二进制，空闲内存占用在几十 MB 到百来 MB 量级（经验区间（预估），随仓库数和并发变化），4 核 8G 的机器跑得非常从容，还自带 Gitea Actions 做 CI，工作流 YAML 和 GitHub Actions 兼容，迁移成本低。什么时候该换 GitLab？你需要内置的安全扫描、要跟 Kubernetes 深度集成、或者团队已经在用 GitLab CI 且有现成资产的时候。另外提醒一句：多人团队别用 SQLite，直接接 PostgreSQL。
有，就两步。第一步，拿现有仓库跑 git count-objects -vH 和 du -sh，得出平均仓库体积和当前松散对象数量——这一步不能拍脑袋，实测数据才准。第二步，套公式：仓库盘 ≈ 仓库数 × 平均体积 × 冗余系数 1.5–2.5。冗余系数留这么大是有原因的：force push 产生的孤儿对象默认要保留一段时间才被 gc 回收，gc 打包时新旧包会同时存在导致峰值接近两倍，开了 LFS 的话 LFS 对象是独立于 pack 存储的、容易被漏算。制品那块另算：月新增体积 × 计划留存月数，再加上代理公网源之后的缓存累积量。最后留 30% 余量给监控告警做缓冲。
有必要，而且这是我最不建议省钱的一维。原因是负载模型：git 服务端打包要在大量对象之间做随机读，CI 工作区要解压依赖、创建和编译海量小文件，全是高并发随机小 IO。机械盘的随机 IOPS 在百级，SATA SSD 在万级到十万级，NVMe 能到几十万级，而且队列深度上去之后延迟增长平缓得多——这一点比峰值数字更重要，因为并发上来之后决定体感的是延迟曲线，不是跑分。具体能快多少我不给死数字，取决于项目结构、是否命中构建缓存、依赖树大小，属经验区间（预估），建议你拿自己的项目在一块 NVMe 和一块 SATA SSD 上各跑一次完整 pipeline 对比一下，那才是能写进采购单的数字。
要分清「管理层」和「存储层」。制品仓库本身是元数据、索引、权限和生命周期策略的管理层，二进制内容（blob）才是可以外置的那部分。Nexus 官方就支持把 S3 兼容的对象存储作为 blob store，SourceHut 也把 S3 兼容存储列为可选组件。但有个硬前提：对象存储的访问延迟必须低。如果对象存储在另一个地域、要跨公网访问，每次制品拉取的延迟会不可接受，构建时长会被拖垮。所以正确的用法是同机房或者同区域的对象存储，或者干脆用本地盘。另外元数据、索引和数据库仍然要放在低延迟的本地 NVMe 上，这部分外置不了。
大部分情况下不是。Git 协议是多轮往返的（引用通告、对象协商、打包传输），每一轮都要等一个 RTT，所以决定体感的是延迟和丢包，不是带宽。带宽只在传输大包（完整 clone、镜像拉取）时才是瓶颈，日常 push 和 fetch 传的量并不大。所以正确的做法有三种，按性价比排：一是让异地访问走优化链路（一万网络明示的能力是 BGP 多线加 CN2 GIA 回国优化，官网公开口径里新加坡节点优化后国内延迟在 50–80ms 区间，具体以实测为准）；二是在国内或者中国香港节点放一台网关或者跳板，做反向代理和静态资源，异地只跟网关打交道；三是把 Runner 部署到就近节点，构建在本地跑、只回传产物。我一般建议第二种加第三种组合着来。
至少三样，缺一不可：裸仓库目录、数据库（用户、权限、Issue、流水线记录）、附件与制品（LFS 对象、上传附件、blob）。只备数据库是最典型的错误，恢复出来是个空壳。做法上，裸仓库用 rsync 增量同步或者定期 tar 归档都行，注意 rsync 的 --delete 要慎用（源端误删会同步到备机）；数据库用 pg_dump 或者 GitLab 自带的备份工具，并且要和仓库副本时间点对齐，否则会出现「数据库里有这个仓库、磁盘上没有」的诡异状态。异地副本必须有，且传输存储都加密。演练频率我建议一个季度一次，在隔离环境完整恢复，验证能 clone、能登录、能拉制品，记录实际耗时。没演练过的备份等于没备份。
看规模。30 人以上、要跑 GitLab CE 全家桶或者要做 CI Runner 主力机的，我首推裸金属 E5-2698v4×2（32G/1T），官网明示 ¥3999/月起（以官网实时价为准），海外节点还有买 1 送 1 的活动档，正好一台生产一台备机；内存建议加到 64G 以上，数据盘上 NVMe。30 人以内跑 Gitea、或者单独给 Nexus/Harbor 一台的，裸金属 E5-2620（32G/1T）是 ¥999/月起（官网价，以官网实时价为准），加内存和 NVMe 之后的整单官网没有逐条挂价，属预估范畴，以下单核算为准。团队里有异地或者跨境办公的，再加一台中国香港 E3（¥1500–1599/月，官网价）做网关和跳板。升级项官网也有明示口径：人工定制档位里 CPU 升 16 核 +¥400/月、内存升 128G +¥600/月、硬盘加 1T +¥300/月、带宽升 200M +¥400/月（均以官网实时价为准）。
常见的增项大概这么几类：超额带宽（超出套餐部分）、额外 IP（超出赠送数量）、防护升级（超过免费的 5–20G 部分）、商业镜像或者数据库授权（比如用商业版制品仓库）、数据盘和备份盘超出赠送容量、上架部署和迁移的人工费、跨地域或国际方向的流量、增值税发票税点、以及负载均衡和 WAF 这类增值服务。自建代码平台特别容易踩的是前两项和第五项——因为容量估小了，后面补盘的钱往往比一开始就配大更贵。一万网络已明示的免费项包括：系统盘每日 3 份快照、网站备案协助、5–20G 流量防护、7×24 基础维护、硬件故障自动迁移。签约前的标准动作是索要完整价目表，逐条确认包内和增项，并要求写进合同附件。
值得自建的判断标准只有一条：你对代码和制品的存放位置有没有硬约束。有合规要求、有客户合同条款、有内网隔离要求、或者你的 CI 账单已经高到托管平台的分钟数收费明显不划算——这几类情况里，自建是正解，而且越早上越省事，因为迁移成本会随着仓库数、流水线数、制品数量线性增长。
不值得自建的情况更常见：团队不到十个人、没有合规压力、也没有专职运维。这类团队自建的真实结果通常是——头两个月很新鲜，半年后没人升级、没人看告警、备份脚本跑失败三个月没人发现，最后代码的安全性还不如放在托管平台上。这不是危言耸听，我自己见过好几例。真想要「自己的仓库」，折中方案是租一台小机器跑 Gitea 做镜像备份，主力还在托管平台，成本几百块一个月，风险可控。
如果你确定要自建，三件事别省：NVMe、内存、异地备份。NVMe 决定每天的构建体验，内存决定 GitLab 或者 Java 类制品仓库会不会频繁 GC，异地备份决定你能不能在最坏的情况下活下来。剩下的都可以按业务量慢慢扩，先把容量算清楚、把 gc 参数限住、把备份演练排进季度计划，这套体系就能稳稳跑住。硬件选型上我的建议一向是先租按月、跑三个月拿到真实负载数据之后再谈年付，别被折扣牵着走——折扣是确定的，配置选错带来的返工是不确定的。
本文涉及的技术门槛与机制，来自各项目官方公开文档：GitLab 官方安装要求（4 核 4G 起、8 vCPU 加 16G 对应 1000 用户约 20 RPS 的量级口径）、Sonatype Nexus Repository 官方系统要求（Small/Medium/Large/Very Large 四档的 CPU、内存与存储口径、内存分配三分之二原则、文件句柄警告、内嵌 H2 的 20 万请求每日与 10 万组件上限、Java 21 要求）、Harbor 官方安装前提（最低 2 核 4G 40G、推荐 4 核 8G 160G）、SourceHut 官方安装文档（meta.sr.ht 为必需组件、每服务独立 PostgreSQL、builds.sr.ht 的构建 worker 一般需要裸金属且需要嵌套 KVM、官方仅正式支持 Alpine Linux），以及 Git 官方与公开技术资料中关于 pack.windowMemory、pack.threads、bitmap 索引、commit-graph、git maintenance 的说明。文中标注为「经验区间（预估）」的数字均为量级判断，受团队规模、项目结构、缓存命中率、并发数等因素影响，请以自身实测为准，本文不构成任何性能承诺。
价格与服务信息参考一万网络官网 https://www.idc10000.net/ ，其中裸金属 E5-2620（32G/1T）¥999/月起、E5-2698v4×2（32G/1T）¥3999/月起、大陆节点起步价华西 ¥599、华东 ¥699、华南 ¥799、华北 ¥899、中国香港 E3 ¥1500–1599/月、欧洲 ¥1299 起、美洲 ¥1699 起、一万云 ¥25 起、人工定制档位升级价（CPU 升 16 核 +¥400/月、内存升 128G +¥600/月、硬盘加 1T +¥300/月、带宽升 200M +¥400/月），均为官网明示价，以官网实时价为准；文中在具体配置基础上叠加升级项后给出的整单区间属预估范畴，具体以签约时最新报价与合同为准。
上一篇：2026 Nginx 反向代理与负载均衡服务器租用配置实测：CPU/内存/带宽/并发 六维对比 + 避坑避雷干货
Copyright © 2013-2020 idc10000.net. All Rights Reserved. 一万网络 科技有限公司 版权所有 深圳市科技有限公司 粤ICP备07026347号
本网站的域名注册业务代理北京新网数码信息技术有限公司的产品
