opcache必须开启并关闭时间戳校验（opcache.validate_timestamps=0），合理设置内存与文件数阈值，php-fpm选用ondemand模式，规避n+1查询，协程需全链路异步支持。
OPcache必须开，且要关掉时间戳校验
PHP 8.5.5 默认仍启用 opcache.validate_timestamps=1，这意味着每次请求都会检查 PHP 文件是否被修改，哪怕只是改了个空格，也会导致缓存失效、重新编译。这在生产环境是性能杀手。
正确做法是：把 opcache.validate_timestamps 设为 0，同时确保部署流程中用 opcache_reset() 或重启 PHP-FPM 来主动刷新缓存，而不是靠文件检测。
-
opcache.memory_consumption至少设为256（单位 MB），ThinkPHP 或 Laravel 类项目常有数千个文件，128容易溢出 -
opcache.max_accelerated_files建议设到20000，避免因文件数超限触发“缓存驱逐”导致命中率骤降 - 别只改
php.ini—— 某些 CentOS/RHEL 环境下 OPcache 配置在/etc/php.d/10-opcache.ini，改错位置等于没改
PHP-FPM 进程模型选 ondemand，别硬套 static
很多人照着教程把 pm = static + pm.max_children = 50 当成万能配置，结果在低流量时段白白占着 50 个 idle 进程，内存吃紧、响应反而变慢。
ondemand 模式会按需拉起子进程，空闲时自动回收，更适合中小流量或资源受限场景。它不是“性能差”，而是更省、更稳。
-
pm.process_idle_timeout设为10s（默认 10 秒），太短会导致频繁启停，太长则浪费资源 -
pm.max_requests建议设为1000，防止长期运行的进程因内存泄漏缓慢退化 - 别忽略
rlimit_files—— 如果单个 FPM 进程打开文件数不够，高并发时会卡在Too many open files
数据库 N+1 查询在 PHP 8.5.5 里更隐蔽也更伤
PHP 8.5.5 的 JIT 编译对 CPU 密集型代码加速明显，但对 I/O 等待毫无帮助。而 ORM 层常见的 N+1 查询——比如循环里调 $user->posts——会让 JIT 失去作用，90% 时间花在等 MySQL 返回上。
尤其 ThinkPHP 5/6 或 Laravel 的 Eloquent，在未显式预加载时极易触发这种问题，日志里看不出异常，但 slow_query_log 会暴增。
- 用
->with(['posts', 'profile'])显式预加载，别依赖懒加载 - 查完数据立刻
unset($model)，避免对象引用链拖慢 GC - 对高频查询字段建覆盖索引，例如
SELECT id, title FROM article WHERE status=1 ORDER BY created_at DESC，索引应为(status, created_at, id, title)
协程不是开了就快，得避开同步阻塞调用
PHP 8.5.5 的原生协程（Fiber）确实能跑几千并发，但只要代码里出现一个 file_get_contents()、mysqli_query() 或没适配协程的 Redis 扩展，整个协程就卡住，退化成同步行为。
协程提速的前提是所有 I/O 调用都走异步驱动，否则只是“假并发”。
- HTTP 请求必须用
Swoole\Http\Client或amphp/http-client，不能用curl_exec() - MySQL 必须用
mysqlnd+ext-async-mysql或swoole_mysql，PDO 不行 - Redis 推荐
ext-redis的setOption(REDIS_OPT_READ_TIMEOUT)配合非阻塞 socket，但原生不支持协程，得换amphp/redis
协程的复杂点不在写法，而在生态适配——你得确认每个依赖包都提供异步接口，漏掉一个，整条链路就掉回同步模型。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
