private 是安全起点，字段默认应声明为 private；只读字段仅提供返回不可变视图或拷贝的 getter；可写字段的 setter 必须校验输入；避免裸暴露字段和机械配齐 getter/setter。
private 是默认起点，不是妥协方案
Java 类成员不加修饰符时是包级私有，但这是历史包袱带来的陷阱——它让类在同一个包里被随意访问，破坏封装。真正安全的起点只有 private：只要没明确需要被外部访问，就先锁死。
常见错误现象：public int count 直接暴露字段，后续想加校验或日志只能改调用方；protected String name 导致子类意外依赖父类字段实现，一改就崩。
- 所有字段（
String、int、集合等）默认声明为private - 只在确实需要被子类继承时，才考虑
protected，且必须同步提供protected的 setter/getter 而非裸字段 - 包内协作场景极少需开放字段，优先用
package-private方法（无修饰符）代替字段暴露
getter/setter 不是“必须配齐”，而是按需暴露
加了 private 字段后，很多人机械补上 getXXX() 和 setXXX()，结果把不可变对象变成可变，或让业务逻辑绕过校验。暴露接口的本质是“承诺”——一旦公开，就得长期维护。
使用场景差异明显：LocalDateTime 字段若只读，返回 getCreatedAt().toInstant() 比直接返回 getCreatedAt() 更安全；集合字段绝不能返回内部引用，必须用 Collections.unmodifiableList() 或新拷贝。
立即学习“Java免费学习笔记（深入）”；
分析 Java Spring Boot 后端 Controller 代码，自动生成 Markdown 格式的接口文档。当用户说“生成 Java 接口文档”、“生成 API 文档”、“从 Spring 代码生成文档”时触发。
- 只读字段：只提供
getXXX()，返回不可变视图或拷贝（如new ArrayList(this.items)） - 可写字段：
setXXX()必须做非空/范围/状态校验（如if (value ） - 布尔字段：用
isXXX()而非getXXX()，避免 Jackson 等框架反序列化出错
protected 成员要警惕“继承即耦合”
protected 看似折中，实则是最危险的可见性级别：它既打破封装，又没完全放开，导致子类和父类在实现细节上深度绑定。JDK 自身都极少用 protected 字段，多用 protected 方法配合 final 模板逻辑。
性能影响不大，但兼容性极差——一旦父类修改 protected 字段语义（比如从“缓存”改成“懒加载”），所有子类可能静默失效。
- 禁止
protected字段，一律改为private+protected访问方法 -
protected方法必须文档化契约：输入约束、副作用、线程安全性 - 子类需重写的方法，优先用
abstract或模板方法（final void execute() { before(); doWork(); after(); }）替代裸protected钩子
public 接口要区分“被谁用”和“怎么用”
public 不等于“谁都能调”，而是“谁应该调”。一个 public 方法如果只被框架反射调用（如 Spring Bean 初始化），就该用 @VisibleForTesting 标注，并在模块层限制扫描范围；如果被其他模块调用，必须通过接口抽象，而非直接暴露实现类。
容易踩的坑：把 public class Utils 当工具箱，堆满静态方法，结果无法 mock、无法替换、无法演进；或把 DTO 字段全设 public，导致 JSON 序列化失控（如 transient 失效、Jackson 注解失效）。
- 对外提供的
public类，优先定义public interface，实现类用package-private - DTO/VO 字段保持
private，靠 Lombok@Data或显式 getter 控制序列化行为 - 测试需要访问的
private成员，用ReflectionTestUtils，而不是降级为package-private
最小化权限不是写完再检查，而是在敲下第一个 class 时就决定每个成员的“生存边界”。最常被忽略的是集合字段的防御性拷贝，和 protected 方法未声明线程安全前提——这两处一出问题，往往在线上压测或并发场景才暴露。
