一款运行了23年、单一服务器承载几十万玩家共享经济的太空游戏,终于要跟Python 2说再见了。CCP Games在公告里语气克制得反常——没给完成日期,没提怎么替换调度器,只说第一阶段用futurize脚本处理了240万行代码。这不是一次寻常的版本升级,而是一次不能停服、不能出错的心脏手术。
EVE Online从2003年上线起就跑在Stackless Python上,2010年升级到2.7之后再没大动过。2020年Python 2官方寿终正寝,业界迁移潮基本在那前后完成,EVE拖到2026年才正式启动,晚了整整六年。
95.9%达标,剩下的4.1%才是真麻烦
CCP的初步扫描显示,2万个文件里95.9%已经能同时在Python 2.7和Python 3下编译通过。听起来像是活已经干完了大半,但这恰恰是最容易被误读的一句话——能编译通过,不等于跑起来结果一样。
真正硬性不兼容的代码只有约3300行,主要是四类老写法:旧式print语句、形如123L的长整数字面量、过时的异常子句、旧版不等号操作符<>。这部分是体力活,机器辅助加人工扫一遍基本能解决。
真正棘手的是另外约2万行代码——语法完全合法,两个版本都能跑,但执行结果可能悄悄不同。公告里举的例子很直白:1 / 2在Python 2里是0,在Python 3里是0.5。这种差异出现在普通脚本里是bug,出现在EVE的经济系统里,可能意味着一笔ISK结算错了、一次伤害计算偏了、一个坐标漂移了。玩家资产、货币、坐标全靠这套代码的正确性撑着,这才是CCP真正要死磕的地方。
- 风险.这2万行代码没有捷径,只能靠人工逐条比对Python 2和3的执行差异,任何一处漏审都可能损坏23年积累下来的经济数据。
一个23岁的代码库,为什么现在才动手
Stackless Python在2003年被选中,是因为它能用轻量级“任务”(tasklet)撑起EVE那种成千上万玩家同屏互动的调度模型。这个选择在当时是聪明的,但也意味着EVE的并发逻辑从根上就没打算跟着Python主线走。2010年升级到2.7之后,CCP显然是在“够用就不动”和“动了怕出事”之间选了前者。
超长生命周期代码库不是EVE独有的问题,只是它把这个问题暴露得格外彻底。一款靠单一持久化经济系统运转的游戏,牵动的不只是代码质量,还有几十万玩家账户里实实在在的虚拟财富。CCP旗下新游戏EVE Frontier已经在Carbon引擎上跑通了现代Python 3,跨越了十二个小版本,这给老游戏迁移攒了经验,但风险量级完全不是一回事——新游戏没有历史包袱,老游戏有23年的存量数据要保住。
公告没提怎么替换Stackless的调度模型,但CCP此前公开过Carbon引擎的调度器项目carbonengine/scheduler,也在GitHub上放出了自己维护的CPython分支和greenlet分支。这些线索指向一个合理猜测——用现代CPython加greenlet协程,搭配自研调度器延续tasklet式编程模型——但这仍是社区推测,CCP没有正面证实。
三种声音里,藏着一个被误解的期待
工程圈的Lobsters社区更关心这次迁移的稀有性本身,好奇动态类型语言排查语义差异会有多痛苦。开发者聚集的r/programming更审慎,共识是“语法转换容易,行为迁移难”,str和bytes的边界问题、第三方库兼容性才是真正的雷区,也有人建议干脆把关键路径改写成Rust或C++——但那已经是另一个量级的架构重写,不是这次迁移能解决的问题。
玩家群体的关注点更实际:这次改动能不能缓解舰队大战时的时间膨胀,还是只是换了个语言版本、底层瓶颈原地不动。这个疑问是对的。
换语言版本不等于游戏变快。
Python 3.11相比3.10在官方基准测试里平均提速约25%,但这个数字来自解释器层面的通用负载,不代表EVE的舰队战斗延迟会同比下降。如果性能瓶颈本来就在数据库、网络I/O或调度模型上,解释器跑得快一点,传导到玩家能感知的层面可能微乎其微。这次迁移更现实的收益,是终于能用上现代调试和性能分析工具,给未来的架构优化留出空间——这是长期收益,不是马上兑现的加速包。
- 结论.CCP给这次迁移定的成功标准是“玩家几乎无感”,这恰恰是判断这场高风险改造有没有做对的唯一硬指标。
“其兴也勃焉,其亡也忽焉”说的是王朝更替的速度,放在这里未必贴切——EVE这次不是速朽,而是选择用最慢、最保守的方式活下去。一个能撑23年的系统,愿意为了不出错多等六年,这份克制本身,比迁移这件事更值得记一笔。