适合部署SVN的适合公网服务器

三年前我帮一个外包团队迁移版本库，他们用的部署阿里云最低配ECS，1核1G，公网跑着SVN加Apache，服务二十来人同时提交代码，适合居然没崩过。部署这事儿让我重新掂量了SVN对服务器的公网胃口——它真没你想象的那么娇贵。

选公网服务器，服务第一道坎是适合带宽而不是CPU。SVN的部署传输协议虽然比Git省流量，但每个文件变更都要走完整diff，公网遇到二进制资源库，服务一次checkout就能吃掉几百MB。适合我见过最离谱的部署案例，某设计团队把PSD源文件直接塞进SVN，公网50G的仓库，千兆带宽下首次检出要跑四十分钟。所以带宽低于5Mbps的服务器，趁早别碰，尤其是那种“共享带宽”的便宜货，高峰期能卡到你怀疑人生。

磁盘IO才是真正的隐形杀手。SVN的FSFS格式在并发提交时会产生大量临时文件，机械硬盘的随机读写延迟会让提交排队。我手头一个客户，原来用某云厂商的“突发性能实例”，CPU积分耗尽后性能跌到20%，每次commit要等十几秒。后来换了块SSD云盘，同样的代码量，提交时间缩短到两秒以内。别省这几十块钱，NVMe云盘和SATA云盘的差价，远小于你团队成员浪费时间等提交的隐形成本。

操作系统选型上，我强烈推荐Debian或Ubuntu Server，别碰CentOS——它停止维护后，安全补丁就断了。你可能会说“我用宝塔面板”，那更得避开CentOS，宝塔官方都建议迁移到Debian系。装SVN就三行命令：apt install subversion apache2 libapache2-mod-svn，然后改改配置文件，半小时搞定。Windows Server也能跑，但别忘了Windows更新重启会打断svnserve服务，Linux下systemd管理，稳如老狗。

安全组配置是新手最容易翻车的点。默认SVN走3690端口，但如果你用Apache的mod_dav_svn模块，直接走443端口，省得被运营商封端口。我习惯把Apache监听端口改到8443，配合Let's Encrypt免费证书，既避开扫描器对443的常规探测，又能强制HTTPS加密。别嫌麻烦，公网裸奔的SVN服务器，被爆破是迟早的事——我见过有人用密码“123456”，日志里被尝试登录上万次。

内存大小别抠门。虽然SVN本身吃内存不多，但Apache的MPM模块加上mod_ssl，每个连接要占10-20MB。你算算，同时在线50个开发者，每个开两个连接，光Apache就要吃掉2GB。所以最低配建议2GB内存，4GB更稳妥。别信那些“1核1G能跑SVN”的教程，那是针对内网小团队的，公网环境加上海量扫描机器人的连接请求，内存分分钟见底。

最后说个反直觉的观察：公网SVN服务器，地域选择比配置更重要。如果你团队主要在国内，别买香港或海外的服务器，哪怕延迟只有50ms，SVN的同步机制也会让你体感卡顿。我实测过，从上海访问新加坡节点，checkout一个200MB的仓库要八分钟，而同样配置的上海节点只要两分钟。这不是带宽问题，是TCP往返延迟叠加在SVN的请求-响应模式上，被放大了无数倍。

别迷信“大厂高配”，SVN这种老古董协议，吃的是稳定性和低延迟。选个靠谱的云服务商，2核4G、100GB SSD、5Mbps固定带宽，一年也就一千出头，够你用到团队规模突破五十人。到那时候，你可能早该考虑迁移Git了——但那是另一个故事。