xml编辑器卡顿主因是xml:space="preserve"保留所有空白及超长文本节点，应改用default模式、用xmllint或lxml拆分长文本，并禁用xml tools实时验证。
XML 文件换行后编辑器还卡？检查是否用了 xml:space="preserve"
很多 XML 编辑器（比如 VS Code 的某些插件、Notepad++ 的 XML 工具、甚至部分 IDE 的预览器）在遇到大段无换行的文本节点时会卡顿，但强行加了换行又怕破坏语义——这时候容易忽略 xml:space 属性的影响。xml:space="preserve" 会让解析器把所有空白（包括你手动加的换行、缩进）都当作有效内容保留，不仅增大体积，还可能干扰后续 XPath 查询或 DOM 遍历。
- 默认行为是
xml:space="default"（可省略），此时连续空白会被规范化为单个空格，换行也视为普通空白处理，对编辑器友好 - 只在真正需要保留原始排版的场景（如
<pre class="brush:php;toolbar:false;"></pre>类文本块）才显式设xml:space="preserve" - 用正则批量清理：
sed -i 's/xml:space="preserve"//g' file.xml（Linux/macOS），或在 VS Code 中搜索xml:space="preserve"替换为空
用 xmllint 自动折行长文本节点
人工换行易出错，且不同工具对“合理行宽”的理解不一致。更可靠的做法是用命令行工具标准化格式，同时控制单行长度。核心不是限制总宽度，而是避免 text() 节点内出现超长无空格字符串（比如 Base64、JSON 嵌入、长 URL）。
-
xmllint --format --encode utf-8 file.xml只做基础缩进，不拆分长文本 - 真正起作用的是配合
--maxmem和自定义 XSLT：先用xmllint --xpath '//text()[string-length() > 100]' file.xml找出超长文本节点 - 对这类节点，用 Python +
lxml拆分更可控：用textwrap.fill(node.text, width=80, break_long_words=False)，注意break_long_words=False防止把 Base64 拆断
VS Code 编辑卡顿？关掉 XML Tools 插件的实时验证
VS Code 默认不卡，但装了 XML Tools（尤其是旧版本）后，一旦打开含大文本节点的 XML，它会在后台反复调用 xmllint 或内置解析器做语法校验，CPU 占用飙升，光标响应延迟明显。
- 临时禁用：右键状态栏 XML 图标 → “Disable Validation”
- 永久关闭：设置里搜
xml.validate，把xml-tools.validateOnOpen和xml-tools.validateOnChange全设为false - 替代方案：只在保存时用
emeraldwalk.runonsave插件执行xmllint --noout %FILE%，轻量且可控
嵌入 JSON 或 CDATA 里的长内容怎么处理？
XML 里塞 JSON 字符串或大段日志常导致单行超 10 万字符，这时换行不是为了阅读，而是绕过编辑器的行缓冲限制。但直接在 里换行无效——CDATA 内容被当纯文本，换行符照常保留，仍算“一行”。
- 正确做法：在 CDATA 外包一层元素，并用
xml:space="default"（显式声明），让解析器忽略内部换行的语义影响 - JSON 嵌入建议改用属性而非子节点：
<item data='{"id":1,"name":"xxx"}'></item>，属性值天然受解析器空白处理规则约束 - 实在要放 CDATA，用
sed或 Python 把长内容按 80 字符切分，每行末尾加\（反斜杠续行），再用 XSLT 去掉——但这属于 hack，仅限离线处理
真正难处理的不是换行本身，而是不同环节对“空白”的态度不一致：编辑器当显示问题，解析器当语义问题，XSLT 当样式问题。一个换行，在 DOM 树里可能变成三个文本节点，在 XPath 里可能匹配不到，在 diff 工具里可能引发大量误报。动手前先确认你是在解决编辑体验、解析稳定性，还是协作一致性——目标不同，解法就完全不一样。
