Java反射可突破封装修改私有字段，但应谨慎使用；优先采用setter、Builder等合法方案，必须用时需处理JDK9+模块限制并正视运行时异常、逻辑绕过及安全风险。
Java 反射可以突破访问控制修改私有属性，但这是对封装原则的主动绕过，必须谨慎使用。核心在于：能不用就不用；必须用时，优先考虑合法替代方案（如提供 setter、使用 Builder 模式）；若确需反射，需明确风险并做必要防护。
修改私有属性的基本操作
通过 Field.setAccessible(true) 可临时关闭 Java 的访问检查，再调用 set() 修改值：
- 获取目标字段：用
Class.getDeclaredField("fieldName")，注意是getDeclaredField（非getField），才能拿到 private 字段 - 关闭检查：调用
field.setAccessible(true)—— 这一步在 JDK 9+ 默认受模块系统限制，可能抛出InaccessibleObjectException - 赋值：用
field.set(obj, newValue)，若字段是 static，第一个参数传null
JDK 9+ 的模块化安全边界
从 JDK 9 开始，模块系统默认阻止反射访问非开放的内部 API。常见报错：java.lang.reflect.InaccessibleObjectException。
- 启动参数可临时放宽（仅限开发/测试）：
--add-opens java.base/java.lang=ALL-UNNAMED，或更细粒度地开放具体类所在的包 - 生产环境不建议加这些参数，应推动 API 设计改进，而非依赖 JVM 配置妥协
- 某些框架（如 Spring、Lombok）会自动处理部分反射场景，但底层仍依赖上述机制或字节码增强
安全与维护风险要正视
反射修改私有字段不是“黑科技”，而是破坏契约的行为，带来真实隐患：
立即学习“Java免费学习笔记（深入）”；
- 字段名变更即导致运行时异常，编译期无法发现，测试覆盖不到位时容易漏掉
- 绕过 setter 可能跳过业务校验、状态同步、日志记录等关键逻辑
- 某些安全敏感场景（如金融、权限校验）中，反射修改可能被用于恶意篡改，需配合安全管理器（SecurityManager）拦截，但该类已自 JDK 17 起被弃用
- 单元测试中若大量使用反射设值，说明类设计可能违反高内聚低耦合，应优先重构为可测试形态
更稳妥的替代思路
多数场景下，有比反射更清晰、更可持续的解法：
- 为测试暴露必要接口：添加 package-private 或
@VisibleForTesting注解的 setter（配合 test scope 依赖） - 使用构造器或 Builder 初始化对象，避免后期修改内部状态
- 借助 Mockito 的
Whitebox（旧版）或ReflectionTestUtils（Spring 提供）封装反射细节，统一管控 - 对不可变对象，直接新建实例替代修改 —— 符合函数式思想，也更易推理
