成员变量绝大多数情况下应使用 private + final 修饰，以保障封装性和不可变性；仅在特定场景（如子类需修改、常量、临时缓存）可例外，但须严格遵循规范。
成员变量必须用 private + final 修饰吗？
不是必须，但绝大多数情况下应该这样。public 或 package-private 成员变量会破坏封装，让外部代码直接读写状态，后续改逻辑时极易出错；protected 更危险，子类能随意篡改父类内部状态。
常见错误现象：NullPointerException 频发、单元测试难写、重构时发现几十个地方在直接改 user.name。
- 只在明确需要被子类继承且允许修改时才用
protected，且必须加 Javadoc 说明“此字段可被子类重写” - 常量用
public static final，但值必须是编译期常量（如"API_V1"），不能是new Date()这类运行时对象 - 如果变量只是临时缓存、且不参与业务逻辑（比如
private Map<String, Object> cache;），可以不加final，但必须配@SuppressWarnings("unused")或明确初始化
方法命名和参数顺序怎么才算“标准”？
Java 标准不是靠记忆，而是靠 IDE 和静态检查工具强制落地。方法名必须是动宾结构（calculateTax、validateEmail），不能是名词（taxCalculator）或形容词（valid）。
参数顺序影响调用可读性。比如 copy(File src, File dest) 是标准顺序，反过来就反直觉；再比如 substring(int beginIndex, int endIndex) 的索引顺序，JDK 自己也踩过坑（早期 String.substring 在负数下行为不一致，现在已修复）。
立即学习“Java免费学习笔记（深入）”；
- 布尔参数绝不能单独出现：禁止
save(true)，应拆成saveWithValidation()和saveWithoutValidation() - 多个同类型参数（如
int）必须用封装类替代，避免传错顺序：new Point(x, y)容易写成new Point(y, x)，而Point.of(x, y)更安全 - Builder 模式里，必填参数放构造函数，选填参数走 setter —— 否则
new Builder().build()可能返回非法对象
什么时候该用 record 而不是 class？
record 是 Java 14 引入的不可变数据载体，它不是“简化 class”，而是语义完全不同：record 表达“这就是一组值”，class 表达“这是一个有行为的对象”。误用 record 最常见的坑是试图在 toString() 里加日志，或给 record 加 setter。
使用场景很窄：DTO、JSON 反序列化目标、函数返回值、Map 的 key —— 所有这些都不该有业务逻辑。
- 只要字段需要校验（如
age > 0）、需要懒加载、需要监听变更，就别用record，老实用class+ 私有字段 + 构造器校验 - record 的
canonical constructor不能省略参数，也不能加throws，否则编译失败：public Person(String name) { if (name == null) throw new IllegalArgumentException(); }是合法的，但public Person(String name) throws IOException不行 - record 默认实现
equals/hashCode基于所有字段，如果某个字段不该参与比较（比如lastModifiedTime），就不能用 record
为什么 getter/setter 不是“标准规范”的一部分？
因为它们是封装的副产品，不是目的本身。JDK 从没规定“每个字段都要配 getter/setter”，Spring、Jackson 等框架也早就支持直接访问私有字段（通过反射或 VarHandle）。
真实项目里，90% 的 setXXX() 方法其实只是把值塞进字段，毫无逻辑；而真正需要控制写入时机的字段（如 status），往往要走 transitionTo(Status next) 这种带状态校验的方法。
- 只读字段只暴露 getter，不要加无意义的 setter —— IDE 自动生成的
setXxx很容易被误调用 - 集合类字段（如
List<Item>）的 getter 必须返回不可变副本：Collections.unmodifiableList(items)，否则外部能直接改内部状态 - Lombok 的
@Data会盲目生成所有 getter/setter，上线前务必 grep 检查有没有setPassword这类危险方法漏网
最常被忽略的一点：字段初始化时机和构造器顺序。比如 private final List<String> tags = new ArrayList<>(); 看似安全，但如果父类构造器里调用了被子类重写的 init()，而该方法又访问了 tags，就会触发 NullPointerException —— 因为子类字段还没初始化完。这种 bug 往往只在特定继承链下复现，很难测出来。
