ThinkPHP接口超时主因是环境配置而非框架，需逐层排查：先查Nginx/Apache超时设置（如fastcgi_read_timeout）、再验PHP执行限制（max_execution_time）、最后分析数据库及第三方依赖阻塞，并启用日志追踪定位瓶颈。
ThinkPHP部署后接口超时，通常不是框架本身的问题，而是运行环境、网络链路或配置细节没对齐导致的。重点不在“怎么加超时时间”，而在于先定位是哪一层在超时——是PHP执行卡住？Nginx/Apache拦腰截断？还是数据库/第三方接口拖慢了响应？
检查Web服务器超时设置（最常见原因）
很多线上超时根本没走到ThinkPHP里，就被反向代理或Web服务主动断开了。-
Nginx：默认
fastcgi_read_timeout是60秒，若接口处理稍长（比如导出、批量同步），就会直接返回504 Gateway Timeout。
在server或location块中显式加大：fastcgi_read_timeout 300; // 单位秒，建议设为实际最长耗时+30 proxy_connect_timeout 60; proxy_send_timeout 300; proxy_read_timeout 300;
-
Apache：关注
Timeout和ProxyTimeout指令，尤其用mod_proxy转发时。.htaccess无效，必须改主配置或虚拟主机配置：Timeout 300 ProxyTimeout 300
注意：修改后需重载服务（
nginx -s reload或systemctl reload apache2），不是重启。
确认PHP执行限制是否触发
ThinkPHP本身不限制执行时间，但PHP底层会。-
检查
php.ini中：立即学习“PHP免费学习笔记（深入）”；
max_execution_time = 300 ; 默认30，生产环境建议调高 max_input_time = 120 memory_limit = 256M ; 大数组或文件处理时容易触顶
若用
php-fpm，还要看www.conf里的request_terminate_timeout（慎开，建议用0即不限制）和request_slowlog_timeout（用于抓慢请求）。验证方式：写个测试接口，用
sleep(65)，看是返回504还是500或白屏，能快速区分是Web层还是PHP层拦截。
排查数据库与外部依赖阻塞
ThinkPHP日志里看到“SQL slow”或“cURL timeout”，说明问题在下游。- 数据库连接池不足、慢查询未加索引、锁表，都会让整个请求挂起；
- 调用第三方API（如微信回调、短信网关）没设超时，一个失败就拖垮全链路。
建议统一封装HTTP客户端时强制加超时（非装饰器模式也行）：
Http::timeout(10)->get('https://api.example.com/data');同时开启CURLOPT_CONNECTTIMEOUT_MS和CURLOPT_TIMEOUT_MS双保险。
启用ThinkPHP调试与慢日志追踪
别靠猜，让系统告诉你哪里卡。- 开启应用调试模式（
app_debug = true）并打开trace，查看各阶段耗时分布； - 在
config/log.php中开启record和level，确保error和notice不被过滤； - 关键位置手动打点：
\think\facade\Log::info('before db query', ['time' => microtime(true)]); $data = Db::table('xxx')->select(); \think\facade\Log::info('after db query', ['time' => microtime(true)]);
不复杂但容易忽略
