跨平台换行与编码差异是什么
换行与编码差异是「配置下发成功但服务起不来」的常见原因：类 Unix 用 LF 换行，Windows 传统文本用 CRLF；编码可能是 UTF-8 无 BOM、UTF-8 带 BOM 或系统本地编码。带 BOM 的配置首行、CRLF 的脚本、非 UTF-8 的中文注释，都会让解析器报错或读到多余字符。处理办法是约定「UTF-8 无 BOM + LF」作为配置仓库基准，在适配层按平台转换，并在下发后做一次字节级校验。
基本信息
| 换行约定 | 仓库统一 LF，目标平台需要时在适配层转换 |
|---|---|
| 编码约定 | UTF-8 无 BOM 为基准 |
| 风险点 | BOM 头、CRLF 脚本、本地编码字符集、混合行尾 |
| 校验方式 | 首字节检查与行尾样式检查 |
| 工具支持 | 版本控制的文件属性与编辑器编码设置 |
典型使用场景
- Shell 脚本下发到类 Unix 后报解释器或路径无效（CRLF 所致）
- 配置文件首行出现多余字符（BOM 所致）解析失败
- Windows 侧服务读取配置文件时对 BOM 敏感
- 中文注释在非 UTF-8 环境显示为乱码或截断
- 同一批模板文件在多个平台间共享流转
下发前后校验示意
下发前后校验示意
# 下发前与下发后各校验一次，比事后排错快得多
# 1) 检查是否带 BOM：观察文件开头字节是否符合预期
# 2) 检查行尾样式：LF 与 CRLF 混用是解析失败的高频原因
# 3) 统一约定：仓库内一律 LF + UTF-8 无 BOM
# 4) 目标平台需要转换时在适配层完成，不把差异写进模板
# 5) 各平台对 BOM 的敏感性差异以对应软件官方文档为准差异项与处理
| 差异项 | 典型症状 | 处理方式 |
|---|---|---|
| BOM 头 | 首行出现异常字符或解析失败 | 仓库禁用 BOM，下发前剥离 |
| CRLF 换行 | 脚本无法执行、行尾多出字符 | 脚本类文件强制 LF |
| 本地编码 | 中文乱码或被截断 | 统一 UTF-8 并显式声明编码 |
| 混合行尾 | 仅部分行异常，难以复现 | 保存时统一规范化行尾 |
版本控制通常提供行尾与文件属性设置，可以把「仓库内统一 LF」固化下来，避免开发者各自编辑器的自动转换造成反复回归。
BOM 在某些平台与工具链上完全无害，在另一些（脚本首行、部分配置解析器）会导致硬失败。不要用「本地能跑」判断安全，应以目标平台的解析行为为准。