fopen失败时直接fclose会报错，因返回false而非资源；文件模式错误会导致数据清空或写入失败；未fclose引发句柄泄漏；fclose返回false需检查以确保数据落盘。
fopen 返回 false 时直接用 fclose 会出错
很多人在 fopen 失败后仍习惯性调用 fclose，比如：
$fp = fopen('missing.txt', 'r');
fclose($fp); // Warning: fclose() expects parameter 1 to be resource, bool given
这是因为 fopen 失败时返回 false（布尔值），不是资源类型。PHP 7.4 不会自动静默转换，fclose 会直接报 Warning 并中断执行。
- 必须先判断
$fp !== false再调用fclose - 不要依赖
is_resource($fp)—— 它对false返回false，但无法区分未打开和已关闭的资源 - 更稳妥写法：
if ($fp) { fclose($fp); }（因为false在条件中为假，其他有效资源为真）
文件模式选错导致数据被清空或写不进去
fopen 的 mode 参数不是可有可无的装饰，它直接决定文件内容命运。常见误用：
- 用
'w'模式读取配置文件 → 文件被截断为空，后续fread返回空字符串 - 用
'r'模式尝试fwrite→ 写入失败，返回 0，且不报错（静默失败） - 用
'a'模式后忘记fseek就fread→ 总是从文件末尾开始读，读不到内容
真正需要「读+写」时，优先选 'r+'（文件必须存在）或 'a+'（文件不存在则创建，指针在末尾，读前需 fseek($fp, 0)）。
没 fclose 会导致句柄泄漏，尤其在循环或 CLI 脚本里
PHP 7.4 默认 max_execution_time 和 memory_limit 限制下，短期脚本可能看不出问题。但在长时间运行的 CLI 任务或高并发 Web 请求中：
- 每个未关闭的文件句柄占用操作系统资源（Linux 默认 per-process limit 通常为 1024）
- 达到上限后，后续
fopen全部返回false，且错误信息是「Too many open files」而非文件路径问题 -
file_get_contents等封装函数内部会自动fclose，但手动用fopen就必须自己负责
最简防御：所有 fopen 后紧跟 try...finally 块（PHP 7.4 支持），确保无论中间是否异常，fclose 都执行。
fclose 返回非零值说明写入可能没落盘
fclose 不只是释放句柄，它还会刷新缓冲区并触发系统级写入。它返回 0 表示成功，返回 EOF 或 -1（实际是整数非零）意味着底层 close() 系统调用失败。
- 典型原因：磁盘满、权限丢失、NFS 挂载异常、文件被其他进程锁住
- 仅检查
fopen成功还不够，fclose失败往往才是数据持久化的最后一道防线失守 - 建议写法：
if (fclose($fp) === false) { error_log("fclose failed on $filename"); }
真正关键的不是「有没有调用 fclose」，而是「调用后有没有检查它的返回值」——这点在 PHP 7.4 及之后版本中容易被忽略。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
