PHP无原生请求分发器，实际靠入口文件解析$_SERVER变量路由；高并发下应避免运行时正则匹配，优先用array_key_exists查固定路径；FPM子进程数需按内存合理配置；高并发应交由Nginx或Swoole分担。
PHP 里没有原生的“请求分发器”，别被名字唬住
PHP 是无状态的脚本语言，每次 HTTP 请求都启动新进程/线程（FPM 模式下是子进程），它本身不维护长连接或全局路由调度中心。所谓“请求分发”，实际是：在入口层（如 index.php）解析请求路径、方法、参数，再决定调用哪个控制器/函数/类。框架（Laravel、ThinkPHP）封装了这层逻辑，但底层仍是 $_SERVER['REQUEST_URI'] + $_SERVER['REQUEST_METHOD'] 的手工匹配或正则路由。
高并发下直接写 switch 或 if-else 路由会卡死
当 QPS 过千，简单字符串匹配或未编译的正则路由（如 preg_match('/^\/api\/user\/(\d+)$/', $uri, $m)）会成为瓶颈：每次请求都要重复解析、回溯、分配数组。更糟的是，若路由表含嵌套通配符或大量模糊规则，CPU 耗在模式匹配上，响应延迟飙升。
- 用
array_key_exists()查固定路径（如/login、/status）比正则快 3–5 倍 - 必须用正则时，提前用
preg_replace_callback_array()（PHP 7.4+）或预编译PREG_JIT标志（需 PCRE2 支持） - 避免在路由层做权限校验或 DB 查询——这些该下沉到中间件或业务逻辑层
FPM 子进程数不是越多越好，pm.max_children 配错反而压垮机器
很多人以为加 pm.max_children = 100 就能扛住并发，但没算内存账：每个 PHP-FPM 进程常驻内存 20–40MB（含 OPcache、扩展、应用代码）。100 个就是 2–4GB，若机器只有 4GB 内存，系统开始频繁 swap，请求排队等待 fork，slowlog 里全是“script timed out”。
- 先用
php-fpm -t测单进程内存占用（加载全部扩展后跑一次memory_get_peak_usage(true)） -
pm.max_children≤总内存 × 0.7 ÷ 单进程内存 - 改用
pm = ondemand并设pm.process_idle_timeout = 10s，空闲进程自动回收
真要扛高并发，PHP 得让出“分发权”给更擅长的层
PHP 不适合做网关级流量调度。Nginx 的 ngx_http_upstream_module 和 limit_req 能在毫秒级完成限流、灰度、AB 测试；Swoole 的 HttpServer 可复用进程处理数千连接，但要注意：它绕过了 FPM，所有全局变量、require_once 行为、扩展兼容性都得重验。
立即学习“PHP免费学习笔记（深入）”；
- Nginx 层做最外层分发：
location /api/ { proxy_pass http://php_backend; }，配合ip_hash或一致性哈希 - 用 Redis + Lua 做分布式请求计数（如每秒限 1000 次），比 PHP 内存数组可靠得多
- 别在 PHP 里自己实现“负载均衡算法”——轮询、最小连接数这些交给 Nginx 或 HAProxy
真正难的不是写个分发函数，而是判断哪层该承担哪部分职责。路由规则变更是常事，但 Nginx reload 比重启 PHP-FPM 安全得多；缓存穿透防护需要原子操作，而 Redis 的 SETNX 比 PHP 的文件锁稳得多。
