PHP-FPM内存超限主因是opcache和autoload配置不当及PDO预处理句柄未释放：opcache.memory_consumption盲目调大反增RSS并加剧碎片，需依opcache_get_status()数据精准调优；Composer应生成权威classmap并剔除dev类；PDO需复用或显式关闭预处理语句。
PHP-FPM 进程内存超限的典型表现
请求偶尔 502、php-fpm.log 中反复出现 WARNING: [pool www] child 12345 exited on signal Segmentation fault (11)，或 pm.max_children 设得不高却频繁触发 slowlog，大概率是单个 PHP-FPM worker 实际内存远超预期——不是代码没释放，而是配置和扩展在“偷偷吃内存”。
opcache.memory_consumption 调大反而更耗内存？
默认 opcache.memory_consumption=64（MB）对多数中小项目足够。盲目调到 256 或 512，会导致：
– opcache 缓存更多脚本，但若项目含大量动态生成类（如 Laravel 的 vendor/composer/autoload_classmap.php）、未清理的注释/调试代码，缓存碎片率升高；
– PHP 启动时预分配更大共享内存段，ps aux 看每个 php-fpm 进程 RSS 增加 10–20MB；
– 更关键的是：若 opcache.interned_strings_buffer 没同步调高（默认仅 8），字符串 intern 冲突上升，触发频繁重编译，反而推高 CPU 和内存波动。
实操建议：
- 先用
opcache_get_status()查看memory_usage.used_memory和interned_strings_usage.used_memory，真实占用不到 50%，就别动memory_consumption - 若
interned_strings_usage接近上限，再按需调高opcache.interned_strings_buffer（如设为 16 或 32） - 禁用
opcache.save_comments=0（Laravel/Symfony 项目必须加）——注释不参与执行，却占 opcache 空间
Composer 自动加载器引发的内存泄漏
PHP 8.1+ 中，composer autoload 默认使用 classmap + psr-4 混合模式，但若项目含大量条件加载逻辑（如插件系统、运行时注册服务提供者），ClassLoader::findFile() 可能反复扫描 vendor 目录，每次调用都触发 realpath() 和 file_exists()，累积产生数 MB 临时字符串——这些不会被 opcache 缓存，且在 request 结束前不释放。
立即学习“PHP免费学习笔记（深入）”；
解决方向：
- 强制生成完整 classmap：
composer dump-autoload --optimize --classmap-authoritative，让加载变成纯数组查表，跳过文件系统调用 - 检查
autoload-dev是否误包含测试工具类（如phpunit相关），它们不该进生产 autoloader - 避免在
__construct()或中间件中动态require_once未声明路径的文件——这类操作绕过 autoloader，又无法被 opcache 覆盖
MySQL 长连接与 PDO 预处理语句残留
PHP-FPM worker 复用 MySQL 连接时，若用 PDO::prepare() 创建大量语句但未显式 $stmt->closeCursor() 或 unset($stmt)，MySQL 服务端会保留预处理句柄，PHP 进程则持续持有 PDOStatement 对象引用。尤其在分页查询、导出循环中反复 prepare 同一 SQL 却不同参数，极易堆积。
验证方式：
- 登录 MySQL 执行
SHOW PREPARED STATEMENTS;，看数量是否随请求增长 - 在 PHP 中启用
pdo_mysql.default_socket并设置mysqlnd的mysqlnd.collect_statistics=On，再查mysqli_get_client_stats()
安全做法：
- 复用
PDOStatement实例，而不是每次prepare()新对象 - 在 long-running CLI 脚本中，手动调用
$pdo->setAttribute(PDO::ATTR_EMULATE_PREPARES, true)关闭原生预处理（Web 请求通常无需改） - 确保
mysqlnd已启用（非libmysql），它对 prepared statement 生命周期管理更严谨
内存优化不是堆参数，而是看清每个字节从哪来、到哪去。最常被忽略的是：opcache 不缓存 include 的内容，但 Composer autoloader 里一堆 include；PDO 不释放句柄，但 MySQL 服务端已记下你；PHP-FPM 进程看似空闲，其实正拿着上个请求的 SimpleXML 对象不肯撒手。
