我为什么把“本地能跑”从字典里删掉了：一次环境差异引发的血案

做开发的朋友肯定听过这句话：“本地能跑啊，怎么线上就不行？”——以前我觉得这是句玩笑，后来发现这是所有生产事故的通用开头。

我自己的那次“血案”发生在一次大版本上线。本地、测试环境、预发环境，全部验证通过，信心满满地发布生产。结果上线后 10 分钟，订单创建接口开始大面积超时，监控告警直接打爆。我第一反应还是那句：“本地能跑啊……”然后硬着头皮去查。

最后定位到的问题，现在回头看简直可笑：本地用的是 macOS，生产用的是 Linux，而我在代码里拼了一个文件路径：data/export/order_123.xlsx。 macOS 的文件系统默认不区分大小写，data/Export 和 data/export 是同一个目录；但 Linux 区分大小写，而测试环境恰好有人手动建过 data/Export 目录，所以测试也“阴差阳错”能跑。生产环境是全新机器，目录不存在，代码又没有自动创建目录的逻辑，直接抛了 FileNotFoundException，被上层捕获后返回了超时——因为异常被吞了（对，又是吞异常，参见我之前那篇博客）。

这次事故让我彻底明白一件事：“本地能跑”是最低标准，不是合格标准。

从那以后，我做了几件事，彻底改变了自己的开发习惯。

一、开发环境和生产环境，能多像就多像

以前我本地用 H2 内存数据库，生产用 MySQL，美其名曰“轻量快捷”。后来发现，SQL 语法差异、事务行为差异、索引行为差异，每一个都能在生产上给你惊喜。现在我的原则是：

• 本地必须跑跟生产同版本的数据库。Docker 起来一个 MySQL 容器，五分钟的事，别偷懒。
• 中间件版本对齐。Redis、MQ、ES，本地用 Docker Compose 一把拉起，版本号跟生产一致。
• 操作系统差异要警惕。如果你用 Windows 或 macOS 开发，而生产是 Linux，至少准备一台 Linux 虚拟机或容器，在关键流程上跑一遍。文件路径、换行符、权限、信号量——这些“小东西”分分钟教你做人。

我们团队现在新人入职第一天，不是配 IDE，而是跑一条 docker-compose up，把整套依赖服务拉起来。本地环境和生产环境的差异，被压缩到最小。

二、配置分层，别让环境差异藏在代码里

以前我们的代码里到处是 if (env.equals("prod")) { ... } 这种判断，环境差异散落在各个角落，谁也说不清到底有哪些不同。后来我们统一成配置驱动：

• 所有环境相关参数（数据库地址、超时时间、线程池大小、开关）全部外置到配置文件或配置中心。
• 代码里不写任何环境判断，只读取配置。
• 每个环境有独立的配置集，CI/CD 流水线根据环境自动注入。

这样做的好处是：你一眼就能看出两个环境有什么不同，而不是等到上线了才发现“哦原来生产这个超时是 3 秒，测试是 30 秒”。

三、用容器化消灭“我机器上能跑”

Docker 彻底解决了环境一致性的问题。现在我们所有服务都容器化，开发、测试、生产跑的是同一个镜像。你本地 docker run 能跑，上到生产就不会因为“缺个系统库”或者“JDK 版本不对”而翻车。

有个细节值得提：不要只在本地 mvn package 然后手动跑 JAR。要把构建和运行的完整过程写成 Dockerfile，本地就用 docker-compose 启动整套服务。这样你验证的才是“真正的产物”，而不是“编译出来的半成品”。

四、上线前做“最后一步”验证

我们现在的发布流程里，多了一个步骤：在预发环境用生产配置跑一遍核心链路。不是功能测试，是端到端的真实请求验证。因为预发环境的配置、数据量、网络拓扑都跟生产最接近，很多“本地测不出来”的问题会在这里暴露。

一个心态上的转变

以前我觉得“环境差异导致的 Bug”是低级错误，是运维的事。现在我知道，环境一致性是开发的责任，不是运维的恩赐。你写的代码要在生产上跑，你就有义务确保它在生产环境能正常工作——而不是把验证的锅甩给测试、甩给运维、甩给“上线后再说”。

“本地能跑”应该只是起点，不是终点。真正的终点是：在任何环境下都能按预期工作。

如果你现在还在用“本地能跑”来安慰自己，不妨今晚就试试用 Docker 把你的服务完整跑起来——不手动装任何依赖，纯靠容器。如果跑不起来，那恭喜你，你提前发现了上线后会踩的坑。