OPcache真正在Web请求中生效需三步确认：一是浏览器访问phpinfo()页面，核对Loaded Configuration File路径并确保Opcode Caching显示Enabled且opcache.enable为On；二是调用opcache_get_status()不报错；三是确认zend_extension=opcache.so（Linux/macOS）或带引号的绝对DLL路径（Windows）已正确配置，且重启了PHP-FPM服务。
确认OPcache是否真正在Web请求中生效
浏览器访问一个含<?php phpinfo(); ?>的info.php页面，不是看命令行php -m | grep opcache输出——后者只说明扩展装了，不等于网页请求走的是带OPcache的PHP-FPM进程。
在phpinfo()页面里搜索Loaded Configuration File，记下那个ini路径，后面所有修改都必须改这个文件，而不是随便一个php.ini。
页面中必须出现Opcode Caching区块，且状态为Enabled；旁边opcache.enable值必须是On。如果搜不到该区块，或调用opcache_get_status()报Call to undefined function，说明OPcache根本没加载进PHP-FPM进程。
Linux/macOS下必须写zend_extension=opcache.so，写成extension=opcache.so会静默失效；Windows下必须用带引号的绝对DLL路径：zend_extension="C:\php\ext\php_opcache.dll"，路径不存在或引号漏掉，OPcache就完全不工作。
立即学习“PHP免费学习笔记（深入）”；
检查OPcache关键参数是否匹配项目规模
默认opcache.memory_consumption=64（MB）和opcache.max_accelerated_files=10000在Laravel、Symfony等Composer项目里极易触发缓存踢出——表现为CPU突然升高、TTFB抖动、页面偶发白屏或Class not found。
将opcache.memory_consumption设为256起步，Laravel项目直接设512；opcache.max_accelerated_files按项目实际PHP文件数×1.5估算，超3000文件就别卡在默认值。
【opcache.validate_timestamps=0是生产环境最大雷区】设为0不是“更省事”，而是让代码更新后页面永远不刷新——上线新类、改路由、加方法全无效，只能靠手动opcache_reset()或重启PHP-FPM。开发环境必须为1+opcache.revalidate_freq=2；生产环境可设1+60，但绝不能为0。
禁用xdebug等非必要扩展
执行php -m列出已启用模块，重点检查xdebug、xhprof、blackfire是否开着——它们在本地开发时有用，但一开就拖慢3～5倍，且常被误留到生产配置里。
打开php.ini，找到对应行，在前面加;注释掉，例如：;zend_extension=xdebug.so。
重启PHP-FPM服务（不是仅重启Nginx/Apache），否则禁用不生效。
优化自动加载与文件包含开销
Composer项目中大量require和PSR-4自动加载会引发高频realpath查找，尤其在未启用realpath缓存时，每次require都要遍历整个include_path。
在php.ini中设置：realpath_cache_size=4096K和realpath_cache_ttl=600，大幅降低文件路径解析系统调用次数。
检查代码中是否在循环内require 'config.php'或include_once 'helper.php'——这类写法会重复触发IO和编译，应移出循环，或改用单次加载+变量复用。
调整PHP-FPM进程管理策略
第一步：打开www.conf（通常在/etc/php/8.2/fpm/pool.d/下），定位到[www]段落。
第二步：将pm = dynamic改为pm = ondemand，空闲时子进程数归零，避免内存常驻浪费。
第三步：设置pm.max_children = 16，pm.start_servers = 4，pm.min_spare_servers = 2，pm.max_spare_servers = 6，pm.process_idle_timeout = 10s。
第四步：保存后执行sudo systemctl reload php8.2-fpm，不是restart，reload即可生效。
