写配置文件时，很多人只关心键值对有没有写对，却忽略了换行这种“小事”。可就是这个小细节，有时候能让服务起不来，CI/CD 流水线直接挂掉。
\n\n为什么换行会出问题？
\n不同操作系统对换行的处理方式不一样。Windows 用的是 \\r\\n（回车+换行），Linux 和 macOS 用的是 \\n（只有换行）。当你在 Windows 上编辑完 config.yaml 提交到 Git，然后在 Linux 服务器上部署，某些解析器可能会因为多出的 \\r 字符报错。
\n\n比如你看到日志里出现这样的错误：
\nError parsing config: invalid character '\\r' at line 15其实不是配置写错了，而是换行符惹的祸。
\n\n常见配置文件的换行要求
\nYAML、JSON、.env 这些格式虽然语法不同，但都对换行敏感。尤其是 JSON，严格要求使用 UTF-8 编码和标准换行，否则 parse 失败。
\n\n看一个 .env 文件的例子：
\nDB_HOST=localhost\r\nDB_PORT=5432\nREDIS_URL=redis://cache:6379第一行用了 \\r\\n，后两行是 \\n。这种混合换行在某些环境下会导致 DB_HOST 的值变成 localhost\\r，连不上数据库。
Git 怎么处理换行才靠谱？
\nGit 有个配置叫 core.autocrlf，能自动转换换行符。团队协作时建议统一设置：
# Windows 开发者执行\ngit config --global core.autocrlf true\n\n# Linux/macOS 用户执行\ngit config --global core.autocrlf input这样提交时自动转成 LF，拉取时根据系统决定是否转回 CRLF。
\n\n编辑器别乱来：关掉“自动添加 BOM”
\n有些文本编辑器（比如记事本）保存 UTF-8 文件时会偷偷加个 BOM 头，加上之后，YAML 解析器可能直接拒识读取。VS Code、Sublime 都可以手动选“UTF-8 without BOM”保存。
\n\n自动化检查更省心
\n在 CI 流程里加一步检查，确保所有配置文件都是 LF 换行：
\n#!/bin/sh\nfind . -name '*.yaml' -o -name '*.json' -o -name '.env*' | xargs grep -U $'\\r' &> /dev/null \&& echo 'Found CRLF line endings' && exit 1发现问题提前报，别等到上线才发现服务起不来。
\n\n团队协作的小建议
\n项目根目录放个 .editorconfig 文件，约定好换行风格：
root = true\n\n[*.yml, *.yaml, *.json, .env*]\nend_of_line = lf\ncharset = utf-8\ntrim_trailing_whitespace = true\ninsert_final_newline = true主流编辑器都支持 EditorConfig 插件，打开项目就自动生效，新人接入也少踩坑。
\n\n换行看着不起眼，真出问题能让你查半天。早点把规范定好，比半夜被报警电话吵醒强。
","seo_title":"配置文件换行规范：避免因换行符导致的部署失败","seo_description":"了解配置文件中的换行规范，解决因CRLF与LF不一致引发的解析错误，提升开发协作效率。","keywords":"配置文件换行规范,换行符,CRLF,LF,配置文件解析错误,开发工具,YAML换行,JSON换行"}