本文介绍在 spring/jpa 应用中，当 user 实体存在双向多对多自引用关系（如关注/粉丝）时，dto 递归映射引发 stackoverflowerror 的根本原因及专业解决方案——推荐采用中间关联实体建模，规避无限递归。
在典型的社交系统建模中，User 实体常需表达“关注”（following）与“被关注”（followers）两类互逆关系。若直接使用 @ManyToMany 双向映射（如原代码中 friends 与 friedns_of 字段），JPA 会在加载时形成闭环图结构；而当 UserMapper::toUser() 方法对每个 User 递归调用自身映射其关联列表时，便触发无限调用链，最终抛出 StackOverflowError。
根本问题在于：
- 原始设计将关系语义（谁关注谁）隐含在双向集合中，缺乏明确的方向性与边界控制；
- DTO 映射层未做深度限制或引用去重，导致 user → followers → user → ... 无限展开。
✅ 推荐解决方案：引入显式关联实体 Follows
将“关注”行为建模为独立实体，清晰分离关系数据与主体数据，既符合数据库范式，也天然切断递归路径：
使用约定式提交（Conventional Commits）生成标准化的 Git 提交信息。适用于以下场景： (1) 暂存更改时需要提交信息； (2) 审查 diff 时希望获得结构化摘要； (3) 编写 PR 描述或变更日志（changelog）条目； (4) 用户明确要求“为本次更改编写提交信息”。 该功能会分析已暂存/未暂存的 diff，并生成按类型（type）划分范围的提交信息。
@Entity
@Table(name = "user_followers")
public class Follows {
@EmbeddedId
private FollowsId id;
@MapsId("followerId")
@ManyToOne(fetch = FetchType.LAZY)
@JoinColumn(name = "follower_id")
private User follower;
@MapsId("userId")
@ManyToOne(fetch = FetchType.LAZY)
@JoinColumn(name = "user_id")
private User user;
// 构造函数、getter/setter 省略
}
@Embeddable
public class FollowsId implements Serializable {
private Long followerId;
private Long userId;
// equals/hashCode/constructor/getter/setter 必须实现
}对应地，更新 User 实体，移除易引发循环的 @ManyToMany 集合，改用单向 @OneToMany 关联 Follows：
@Entity
public class User {
@Id
@GeneratedValue
private Long id;
private String firstName;
private String lastName;
@OneToMany(mappedBy = "user", fetch = FetchType.LAZY)
private List<Follows> followers; // 当前用户被谁关注
@OneToMany(mappedBy = "follower", fetch = FetchType.LAZY)
private List<Follows> following; // 当前用户关注了谁
}此时，DTO 映射可安全、可控地展开：
public static UserResponse toUser(User user) {
UserResponse response = new UserResponse();
response.setId(user.getId());
response.setFirstName(user.getFirstName());
response.setLastName(user.getLastName());
// ✅ 安全映射：仅提取 ID 或基础字段，避免递归
response.setFollowerIds(user.getFollowers().stream()
.map(follows -> follows.getFollower().getId())
.collect(Collectors.toList()));
response.setFollowingIds(user.getFollowing().stream()
.map(follows -> follows.getUser().getId())
.collect(Collectors.toList()));
return response;
}? 关键实践建议：
- 永远避免在 DTO 映射中递归调用同一映射方法（如 UserMapper::toUser 调用自身）；
- 若需展示关联用户简要信息（如姓名+头像），可预加载并映射为轻量级 UserSummaryDto，而非完整 UserResponse；
- 在 Repository 层使用 @Query 或 JOIN FETCH 精确控制关联数据加载范围，防止 N+1 查询或过度加载；
- 对前端敏感场景，还可结合 Jackson 的 @JsonIgnore, @JsonView 或 DTO 分层（UserBasicDto / UserDetailDto）进一步解耦序列化逻辑。
通过将关系升格为一等公民（即 Follows 实体），我们不仅解决了循环依赖的技术痛点，更提升了领域模型的表达力与可维护性——这是 DDD 思想在数据映射层的务实落地。
