mybatis实现多对多关联需显式控制映射逻辑：纯关联表用collection+join三表查询；含业务字段的中间表须升格为实体，采用user→userroleassignment→role三层嵌套映射。
MyBatis 实现多对多复杂关联关系，核心在于**正确设计中间表、合理编写 SQL（尤其是 JOIN 查询）、精准配置 ResultMap 的嵌套映射关系**。不是靠自动扫描或注解“猜”关系，而是显式控制数据组装逻辑。
明确表结构与中间表角色
多对多必须有中间表（如 user_role），它通常只含两个外键（user_id, role_id），不建议在中间表里塞业务字段——若需扩展（如分配时间、状态），应将中间表升格为实体（如 UserRoleAssignment），此时关系变为“一对多→多对一”，映射逻辑更清晰。
示例三张表：
- user（id, name）
- role（id, code, description）
- user_role（user_id, role_id, assigned_at, status）← 含业务字段，视为实体
用 collection + association 分层嵌套映射
当中间表是纯关联表（无业务字段）：直接在 User 的 ResultMap 中 collection 映射 Role 列表，SQL 用 LEFT JOIN 三表联查，MyBatis 自动按 id 去重组装。
当中间表含业务字段（如 user_role 有 assigned_at）：不能跳过中间实体。应定义三层结构：User → List
Java项目代码review工具。分析Git变更+完整调用链路上下文，推断业务需求，进行多维度评分和分类汇总，生成完整PRD文档。包含细粒度Java代码审查清单（Null安全、异常处理、Streams、并发、equals/hashCode、资源管理、API设计、性能、MyBatis/ORM、事务边界、SQL/DD...
- 第一层：User 的
<collection property="assignments" oftype="UserRoleAssignment"></collection> - 第二层：UserRoleAssignment 的
<association property="role" javatype="Role"></association>
这样既能拿到分配时间、状态等上下文，又保持对象关系可追溯。
SQL 写法决定映射成败
避免写成“SELECT * FROM user u LEFT JOIN user_role ur ON … LEFT JOIN role r ON …”，容易因笛卡尔积导致重复行和内存浪费。推荐做法：
- 主查询只查 user 表基础字段
- 用
<collection></collection>的select属性调用另一个 SQL（即 N+1），适合数据量小、懒加载场景 - 更推荐：主 SQL 使用 JOIN，但用
<id></id>和<result></result>显式指定列别名，配合columnPrefix避免字段冲突，例如：SELECT u.id AS uid, u.name, ur.assigned_at, r.id AS rid, r.code FROM ...
然后在 collection 中设columnPrefix="r."，让 MyBatis 自动绑定 role 字段
用注解方式要更谨慎
@Select + @Results 可以实现，但复杂多对多时 XML 更易维护。若坚持用注解：
- 用
@One映射一对一（如 UserRoleAssignment → Role） - 用
@Many映射一对多（如 User → List） - 注意
@Many的select方法必须返回集合，且参数能被自动传递（如 user.id） - 无法使用
columnPrefix，字段别名需严格匹配，易出错
不复杂但容易忽略：始终检查 resultMap 的 id 字段是否唯一标识主对象；嵌套 collection 的 property 名称必须与 Java Bean 字段名完全一致（包括大小写）；中间实体类要有无参构造器和 getter/setter。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
