小项目上线清单：从本地跑通到云服务器稳定运行

很多小项目在本地跑得好好的，一部署到云服务器就出问题：页面打不开、接口报 502、第二天发现服务悄悄挂了。问题往往不是代码本身，而是上线时漏了几步检查。下面这份清单是我每次部署小项目时固定走的流程，按“上线前、上线中、上线后”三段来做，照着走一遍，大部分低级故障都能在上线前拦住。

一、上线前：先在本地把“生产形态”跑一遍

本地开发时常用的做法是直接跑源码、开调试模式、连本地数据库，到了服务器上换成另一套运行方式，差异就藏在这里。上线前，先在本地用和生产一致的方式跑一次：用生产模式启动应用，关掉调试开关，确认静态文件、环境变量、数据库连接这些不是靠开发环境的默认值撑着的。

环境变量要单独列一张表：数据库地址、端口、账号密码、第三方接口的密钥、日志级别，每一项都要确认服务器上有对应的值，而不是代码里写死的默认值。密钥一律从环境变量或服务器上的配置文件读，不要写进代码仓库，更不要为了图省事把测试环境的密钥直接用到生产。

依赖也要锁定。本地装的是最新版，服务器上装的也是最新版，但两次安装隔了几天，版本可能已经不一样，结果就是本地能跑、线上报错。把依赖版本写死在清单文件里，部署时按清单安装，升级依赖要单独走一次测试，而不是在上线当天顺手升级。

二、上线中：端口、反向代理、进程守护三件套

云服务器部署最常见的结构是：应用跑在内网端口上，Nginx 在前面做反向代理，对外只暴露 80 和 443 端口。应用本身不要直接对外暴露高位端口，既不安全，也不利于以后加 HTTPS 和负载均衡。Nginx 配置写完先做语法检查再重载，改错配置导致所有站点一起挂掉，是最不应该犯的错误。

进程守护是很多人漏掉的一步：用命令行直接启动应用，终端一关服务就没了，服务器一重启服务也不会自动回来。正确的做法是用 systemd 这类系统服务来托管：写一个简单的服务文件，指定工作目录、启动命令、环境变量文件、失败自动重启。配好之后做两次验证：手动停掉服务看它能不能自动拉起来，重启一次服务器看它是不是随系统自动启动。这两次验证通过，才算真正“上线”了。

数据库和文件权限也要在上线中确认。应用连接数据库用的账号，只给它需要的最小权限，不要用管理员账号跑业务；上传目录、日志目录的写权限要给到运行应用的那个用户，而不是图省事全改成 777。权限放得太宽，当时省事，出问题时排查起来全是隐患。

三、上线后：健康检查、日志、回滚三道保险

服务起来之后，先不要急着宣布上线成功。先从外网访问一次真实地址，确认首页、登录、核心接口都能走通，再看一遍应用日志里有没有报错。很多部署问题在启动时不报错，第一次真实请求才暴露出来，只看“进程在跑”是不够的。

健康检查和日志是上线后的第一道保险。给应用加一个轻量的健康接口，只返回运行状态；再配一个定时检测，连续两次失败就提醒。日志要按天切割、保留两周左右，并且确认日志里没有打印密码和令牌。没有健康检查，服务挂了只能等用户来告诉你；没有日志，出问题只能靠猜。

回滚方案要在上线前就想好，而不是出问题时现想。代码用版本控制管理，每次部署记下对应的提交号；数据库有结构变更时，先备份再执行，变更脚本要能正向跑、也要想好反向怎么处理。回滚的判断标准也要提前定好：比如核心接口连续报错超过五分钟、或者新功能导致数据写错，就立刻回滚到上一个版本，不要在生产环境上反复修修补补。

四、一个最小可用的上线顺序

把上面这些收敛成一个固定顺序，每次部署照单执行：本地生产模式跑通并锁定依赖，服务器上建好目录和最小权限账号，写好 systemd 服务文件并验证自启，配好 Nginx 反向代理并做语法检查，从外网走一遍核心流程，确认健康检查和日志都在工作，最后记下本次部署的版本号和回滚步骤。

小项目不需要复杂的发布平台，但需要一套固定的流程。流程的价值不在于它多高级，而在于每次都一样：一样的检查项、一样的验证步骤，出问题时你能立刻定位到是哪一步没做，而不是从头猜一遍。把这份清单存下来，下次上线直接照着打勾，部署这件事就会从“凭运气”变成“可重复”。