该错误本质是PHP主动中止脚本执行，因超过max_execution_time阈值（默认30秒）；需先用microtime(true)打点确认实际耗时，若远低于阈值则问题在阻塞操作（如未设超时的cURL、数据库连接），而非单纯需延长时间。
这个错误不是“脚本写错了”，而是 PHP 主动中止了它——因为执行时间超过了 max_execution_time 设置的阈值（默认 30 秒）。直接调大时间能跑通，但掩盖了真正的问题。得先判断：是代码太慢，还是业务真需要这么久？
怎么确认是代码效率问题，而不是单纯要延长时间？
别急着改配置，先加两行时间戳看实际耗时：
<?php
$startTime = microtime(true);
// ... 你的核心逻辑（比如数据库查询、循环处理） ...
$endTime = microtime(true);
error_log(sprintf('Script took %.2f seconds', $endTime - $startTime));
?>如果日志里显示只跑了 0.8 秒却报了 30 秒超时，说明问题不在执行时间，可能出在：
– 数据库连接卡住（没设 CURLOPT_CONNECTTIMEOUT 或 PDO::ATTR_TIMEOUT）
– cURL 请求没设超时，第三方接口挂了导致无限等待
– file_get_contents() 读取远程 URL 时阻塞
– 循环里反复做 echo/print_r()，输出缓冲未刷新，浏览器以为没响应
set_time_limit(0) 能用，但有三个硬限制
这个函数看似万能，实际受制于运行环境：
立即学习“PHP免费学习笔记（深入）”；
- PHP 安全模式（
safe_mode = On）下完全失效（PHP 5.4+ 已移除，但某些老旧托管环境仍模拟该行为） - Web 服务器层可能拦截：Nginx 的
fastcgi_read_timeout、Apache 的Timeout都会先于 PHP 终止请求 - CLI 模式下有效，但 Web 模式下若启用 opcache + JIT，某些极端循环可能绕过计时器重置逻辑（PHP 8.2+ 已修复，但低版本仍有风险）
更稳妥的做法是：用 set_time_limit(120) 明确设上限，而非 0；同时检查 Web 服务器配置是否同步放宽。
php.ini 修改后为什么没生效？
常见原因不是改错位置，而是没找对生效的配置文件：
- 运行
php --ini（CLI）或phpinfo()（Web）确认实际加载的php.ini路径，别只改了 /etc/php/8.2/cli/php.ini 却忘了 /etc/php/8.2/fpm/php.ini -
max_execution_time在 FPM 模式下会被php_admin_value强制覆盖（如宝塔、cPanel 常见），此时改 php.ini 无效，得去对应 pool 配置里加php_admin_value[max_execution_time] = 300 - Docker 环境中，镜像可能把 php.ini 设为只读，或通过环境变量
PHP_INI_SCAN_DIR加载额外配置覆盖了你的修改
改完务必验证：新建一个 test.php，内容为 <?php echo ini_get('max_execution_time'); ?>，访问它看输出是否是你设的值。
真正该优先做的：把长任务拆出去
用户点击“导出 10 万条数据”，不该让浏览器干等 2 分钟。更健壮的路径是：
- 前端发起请求，PHP 立即返回任务 ID 和状态轮询地址（如
/api/task/status?id=abc123） - 后台用 CLI 启动独立进程（
php artisan queue:work或nohup php export.php &），不受 Web 超时约束 - 导出完成写入临时文件，前端轮询到“done”后提供下载链接
这种分离才是应对“合理长耗时”的标准解法。set_time_limit 和 php.ini 调整，只是临时兜底，不是设计常态。
