PHP项目通过Nginx发布上线，发布前需要校验网站根目录、伪静态规则、静态资源缓存、PHP-FPM连接参数，同时做好版本备份，搭建清晰的回退方案，降低发布故障带来的业务中断。
发布前：Nginx基础站点配置核对
PHP站点使用Nginx作为web服务，很多线上故障并不是代码bug，而是Nginx配置疏漏。发布新版本之前，优先核对server块的基础配置。首先确认root根目录是否正确，避免指向旧目录或者测试目录；index默认首页顺序，一般配置index.php放在前面，防止目录遍历风险。
域名与SSL证书也要提前核验，检查ssl_certificate、ssl_certificate_key路径，证书是否在有效期内，同时配置ssl协议套件，关闭老旧不安全协议。强制HTTPS跳转的301规则要提前测试，防止循环跳转。监听端口、server_name匹配规则不能写错，避免访问域名落到默认站点。
目录权限是高频踩坑点。网站运行用户和Nginx、PHP-FPM运行用户保持匹配，上传目录需要写入权限，但不要给777权限。禁止直接把项目根目录设置成可执行，减少被利用的风险。同时确认autoindex目录浏览功能关闭，避免目录结构对外暴露。
伪静态、重写规则与路由兼容检查
大部分PHP框架（ThinkPHP、Laravel等）都依靠Nginx rewrite伪静态实现友好URL。伪静态规则写错，会出现页面404、静态文件被转发到PHP解析的问题。区分两类资源：静态资源图片、JS、CSS直接由Nginx读取；动态请求交给PHP-FPM处理。
常见错误：rewrite规则顺序颠倒，或者没有排除真实存在的静态文件。标准思路是先判断文件、目录是否存在，不存在再转发到入口index.php。发布前在测试环境模拟线上URL，逐一测试栏目页、详情页、分页链接、带参数的地址，确认参数可以正常传递到PHP程序。旧站点的301迁移重定向，也要和伪静态分开管理，防止互相冲突。
另外留意请求uri、query_string的传递，有些框架依赖原始请求参数，rewrite时不要丢失参数。规则调整完成，先用nginx -t校验配置语法，语法通过再reload，避免配置直接报错导致站点下线。
静态资源缓存、跨域与防盗链
图片、JS、CSS、字体这类静态资源，合理设置expires缓存头，可以减少后端请求压力。但是静态资源缓存时间不能盲目设置过长，改版后资源更新会出现用户浏览器一直加载旧文件。一般策略：经常改动的脚本缓存短一点，图片类资源缓存周期可以拉长，并且使用资源版本号、hash后缀做刷新。
如果站点有外部资源调用、前后端分离接口，需要配置跨域头；内容型站点可以增加referer防盗链配置，防止图片被其他站点大量盗用消耗流量。注意防盗链规则不要把自己的CDN、内部访问拦截掉。
PHP-FPM连接池、超时、文件上传配置
Nginx只是转发器，真正执行PHP代码的是PHP-FPM，很多超时、502错误根源都在FPM。核对fastcgi_pass地址，是unix socket还是tcp地址，socket文件权限是否正常。重点看几个参数：pm进程管理方式、max_children最大子进程数量、request_terminate_timeout执行超时时间。
max_children不是越大越好，受服务器内存限制，进程过多会造成内存耗尽、频繁swap。超时时间要和Nginx侧的fastcgi_read_timeout配合，如果PHP脚本执行时间较长，两边超时需要同步放大，不然Nginx提前断开连接返回504。
文件上传相关：nginx的client_max_body_size和php.ini里面upload_max_filesize、post_max_size一起核对，一边限制太小就会上传失败。上传目录做好单独限制，禁止上传的文件被当做PHP脚本解析，这是非常关键的安全防护。
发布流程：先备份，再上线
直接覆盖代码是风险最高的发布方式。推荐基于版本目录部署，每一个版本放到独立文件夹，上线通过软链接切换指向。例如current软链接指向正在运行的版本，新版本部署到release目录，验证没问题之后切换软链接。这种模式天然方便回滚。
发布前备份：代码目录备份、数据库备份。数据库优先在低峰期导出，备份文件单独存放，不要放在网站可访问目录。发布步骤建议：上传新版本代码 → 核对文件完整性、权限 → 在测试地址预访问验证 → 切换软链接或者替换配置 → nginx reload平滑加载，尽量避免restart。
平滑reload很重要，Nginx reload不会中断已经在处理的请求；restart会短暂断开连接，用户访问直接报错。reload之后观察error.log、access日志，看有没有大量新增报错。
快速回退方案，故障时优先止损
发布之后出现异常，第一原则是先恢复服务，再排查原因。软链接方式回滚最简单：把current切回上一个稳定版本的目录，重新reload Nginx即可。如果是数据库变更，提前准备回滚SQL，确认故障由数据库变更引起时执行。
区分故障类型：配置错误就回退nginx配置；代码bug切回旧版本；数据问题执行回滚脚本。不要一边在线上反复改代码调试，持续影响用户。发布前就约定好回退触发条件，比如5xx报错量上涨、核心页面打不开，直接触发回滚，故障恢复之后再慢慢定位根因。
上线之后持续监控
发布完成不等于结束，短时间内重点监控：响应状态码、502/504、404数量、接口耗时、CPU和内存负载。观察PHP-FPM进程状态，查看是不是进程堆积、大量慢脚本。有条件可以接入日志收集，快速筛选报错请求。
定期清理过期版本包，防止磁盘占满；证书到期监控，避免证书过期站点HTTPS失效。Nginx+PHP的稳定运行，核心不在于复杂配置，而是发布前逐项校验、流程标准化，并且准备好可靠的回退路径，把发布风险控制住。