PHP性能问题多因php.ini参数配置不当：memory_limit需按CLI/FPM场景分设；上传失败需同步调大upload_max_filesize、post_max_size和超时参数；OPcache需调高memory_consumption并关闭validate_timestamps；FPM超时须与Nginx协同配置。
PHP 应用卡顿、上传失败、内存溢出、超时中断——这些问题八成不是代码写的烂，而是 php.ini 里几个关键参数压根没调对。
内存限制不够：memory_limit 到底设多大？
很多开发者一上来就把 memory_limit 改成 2G 或 -1（无限制），结果线上 OOM 被系统 kill。这不是“够用就行”，而是得看运行场景：
- CLI 脚本（如队列任务、导出）可设为
512M～1G，但必须配合gc_collect_cycles()主动回收 - FPM 模式下每个 worker 独占内存，设太高会导致并发数暴跌；建议从
256M起步，观察pm.max_children和free -h的实际占用 -
memory_limit不影响 OPcache 内存，别指望它解决 opcode 缓存不足问题
上传文件总失败？重点查这三项
upload_max_filesize、post_max_size、max_execution_time 是上传链路上的三座关卡，缺一不可：
-
upload_max_filesize必须 ≤post_max_size，否则表单提交直接 400；比如要传 50MB 文件，至少设upload_max_filesize = 50M，post_max_size = 55M（留点 header 余量） -
max_execution_time在上传大文件时容易触发超时，尤其 Nginx 默认 60 秒；FPM 下建议同步调高request_terminate_timeout和 Nginx 的fastcgi_read_timeout - 别忘了
file_uploads = On，某些 Docker 镜像默认关掉
OPcache 开了却没生效？这些参数才是命门
只开 opcache.enable=1 还远远不够，缓存命中率低往往因为：
立即学习“PHP免费学习笔记（深入）”；
-
opcache.memory_consumption太小（默认 64M），现代 Laravel/WordPress 项目至少要128～256；用opcache_get_status()查memory_usage是否频繁 hit limit -
opcache.validate_timestamps=0在生产环境必须关，否则每请求都 stat 文件，完全废掉缓存意义 -
opcache.revalidate_freq设为0时，validate_timestamps=0才真正生效；两者是绑定关系，不是独立开关
FPM 模式下最易被忽略的超时组合
用户看到“504 Gateway Timeout”，第一反应是 Nginx，其实常是 PHP-FPM 先跪了：
-
request_terminate_timeout（FPM 级）必须 ≥ Nginx 的proxy_read_timeout，否则 FPM 强杀进程前 Nginx 还在等 -
request_slowlog_timeout建议设为5s，配合slowlog路径，能快速定位死循环或未加索引的 DB 查询 -
pm.process_idle_timeout在动态模式下影响空闲 worker 回收节奏；设太短会频繁启停进程，设太长则浪费内存
改完 php.ini 别忘了重载服务：sudo systemctl reload php*-fpm（版本号补全），且用 php --ini 和 phpinfo() 确认加载的是你改的那个文件——Docker、多版本共存、cPanel 环境下，很容易改错位置。
