不一定有效。单纯调高max_execution_time无法解决file_get_contents()一次性加载大文件导致的内存耗尽问题，应采用fopen()+fread()流式分块读取，控制单次读取8KB–64KB，及时处理数据并关闭文件指针。
PHP读取大文件时脚本超时，max_execution_time调高就一定有效？
不一定。单纯增大 max_execution_time 只是“拖时间”，不解决根本问题：PHP默认用 file_get_contents() 或 file() 一次性把整个文件载入内存，1GB 文件可能直接触发内存耗尽（Fatal error: Allowed memory size exhausted），此时超时设置根本没机会生效。
真正要处理的是「阻塞式加载」和「内存爆炸」两个问题。优先考虑流式分块读取，而非硬扛超时限制。
用 fopen() + fread() 分块读取大文件的最小安全模式
这是最可控、兼容性最好、内存占用恒定的方式。关键不是“一次读多少”，而是“别让缓冲区失控”。
-
fopen($path, 'rb')必须加b模式，避免 Windows 下换行符干扰二进制内容 - 单次
fread($fp, $chunk_size)建议控制在8192（8KB）到65536（64KB）之间；超过 1MB 容易在低内存环境引发抖动 - 每次读完立即处理或写入，不要累积到数组里——
$buffer .= fread(...)是常见内存泄漏源头 - 记得
fclose($fp)，尤其在循环中频繁打开文件时，否则可能快速耗尽系统文件描述符
while (($chunk = fread($fp, 8192)) !== false) {
// 处理 $chunk，例如写入数据库、计算哈希、转码等
if (strlen($chunk) === 0) break;
}
stream_set_timeout() 和 set_time_limit(0) 的实际作用边界
这两个函数常被误用：
立即学习“PHP免费学习笔记（深入）”；
-
set_time_limit(0)禁用脚本总执行时间限制，但对 I/O 阻塞（如 NFS 挂载点卡死、网络文件系统延迟）无效；它只计 PHP 用户态 CPU 时间 -
stream_set_timeout($fp, $sec, $usec)只影响该流后续的fread()/fgets()调用，且仅在流处于阻塞模式下生效；如果底层是本地磁盘文件，这个 timeout 几乎不会触发 - 真正需要 timeout 的场景其实是远程 HTTP 流、socket 连接或挂载的 CIFS/NFS，而不是读取本地 SSD 上的 500MB 日志
大文件读取中容易被忽略的三个细节
这些点不报错，但会导致行为异常或性能断崖式下跌：
- 文件指针位置错乱：
fseek($fp, 0, SEEK_END)后没fseek($fp, 0, SEEK_SET)就直接fread()，会读不到任何内容 - 编码陷阱：用
fgets()读文本时，若文件含 BOM 或混合编码（如 GBK + UTF-8），strlen()计算长度会失准，建议统一用fread()+ 显式编码检测 - opcache 干预：某些 PHP 版本（尤其是启用了
opcache.enable_cli=1的 CLI 环境）会对file_get_contents()缓存结果，导致多次调用返回旧内容；分块读取不受此影响
分块读取不是“更慢的妥协”，而是面向真实 I/O 行为的设计选择。超时参数只是兜底，不是主逻辑。
