容器化部署实战：Nginx 反向代理与 WordPress 原生方案的取舍
容器技术让应用交付变得标准化，但”是否所有服务都该容器化”仍是一个值得深思的工程决策。本文以一次站点迁移为例，对比容器反向代理与原生部署两种方案的适用场景。
一、场景回顾
此前，某站点通过 Docker 容器运行应用，并由 Nginx 作为反向代理对外提供访问。容器方案带来了环境一致性，但同时也引入了额外的网络跳转与运维复杂度。在业务形态变化后，站点需要切换为以内容管理为核心的形态，这促使我们重新评估部署策略。
二、反向代理 vs 原生 PHP-FPM
方案一（反向代理）：应用跑在容器内，Nginx 将请求转发到容器端口。优点是与宿主机隔离、便于多实例伸缩；缺点是增加了代理层的性能损耗与排障链路。
方案二（原生 PHP-FPM）：Nginx 直接与 PHP-FPM 通过 Unix Socket 通信，省去一层转发。对于 WordPress 这类以 PHP 为核心的站点，原生方案响应更快、配置更直观，也更利于结合 OPcache 做内存级优化。
三、取舍标准
没有绝对最优，只有适合与否：
- 追求弹性伸缩、多副本扩展 → 容器化更合适；
- 内容型站点、追求响应速度、运维简单 → 原生部署往往更省心；
- 两者亦可混用：静态资源走 CDN，动态 PHP 走原生 FPM。
四、迁移注意事项
从容器切到原生时，最需关注两点：一是数据持久化，确保数据库与上传目录迁移完整；二是环境差异，容器内依赖需在宿主机核对无误后再上线。
结语
技术选型应以业务目标为出发点，而非追逐某个流行词汇。理解每种方案的边界，才能做出经得起时间检验的决策。