PHP 8.5.5不改变并发模型，需关闭阻塞点、压测调参及选用合适运行时；php-fpm宜用static模式并显式配置max_children与禁用idle_timeout；OPcache须设validate_timestamps=0和足够max_accelerated_files；协程不可用于php-fpm，仅限Swoole等协程运行时；高频状态共享优先用Swoole Table；I/O操作必须使用协程安全驱动。
PHP 8.5.5 本身不改变并发模型，但提供了协程原语和更稳的底层调度器；真正提升并发能力，靠的是关闭阻塞点、压测后调参、以及用对运行时模型——不是升级版本就能自动高并发。
php-fpm 进程模型选 static 还是 dynamic
dynamic 模式在压测中容易误判容量：子进程数随负载浮动，fork/spawn 频繁引发上下文抖动，响应延迟波动大。static 模式固定常驻进程，消除创建开销，吞吐更稳。
- 设
pm = static，显式配pm.max_children（例如 64），按单进程 RES 均值 × 1.2 留余量反推 -
pm.process_idle_timeout必须注释或设为 0 —— static 下该参数无效，残留会干扰行为 - 确认
ps aux --sort=-%mem | grep php-fpm中 worker 的RES值稳定，避免内存持续上涨
OPcache validate_timestamps=0 必须显式写死
哪怕 php.ini 默认是 0，也必须手动写上 opcache.validate_timestamps=0。否则每次请求触发 stat() 系统调用，在高并发下打爆 inode cache 或卡住磁盘 I/O。
- 搭配设
opcache.max_accelerated_files=65536，ThinkPHP5.1+ 自动加载 + 模板编译容易超默认 2000 限制 - 验证是否生效：
php -r "print_r(opcache_get_status());"，重点看opcache_enabled为 true、memory_usage.used_memory有实际占用 - 部署时加清缓存脚本，避免
validate_timestamps=0导致代码更新不生效
协程不能直接用在 php-fpm 里
php-fpm 是多进程同步模型，async/await 在其中不会调度协程，只会退化成普通函数调用，甚至引发 fatal error。协程只在 CLI + Swoole 或 Fiber-aware 运行时中有效。
立即学习“PHP免费学习笔记（深入）”；
- 想用协程，必须脱离 php-fpm：改用
swoole_http_server或hyperf等协程框架启动服务 - CLI 后台任务可启用协程，但需确保
opcache.enable_cli=1，并用php -d memory_limit=512M think queue:work控制资源 - 别在控制器里写
async function然后期望它并发执行——FPM 进程根本不会跑事件循环
Redis + Swoole Table 替代文件/DB 做高频状态共享
订单号生成、秒杀计数、登录态校验这类操作，走 Redis 虽快但仍有网络序列化开销；Swoole Table 在内存中建无锁哈希表，微秒级读写，适合窗口内强一致性场景。
- 初始化 table 需在 server 启动时完成，字段类型用
SWOOLE_TABLE_STRING或SWOOLE_TABLE_INT显式声明 - key 建议带时间前缀（如
order_sn_240625），配合SETEX设 TTL，防冷 key 长期占内存 - 不要把 table 当数据库用：不支持事务、无持久化、不跨进程，仅限单机高频读写
最易被忽略的一点：协程调度器本身不管理数据库连接或 Redis 客户端，所有 I/O 操作必须用协程安全的驱动（如 swoole_redis 或 co\MySQL），混用传统 mysqli 或 pdo 会直接阻塞整个事件循环。
