max_execution_time在CLI下默认为0（不限时），Web环境下才受php.ini配置影响；CLI须用set_time_limit()或-d参数设置，且需配合系统调用超时控制。
max_execution_time 在 CLI 和 Web 环境下表现完全不同
PHP 的 max_execution_time 默认只对 Web SAPI（如 Apache、FPM）生效，CLI 模式下默认是 0（不限时）。很多人在命令行跑脚本卡死，却去改 php.ini 里的 max_execution_time，结果毫无反应——因为 CLI 根本不看这个值。
实操建议：
- Web 场景：修改 php.ini 或 .htaccess（Apache）或 pool.d 配置（PHP-FPM），设
max_execution_time = 120 - CLI 场景：必须用
set_time_limit(120)或启动时加-d max_execution_time=120 - 注意：
set_time_limit(0)在 CLI 下才真正无限；Web 下设为 0 可能被 SAPI 层拦截（比如 Nginx 的fastcgi_read_timeout会先超时）
set_time_limit() 不是万能的，它会被某些系统调用“跳过”
set_time_limit() 只监控 PHP 用户态执行时间，一旦进入阻塞式系统调用（比如 fsockopen() 连接远端、sleep()、stream_socket_client()），计时器就暂停了。你设了 30 秒，但网络卡住 2 分钟，脚本照样挂在那里不动。
实操建议：
- HTTP 请求务必用带超时的客户端：cURL 要设
CURLOPT_TIMEOUT和CURLOPT_CONNECTTIMEOUT；file_get_contents() 配合stream_context_create()设timeout选项 - 数据库连接和查询超时要单独配：MySQLi 用
mysqli_options($link, MYSQLI_OPT_CONNECT_TIMEOUT, 5)；PDO 则在 DSN 后加;connect_timeout=5 - 避免用
sleep()做延时逻辑，改用非阻塞方式或信号控制
php.ini、.user.ini、ini_set() 三层优先级容易搞混
不是所有地方都能随意改 max_execution_time。它的生效受 PHP 配置层级限制：php.ini 是全局基础；.user.ini 只对当前目录及子目录生效，且要求 user_ini.filename 未被禁用；ini_set('max_execution_time', '60') 在脚本里调用，但仅对当前请求有效，且某些 SAPI（如 PHP-FPM 的某些安全模式）会禁止运行时修改。
实操建议：
- 线上环境优先改
php.ini或 FPM pool 配置，稳定可控 - 共享主机若只允许
.user.ini，确认user_ini.allow_path允许该目录，且文件名确实是.user.ini（不是 .htaccess 或其他） -
ini_set()适合调试或临时覆盖，但必须在脚本开头尽早调用，且要检查返回值：if (ini_set('max_execution_time', '60') === false) { /* 失败，可能被 disable_functions 拦了 */ }
超时不是越长越好，尤其涉及并发和资源泄漏
把 max_execution_time 设成 300 秒，看似“更稳”，但实际会让慢请求堆积，吃光 PHP-FPM 的 worker 进程或 Apache 的线程数。更危险的是，超时前没清理的资源（如未关闭的 MySQL 连接、打开的文件句柄、未 unset 的大数组）会持续占用内存，引发雪崩。
实操建议：
- 按业务真实耗时设上限：API 接口建议 ≤ 30s，后台任务拆成小步 + 队列，单次执行 ≤ 10s
- 超时前主动清理：注册
register_shutdown_function()，检查error_get_last()是否含"Maximum execution time"，然后 close db conn、unset big vars - 监控比调参更重要：用
slowlog（PHP-FPM）或error_log记录超时脚本路径，定期分析瓶颈点，而不是一味加时间
超时设置本质是权衡：既要防死循环，又不能掩盖设计缺陷。最常被忽略的，是忘了查 nginx/apache 的上游超时配置，它们往往比 PHP 层更早掐断连接。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
