改max_execution_time必须同步调整php.ini、nginx的fastcgi_read_timeout及php-fpm的request_terminate_timeout三处配置并重启服务，否则无效；php.ini修改全局生效，set_time_limit()仅当前脚本有效且不能超php.ini上限。
直接改 max_execution_time 就行，但必须分清改哪里、谁生效、谁不生效。
php.ini 里改 max_execution_time 是最稳的方式
全局生效，所有通过该 PHP 实例运行的脚本都受控。适合你有服务器权限、且希望统一管理超时行为的场景。
- 用
php --ini或phpinfo()确认当前生效的php.ini路径，别改错文件 - 找到
max_execution_time = 30这行，改成需要的秒数，比如max_execution_time = 600（10 分钟） - 设为
0表示不限制，但生产环境慎用——PHP-FPM 可能被 pool 的request_terminate_timeout截断，Nginx 也可能在 upstream timeout 后断连 - 改完必须重启 PHP-FPM 或 Apache/Nginx，否则配置不加载
set_time_limit() 在脚本里调用最灵活
适用于只想延长某个脚本、或部署在共享主机无法改 php.ini 的情况。它会重置计时器，不是简单“追加”时间。
- 写在脚本开头即可：
set_time_limit(300);—— 这会让脚本最多再跑 300 秒（从调用点起算） - 传
0：set_time_limit(0);表示取消限制，但前提是没开安全模式，且disable_functions没禁用它 - 注意：如果脚本已运行 25 秒，此时调用
set_time_limit(20)，总时限是 45 秒，不是 20 秒 - CLI 模式下默认是 0（不限制），所以 Web 环境和 CLI 行为不一致，别混淆
ini_set('max_execution_time', ...) 容易踩坑
看起来和 set_time_limit() 类似，但底层机制不同，实际效果更不可靠。
-
ini_set('max_execution_time', '300');不会重置计时器，只修改配置值，对已开始计时的脚本基本无效 - 很多托管环境会把
ini_set加进disable_functions，一调就静默失败 - 它不能绕过
php.ini中的硬性上限（比如某些 SaaS 平台锁死 max_execution_time ≤ 120） - 不如直接用
set_time_limit()，语义明确、行为可预期
别漏掉 max_input_time 和 Web 服务器层超时
只调 max_execution_time 常常不够，尤其是处理大文件上传或长表单时。
-
max_input_time控制 PHP 解析 POST/GET/上传数据的时间，和max_execution_time是两个独立开关，都要检查 - Nginx 默认
fastcgi_read_timeout是 60 秒，若 PHP 脚本花了 90 秒才返回，Nginx 早就主动断开了，这时 PHP 日志里看不到错误，但浏览器收不到响应 - Apache 的
Timeout指令（默认 300 秒）也会截断连接，和 PHP 层超时无关 - PHP-FPM 的
request_terminate_timeout优先级高于max_execution_time，设了0也可能被它 kill
真正要调通一个长耗时脚本，得同时盯住 PHP 配置、Web 服务器配置、以及 PHP-FPM（如果用了）三层超时参数，缺一不可。很多人只改了 php.ini 就以为万事大吉，结果卡在 Nginx 那一层，连 PHP 都没进到。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
