ThinkPHP 6 的 timeout 配置不控制接口响应超时，仅影响底层 HTTP 客户端；接口超时需由 Web 服务器、PHP（set_time_limit 或 ini_set）、数据库（如 MySQL max_execution_time）及应用层中间件协同控制。
ThinkPHP 6 的 timeout 配置根本不管用？
不是配置写错了，是它压根不控制 HTTP 请求超时——timeout 在 ThinkPHP 6 的 app.php 或 http.php 里只影响底层 HTTP 客户端（比如发 CURL 请求时），跟接口响应超时不搭界。用户发起的请求超时，得靠 Web 服务器或 PHP 自身机制兜底。
实操建议：
- Apache 下检查
Timeout指令（默认 300 秒），Nginx 则看fastcgi_read_timeout和proxy_read_timeout - PHP 层可用
set_time_limit()控制脚本最大执行时间，但必须在逻辑开头调用，且不能在disable_functions里被禁用 - CLI 模式下
php -d max_execution_time=10 your_script.php可临时覆盖
用中间件做接口级超时拦截（ThinkPHP 6+）
想对某个 API 接口单独设 5 秒超时？不能靠框架自动中断，但可以手动检测耗时并在临界点提前返回。关键不是“终止 PHP 执行”，而是“不再往下走业务逻辑”。
常见错误现象：写了 microtime(true) 计时，但放在中间件末尾判断，实际已经晚了。
立即学习“PHP免费学习笔记（深入）”；
实操建议：
- 在中间件
handle()开头记录起始时间：$start = microtime(true) - 在业务逻辑前插入检查：
if (microtime(true) - $start > 5.0) { return json(['code'=>504, 'msg'=>'Request timeout']); } - 注意：该方式无法真正中断正在执行的数据库查询或外部 API 调用，仅适用于 CPU 密集型或可控流程
- 避免在事务中使用，否则可能造成连接未释放
think\facade\Db 查询卡住时怎么设 SQL 层超时？
MySQL 查询本身支持 max_execution_time，但 ThinkPHP 默认不透传。直接写原生 SQL 可加提示，ORM 查询则需手动干预。
使用场景：报表导出、模糊搜索等易慢操作
实操建议：
- 执行前设置会话级超时：
Db::execute('SET SESSION max_execution_time = 3000')（单位毫秒，MySQL 5.7.8+） - Query Builder 不支持链式设超时，但可改用原生语句：
Db::query('SELECT /*+ MAX_EXECUTION_TIME(3000) */ * FROM user WHERE ...') - 注意：PDO 默认不启用异常模式，超时错误可能被静默吞掉，务必确认
pdo::ATTR_ERRMODE => pdo::ERRMODE_EXCEPTION已开启 - PostgreSQL 用户用
statement_timeout，语法不同，别混用
为什么 ini_set('max_execution_time', 1) 经常失效？
这个函数只对当前请求生效，但 ThinkPHP 的生命周期里，很多初始化动作（如路由解析、中间件加载）已在它之前跑完。等你调到控制器里再设，黄花菜都凉了。
性能影响：频繁调用 ini_set 几乎无开销，但时机错就完全没意义。
实操建议：
- 最可靠的位置是在入口文件
public/index.php顶部第一行就写：ini_set('max_execution_time', 10); - 如果用了 Swoole 或 RoadRunner，PHP 生命周期不同，
max_execution_time会被忽略，必须用协程超时控制（如go(function() { Co::sleep(10); })） - 某些共享主机禁用
ini_set，此时只能靠 .htaccess 或 php.ini 修改，联系运维
超时控制从来不是单点开关，而是 Nginx、PHP、数据库、应用逻辑四层叠加。漏掉任何一层，都可能让“设了 5 秒”变成“卡死 300 秒”。
