常见的XML映射错误及解决方法

xml解析报“content is not allowed in prolog”错误，本质是文件开头存在bom、空格或换行等非法字符；jaxb字段为NULL多因命名不规范或缺少无参构造；mybatis嵌套查询为空常因Property名不匹配或foreigncolumn缺失；spring boot需配置jackson xml模块及消息转换器才能支持@requestbody解析xml。

XML解析时报“Content is not allowed in prolog”错误

这是最常见的XML映射起始阶段报错，本质是XML文件开头存在不可见字符（如BOM、空格、换行或UTF-8签名），导致解析器在读取根元素前就遇到了非法内容。

• 用文本编辑器（如VS Code）以十六进制模式打开XML文件，检查开头是否有EF BB BF（UTF-8 BOM）；如有，另存为“UTF-8 无BOM”格式
• 确认XML声明<?xml version="1.0" encoding="UTF-8"?>之前**没有任何字符**，包括空行、注释或空白符
• Java中用InputStreamReader读取时，避免用FileReader（它默认使用平台编码且无法跳过BOM）

JAXB unmarshal时字段始终为null

这通常不是XML结构问题，而是JAXB绑定规则未被满足：字段名、getter/setter命名、注解或包级配置不匹配。

• 确保Java类有无参构造函数；否则JAXB无法实例化对象
• 字段必须是public或配有符合JavaBeans规范的getXXX()/setXXX()方法（如字段userName对应getUserName()和setUserName()）
• 若XML元素名与字段名不一致，必须显式加@XmlElement(name = "user_name")，不能只依赖默认映射
• 包路径下缺少package-info.java且含@XmlSchema时，某些JAXB实现（如 older JDK）可能忽略Namespace处理

MyBatis中嵌套查询返回空集合

不是sql写错，而是<Collection></collection>或<association></association>的property与Java属性名不一致，或未正确设置javaType/ofType。

• property值必须严格匹配Java Bean中的字段名（区分大小写），例如Java中是orderItems，就不能写成orderitems或order_items
• 集合字段必须声明为接口类型（如List<orderitem></orderitem>），并在<collection></collection>中指定ofType="com.example.OrderItem"
• 嵌套查询的select语句返回结果集列名，需与OrderItem的字段能通过驼峰/下划线自动映射，或显式用<resultmap></resultmap>定义映射关系
• 检查外键字段是否在主查询中SELECT出来（如order_id），否则collection的foreignColumn找不到匹配值

spring boot中@RequestBody接收XML请求体失败

Spring默认只支持json，要让@RequestBody正确反序列化XML，必须补全Jackson XML模块与MIME类型配置。

• 添加依赖：com.fasterxml.jackson.dataformat:jackson-dataformat-xml（注意不是jackson-core或databind单独引入）
• 在@PostMapping上显式声明consumes = MediaType.APPLICATION_XML_VALUE，否则Spring按默认JSON处理器处理
• 确保DTO类有@XmlRootElement（JAXB方式）或启用Jackson XML的@JacksonXmlRootElement；二者不可混用
• 若用JAXB，需在启动类或配置类中注册Jaxb2RootElementHttpMessageConverter，否则即使有注解也不生效

@Configuration public class WebConfig {     @Bean     public HttpMessageConverter<Object> jaxbMessageConverter() {         return new Jaxb2RootElementHttpMessageConverter();     } }

XML映射真正难的不是语法，而是隐式约定——JAXB依赖命名规范，MyBatis依赖SQL与XML标签的双向对齐，Spring则依赖消息转换器链的精确触发。任何一个环节的“看起来差不多”，都可能导致静默失败。