本地能跑不等于线上能用：小项目上线前的 7 项检查

本地能跑不等于线上能用：小项目上线前的 7 项检查

每个做过小项目的开发者都经历过这一幕：本地跑得好好的，一部署到线上就出问题。接口 500、静态资源 404、定时任务悄悄停了，用户一反馈才发现服务早就挂了。问题往往不在代码本身，而在本地和线上环境的差异。下面这 7 项检查，是我每次上线前都会过一遍的清单，成本很低，能挡住绝大多数低级事故。

第一，环境变量和配置。本地写死的端口、数据库地址、第三方接口地址，上线后必须全部改成环境变量注入。最常见的一类事故就是代码里残留了 localhost，或者测试环境的密钥被带到了生产。检查方法很简单：全局搜一遍 localhost、127.0.0.1 和测试域名，确认生产配置全部来自环境变量，敏感信息不进代码仓库。

第二，端口与进程守护。本地用命令行启动、关掉终端服务就停，这在线上是行不通的。服务必须以后台进程或系统服务的方式运行，崩溃后能自动重启。部署完先做一次验证：主动杀掉进程，看它是不是自己爬起来了；再重启一次机器，看服务是不是随系统启动。

第三，日志要能找到。本地调试靠控制台打印，线上出问题时控制台早就不见了。上线前确认三件事：日志写到了固定文件或日志服务里、日志带时间戳和请求标识、错误日志和正常日志分开。没有这三样，线上排障基本等于盲人摸象。

第四，静态资源路径。单页应用和静态站最容易在这里翻车：本地用根路径访问没问题，部署到子路径下，JS、CSS、图片全 404。上线后第一件事就是用无痕模式打开页面，按 F12 看网络请求有没有 404，再点一遍所有关键按钮和跳转。

第五，定时任务的存活确认。很多小项目的定时任务是靠 cron 或平台定时触发的，部署时最容易被漏掉。上线后不要假设它在跑，主动等一个触发周期，或者手动触发一次，确认日志里有执行记录。定时任务静默失效是最难发现的一类问题，因为它不报错，只是不干活。

第六，备份与回滚。哪怕是个人小项目，上线前也要想好两件事：数据丢了怎么恢复，部署坏了怎么回滚。数据库至少要有一份可用的导出或快照；部署包保留上一个稳定版本，出问题能在几分钟内切回去，而不是现找代码重新打包。

第七，健康检查与告警。服务挂了要能第一时间知道，而不是等用户来报。最低成本的做法是：一个返回 200 的健康检查接口，加上外部的定时拨测，拨测失败就发消息提醒。没有告警的监控等于没有监控。

这 7 项检查加起来不过十几分钟，却能把上线后最常见的事故挡在门外。本地能跑只是第一步，线上能扛才是交付的完成标准。把这份清单保存下来，下次上线前逐项打勾，你会发现深夜被叫起来修服务的次数明显变少了。