phpenv 不提供超时设置功能，其仅用于切换 PHP 版本；真正生效的是各版本独立的 php.ini 中 max_execution_time 配置或运行时 set_time_limit() 调用，且 Web 环境下还受 Nginx、PHP-FPM 等多层超时限制。
phpenv 本身不提供修改 PHP 脚本执行时间的功能——它只是用来切换不同版本 PHP 的环境管理工具，不干预运行时配置。真正起作用的是 PHP 自身的超时机制，而 phpenv 切换的每个 PHP 版本，仍需各自独立配置 max_execution_time 或调用 set_time_limit()。
为什么 phpenv set-time-limit 不生效
你可能搜到过类似 phpenv set-time-limit 600 的命令，但它并不存在。phpenv 没有内置超时设置子命令，所有这类误传都源于混淆了工具职责。
-
phpenv只负责 PATH、php可执行文件路径、php-config等环境变量的软链接切换 - 它不修改
php.ini，不调用ini_set()，也不注入任何运行时参数 - 即使你用
phpenv local 8.2切到某个版本，该版本的max_execution_time仍是其自带php.ini里定义的值（通常是 30 或 60 秒）
在 phpenv 管理的 PHP 下改超时的正确路径
必须进入目标 PHP 版本的实际配置层操作。先确认当前生效的 php.ini 位置：
php --ini
输出类似：
立即学习“PHP免费学习笔记（深入）”；
Configuration File (php.ini) Path: /Users/xxx/.phpenv/versions/8.2.12/etc Loaded Configuration File: /Users/xxx/.phpenv/versions/8.2.12/etc/php.ini
然后编辑这个 php.ini 文件，修改：
max_execution_time = 600
保存后，**重启你的 Web 服务或 PHP-FPM 进程**（CLI 脚本可直接生效，但 Web 请求依赖服务重载）。
- 如果你用的是
php-fpm，执行：phpenv fpm-restart（需装phpenv-ext插件）或手动 kill + restart - 如果只是跑 CLI 脚本，改完
php.ini后无需重启，下次php script.php就按新值走 - 注意：有些
phpenv安装方式（如通过 Homebrew）默认不带etc/目录，此时需手动复制模板：cp $(phpenv root)/versions/8.2.12/etc/php.ini.default $(phpenv root)/versions/8.2.12/etc/php.ini
set_time_limit() 在 phpenv 环境下是否可靠
可以调，但效果受限于底层 PHP 配置和运行模式。
- Web 模式（Apache/Nginx + PHP-FPM）：只要
disable_functions没禁用set_time_limit，且没开safe_mode（已废弃），就能生效 - CLI 模式：
max_execution_time默认被忽略，set_time_limit(0)才真正取消限制 —— 这正是phpenv最常用于长任务的场景 - 关键陷阱：它只重置 PHP 用户态 CPU 时间，对
curl_exec()、mysqli_query()、sleep()等 I/O 或系统调用不计时；卡在网络或数据库上，set_time_limit()压根不管
更稳妥的长期方案：绕过 Web 超时链
别在 Web 请求里硬扛长任务。用 phpenv 切好版本后，把耗时逻辑拆成 CLI 脚本：
phpenv local 8.2 php long-task.php
这样既避开 Nginx/Apache 的 fastcgi_read_timeout 或 ProxyTimeout，也绕开 PHP-FPM 的 request_terminate_timeout，只受系统资源和你自己脚本逻辑约束。
真正的难点从来不在“怎么设 0”，而在于：I/O 超时、数据库连接池、信号中断、内存泄漏——这些都不会因为 set_time_limit(0) 就自动消失。
