PHP-FPM 启动慢需检查 pm.start_servers 和 pm.max_children 配置，开发环境建议 static 模式并设 max_children=2；同时确认 opcache.preload 权限与重启生效、禁用 dev 插件、调小 realpath_cache_size。
PHP-FPM 启动慢？检查 pm.start_servers 和 pm.max_children 配置
PHP-FPM 启动耗时长，常因进程管理器（pm）配置不合理导致。默认 pm = dynamic 时，pm.start_servers 过高会让 FPM 在启动时预派生大量子进程，尤其在低配机器上明显卡顿；而 pm.max_children 过大不仅拖慢启动，还会因内存超限触发 OOM Killer。
-
开发环境建议设为
pm = static+pm.max_children = 2，避免动态伸缩开销 - 若必须用
dynamic，按公式估算：pm.start_servers ≈ (total_memory * 0.6) / avg_child_memory，其中单个php-fpm子进程通常占 20–40MB（可用ps aux --sort=-%mem | grep 'php-fpm' | head -5实测） - 删除或注释掉未启用的
pool配置段（如www.conf外多余的dev.conf），每个 pool 都会独立初始化，拖累总启动时间
OPcache 预加载（opcache.preload）没生效？确认 PHP 版本与路径权限
PHP 7.4+ 支持 opcache.preload，能把常用类/函数一次性编译进共享内存，跳过每次请求的文件读取和编译。但常见失效原因不是写法错，而是环境约束被忽略。
- 必须使用
opcache.enable=1且opcache.preload指向的 PHP 文件需在 FPM master 进程启动前可读（即：FPM 用户如www-data必须有该文件及所有include路径的读权限） -
opcache.preload文件里不能含运行时逻辑（如$_SERVER、date()），只允许declare、require、class_alias等编译期语句 - 修改预加载脚本后，必须重启 FPM（
systemctl restart php*-fpm），仅 reload 不生效
opcache.preload=/var/www/preload.php
Composer 自动加载变慢？禁用 dev-only 的插件与脚本
很多项目在 composer.json 中启用了 scripts 或 plugins（如 hirak/prestissimo、phpstan/extension-installer），这些会在每次 Composer 加载自动注册——哪怕只是跑一个 php index.php，只要 autoloader 被引入，它们就可能被触发。
- 检查
vendor/autoload.php是否被提前 require —— 某些框架（如 Laravel）在public/index.php开头就加载它，此时所有 Composer 插件已激活 - 将开发专用插件移入
require-dev，并确保生产环境执行composer install --no-dev - 在
autoload-dev中定义的类，不要出现在生产代码的use列表里，否则 Composer 会尝试加载整个vendor/composer/autoload_dev.php
Apache/Nginx 代理 PHP 请求前就卡住？关掉 realpath_cache_size 的过度设置
PHP 的 realpath_cache_size 默认 4MB，对小项目完全过剩。过大值会导致 PHP 在启动时分配大量共享内存页，并做冗余路径缓存初始化，尤其在容器或 CI 环境中表现明显。
- 开发机可设为
realpath_cache_size=32k，足够覆盖几十个常用路径 - 同时调小
re（秒），避免缓存长期无效路径拖慢
alpath_cache_ttl=30
file_exists类调用 - 注意：此配置对 CLI 模式无效，只影响 Web SAPI（如 FPM、Apache module）
真正影响启动速度的，往往不是某一行代码，而是多个「默认合理」的配置叠加后的隐性开销。比如预加载脚本权限不对 + realpath cache 过大 + 多余 pool，三者各自只慢 200ms，合起来就多出近一秒冷启动延迟。
