很多 PHP 项目跑在 Linux 上时，真正影响响应速度和稳定性的，往往不是某一个单独参数，而是 PHP-FPM、php.ini 与 Nginx 或 Apache 之间是否配合得当。下面按部署中最常见的三层配置展开，保留可直接使用的命令和示例，同时补出每类参数的判断依据，方便你在改动后知道该看什么、该怎么继续调。
PHP-FPM：先把进程模型和慢请求排查能力配好
PHP-FPM 是目前最常见的 PHP FastCGI 实现，它直接决定 PHP 请求是如何被调度和处理的。配置文件通常位于 /etc/php/7.x/fpm/pool.d/www.conf 或 /etc/php/7.x/fpm/php-fpm.conf，其中 7.x 需要替换成实际安装的 PHP 版本。
实际调优时，优先关注进程管理方式、子进程数量、超时时间和慢日志：
; 增加进程管理器进程数
pm = dynamic
pm.max_children = 50
pm.start_servers = 5
pm.min_spare_servers = 5
pm.max_spare_servers = 35
; 调整请求处理超时时间
request_terminate_timeout = 30s
; 启用慢日志
slowlog = /var/log/php-fpm/www-slow.log动态进程模式为什么适合大多数场景
pm = dynamic 代表 PHP-FPM 会根据负载在一定范围内动态维持空闲和工作进程。对于普通业务站点、后台系统和中小型接口服务，这通常比静态配置更容易兼顾内存占用与并发处理能力。
其中 pm.max_children = 50 常被用作中等规模机器的起点值，但它不是固定答案。这个值最终要看单个 PHP 进程的平均内存消耗，以及服务器总内存还要给数据库、缓存、Web 服务器和系统本身留出多少空间。并发高但内存小的环境，盲目把它调大，结果往往不是更快，而是频繁触发内存压力。
空闲进程参数决定高峰期是否容易抖动
pm.start_servers、pm.min_spare_servers 和 pm.max_spare_servers 控制的是启动时和运行时保留多少空闲进程。空闲进程太少，流量突然上来时需要频繁拉起新进程；空闲进程太多，则会长期占用内存。示例里的 5、5、35 更适合“有一定并发但不是超高峰”的通用部署。
超时与慢日志是排查瓶颈的基础配置
request_terminate_timeout = 30s 可以避免异常请求长期挂住工作进程，尤其适合存在外部接口调用、慢 SQL 或偶发阻塞的应用。这个值不宜随意设得过长，否则 PHP-FPM 进程会被慢请求拖住，吞吐量明显下降。
slowlog = /var/log/php-fpm/www-slow.log 则是定位问题时最有价值的配置之一。它能帮助你找出哪些请求执行异常慢，从而判断问题到底出在代码、数据库、文件 IO，还是上游服务。很多时候，性能优化的第一步不是继续改参数，而是先通过慢日志找到真正的慢点。
配置改完后，需要重启 PHP-FPM 让新参数生效：
sudo systemctl restart php7.x-fpmphp.ini：内存、缓存和上传限制要一起看
PHP 的全局行为主要由 php.ini 控制。常见位置包括 /etc/php/7.x/cli/php.ini 和 /etc/php/7.x/apache2/php.ini，具体要看你修改的是 CLI 环境还是 Web 运行环境。生产环境里，很多人改了 CLI 配置却没有改 Web 对应文件，最后发现页面表现没有变化，这一点需要先确认清楚。
内存限制：先给合理起点，再按业务上调
memory_limit = 256M256M 对多数现代 PHP 框架来说，是一个相对稳妥的起点值。它既不会像过低限制那样频繁触发内存不足，也不会一开始就把单进程上限放得太宽。
如果你的业务涉及图片处理、批量导出、复杂报表或大体量数组运算，256M 可能仍然不够；反过来，如果应用只是轻量接口或简单内容站，设置过高也会放大单请求的资源占用。这里的思路不是“越大越安全”，而是先给出能跑稳的基线，再根据错误日志和真实负载调整。
OPcache：多数 PHP 站点最直接的性能收益点
[opcache]
zend_extension=opcache.so
opcache.enable=1
opcache.memory_consumption=128
opcache.interned_strings_buffer=8
opcache.max_accelerated_files=4000
opcache.revalidate_freq=60OPcache 的作用是把编译后的 PHP 脚本缓存在共享内存中，减少每次请求都重新编译脚本的开销。对于代码文件数量较多、请求频繁的项目，这往往是最容易看到收益的一项优化。
这组参数里，opcache.memory_consumption=128 和 opcache.max_accelerated_files=4000 属于很常见的中小型项目配置。它们通常足以覆盖常规框架项目、后台管理系统和内容站点。如果项目文件量更大，或者部署了多个大型组件，命中率不理想时再考虑继续上调。
opcache.revalidate_freq=60 表示 PHP 不会在每次请求都检查脚本是否更新，这能减少文件状态检查带来的开销。它适合以稳定发布为主的环境；如果你在频繁开发调试，就要结合实际发布方式确认是否需要更及时的更新检测。
禁用不必要函数：重点在安全边界，不是机械精简
; 禁用不需要的模块
disable_functions = ...这里没有标准通用答案，必须根据业务判断。如果应用根本不需要执行系统命令，可以考虑禁用 exec、shell_exec 等函数。这样做首先是收紧安全面，其次才是减少潜在开销。
需要注意的是，某些框架、队列组件、图像处理工具或部署脚本可能依赖相关函数。如果没有核对实际使用情况就直接禁用，反而可能引发功能异常。因此这一项更适合在你已经明确运行边界之后再做。
上传大小限制：两个参数必须同步考虑
upload_max_filesize = 10M
post_max_size = 10Mupload_max_filesize 控制单个上传文件大小，post_max_size 控制整个 POST 请求体大小。两者如果不协调，最常见的结果就是看起来配置了上传限制，但用户上传稍大一点的文件仍然失败，而且报错信息并不总是直观。
示例中的 10M 对多数普通表单和附件上传已经够用。如果业务有视频、设计稿、压缩包等更大文件需求，这两个值需要一起调整，而不是只改其中一个。
Web 服务器：Nginx 和 Apache 都要围绕传输与并发来调
PHP 自身调好后，Web 服务器仍然会明显影响整体表现。这里的关键不只是“能跑起来”，而是要让静态文件传输、压缩、连接保持和 PHP 转发逻辑处在合理状态。不同环境使用 Nginx 或 Apache，都有各自需要优先检查的配置点。
Nginx：自动匹配 CPU、启用压缩、明确 PHP 转发
Nginx 主配置文件通常在 /etc/nginx/nginx.conf，站点级配置也可能拆分到单独文件。常见优化重点包括 worker_processes、连接数、文件传输和 gzip：
worker_processes auto;
events {
worker_connections 1024;
}
http {
sendfile on;
tcp_nopush on;
tcp_nodelay on;
keepalive_timeout 65;
types_hash_max_size 2048;
include /etc/nginx/mime.types;
default_type application/octet-stream;
gzip on;
gzip_disable "msie6";
server {
listen 80;
server_name example.com;
root /var/www/html;
index index.php index.html index.htm;
location / {
try_files $uri $uri/ =404;
}
location ~ .php$ {
fastcgi_pass unix:/var/run/php/php7.x-fpm.sock;
fastcgi_index index.php;
include fastcgi_params;
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
fastcgi_param PATH_INFO $fastcgi_path_info;
}
}
}worker_processes auto 会让 Nginx 根据 CPU 核心数自动设置工作进程数量，通常是默认优化里最省事也最可靠的一项。worker_connections 1024 则决定每个工作进程可处理的连接规模，实际承载能力还要结合系统文件句柄限制一起看。
sendfile on、tcp_nopush on 和 tcp_nodelay on 属于典型的网络传输优化组合，能帮助静态内容发送更高效。keepalive_timeout 65 则影响连接复用时间，过短会增加握手成本，过长则可能占用更多连接资源。
压缩方面，gzip on 可以显著减少 HTML、CSS、JavaScript 等文本内容的传输体积，对带宽和首屏加载都有帮助。但已经压缩过的图片、视频、归档文件通常不适合再做二次压缩，否则收益有限，还会增加 CPU 负担。
PHP 转发部分要特别核对 fastcgi_pass unix:/var/run/php/php7.x-fpm.sock 是否与当前 PHP-FPM 套接字路径一致。很多“页面 502”问题并不是 PHP 代码出错，而是这里的套接字路径、版本号或运行方式没有对应上。
Apache：先确认使用哪种 MPM，再看压缩与缓存
如果环境使用 Apache，性能表现很大程度上取决于 MPM（多处理模块）配置。不同 MPM 的并发模型不同，所以参数不能混着理解。下面是 prefork、event 和 worker 三种常见模式的示例：
StartServers 5
MinSpareServers 5
MaxSpareServers 10
MaxRequestWorkers 150
MaxConnectionsPerChild 0
StartServers 2
MinSpareThreads 25
MaxSpareThreads 75
ThreadLimit 64
ThreadsPerChild 25
MaxRequestWorkers 150
MaxConnectionsPerChild 0
StartServers 2
MinSpareThreads 25
MaxSpareThreads 75
ThreadLimit 64
ThreadsPerChild 25
MaxRequestWorkers 150
MaxConnectionsPerChild 0
AddOutputFilterByType DEFLATE text/html text/plain text/xml text/css text/ja vascript application/ja vascript
ExpiresActive On
ExpiresByType text/html "access plus 1 week"
ExpiresByType text/css "access plus 1 month"
ExpiresByType application/ja vascript "access plus 1 month"
prefork、event 和 worker 的资源占用方式不一样。你首先要知道当前 Apache 实际启用了哪一种，再去调整对应参数，否则改动很可能没有意义。示例中的 MaxRequestWorkers 150 可以作为通用参考，但能否撑住还取决于单请求资源消耗和服务器规格。
mod_deflate 负责压缩输出内容，目标与 Nginx 的 gzip 类似，都是减少文本响应体积；mod_expires 则通过设置缓存过期时间，让浏览器和中间缓存减少重复请求。像 CSS 和 JavaScript 这样的静态资源设置为 access plus 1 month，通常能明显降低重复访问时的后端压力。
除了调参数，还要补上连接、缓存和数据库层优化
把 PHP-FPM、php.ini 和 Web 服务器都配置好之后，系统性能通常会有一轮可见提升，但这还不是全部。如果应用本身访问数据库频繁、重复查询多，或者外部依赖较重，单靠 Web 层调优很快会碰到天花板。
持久连接适合高并发场景，但要看数据库侧承受能力
在数据库连接层启用持久连接，可以减少每次请求都重新建立 TCP 连接的开销。在并发较高、请求生命周期短的环境里，这类优化有时能带来稳定收益。不过它并不是无条件更优，因为数据库侧也要能承受更多长期维持的连接。
缓存系统比单纯加机器更值得优先考虑
Redis 或 Memcached 仍然是 PHP 应用最常见的缓存方案。把高频访问的数据，例如查询结果、热点配置、会话数据缓存起来，可以直接减少数据库压力，也能让 PHP 请求路径变短。相比反复调小参数，这通常是更接近业务本质的优化方式。
数据库优化经常决定最终上限
如果慢点来自数据库，应用层参数再漂亮也只能缓解一部分问题。合理建立索引、定期清理碎片、分析并优化慢查询，往往比继续增加 PHP 进程数更有效。尤其是读写混合、报表查询多或历史数据量大的项目，数据库层就是最终瓶颈所在。
每次只改一个变量，才能知道优化是否真的有效
无论你调整的是 PHP-FPM、php.ini，还是 Nginx、Apache，改完后都要重启对应服务让配置生效。更重要的是，不要一次性改动太多项。每次只调整一个关键参数，再结合响应时间、错误日志、慢日志和机器资源使用情况观察结果，才更容易找到真正适合当前业务的配置组合。
性能优化从来不是“一套参数通吃所有项目”。上面的示例更适合作为 Linux 上 PHP 服务的起步模板：先让进程模型、脚本缓存、压缩传输和缓存策略回到合理区间，再根据应用体量、并发模式和资源瓶颈继续细调，效果通常会比盲目抄配置稳定得多。
