通义灵码高效生成MyBatis XML映射文件与SQL逻辑
通义灵码并不会自动生成一份可用的MyBatis Mapper XML。它无法读取你的数据库表结构，无法识别实体类的字段映射，更无权访问项目上下文——resultMap的映射关系、typeHandler的配置细节、动态SQL的嵌套逻辑，这些核心约束它一个都推断不出来。结论很明确：Mapper XML必须由你手动编写，完成后还需要逐条对照Java接口，确认参数、返回类型和SQL语句完全一致。
简而言之，通义灵码不是项目扫描器，它无法从零生成一份包含完整SQL逻辑的映射文件。你只能亲手编写XML，并确保它与Java接口严丝合缝。
确认是否真需XML方式
动手前先评估：这个项目必须用XML吗？如果你的Mapper接口方法比较简单——单表增删改查、不涉及复杂嵌套——那么注解方式（@Select/@Insert等）完全够用。注解不仅少维护一个XML文件，而且通义灵码在注解中生成SQL的可靠性更高。
但如果项目强制要求XML——比如你需要复用SQL片段、处理多级association/collection映射、或者自定义typeHandler——那就只能手写XML。通义灵码在这种场景下只能提供参考，别指望它替你校验正确性。
手写Mapper XML前的必要准备
第一步：在IDEA中右键点击Mapper接口 → Generate → MyBatis Generator → 选择“Create Mapper XML File”。前提是你已安装MyBatisX插件。这一步会生成一个包含基础namespace和空标签的XML骨架。
第二步：将实体类的全限定名（例如com.example.demo.model.User）粘贴到XML的resultMap的type属性中。注意：type值必须与实体类路径完全一致，大小写必须准确，否则运行时会直接抛出ClassNotFound异常。
第三步：打开数据库表结构，逐列核对字段名与实体类属性名。如果数据库采用下划线命名（如user_name），实体类采用驼峰命名（如userName），则需要确认mybatis.configuration.map-underscore-to-camel-case=true已开启。若未开启，则必须在resultMap中显式声明column="user_name" property="userName"映射。
用通义灵码辅助写SQL片段（仅限参考）
方法一：在XML的标签中，光标定位到SQL区域，输入一句自然语言描述，比如：“查用户表，条件是status=1且create_time在最近7天，按id倒序，只取前10条”。触发通义灵码，它可能会输出类似：
注意：这段输出没有parameterType、没有resultMap引用、也没有动态where标签，字段与实体类的对应关系它完全无法知晓。你必须人工改写：将?替换为#{xxx}占位符，补全命名空间，并逐一检查字段名是否匹配。
方法二：针对复杂动态SQL，可以在
这段代码基本可粘贴直接使用，但有一个关键点：test表达式中的字段名必须与Mapper接口方法的参数类型匹配。如果方法参数是User对象，则需写成test="user.name != null"；如果参数是Map，则写test="name != null"。务必分清，否则运行时可能报错。