set_time_limit有时不起作用，主要因安全模式启用、sapi层配置（如php-fpm的php_admin_value[max_execution_time]或nginx的request_terminate_timeout）强制覆盖，或web服务器超时（如fastcgi_read_timeout）先于php层触发。
set_time_limit 为什么有时不起作用
PHP 脚本超时默认由 max_execution_time 配置控制，而 set_time_limit 是运行时动态重置这个计时器。但它只在非安全模式（safe_mode = Off）下生效，且不能在 CLI 模式下禁用超时（CLI 默认为 0，即不限制），但如果你在 web SAPI（如 Apache、FPM）中调用它却没效果，大概率是 PHP 运行在 safe_mode = On（已废弃但旧环境仍可能残留），或被 SAPI 层本身强制覆盖——比如 Nginx + PHP-FPM 组合中，request_terminate_timeout 或 php_admin_value[max_execution_time] 会直接掐断进程，set_time_limit 根本没机会触发。
- 检查当前是否处于安全模式：
ini_get('safe_mode')，返回"1"就得改配置或换环境 - FPM 下优先看 pool 配置里有没有
php_admin_value[max_execution_time]，它比set_time_limit级别更高 - Apache mod_php 中，
php_value max_execution_time也会压制运行时修改
set_time_limit(0) 在 Web 环境中慎用
set_time_limit(0) 表示取消脚本执行时间限制，听起来很爽，但在 Web 场景下极易引发雪崩：一个慢查询或死循环会让 worker 进程卡死，连接堆积，最终整个服务不可用。尤其在 PHP-FPM 中，worker 被占满后新请求直接 502/504；Nginx 默认 fastcgi_read_timeout 是 60 秒，即使 PHP 层没超时，Nginx 也会先断连。
- Web 请求应设合理上限，比如导出报表最多 120 秒：
set_time_limit(120) - 若真需要长时间运行（如大文件处理），拆成异步任务，用 CLI 模式跑，配合队列（如 Redis + Worker）
-
set_time_limit(0)只应在 CLI 脚本开头明确声明用途时使用，且必须配超时兜底逻辑（如信号监听或心跳检测）
CLI 和 Web 的超时机制根本不同
CLI 模式下 max_execution_time 默认值是 0（不限时），所以 set_time_limit 多数时候是“从不限时改成限时”，而 Web 模式默认是 30 或 60 秒，set_time_limit 是“延长”。更关键的是：CLI 不受任何 Web 服务器超时影响，但会受操作系统级限制（如 ulimit -t CPU 时间限制）。
- CLI 脚本中调用
set_time_limit(300)，实际仍可能被系统 kill —— 查看ulimit -t输出，若为 300，则到点就终止，PHP 层无感知 - Web 环境中，
set_time_limit只重置 PHP 自己的秒表，不碰 Nginx/Apache 的连接超时、读写超时、代理超时 - 调试时可用
ini_get('max_execution_time')+getrusage()估算剩余时间，但无法精确获知“还剩几秒”，因为底层计时器不对外暴露
替代方案：用 pcntl_alarm 或 stream_set_timeout 更精准控时
当需要在某个具体操作（如 cURL 请求、socket 连接、数据库查询）上单独设超时，而不是整脚本一刀切，set_time_limit 就太粗了。这时候应该用对应扩展的原生超时参数。
- cURL：用
curl_setopt($ch, CURLOPT_TIMEOUT_MS, 5000)，比全局限时限得更准 - PDO：连接时加
PDO::ATTR_TIMEOUT => 5，查询用SQLSRV_ATTR_QUERY_TIMEOUT（SQL Server）或 MySQLi 的mysqli_options($link, MYSQLI_OPT_CONNECT_TIMEOUT, 5) - Socket：用
stream_set_timeout($fp, 5)控制单次读写等待，比set_time_limit更轻量、可恢复 - 若需中断正在执行的阻塞函数（如
fread），CLI 下可用pcntl_alarm()发送 SIGALRM，但 Web SAPI 不支持pcntl扩展
set_time_limit 就万事大吉，结果被 Nginx 的 proxy_read_timeout 或 MySQL 的 wait_timeout 默默截断，连错误都捕获不到。php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
