本地跑通、线上报错：部署的最后一公里难在哪？

一个站点在本地全部跑通、构建也顺利通过，一部署到线上却报错——这几乎是每个团队上线时都会遇到的场景。AI 让「把功能写出来」这件事快了很多，但从「能构建」到「线上真的能用」，中间还隔着一整层配置，而这层配置既不在代码里，测试也覆盖不到。

我们最近把一个静态站点部署到 Cloudflare Pages，就在这层上接连踩了几个坑。第一类是作用域：平台的环境变量分「预览」和「生产」两套，互相独立，配错了地方线上就是读不到。第二类更隐蔽，是配置的「事实源冲突」——当仓库里放了一个平台配置文件，平台会把它当成配置的唯一来源，你在控制台里辛苦配好的变量会被整体忽略，而报错只告诉你「变量为空」，不会告诉你是那个文件把它们架空了。

还有一类是形态：同一个变量，存成「密文」还是「明文」，运行时读不读得到，行为可能不一样；构建时要用的变量必须在构建那一刻就能读到，运行时的变量则是每次请求才读。这些区别都不写在显眼的地方，往往踩过一次才知道。

比坑本身更值得说的，是怎么排。面对「提交失败」这种被刻意脱敏的报错，靠猜是最慢的。有效的做法是逐层取证：先绕过前端直接调接口，拿到真实的状态码；再翻服务端日志，看到被隐藏的真实错误；最后用一份已知正确的凭据在本地直连同一个外部服务做对照。这样就能把「配置传递错了」和「凭据或资源本身错了」一刀切开。错误信息的每一次变化，都是在帮你缩小范围。

这段经历指向一个常被低估的事实：模型能把功能写出来，但让它稳定跑在真实环境里，依赖的是把配置、部署、排障当成工程来对待的纪律。这也是我们理解的「AI 落地」里最后、也最容易被跳过的一公里——把它一并设计进交付路径，产品才算真的落地，而不是停在「本地能跑」。