java访问修饰符仅控制编译期可见性，不提供运行时安全；敏感字段必须private，禁用public/default，setter需校验逻辑而非无脑赋值，反射等绕过手段需配合模块化、securitymanager等加固。
Java 中访问修饰符本身不提供加密或运行时防护，它只在编译期控制“谁能看到、谁能调用”。要保护敏感数据安全性，核心不是靠修饰符“锁住”数据，而是通过最小暴露 + 明确控制流来切断非法访问路径。关键在于：字段私有化是起点，不是终点；getter/setter 是控制入口，不是摆设。
字段一律用 private，禁止 public 或 default 暴露
敏感字段（如密码、token、余额、身份证号）必须声明为 private。哪怕同包工具类或测试类能直接访问 default 成员，那也等于裸奔——Maven 项目中 test 与 main 共享 classpath，default 就形同虚设。public 更不可取，它让任何代码都能随意读写，完全放弃控制权。
- ❌ 错误示例：
public String password;或String token;（无修饰符即 default） - ✅ 正确做法：
private String password;，且不提供无条件的setPassword(String)
getter/setter 要带校验和逻辑，不能无脑生成
加了 private 只是拦住了直接赋值，不代表安全。Lombok 的 @Data 自动生成所有 setter，等于把校验权交出去。真正有效的 setter 应该做明确约束：
你接手一个需求时，是不是经常这样："改一个小字段 → 结果把不相关的代码也改了"、"需求说得很模糊 → 做着做着发现跑偏了"、"数据库加个字段 → 上线才发现漏了数据兼容"、"做了个新功能 → 一个月后自己都忘了当时怎么设计的"、"写到一半被中断 → 再回来不知道从哪继续"；这个 Skill 就是专门解决这些问题的。 它会自动探测你的项目环境（JDK、Spring Boot、ORM、数据库、前端框架），记在
- 对密码字段，
setPassword(String raw)应转成哈希再存，不保留明文 - 对金额字段，
withdraw(double amount)必须检查amount > 0 && amount - 避免通用
setXXX()，优先用语义化方法（如changePassword(String old, String new)）
敏感操作禁用反射绕过，需额外加固
private 在运行时可被反射强行访问（field.setAccessible(true)）。若系统需防恶意调试或插件注入，应配合安全管理器（SecurityManager，已弃用但仍有遗留场景）或模块化限制：
- 使用
module-info.java显式exports仅必要包，未导出的包内 private 成员对外不可见 - 敏感类可加
final防止被继承篡改行为 - 关键字段可配合
transient防序列化泄露，再辅以自定义writeObject
区分场景：内存安全 ≠ 传输/存储安全
访问修饰符只管 JVM 内存中的可见性。真实的安全链路还需其他手段：
- 数据库密码等凭证不硬编码，走配置中心 + 加密存储
- 网络传输用 HTTPS，敏感字段前端脱敏、后端加密入库（AES/RSA）
- 日志打印前过滤
password、idCard等关键词，避免明文落盘
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
