PHP高并发需聚焦真实瓶颈：I/O密集型选Swoole协程（须run()包裹、禁用阻塞调用）、CPU密集型慎用pcntl_fork（仅CLI有效、须exit+wait回收），多线程仅限ZTS环境；消息队列才是解耦削峰通用解法。
PHP 高并发不是靠“学概念”练出来的，而是靠在真实瓶颈场景里反复试错、验证、调优出来的。没有统一路径，但有明确的发力点：先分清你面对的是 I/O 密集型还是 CPU 密集型任务，再选对工具链，否则投入再多时间也白搭。
pcntl_fork 多进程必须跑在 CLI 模式下
Web SAPI（如 Apache、PHP-FPM）不支持 pcntl_fork 的可靠使用，子进程可能被 SAPI 自行回收或引发信号混乱。只有 CLI 环境能稳定控制生命周期。
- 用
php -m | grep pcntl确认扩展已启用；没输出就别往下走 - 子进程逻辑结束后必须调用
exit(0)，不能用return—— 否则会继续执行父进程后续代码，极大概率导致重复 fork 或资源泄漏 - 父进程务必调用
pcntl_waitpid()或pcntl_wait()回收，否则产生僵尸进程；WNOHANG是非阻塞轮询的关键参数，别漏掉 - 临时文件传结果时，记得用
sys_get_temp_dir()+uniqid()生成唯一路径，避免并发写入覆盖
Swoole 协程不是“加个 go 就高并发”
go 和 Swoole\Coroutine\create 是同一函数，但协程生效的前提是整个调用栈都运行在 Swoole 的事件循环中。直接在普通 PHP-FPM 脚本里写 go(...) 不会起作用，也不会报错，只是默默退化成同步执行。
- 必须用
Swoole\Coroutine\run()包裹主逻辑，或启动Swoole\Http\Server等 Swoole 服务端实例 - 协程内不能调用阻塞函数（如
sleep()、file_get_contents()、PDO::query()），得换co::sleep()、Swoole\Coroutine\Http\Client、Swoole\Coroutine\MySQL - 协程间共享变量不安全，要用
Swoole\Coroutine\Channel或Swoole\Atomic，别直接读写全局数组
pthreads 多线程只在 ZTS 版本 PHP 上有效
绝大多数生产环境用的都是 NTS（Non-Thread-Safe）PHP，比如 Ubuntu 官方源、Docker php:apache 镜像。这种环境下装了 pthreads 也加载不了，php -m 看不到，class_exists('Thread') 返回 false。
立即学习“PHP免费学习笔记（深入）”；
- 先运行
php -r "echo PHP_ZTS ? 'ZTS' : 'NTS';"，输出 NTS 就别折腾 pthreads 了 - ZTS 版本通常需自行编译，且与多数扩展（如 Xdebug、OPcache）存在兼容风险
- 即便环境满足，
Thread类的run()方法里也不能直接访问父作用域变量，得靠$this->prop = $value显式传递
消息队列才是解耦高并发的通用解法
多进程、协程、线程都解决不了“任务持久化”和“削峰填谷”，它们只是加速执行。一旦请求洪峰到来或下游服务抖动，这些方案要么崩溃，要么把压力原样传导过去。
- 用
Redis::lpush()或AMQP\Connection推任务进队列，主流程立即返回，这是最轻量的解耦起点 - 消费者进程用
pcntl_fork或Swoole\Process启多个 worker，并发拉取处理，失败可重试、可死信 - 别自己实现“队列”，Redis List / RabbitMQ / Kafka 都经过大规模验证，自研队列在 ACK、幂等、堆积监控上全是坑
真正卡住人的从来不是语法或 API，而是子进程退出后父进程没 wait、协程里混用了阻塞函数、或者把队列当缓存用还设了短过期——这些细节不亲手跑通几遍，文档看得再多也没用。
