结论：应使用 open() 的 newline 参数配合 os.linesep 控制写入，而非手动替换换行符；默认写入时设 newline=None 或 ""，强制 LF 用 newline="\n"，仅在生成系统原生脚本时才需 os.linesep。
直接说结论：不要手动替换 \r\n 或 \n，而是用 Python 的 open() 的 newline 参数 + os.linesep 组合控制写入行为，读取时默认即可。
写文件时换行符错乱（git diff 显示大量 ^M）
这是最常见现象：Windows 上生成的文件传到 Linux 服务器后，每行末尾多出 \r，vim 里显示 ^M，grep 或 json.loads() 可能失败。
- 根本原因不是字符串里写了
\r\n，而是用open(..., "w")写文本时，Python 在 Windows 下自动把\n转成\r\n，但你又在代码里手动拼了\r\n，导致双重转换 - 正确做法是：统一用
\n构建内容，写入时让 Python 自动适配 —— 即不设newline参数（默认值None），或显式设为newline="" - 如果必须强制输出 LF（比如生成 shell 脚本、Dockerfile、JSON 配置），则用
newline="\n"并确保以文本模式打开：with open("script.sh", "w", newline="\n") as f: - 绝对避免：用
.replace("\n", "\r\n")后再写入 —— 这会在 Linux/macOS 上污染内容，且在 Windows 上触发二次转换
os.linesep 该不该用？
os.linesep 只在极少数场景有用：你要生成一个“给当前系统原生工具用”的文件，且该工具对换行符敏感（比如 Windows 批处理 .bat、PowerShell 脚本）。
- 它返回的是当前 Python 解释器编译时绑定的 C 库所定义的换行符，不是运行时检测结果 —— 所以在 WSL 里
os.linesep仍是"\n"，哪怕你在 Windows 上跑 - 绝大多数情况不需要它：日志、配置、API 响应、模板渲染都用
\n即可；open()默认行为已足够健壮 - 唯一推荐用它的地方：拼接命令行参数或生成脚本内容时，例如
f.write(f"echo hello{os.linesep}ls -l")
第三方库（如 yapf、pyecharts）输出 HTML/JSON 文件错乱
这类问题本质是库内部写文件时没控制 newline，或用了二进制模式但内容含 \n。
立即学习“Python免费学习笔记（深入）”；
-
yapf默认保留源文件换行符，靠retain_line_endings = True控制，不是靠os.linesep—— 它读取文件时就记住了原始换行符类型，格式化后原样写出 -
pyecharts渲染 HTML 时若出现空白行，大概率是模板里混用了\r\n和\n；解决方案是统一用re.sub(r'[\r\n]+', '\n', text)预处理输入内容 - 所有生成文本文件的库，只要没显式指定
newline，都依赖 Python 默认的 universal newlines 行为；如果你发现输出异常，优先检查是否被上层代码提前做了.replace操作
最容易被忽略的点：换行符问题几乎从不发生在字符串构造阶段，而总在文件写入或跨进程通信（如 subprocess.run 输入）时暴露。盯住 open() 的 newline 参数和 subprocess 的 text=True 开关，比到处 .replace 有效得多。
