写配置文件时，很多人随手一回车就换行，觉得只要内容对，格式无所谓。可真到项目上线那一刻，服务起不来，排查半天发现是因为换行符不对，这种事在开发圈里并不少见。
换行符不是都一样
Windows、Linux、macOS 对换行的处理方式不一样。Windows 用的是 CRLF（\r\n），而 Linux 和 macOS 通常用 LF（\n）。看着只是多了一个字符，但在某些严格解析的场景下，比如 Kubernetes 的 YAML 配置、Nginx 的 conf 文件，或者 CI/CD 流水线脚本，CRLF 可能直接被当作非法字符拒绝。
举个例子，你在 Windows 上编辑好一份 docker-compose.yml，传到 Linux 服务器上运行，结果报错：invalid character '\r' looking for beginning of value。问题就出在每一行末尾那个看不见的 \r 上。
文本编辑器的“贴心”可能是坑
像 VS Code、Notepad++ 这类工具，默认会根据系统自动设置换行符。你可能根本没注意右下角那个 CRLF 的提示，点一下就切成了 LF。团队协作时，有人用 Mac，有人用 Windows，提交到 Git 的配置文件换行符来回变，不仅容易出错，还让版本记录一团乱。
Git 怎么处理换行
Git 提供了 core.autocrlf 配置来缓解这个问题。Windows 用户可以设成 true，提交时自动转成 LF，拉取时再转回 CRLF；Linux 和 Mac 用户建议设为 input 或 false，保持 LF 不变。
# Windows
git config --global core.autocrlf true
# Linux / macOS
git config --global core.autocrlf input更稳妥的方式是在项目根目录加个 .gitattributes 文件，明确指定哪些文件必须用 LF：
*.yml text eol=lf
*.yaml text eol=lf
*.json text eol=lf
*.conf text eol=lf
*.env text eol=lf这样不管谁在什么系统上提交，Git 都会按规则统一处理。
配置文件里的长字符串怎么换行
除了行尾换行符，配置中长值的换行也有讲究。比如 YAML 里写一段脚本，可以用 | 保留换行，或用 > 折叠成单行：
script: |
echo "第一步"
echo "第二步"
exit 0或者：
message: >
这是一段很长的日志信息
自动合并成一行存储用错了符号，原本该换行的内容被压成一行，脚本执行就可能出错。
编辑器配置建议
在 VS Code 里，可以打开设置，搜索 “eol”，改成 \n；也可以装 EditorConfig 插件，配合项目中的 .editorconfig 文件统一风格。很多开源项目根目录都有这个文件，作用就是锁定缩进、换行、编码等基础格式。
root = true
[*.yml]
indent_style = space
indent_size = 2
end_of_line = lf
charset = utf-8
[*.sh]
end_of_line = lf
insert_final_newline = true只要团队成员都装了插件，就能自动遵循这些规则，少很多扯皮。