直接结论：别手动替换，用yapf或black自动统一，配合git配置防复发。因字符串替换不可靠，易漏混合换行符、破坏原始意图且难集成ci/cd；black保留原始换行符风格并统一代码格式，yapf可强制全项目用lf；git需配core.autocrlf及.gitattributes兜底，历史问题须用git add --renormalize修复。
直接结论：别手动替换，用 yapf 或 black 自动统一，配合 git 配置防复发。
为什么 replace('\r\n', '\n') 不可靠
这种字符串级替换看似简单，但容易漏掉混合情况（比如 '\r\r\n' 或末尾多余 '\r'），更关键的是——它破坏原始文件的换行符“意图”。比如一个 Windows 用户写的 .py 文件本该是 \r\n，你全换成 \n 后，他在记事本里打开会变成一行。而且这种硬编码方式无法集成进 CI/CD 或编辑器保存钩子。
常见错误现象包括：
- Git diff 显示整文件变更，实际只改了一行
- PyCharm 提示 “Line separator is not consistent” 但不自动修复
- CI 构建失败，报错信息里混着
^M
用 black 保留平台习惯并统一风格
black 默认读取文件时归一化换行符，写回时按原始文件风格输出（\r\n 的保持 \r\n，\n 的保持 \n），同时强制代码格式一致。这是最贴近开发者直觉的方式。
实操建议：
- 在项目根目录加
pyproject.toml，内容只需：[tool.black] line-length = 88
- 运行
black --check .检查哪些文件需格式化 - 执行
black .一次性修复所有.py文件 - 注意：它不会改动空文件或纯空白行，也不会把
\r\n强制转成\n—— 这正是你要的“兼容性”
用 yapf 强制跨团队统一换行符
当团队明确要求所有文件必须用 \n（比如部署到 Linux 容器），yapf 的 line_ending 配置比 black 更直接可控。
实操建议：
- 创建
.style.yapf文件：[style] line_ending = '\n' indent_width = 4 continuation_indent_width = 4
- 运行
yapf --in-place --recursive .批量处理 - 验证是否生效：用
file my_script.py（Linux/macOS）或 PowerShell 的Get-Content my_script.py -Raw | Format-Hex查看末尾字节 - 注意：
retain_line_endings = True是默认值，显式关闭它才能启用line_ending强制规则
Git 层必须配 core.autocrlf
工具再好，没配 Git 就白搭。Windows 开发者提交前若没设好，\r\n 仍会进仓库，后续所有人拉下来都得再修一遍。
正确配置方式：
- Windows 用户运行：
git config --global core.autocrlf true（检出时转\r\n，提交时转\n） - macOS/Linux 用户运行：
git config --global core.autocrlf input（只提交时转\n，检出不变） - 项目级兜底：在仓库根目录加
.gitattributes：* text=auto eol=lf *.py text eol=lf
这比全局配置更可靠，尤其对新成员
最容易被忽略的一点：已有历史提交里的换行符错误不会自动修正。如果项目已存在大量 \r\n 混入，先用 black 或 yapf 批量重写，再 git add --renormalize . 刷新 Git 缓存，否则下次 git status 还会报一堆换行符变更。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
