在日常的 Java 后端开发中，我们经常会遇到这样的需求：前端需要开发一个“分配角色”的功能，页面既要展示所有的角色列表供用户勾选，又要回显当前用户已经拥有的角色（默认打 ✅）。
为了满足这个需求，我们需要组装一个包含两部分数据的实体：
全部角色列表（为精简传输，仅保留角色 ID 和名称）。
已选中的角色 ID 列表。
很多开发者的第一反应是：新建一个 UserRoleVo 类，然后再额外建一个 RoleSimpleVo 类。但是，仅仅为了两个字段去单独创建一个 .java 文件，会增加项目中类的数量，显得有些“大材小用”。
有没有更优雅的解法？这里我强烈推荐使用内部类的方式。这样既避免了过度封装导致的“类爆炸”，又让相关联的数据结构保持了极高的内聚性。
🛡️ 为什么要用 static 修饰？
阻断隐式引用（防内存泄漏）： 在 Java 中，非静态的成员内部类会隐式持有一个外部类实例的引用。这意味着，只要内部类对象存活，外部类对象就无法被垃圾回收器回收，极易引发内存泄漏。加上
static后，它就变成了独立的静态嵌套类，斩断了这层隐式联系。兼容序列化框架： 主流的 JSON 框架（如 Jackson、Fastjson）在反序列化时，通常要求内部类必须是
static的，否则框架无法通过反射创建内部类对象。生命周期解耦： 作为一个纯粹的 VO 数据载体，内部类在逻辑上完全独立，它不应该依赖外部类的实例状态而存在。
🚧 为什么要用 private 修饰？
我们之所以不把 RoleSimpleVo 提取成单独的文件，正是因为它仅服务于当前的 UserRoleVo。
如果将其声明为 public，其他同事在编写其他接口时，很可能会图省事直接引用。一旦产生了这种跨模块的复用，未来你在这个内部类中增删字段时，就可能会意外导致其他功能报错。
使用 private 修饰，相当于确立了规矩：这个类是当前 VO 私有的，禁止任何外部类直接引用。这也是面向对象设计中“封装”原则的完美体现。
🚨 实战踩坑：坚持 private 带来的两个问题
既然 private 这么好，那问题来了：由于内部类是私有的，外部根本没有访问权限，当我们在 Service 层查完数据库后，怎么把数据塞进去呢？
如果你直接在 Service 层硬写，马上就会遇到两个致命问题：
编译报错（无法实例化）： Service 层想组装数据，但因为类是
private，连new UserRoleVo.RoleSimpleVo()的权限都没有。运行时空指针异常（NPE）： 如果你在
UserRoleVo里提供一个方法来添加元素，但忘记初始化 List，在调用.add()时会直接抛出NullPointerException。
🎯 破局之道：充血模型与严格封装
为了坚守 private 带来的架构边界，我们绝对不能向外妥协把修饰符改成 public。正确的做法是：让外部类自己管理它的私有内部类，并确保集合的安全初始化。
下面是经过完善后的最终版代码，完美解决了上述坑点：
package cn.okcl.oa.model.vo;
import cn.okcl.oa.model.entity.SysRole;
import lombok.Data;
import java.util.ArrayList;
import java.util.List;
/**
* 用户角色关联VO
*/
@Data
public class UserRoleVo {
/**
* 所有角色列表（避坑点1：必须在这里初始化，防止后续 add 时报空指针）
*/
private List<RoleSimpleVo> allRoleList = new ArrayList<>();
/**
* 已选择的角色ID列表
*/
private List<Long> checkedRoleIdList;
/**
* 添加角色简单VO
* 避坑点2：提供对外的操作方法，而不是让外部去 new 内部类
* @param sysRole 角色实体
*/
public void addRoleSimpleVo(SysRole sysRole) {
RoleSimpleVo roleSimpleVo = new RoleSimpleVo();
roleSimpleVo.setId(sysRole.getId());
roleSimpleVo.setRoleName(sysRole.getRoleName());
this.allRoleList.add(roleSimpleVo);
}
/**
* 角色简单VO
*/
@Data
private static class RoleSimpleVo {
/**
* 角色ID
*/
private Long id;
/**
* 角色名称
*/
private String roleName;
}
}
这样设计的巧妙之处在于： 我们在 UserRoleVo 中暴露了一个 addRoleSimpleVo(SysRole sysRole) 方法。当 Service 层查出角色列表后，只需要把原始的实体对象（SysRole）传给 VO 即可，不需要知道内部类的存在。
// Service 层的使用变得极其清爽：
UserRoleVo vo = new UserRoleVo();
List<SysRole> sysRoleList = sysRoleService.list();
for (SysRole sysRole : sysRoleList) {
// Service 层只管塞实体，内部的转换和组装由 VO 自己完成
vo.addRoleSimpleVo(sysRole);
}
🚀 总结
在开发中，合理使用内部类是减少代码碎片化的利器。建议大家在编码时养成一个习惯：
如果不涉及访问外部类的实例变量，内部类请一律使用
static修饰。如果该内部类只为当前外部类服务，请果断加上
private。遇到私有内部类无法赋值时，不要急着改
public，尝试在外部类中提供行为方法（充血模型），将对象的构建和转换封装在类内部。