phpenv不控制超时，真正起作用的是PHP实例的php.ini、PHP-FPM的request_terminate_timeout及Web服务器（如Nginx的fastcgi_read_timeout、Apache的Timeout）三层配置，任一层缺失都会导致set_time_limit(0)失效。
phpenv 本身不控制脚本超时，也不提供“长连接配置”功能——它只是 PHP 版本管理工具，所有超时和连接行为由你当前激活的 PHP 实例及其运行环境决定。
为什么 set_time_limit(0) 在 phpenv 环境下可能失效
你用 phpenv local 8.3.13 切换到某个版本后，该 PHP 的行为完全取决于它的 php.ini 和运行模式（CLI / FPM / Apache）：
- CLI 模式下：
max_execution_time默认为 0（不限制），set_time_limit(0)通常有效 - FPM 模式下：即使你改了 php.ini，PHP-FPM pool 配置里的
request_terminate_timeout会强制 kill 进程，优先级高于 PHP 内部设置 - Apache + mod_php 下：
Timeout指令（非max_execution_time）控制整个请求生命周期，包括网络传输、SSL 握手，PHP 根本来不及响应 - 如果你在 phpenv 管理的 CLI 脚本里调用了
curl_exec()或mysqli_query()却卡住，问题不在 PHP 超时，而在这些扩展自身的超时未设（如curl_setopt($ch, CURLOPT_TIMEOUT, 10)）
phpenv 环境中真正要改的三个地方
不要只盯着 phpenv 或 php.ini —— 超时是层层拦截的，漏一层就白配：
-
PHP 层：编辑当前版本的 php.ini（路径可通过
php --ini查看），设max_execution_time = 0或具体秒数；CLI 下可跳过这步，直接用php -d max_execution_time=0 script.php -
PHP-FPM 层（若用 FPM）：修改对应 pool 的配置（如
/path/to/php-fpm.d/www.conf），加php_admin_value[max_execution_time] = 0和request_terminate_timeout = 0（设为 0 表示禁用，生产环境慎用） -
Web 服务器层：Nginx 要同步调大
fastcgi_read_timeout；Apache 要确认Timeout值 ≥ PHP 限值；否则你看到的是 504，不是 PHP 错误
所谓“长连接”在 phpenv 场景下实际指什么
phpenv 不参与连接管理，但你用它装的 PHP 版本支持两类常见“长连接”场景，需分别配置：
立即学习“PHP免费学习笔记（深入）”；
-
数据库长连接：PDO 构造时传
[PDO::ATTR_PERSISTENT => true]；mysqli 则需在new mysqli()第七个参数传MYSQLI_CLIENT_LONG_FLAG。注意：连接池由 MySQL 服务端维护，PHP 不负责复用逻辑 -
cURL 复用连接：用
curl_init()创建句柄后，多次curl_setopt_array()+curl_exec()不关闭句柄，就能复用 TCP 连接；关键要设CURLOPT_TCP_KEEPALIVE => 1和CURLOPT_TIMEOUT防卡死 -
HTTP 客户端断开后继续执行：必须配合
fastcgi_finish_request()（仅 FPM 有效）+ignore_user_abort(true)+set_time_limit(0)，否则浏览器关掉，FPM 进程大概率被回收
最常被忽略的一点：phpenv 切换版本后，你改的 php.ini 可能不是当前生效的那个 —— 每个 PHP 版本有独立的配置目录，php --ini 输出的 “Loaded Configuration File” 才是真实路径。改错文件，等于没改。
