Java类命名须大驼峰且与文件名严格一致；包名全小写；字段优先private final；构造函数禁业务逻辑，用构造器注入；方法遵循单一职责，参数少而语义清。
类名必须用大驼峰，且与文件名严格一致
Java编译器强制要求 public 类的名称必须和文件名完全相同（包括大小写），否则编译失败。比如定义了 public class HttpClientUtil，就必须保存在 HttpClientUtil.java 中；若误写成 httpclientutil.java 或 HttpClientutil.java，javac 会报错 class HttpClientUtil is public, should be declared in a file named HttpClientUtil.java。
非 public 类可以和文件名不一致，但不建议——这会让团队成员难以定位类，IDE 也无法正确索引。
- 包名全小写（如
com.example.order），避免下划线或大写字母 - 类名体现职责，避免模糊词如
Manager、Helper、Tool（除非确实只做单一工具方法） - 接口名也用大驼峰，通常以形容词或名词结尾（如
Runnable、OrderRepository），避免加I前缀（那是 C# 风格）
字段优先私有 + final，暴露用 getter 而非 public 字段
直接暴露 public 字段会破坏封装，导致外部随意修改、无法添加校验逻辑、难以调试变更来源。哪怕只是 public static final String VERSION = "1.2" 这种常量，也建议统一用 public static final + 大写下划线命名，且确保不可变。
实例字段几乎都该是 private，需要读取时提供 getXXX() 方法；如果字段本身是可变对象（如 List、Map），getter 必须返回副本（如 new ArrayList(this.items)），否则外部仍能修改内部状态。
立即学习“Java免费学习笔记（深入）”；
-
private final是首选组合：明确表达“初始化后不变”，JVM 也能更好优化 - 布尔字段不要用
isXXX()命名却返回非布尔值，否则 Jackson、Spring 等框架反射解析会出错 - 避免为每个字段机械生成 getter/setter：只暴露真正需要被外部访问的属性
构造函数只做必要初始化，拒绝业务逻辑和远程调用
构造函数里执行 HTTP 请求、数据库查询、文件读取等操作，会导致 new 对象失败风险高、单元测试难 mock、类生命周期失控。例如 new OrderService() 内部去连 Redis，那所有单元测试都会因网络失败而挂掉。
合理做法是把依赖通过构造参数注入（即“构造器注入”），让创建者负责提供已准备好的协作对象：
public class OrderService {
private final OrderRepository repository;
private final NotificationClient notifier;
<pre class='brush:java;toolbar:false;'>public OrderService(OrderRepository repository, NotificationClient notifier) {
this.repository = Objects.requireNonNull(repository);
this.notifier = Objects.requireNonNull(notifier);
}}
- 所有非 primitive / 不可变类型的参数，建议用
Objects.requireNonNull()校验，及早暴露空指针 - 避免重载过多构造函数，优先用 Builder 模式处理可选参数多的场景
- 不要在构造函数中调用
this.xxx()非 final 方法——子类可能覆盖它，而此时子类字段还未初始化
方法设计遵循单一职责，参数尽量少且语义清晰
一个方法超过 10 行、参数超过 4 个、方法名含 “and” 或 “or”，基本说明它在承担多个职责。比如 processAndNotifyAndLog(Order order, boolean sendEmail) 就该拆成 process(order)、notify(order)、log(order) 三个方法。
参数类型优先用具体契约而非宽泛类型：用 Instant 而非 Date，用 List<String> 而非 Collection（除非真要兼容 Set/Queue），用 Path 而非 String 表示路径。
- 避免布尔参数控制行为分支（如
save(order, true)）——改用两个方法saveWithValidation()和saveWithoutValidation() - 返回值别用
null表示“无结果”，优先用Optional<T>（但仅限于可能为空的查找场景；集合返回空List比Optional<List>更自然） - 异常策略要明确：检查型异常（
Exception）用于可预期且调用方应恢复的错误（如文件不存在）；运行时异常（RuntimeException）用于编程错误或不可恢复问题（如参数为 null）
类设计最易被忽略的其实是“何时不该设计新类”——比如只是为了把几个静态方法包在一起而建一个 StringUtils，没问题；但若开始往里塞状态、依赖、构造逻辑，就该立刻停下来问：它到底是一个实体？一个服务？还是本该是某个现有类的方法？
