file_put_contents更适合大多数写入场景，因其原子写入、自动资源管理；但大文件需fwrite分块写，并发写需flock加锁，权限和路径问题最常导致失败。
file_put_contents 比 fwrite 更适合大多数写入场景
直接用 file_put_contents，除非你真需要边写边控制缓冲、或追加时还要自己处理文件锁。它底层封装了 fopen/fwrite/fclose，但默认带原子写入（临时文件 + 重命名），避免写到一半崩溃导致脏数据。
常见错误是忽略返回值：写失败时它返回 false，但很多人只当成功处理。尤其在 NFS 或容器挂载卷上，磁盘满、权限错、路径不存在都可能静默失败。
-
file_put_contents默认覆盖，要追加必须显式传FILE_APPEND - 写大文件（>1MB）时，它会把整个内容 load 进内存，可能触发
memory_limit报错；这时得切回fwrite分块写 - Windows 下路径分隔符用
/没问题，但拼接变量时别漏了realpath或dirname(__FILE__)防相对路径失效
fwrite 必须配 fopen/fclose，且手动管理资源
用 fwrite 就意味着你主动接管了文件句柄生命周期。漏关句柄（fclose）会导致系统文件描述符耗尽，尤其在长连接或 CLI 脚本里，几分钟就崩。
典型误用：在循环里反复 fopen 写一行再 fclose——性能差、易出错。正确做法是打开一次，循环 fwrite，最后关一次。
立即学习“PHP免费学习笔记（深入）”；
- 打开模式选错：写新文件用
'w'，追加用'a'，读写用'c+'（'w+'会清空原内容） - 写入前不检查
fopen返回值是否为false，结果fwrite直接警告“expects parameter 1 to be resource” - 二进制内容（如图片、加密数据）必须用
'wb'或'ab'，否则 Windows 下换行符会被悄悄转成\r\n
权限和路径问题比函数选择更常导致失败
90% 的 “写不进去” 不是代码问题，而是 PHP 进程用户（如 www-data 或 nginx）对目标目录没写权限，或父目录不可执行（no execute permission）。Linux 下目录必须有 x 权限才能进入，没它连 is_writable 都返回 false。
常见现象：file_put_contents 返回 0 或 false，error_get_last 显示 failed to open stream: Permission denied。
- 先用
is_writable($dir)检查目录，别只查文件是否存在 - 用
getcwd()确认当前工作目录，CLI 和 Web Server 的默认路径往往不同 - 绝对路径优先：用
__DIR__ . '/logs/app.log'，别依赖./logs/ - SELinux 或 Docker 容器里，还需确认上下文标签（
ls -Z）是否允许 httpd_t 写入
并发写同一个文件时，file_put_contents 不自动加锁
file_put_contents 默认不加锁，多进程同时写一个日志文件，大概率出现内容交错、丢失。它提供的 LOCK_EX 标志只对单次调用生效，不能替代应用层锁机制。
比如两个请求同时执行 file_put_contents('log.txt', "A\n", FILE_APPEND | LOCK_EX)，仍可能因内核调度导致写入顺序混乱，只是不会覆盖彼此。
- 高并发日志场景，用
error_log()或专用日志库（如 Monolog），它们内置轮转和串行化 - 必须手写日志时，用
flock($fp, LOCK_EX)包住fwrite，且确保$fp是fopen打开的持久句柄 - 临时方案：给每个写入加微秒级随机延迟（
usleep(rand(100, 500))），治标不治本，但能缓解测试环境问题
真正麻烦的是混合场景：既要追加、又要原子性、还要并发安全、还得支持超大文件。这时候得拆逻辑——用 fwrite 分块写临时文件，写完再 rename，再配合 flock 控制入口。没人喜欢这么干，但线上出过问题的人，都默默写过这套逻辑。
