PHP上传并发限制本质是服务端资源控制，需通过Nginx连接限制、PHP-FPM进程配置及Redis原子计数（INCR/DECR）实现跨服务器安全限流，禁用session或文件锁等串行化方案。
PHP 上传并发限制本质是服务端资源控制，不是靠 PHP 单独实现
PHP 本身没有内置的“上传并发数”开关。所谓限制音频上传并发，实际是在限制同一时间能被 $_FILES 接收并处理的请求数量——这取决于 Web 服务器（如 Nginx/Apache）的连接数、PHP-FPM 的进程/线程配置，以及应用层是否加了排队或拒绝逻辑。
直接在 PHP 脚本里用 sleep() 或计数器无法真正限流：它只阻塞当前请求，不阻止新请求抵达并占用 FPM worker，反而可能引发超时堆积和雪崩。
- Web 服务器层最有效：Nginx 可用
limit_conn按 IP 或 zone 限制连接数 - PHP-FPM 层可调
pm.max_children控制最大并发处理能力 - 应用层适合做“软限流”：比如检查当前活跃上传任务数（用 Redis 计数），超阈值则返回
503 Service Unavailable
用 Redis 实现上传任务数实时计数（推荐落地方式）
适用于需要区分“音频上传”这一特定行为，且希望动态调整阈值（如高峰时段降为 3，并发音频上传最多 3 个）。
关键点：计数必须在 move_uploaded_file() 前完成，并在上传失败或成功后及时释放。
立即学习“PHP免费学习笔记（深入）”；
- 上传开始前：
$redis->incr("upload:audio:active")，然后用$redis->get("upload:audio:active")判断是否超过阈值（如 5） - 若超限，立即
header("HTTP/1.1 503 Service Unavailable")并exit，不进入后续处理 - 上传成功后：
$redis->decr("upload:audio:active") - 上传失败或异常退出时，务必用
register_shutdown_function()或 try/catch + finally 确保decr - 给 key 加 TTL（如
$redis->expire("upload:audio:active", 300)），防僵尸计数
为什么不用 session 或文件锁来计数？
session 写入会阻塞请求，尤其在并发高时，session_start() 可能成为瓶颈；文件锁（flock）同样串行化，且跨服务器失效，不适合集群环境。
- Redis 是原子操作，支持高并发读写，
INCR/DECR天然线程安全 - 本地文件锁在负载均衡多机部署下完全不可用
- 数据库（如 MySQL）做计数开销大、延迟高，还可能因事务或锁导致上传响应变慢
- 如果没 Redis，可用
apcu_inc()（仅单机 PHP-FPM 进程内有效），但重启后计数丢失，且无法跨 worker 共享
别忘了前端配合与错误反馈
单纯后端限流，用户点击上传按钮后可能等几秒才收到 503，体验差。应在前端加一层轻量判断：
- 上传前先 GET
/api/upload/status查当前活跃数（返回 JSON{"active":2,"limit":5}） - 若
active >= limit，禁用上传按钮并提示“当前上传繁忙，请稍后再试” - 后端接口需对这个 status 请求也做缓存（如用
apcu_store缓存 2 秒），避免它本身成为新瓶颈 - 注意：前端状态仅供参考，最终以服务端校验为准，防止绕过
真正容易被忽略的是超时场景——比如用户上传中途关闭页面，decr 没执行，Redis 计数就卡住。必须配一个定期清理脚本或用带 TTL 的计数+看门狗机制，否则几天后所有上传都会被拒绝。
