fread() 分块读取易卡住或读不完，因返回 false 不一定是 EOF，需配合 ferror() 判断错误、feof() 在 PHP 7.4 下不可靠；推荐用 filesize() 获取总大小，结合累计读取字节数控制循环。
fread() 分块读取时为什么总卡住或读不完
PHP 7.4 中用 fread() 分块读取大文件，常见现象是循环不退出、最后一块读不到、或某次 fread() 返回 false 但文件没完——这不是代码写错了，而是没处理好底层状态判断。
-
fread()返回false可能是 I/O 错误，不一定是 EOF；必须配合ferror($fp)检查是否出错 -
feof($fp)在 PHP 7.4（尤其配合 mmap 或大文件）下可能延迟生效，甚至返回false即使已到末尾 - 更可靠的做法是：先用
filesize($path)获取总大小，再用偏移量 + 累计读取字节数控制循环 - 示例逻辑：
$size = filesize($path); $read = 0; while ($read
file_get_contents() 的 offset/maxlen 参数怎么安全分段用
file_get_contents() 支持分段读，但很多人直接传 0 或负数 offset 导致跳过开头、读错位置，或忽略返回 false 的错误分支。
- offset 必须 ≥ 0，且不能超过文件大小，否则返回
false；建议先filesize()校验 - maxlen 是「最多读多少字节」，不是「固定读这么多」；实际返回长度可能更短（比如只剩 100 字节却指定 1024）
- 不要依赖
strlen(file_get_contents(...)) === maxlen判断是否读完，应比对累计读取量与文件总长 - 典型安全用法：
$offset = 0; $chunk_size = 1024 * 1024; while ($offset
大日志文件逐行读取，fgets() 为什么内存还在涨
用 fgets() 逐行读看似省内存，但若某一行超长（比如日志里混了 base64 或 JSON blob），fgets() 会一次性把整行载入内存，照样触发 OOM。
- 默认情况下
fgets()无长度限制，遇到超长行就爆内存；务必显式传入 length 参数，如fgets($fp, 8192) - 如果行边界不明确（如没有换行符的二进制日志），
fgets()可能阻塞或读满 buffer 后截断，导致数据损坏 - 更稳妥的替代是
stream_get_line($fp, 8192, "\n")，它在指定长度内找分隔符，找不到就返回当前 buffer 内容，可控性更强 - 注意：
fgets()和stream_get_line()都会包含换行符，后续处理需rtrim()
PHP 7.4 下 Generator 处理大文件的坑
用 yield 写生成器读大文件很优雅，但 PHP 7.4 的 GC 机制对 generator 内部引用清理不够及时，容易造成隐式内存堆积。
立即学习“PHP免费学习笔记（深入）”；
- 不要在生成器函数里缓存整行或整块数据到局部变量（比如
$buffer .= $line），这会让引用无法释放 - 每次
yield后，确保该轮使用的变量被重置或超出作用域，例如用unset($line)显式释放（虽非必需，但在关键路径上可降低风险） - Generator 本身不自动
fclose()，必须在外层调用后手动关闭文件句柄，否则 fd 泄漏 - 示例安全结构：
function readLargeFile($path) { $fp = fopen($path, 'r'); if (!$fp) return; try { while (($line = fgets($fp, 8192)) !== false) { yield rtrim($line); } } finally { fclose($fp); } }
实际项目里最易被忽略的，是把「分块」当成万能解药——块大小设太大（比如 10MB）仍可能压垮小内存 VPS，设太小（比如 1KB）又引发频繁系统调用拖慢速度。真正稳的方案，永远是结合业务场景测出临界值：日志分析可 64KB，SQL 导入建议 1–2MB，视频元数据提取则优先用 fseek() 定点读而非流式扫。
