XML换行符本身不影响解析，但跨平台生成与处理时易引发隐性错误；需检查Git设置、十六进制文件格式及生成工具的平台相关编码，并统一用LF提交和标准化文本节点中的换行。
XML 文件本身跨平台没问题，但换行符会影响解析稳定性
XML 规范明确允许
（LF）、
（CRLF）、
（CR）三种换行形式，主流解析器（如 Python 的 xml.etree.ElementTree、Java 的 DocumentBuilder、libxml2）都能识别。问题不出在“能不能读”，而出在“谁写的文件、怎么写的、谁来读”——尤其当 XML 由脚本生成或经 Windows 编辑器保存后，在 Linux 下用某些工具处理时容易触发隐性错误。
Windows 编辑器保存的 XML 在 Linux 下解析报 xmlParseEntityRef: no name
这不是换行符直接导致的，而是典型副作用：Windows 编辑器（如记事本、早期 VS Code 默认设置）用 CRLF（\r\n）保存文件，若 XML 内容里又含未转义的 & 字符（比如写成 © 但漏了分号），在部分解析器中 \r 可能干扰实体边界判断，放大原本就存在的语法错误。更常见的是，用 cat 或 grep 查看时发现行尾多出 ^M，说明文件混入了 CR，虽不直接破坏 XML 结构，但会干扰依赖行首/行尾匹配的预处理脚本。
- 检查是否真有
^M：运行file your.xml，输出含CRLF即表示含\r - 安全清理：用
dos2unix your.xml（Linux/macOS）或sed -i 's/\r$//' your.xml - 生成端预防：Python 写 XML 时打开文件务必用
open(..., newline='')；Node.js 用fs.writeFileSync时指定encoding: 'utf8'即可，无需额外处理换行
Python xml.etree.ElementTree 读取含 \r 的 XML 是否需特殊处理
不需要。从 Python 3.9 开始，xml.etree.ElementTree.parse() 和 .fromstring() 对 CRLF、LF、CR 全部透明支持。但注意两个实际坑点：
-
xml_declaration=True时，ElementTree.write()默认用系统换行符（Windows 写出 CRLF，Linux 写出 LF），若需统一，显式传encoding='utf-8'+ 手动控制内容换行（例如用tostring()后替换\r\n为\n） - 如果 XML 中文本节点含
\r\n，解析后elem.text里保留原样；但若后续做字符串比较或正则匹配，\r容易被忽略，建议标准化前先用.replace('\r\n', '\n').replace('\r', '\n') - 用
lxml替代标准库时行为一致，但lxml.etree.XMLParser(recover=True)会容忍更多格式错误——别依赖它来“修复”换行问题
CI/CD 流水线中 XML 配置文件出现解析失败，优先查什么
别急着改换行符，先确认是不是环境差异放大的已有问题：
- 检查 Git 的
core.autocrlf设置：git config --get core.autocrlf。Windows 开发者设为true、Linux CI 设为input是常见组合，此时源码中 XML 应以 LF 提交，否则 CI 拉下的文件可能含意外\r - 用
xxd -c 16 your.xml | head -5直接看十六进制，比肉眼找^M更可靠 - 如果 XML 由 Java 构建工具（如 Maven）生成，检查其插件是否硬编码了
System.lineSeparator()—— 这会导致不同系统产出不同换行，应改用String.format("%n")或显式写\n
换行符只是表象，真正咬人的往往是生成逻辑没隔离平台细节，或者校验流程漏掉了原始文件格式检查。
