本地跑不起来，上线就是演戏：聊聊开发环境的“幻觉”

我之前带过一个新同学，配置环境整整折腾了两天，最后发现由于缺少某个 VPN 权限，连最基础的数据库连不上，只能在那儿干等着。那一刻我意识到，如果一个项目的核心路径在本地根本跑不通，那所谓的“生产就绪”其实只是一场表演。

很多团队现在的状态很危险：CI/CD 流程看起来很绿，文档也写了，但一旦线上出现一个奇葩的 Payload 或者迁移报错，大家第一反应不是去查日志，而是：“谁能帮我重启一下 Staging 环境的 Mock 服务？”或者“谁有这个账号的权限？”

这种靠共享账号和远程环境维持的开发体验（DX），本质上是在透支效率。如果你的工作流必须依赖云端账号或复杂的权限申请才能开始，那这种“部署”其实是在赌运气。

我认为真正的“本地化”不是要把生产环境整个克隆到 Docker Desktop 里，而是要建立一个足够真实的“依赖平面”。

我自己踩过不少坑，总结了一下，一个合格的本地开发环境至少得具备这些：

真实的数据存储： 比如用 Docker 起一个带 pgvector 的 Postgres，哪怕数据是模拟的，也要能本地持久化、能直接用 pgAdmin 去查。

依赖项的 Mock： 别直接调线上 API，用 WireMock 把第三方接口模拟出来，这样你才能测试延迟、超时或者接口报错这种极端情况。

可观测性链路： 这点最关键。本地也要能看 Trace 和 Log，通过 OTel 协议把日志导向本地的 Grafana，而不是等代码上线了才去云端翻日志。

我最近在复用一套类似 dev-tools 的思路，用 Docker Compose 把这些基础设施全拉起来，把原本复杂的依赖变成一行命令：

docker compose up -d

配置逻辑大概是这样的，通过 .env 文件管理端口，确保本地的 n8n、LiteLLM 或者 Hoppscotch 都在同一个 Compose 网络里，互访很方便。

如果你也觉得现在的开发流程太“重”了，总是因为环境问题卡壳，可以参考这种思路把基础设施“降级”到本地跑。本地是成本最低的犯错场所，在本地把 Bug 耗尽，上线才不会心慌。