该写，但仅限发布态不可变XML资源；开发中频繁修改的应避免硬编码版本到文件名，推荐用处理指令标记业务版本，XML声明中的version属性属规范版本，非业务版本。
XML版本号该不该写在文件名里
该写，但只适用于发布态、不可变的XML资源（比如API响应模板、配置快照）。开发中频繁修改的XML，硬编码版本到文件名会破坏工具链——Git diff变多、IDE重命名报错、CI脚本路径要同步改。
- 发布包里的
config-v2.1.xml比config.xml更利于回滚和审计 - Spring Boot 的
@ImportResource加载beans-v3.xml时，版本号必须和实际部署路径一致，否则抛FileNotFoundException - 用 XSD 校验时，
schemaLocation中的命名空间 URI 通常已隐含版本（如http://example.com/schema/v2），此时文件名再加版本属于重复冗余
XML声明里的 version 属性不是版本控制字段
<?xml version="1.0" encoding="UTF-8"?> 里的 version 是 XML 规范版本，不是你的业务版本。把它当业务版号改来改去，解析器不会报错，但会误导人——别人看到 version="1.1" 会以为你用了 XML 1.1 的特性（比如控制字符支持），其实你只是随手改了个数字。
- XML 1.0 和 1.1 在换行、命名字符等细节上有差异，真要用 1.1 必须确认解析器支持（JDK 8+ 的
DocumentBuilder默认不支持version="1.1"） - 某些老系统（如 Oracle WebLogic 10g）解析
version="1.1"会直接拒绝，错误信息是org.xml.sax.SAXParseException: Unsupported version "1.1" - 别在 CI 流水线里 grep
version=".*"来判断业务版本——它根本不是设计来干这个的
用 processing instruction 自定义版本标记最灵活
在 XML 声明后紧跟一条处理指令，比如 <?version 2.3.1?>，既不干扰解析，又能被 XPath 或正则稳定提取。比注释更可靠（注释可能被 minify 工具删掉），比根元素属性更轻量（不用改 schema）。
- XPath 提取：
//processing-instruction('version')→ 返回2.3.1 - Python 用
lxml.etree读取：root.xpath("preceding::processing-instruction('version')")[0].text - 注意：XML 规范允许 PI 出现在文档任意位置，但放在开头最安全；如果用 SAX 解析，需监听
processingInstruction()事件提前捕获
Header 中带版本只对 HTTP 传输有效
HTTP Content-Type 头加参数（如 application/xml;version=2.0）只在 API 响应场景下有意义，且依赖客户端主动检查。文件落地后这个信息就丢了，不能替代文件内标记。
- Spring MVC 的
@ResponseBody方法可通过produces = "application/xml;version=2.1"声明，但前端 fetch 时得手动读取 header：response.headers.get('Content-Type') - Nginx 反向代理静态 XML 文件时，
add_header Content-Type "application/xml;version=1.9";不生效——Nginx 会覆盖为实际 MIME 类型 - curl 测试时容易漏看 header：
curl -I https://api.example.com/data.xml才能看到，光curl输出内容没用
