Transformer.setOutputProperty(OutputKeys.OMIT_XML_DECLARATION, "yes") 不生效的根本原因是JDK实现（如Xalan/XSLTC）对属性支持不一致，且依赖输出目标和编码设置；推荐用StringWriter+前缀匹配删除或改用StAX。
Transformer.setOutputProperty(OutputKeys.OMIT_XML_DECLARATION, "yes") 不生效？
Java 的 Transformer 默认输出带 XML 声明（<?xml version="1.0" encoding="UTF-8"?>），设 OutputKeys.OMIT_XML_DECLARATION 为 "yes" 却没效果，常见于用了 DOMSource 或 StreamSource 后直接写入 StreamResult，但底层序列化器未真正启用该属性。
根本原因是：部分 JDK 实现（尤其 Oracle/OpenJDK 8）对 OMIT_XML_DECLARATION 的支持依赖于实际使用的 XML 序列化器是否尊重该 property。默认的 Xalan/XSLTC 实现有时会忽略它，尤其当输出目标是 OutputStream 且未显式指定编码时。
- 必须在调用
transform()前设置，且不能覆盖或重复设置 - 确保
Transformer实例未被缓存复用并携带旧配置 - 若用
StreamResult(new FileOutputStream(...))，务必同时设置OutputKeys.ENCODING，否则某些实现会退回到带声明的默认行为 - 推荐搭配
OutputKeys.METHOD设为"xml"显式声明意图
用 StringWriter + String.replace() 是最稳的兜底方案
当 OMIT_XML_DECLARATION 行为不可靠（比如跨 JDK 版本、CI 环境偶发失败），直接操作字符串比纠结 Transformer 配置更可控。前提是 XML 内容不包含嵌套的 <?xml 注释或 CDATA 块——这种场景极少，一般生成的文档是干净的。
注意：别用 String.replaceAll("^\s*", "") 这类正则，容易误杀内容里的 XML 声明片段；简单前缀匹配足够安全。
立即学习“Java免费学习笔记（深入）”；
分析 Java Spring Boot 后端 Controller 代码，自动生成 Markdown 格式的接口文档。当用户说“生成 Java 接口文档”、“生成 API 文档”、“从 Spring 代码生成文档”时触发。
- 用
StringWriter接收输出，避免字节流编码干扰 -
result.toString().replaceFirst("^]*>\s*", "")—— 只删开头第一个声明行及后续空白 - 如果后续还要转成
byte[]，记得按原始编码（如 UTF-8）重新 encode，别依赖String.getBytes()默认编码
用 StAX（XMLStreamWriter）彻底绕过 Transformer
如果你只是想把 DOM 或对象序列化成无声明的 XML 字符串，Transformer 其实是重武器。StAX 的 XMLStreamWriter 更轻量、行为确定，且天生不写声明——除非你主动调用 writeStartDocument()。
适合场景：已有 Document 对象但不想走 XSLT 流程；或需要精细控制缩进/命名空间/空元素格式。
- 用
XMLOutputFactory.newInstance().createXMLStreamWriter(writer) - 遍历
Document节点手动写入，跳过根节点前的声明逻辑 - 若需保留缩进，调用
setPrefix("xml", "http://www.w3.org/XML/1998/namespace")等预设前缀可减少冗余 - 性能上比
Transformer略优，尤其小文档；但代码量略增
为什么有些项目里 setOutputProperty 没问题，你的就不行？
差异往往藏在依赖和运行时环境里：Transformer 的底层实现不是标准强制的。你本地用的是 Xalan，CI 用的是 JDK 自带的 XSLTC，或者引入了 saxon-he，它们对 OMIT_XML_DECLARATION 的处理逻辑不同。
一个快速验证方式：打印 transformer.getClass().getName()，再查对应实现的文档。Saxon 默认忽略这个 property，Xalan 8u 之后才稳定支持。
- 检查 classpath 是否混入多个 XSLT 引擎（比如同时有 xalan.jar 和 saxon-he.jar）
- JDK 17+ 已移除内置 Xalan，若没显式引入，走的是 JAXP SPI 查找，结果不可预测
- 测试时用
System.setProperty("javax.xml.transform.TransformerFactory", "com.sun.org.apache.xalan.internal.xsltc.trax.TransformerFactoryImpl")强制路径，能排除 SPI 干扰
真正麻烦的不是怎么删那行声明，而是同一段代码在不同机器上表现不一致——这时候别硬调 property，换 StringWriter 或 StAX，省掉排查时间。
