max_wait_time是caddy中请求排队等待线程的最长容忍时间，非脚本执行时限；它控制新请求在队列中最多等待2～5秒，超时即返回503，而超时指整个http生命周期或脚本执行时限。
max_wait_time 是什么，和超时有什么区别
max_wait_time 不是请求总执行时间限制，而是「排队等线程」的最长容忍时间。它控制的是：当所有 PHP 线程（num_threads + 已扩容的临时线程）都忙时，新请求在队列里最多能等多久，才被 Caddy 主动拒绝并返回 503。它不干预 PHP 脚本运行本身——哪怕脚本已开始执行、跑了 119 秒，只要没卡在队列里，max_wait_time 就完全不生效。
设太小会丢请求，设太大掩盖真实瓶颈
常见错误现象：frankenphp_queue_depth 持续 > 0、Caddy access log 大量 503、监控看到 frankenphp_busy_threads == frankenphp_total_threads 长期成立。
- 设成
100ms：轻负载下看似“响应快”，但稍有并发波动就直接甩 503，用户感知为“服务不稳定” - 设成
30s：请求全堆在队列里等，表面无 503，实则延迟飙升、用户体验崩坏，还可能触发上游（如 CDN 或浏览器）先超时断连 - 合理起点是
2s～5s：给线程回收/扩容留出缓冲，又不让用户干等太久
必须配合 num_threads 和 max_threads 一起调
max_wait_time 的有效性完全依赖线程池水位。如果 num_threads 过低、max_threads 又设了 auto 或过大，线程扩容慢、内存暴涨，队列照样积压——这时调大 max_wait_time 只是掩耳盗铃。
- 你用 8 核服务器，
num_threads 8、max_threads 16→max_wait_time 3s是安全的 - 若
max_threads auto，线程创建延迟不可控，max_wait_time建议 ≤1s，否则排队请求大概率等不到新线程就超时 - I/O 密集型应用（如大量 cURL 调用），线程常处于阻塞态，可略放宽到
5s，但必须同步调高max_threads并盯紧frankenphp_total_memory
别忘了 Caddy 层的 timeout 也要对齐
Caddy 默认有全局 timeout（如未显式配置，可能为 30s），它和 max_wait_time 是两层超时：前者管整个 HTTP 生命周期，后者只管“等线程”这一小段。如果 max_wait_time 5s 但 Caddy timeout 10s，那请求最多还能在拿到线程后跑 5 秒；但如果 Caddy timeout 3s，那 max_wait_time 再大也没用——3 秒一到直接断连。
- 检查方式：
caddy validate --config /etc/caddy/Caddyfile看是否报 warning - 推荐显式写死：
timeout 120s（与frankenphp.yaml中的timeout一致） - 若业务真有长耗时操作（如导出报表），应拆成异步任务 + WebSocket/轮询，而不是靠拉长
max_wait_time
max_wait_time 的单位必须带单位后缀**，比如 2s、500ms，写成 2 或 500 会被 Caddy 当作秒处理（即 2 秒、500 秒），配置静默生效但行为完全失控。php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
