php无原生线程模型，高并发崩溃主因是web服务器配置不当（如apache prefork子进程耗尽、php-fpm pm.max_children过小）、opcache重载锁竞争；需按内存与请求特征调优pm参数，显式管理db/redis连接，关闭opcache时间戳校验并合理设置内存与文件数。
PHP 本身没有线程模型，崩溃通常出在 Web 服务器或运行模式上
PHP 是进程/协程驱动的，不是多线程语言。所谓“高并发下崩溃”，绝大多数情况是 Apache + prefork MPM 下子进程耗尽、PHP-FPM 的 pm.max_children 设置过小导致请求排队超时，或 opcache 在重载时锁竞争激烈。别去查 PHP 的“线程安全编译选项”——除非你真在写 ZTS 扩展，否则它和并发稳定性基本无关。
PHP-FPM 的 pm 配置必须按实际内存与请求特征调优
盲目增大 pm.max_children 可能引发 OOM；设太小又会大量 502 Bad Gateway。关键看单个 PHP 进程常驻内存（用 ps aux --sort=-%mem | head -10 观察 php-fpm 进程的 %MEM 和 RSS），再结合服务器总内存计算：
-
pm = dynamic是更安全的选择（比static更适应流量波动） -
pm.max_children≤ 总内存 × 0.7 ÷ 单进程平均 RSS（单位 MB） -
pm.start_servers设为max_children × 0.3左右，避免冷启动延迟 -
pm.max_requests建议设 500–2000（防内存缓慢泄漏，但别设 0 或过小，否则频繁 fork 影响吞吐）
连接池不是 PHP 内置概念，数据库/Redis 连接需显式管理
PHP 每次请求默认新建 DB 连接，高并发下 MySQL 可能报 Too many connections。这不是 PHP “没连接池”，而是没复用：
- MySQLi/PDO 默认不持久连接，
PDO::ATTR_PERSISTENT => true可启用，但要注意连接状态残留（如事务未提交、临时表未删） - Redis 推荐用
phpredis扩展的Predis\Client不够健壮，改用Redis类并开启connect_timeout和retry_interval - 若用 Swoole，可用
Swoole\Coroutine\MySQL或Swoole\Coroutine\Redis，它们天然支持协程级连接复用，但要求业务代码彻底协程化
opcache 重编译与共享内存争用是隐性崩溃源
部署新代码后大量请求同时触发 opcache 检查，可能造成 CPU 尖刺甚至 fpm 子进程卡死。重点调这几个配置：
立即学习“PHP免费学习笔记（深入）”；
-
opcache.validate_timestamps = 0（上线后关闭文件时间戳校验，改用opcache_reset()主动刷新） -
opcache.memory_consumption至少设 128M（小了会导致频繁淘汰，大了浪费，按opcache_get_status()['memory_usage']实际观察调整） -
opcache.max_accelerated_files必须 ≥ 项目中 PHP 文件总数（用find /path/to/app -name "*.php" | wc -l估算） - 禁用
opcache.fast_shutdown（PHP 7.4+ 已移除，旧版本开启可能导致析构异常）
真正难调的不是数字本身，而是不同服务间的资源耦合：比如提高 pm.max_children 后，MySQL 的 max_connections 没同步扩容，反而更快崩。得盯着 show processlist 和 php-fpm status 的 active processes 对着看。
