根本原因是php_eol仅适配本机系统，不保证跨平台可读性；写入前须先归一化换行符（如str_replace(["\r\n","\r"],"\n",$content)），再按目标平台统一替换为"\n"或"\r\n"。
file_put_contents 写入的换行符在 Windows、Linux、macOS 上展示不一致，根本原因不是 PHP 写错了，而是你没控制输出换行符的字节形态。PHP 默认用 PHP_EOL（当前系统环境的换行符）拼接字符串，但写入文件后，若该文件被跨平台打开（比如 Linux 生成的文件用 Windows 记事本看），就会显示为“所有内容挤在一行”或末尾多出 ^M。
为什么 PHP_EOL 不适合跨平台文件输出
PHP_EOL 是运行时变量，值取决于 PHP 所在操作系统：
– Linux/macOS 下是 "\n"
– Windows 下是 "\r\n"
它只保证“本机脚本执行时换行正常”，不解决“文件被其他系统读取时是否可读”。
所以你在 Linux 服务器上用 PHP_EOL 写日志，运维用 Windows 打开就全是连在一起的；反之亦然。
写入前统一替换为 "\n" 或 "\r\n"
最直接可控的方式：放弃 PHP_EOL，显式指定目标换行风格。
常见需求是“全用 \n”，因为现代编辑器（VS Code、Notepad++、Sublime）和 CLI 工具（cat、grep）都原生支持，且 Git 默认也按 LF 处理。
- 写入前清理已有换行：
$content = str_replace(["\r\n", "\r"], "\n", $content); - 再拼接并写入：
file_put_contents('log.txt', $content . "\n", FILE_APPEND); - 如果必须适配 Windows 用户双击打开（如 Excel、记事本），则统一用
"\r\n"：$content = str_replace(["\r\n", "\n"], "\r\n", $content);
避免 file_put_contents 自动追加换行导致重复
很多人用 FILE_APPEND 模式反复写入，又每行手动加 "\n"，结果最后一行多一个空行，或两行之间空一行——这是因为 file_put_contents 不检查文件末尾是否有换行，也不帮你去重。
- 不要依赖“上次写入是否带换行”，每次写入前先判断目标文件末尾：
$last = substr(file_get_contents($file), -1) === "\n";（小文件适用） - 更稳妥的做法：始终让每条记录以换行结尾，但写入时不额外加换行，由内容自身保证 —— 即
$record .= "\n"在拼接阶段完成 - 大文件场景下禁用
file_get_contents判断，改用fopen+fseek+fread安全读末尾字节
Windows 记事本识别不到 \n 的真实原因
这不是 PHP 的错，是记事本的硬伤：它只认 \r\n 为换行，遇到 \n 就当普通字符处理，整段显示为一行。这不是 bug，是历史兼容性设计。
- 解决方案不是迁就记事本，而是换工具：推荐用户用 VS Code、Notepad++ 或 VS Code Remote 打开日志
- 如果业务强依赖“双击即开即读”，那就在写入前强制转
\r\n，哪怕部署在 Linux 上也这么做 - 注意：不要用
str_replace("\n", "\r\n", $content)粗暴替换 —— 若原文已有\r\n，会变成\r\r\n，产生乱码。必须先归一化：str_replace(["\r\n", "\r"], "\n", $content)，再统一转\r\n
统一换行符的关键不在“怎么写”，而在“写之前是否已归一化”。很多问题其实卡在中间层：从数据库读出来带 \r\n，用户输入 textarea 提交来的是 \n，日志函数又插了一次 PHP_EOL —— 最终写入前不清洗，后面怎么调都白搭。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
