最常见的原因是漏掉了FILE_APPEND标志——它不是默认行为，不加就是覆盖；更隐蔽的问题是路径中父目录不存在，file_put_contents()直接失败返回false但不报错，必须手动mkdir(dirname($path), 0755, true)确保路径存在后再调用file_put_contents($path, $data, FILE_APPEND | LOCK_EX)。
file_put_contents() 追加时为什么没生效？
最常见的原因是漏掉了 FILE_APPEND 标志——它不是默认行为，不加就是覆盖。更隐蔽的问题是：路径中父目录不存在，file_put_contents() 直接失败并返回 false，但不会报错或创建目录。
- 必须手动确保路径存在：
mkdir(dirname($path), 0755, true)再写入 -
file_put_contents($path, $data, FILE_APPEND | LOCK_EX)才真正追加且加锁；只加LOCK_EX不加FILE_APPEND仍会覆盖 - 返回值为
0不代表失败（比如写入空字符串），要用=== false判断错误 - 并发高时
LOCK_EX会阻塞，日志类场景可考虑轮转或用fopen('a')+flock()分段控制
fopen('a') 后 fwrite() 为什么有时写到中间而不是末尾？
因为 'a' 模式只保证“每次 fwrite() 调用都追加到当前文件末尾”，但如果你在同一个句柄里反复 fseek() 或混用读写模式（如 'a+'），文件指针位置就不可控了。真实日志场景里，只要坚持只用 'a'、不调 fseek()、不读取，就绝对安全。
-
'a'模式下，fwrite()总是从物理末尾开始写，不受当前指针影响 -
'a+'允许读，但读操作会移动指针，后续fwrite()可能覆盖而非追加——除非你显式fseek($fp, 0, SEEK_END) - 多进程同时写同一文件时，即使都用
'a'，Linux 内核也保证原子追加（单次write()系统调用），但 PHP 层的fwrite()若分多次调用，仍可能穿插 - 保险做法：每个写操作都独立
fopen('a')→fwrite()→fclose()，或全程加flock($fp, LOCK_EX)
PHP7.4 下 file_put_contents() 和 fopen/fwrite 性能差多少？
单次小数据写入，差异几乎可以忽略；但高频写（比如每秒百次日志）时，file_put_contents() 因每次都要打开/关闭文件，开销明显高于复用一个 fopen() 句柄。
-
file_put_contents()是封装函数，内部等价于fopen()+fwrite()+fclose() - PHP7.4 的
fwrite()在小数据量下做了缓冲优化，连续写比反复打开更稳 - 若需结构化输出（如 JSON 行格式日志），用
fopen('a')复用句柄 +json_encode()+fwrite()+ 换行符，比每次file_put_contents()快 2–3 倍 - 注意：长期持有一个
fopen()句柄要防止泄漏，尤其在 CLI 长周期脚本里，建议写完后主动fclose()或用register_shutdown_function()清理
追加内容时中文乱码或换行失效怎么办？
根本原因不是 PHP，而是文件本身编码和写入内容编码不一致，或者换行符被系统/编辑器误解。PHP 默认按字节写入，不处理编码转换。
立即学习“PHP免费学习笔记（深入）”；
- 确保写入前内容已是 UTF-8：
mb_convert_encoding($text, 'UTF-8', 'auto')，尤其从 $_POST 或数据库读出时 - Windows 记事本认
"\r\n"，Linux/macOS 认"\n"；统一用PHP_EOL替代硬编码换行符 - 如果文件原先是 GBK 编码，直接追加 UTF-8 字符会乱码——要么全量转码后再写，要么保持原始编码写入
- 用
file_put_contents()时，不要传数组指望自动print_r()，那会输出带空格和缩进的文本，破坏日志格式；结构化数据务必json_encode($data, JSON_UNESCAPED_UNICODE | JSON_UNESCAPED_SLASHES)
file_get_contents() 读出来 hexdump 看前几个字节，就能快速判断是 BOM、编码还是换行符问题。追加操作看似简单，但跨平台、多进程、编码混合的场景下，细节决定成败。 
