第一部分：Java 方法深度精讲 ------ 设计原则、传参机制与性能优化
方法是 Java 代码复用的最小逻辑单元，是对一个完整业务操作的逻辑封装。好的方法设计，可以将业务复杂度隔离，让代码可读性提升 10 倍，同时避免绝大多数性能问题。
1.1 方法的本质：逻辑封装与复用入口
从底层逻辑看，方法是一组被封装的执行指令，在类加载时会被存入方法区，调用时，虚拟机会在栈帧中分配局部变量表、操作数栈等核心内存结构。
从业务设计看，方法的核心目标只有两个：
- 逻辑复用：将重复的业务逻辑封装起来，避免代码冗余；
- 逻辑抽象：将复杂的业务实现细节隐藏，对外暴露单一的功能入口。
方法的标准语法结构
// 修饰符 返回值类型 方法名(参数列表) \[throws 异常列表] {
// 方法体：业务逻辑实现
// return 返回值;
// }
public class OrderService {
  // 标准方法示例：计算订单应付金额
  public BigDecimal calculateOrderAmount(List\<OrderItem> itemList, BigDecimal discount) {
  // 校验参数
  if (itemList == null || itemList.isEmpty()) {
  return BigDecimal.ZERO;
  }
  // 累加商品总金额
  BigDecimal total = itemList.stream()
  .map(OrderItem::getSubTotal)
  .reduce(BigDecimal.ZERO, BigDecimal::add);
  // 扣除优惠金额
  return total.subtract(discount).max(BigDecimal.ZERO);
  }
}工业级设计要求：一个方法只完成
单一职责
的一项功能，方法名要采用
动词+名词的驼峰命名格式，参数列表控制在 5 个以内，超过则封装为参数对象。
1.2 核心难点彻底拆解：方法参数传递机制
这是 Java 面试中答错率超过 80% 的核心问题，也是初中级开发者最容易混淆的技术误区。
高频误区澄清
错误认知：基本类型按值传递，对象类型按引用传递。
正确结论：Java 语言永远只有值传递------ 所谓的引用传递，本质是传递了对象内存地址值的副本，语法层面不存在传递对象本身的情况。
这一结论并非经验总结，而是来自Java 语言规范的明确规定 。理解这一逻辑的关键，是分清基本类型变量 和引用类型变量的内存存储差异：
- 基本类型变量：栈帧中直接存储变量的实际值；
- 引用类型变量：栈帧中存储的是对象的内存地址值，对象本身则存放在堆内存中。
代码演示：值传递的底层逻辑
下面通过两个典型案例，直观演示值传递的行为差异，彻底消除误解：
public class MethodPassDemo {
  public static void main(String\[] args) {
  // 案例1：基本类型参数传递
  int num = 10;
  modifyBasicType(num);
  System.out.println("调用后基本类型值：" + num); // 输出：10（原始值未被修改）
  // 案例2：引用类型参数传递
  User user = new User("张三");
  modifyReferenceType(user);
  System.out.println("调用后引用类型值：" + user.getUsername()); // 输出：李四（对象属性被修改）
  // 案例3：引用类型变量重新赋值
  User user2 = new User("王五");
  reassignReference(user2);
  System.out.println("调用后重新赋值用户：" + user2.getUsername()); // 输出：王五（原始引用未变）
  }
  // 基本类型传参：传递的是实际值的副本
  private static void modifyBasicType(int num) {
  num = 20; // 修改的是副本值，不影响原始变量
  }
  // 引用类型传参：传递的是堆内存地址的副本
  private static void modifyReferenceType(User user) {
  user.setUsername("李四"); // 形参和实参指向同一个堆内存对象，所以属性修改会同步
  }
  // 引用类型重新赋值：形参指向了新对象，不影响原始实参
  private static void reassignReference(User user) {
  user = new User("赵六"); // 形参的引用地址被修改，但原始实参的地址未改变
  }
}
// 辅助实体类
class User {
  private String username;
  public User(String username) {
  this.username = username;
  }
  public void setUsername(String username) {
  this.username = username;
  }
  public String getUsername() {
  return username;
  }
}核心结论总结
| 参数类型 | 传递内容 | 方法内修改的影响范围 |
|---|---|---|
| 基本类型 | 原始值的副本 | 仅修改副本值，完全不影响原始实参 |
| 引用类型 | 对象堆内存地址的副本 | 修改对象的属性 / 字段时，会同步影响原始对象；但如果对形参重新赋值，不会影响原始实参的引用 |
业务开发注意事项：如果需要在方法内修改引用类型的属性，且需要同步到外部对象时，必须在方法注释中明确说明这一副作用；对于不需要修改的引用类型参数，建议使用
final修饰，避免意外的重新赋值操作。
1.3 方法重载（Overload）：大厂级设计原则与避坑指南
方法重载是 Java 实现编译时多态的核心技术手段 ------ 核心逻辑是「用同一个方法名，适配不同类型的参数场景」，避免开发者记忆大量功能相似的方法名，简化调用成本。
1.3.1 方法重载的官方语法规则
要实现方法重载，必须严格满足以下四个条件，否则会出现编译错误：
- 必须在同一个类中定义；
- 方法名必须完全相同；
- 参数列表必须存在差异（参数个数不同、或参数类型不同、或参数顺序不同）；
- 方法的返回值类型、访问修饰符、抛出的异常类型，不能作为重载的判断依据。
1.3.2 大厂编码规范中的重载设计原则
Google、Amazon 等国际大厂的 Java 编码规范，对重载设计有明确的约束规则 ------ 语法上的合法重载，并不等于工程级别的合理设计。很多团队的代码歧义、维护困难问题，都是因为重载设计不规范导致的。
结合大厂规范和 YouTube 高级博主的建议，重载设计必须遵循四条黄金原则：
原则一：语义一致性
所有重载方法的核心功能语义必须完全一致，不能出现方法名相同，但业务功能完全无关的情况。
// 反模式：同名方法功能语义不一致，会严重误导调用者
public class OrderService {
  // 功能：根据订单ID查询订单
  public Order getOrder(Long orderId) { ... }
  // 功能：根据订单号更新订单状态------功能语义与查询完全无关，不适合使用重载
  public Order getOrder(String orderNo, Integer status) { ... }
}
// 正例：所有重载方法的核心语义都是「计算订单金额」，只是参数组合不同
public class OrderService {
  // 基于订单ID计算金额
  public BigDecimal calculateAmount(Long orderId) { ... }
  // 基于订单实体计算金额
  public BigDecimal calculateAmount(Order order) { ... }
  // 基于订单项+优惠金额计算金额
  public BigDecimal calculateAmount(List\<OrderItem> itemList, BigDecimal discount) { ... }
}原则二：参数递进性，可选参数后置
重载方法的参数列表，必须从「必选参数」到「可选参数」逐步增加，将可选参数放在参数列表的末尾，符合开发者的调用直觉。
// 正例：必选参数在前，可选参数后置，参数个数变化不超过3个
public class OrderQueryService {
  // 必选参数：只传用户ID
  public List\<Order> query(Long userId) {
  return query(userId, null, null);
  }
  // 增加可选参数：订单状态
  public List\<Order> query(Long userId, Integer status) {
  return query(userId, status, null);
  }
  // 增加可选参数：分页参数
  public List\<Order> query(Long userId, Integer status, Pageable pageable) {
  // 最终业务实现
  }
}原则三：避免过度重载
同一个类中，重载方法的数量不能超过 5 个，且参数个数的差异不能超过 3 个 ------ 过多的重载组合，会增加代码的理解成本，容易出现调用歧义。
如果参数组合超过 5 种，应该使用参数对象模式 或者建造者模式来替代重载，避免方法膨胀。
原则四：谨慎设计可变参数的重载
可变参数的重载方法，容易引发调用歧义。如果必须使用，需要保证可变参数的重载方法，与其他重载方法的参数类型有明显区别。
// 反模式：可变参数与固定参数存在歧义
public class Calculator {
  public int sum(int... nums) {
  return Arrays.stream(nums).sum();
  }
  public int sum(int a, int b) {
  return a + b;
  }
  // 调用sum(1,2)时，编译器无法确定调用哪个方法，会出现编译错误
}第二部分：Java 构造方法深度精讲 ------ 初始化逻辑、重载设计与性能优化
构造方法是 Java 对象创建的核心入口 ------ 每一个对象的初始化状态，完全由构造方法决定。它的设计质量，直接决定了对象的合法性、初始化效率，以及后续业务代码的健壮性。
2.1 构造方法的本质：对象的初始化仪式
很多开发者误以为构造方法的作用是创建对象 ------ 这是一个常见的认知误区。对象的实际创建工作，是由虚拟机在堆内存中完成的；构造方法的真正核心作用，是在对象创建完成后，为对象的成员变量赋予合理的初始值，保证对象在诞生时处于合法可用的状态。
构造方法的执行时机，是在new关键字完成堆内存分配、并对成员变量进行默认初始化（0、null、false）之后 ------ 也就是说，构造方法的执行，是对象创建过程的最后一步。
构造方法的严格语法规则
与普通方法不同，构造方法的语法规则是强制性的，任何违反都会导致编译错误：
- 构造方法的名称，必须与类名完全一致，包括大小写；
- 构造方法不能声明返回值类型 ，就连
void也不能声明； - 构造方法不能被
static、final、abstract关键字修饰 ------ 构造方法属于实例级别的资源，且需要被子类调用，因此这些修饰符没有意义； - 构造方法可以被
private修饰 ------ 这是单例模式、静态工厂模式的核心实现方式。
2.2 构造方法的分类与使用场景
Java 中的构造方法，分为三类，分别对应不同的业务初始化场景：
1. 隐式无参构造方法
如果一个类没有显式定义任何构造方法，Java 编译器会自动生成一个无参的默认构造方法，其内部会自动调用父类的无参构造方法，完成父类的初始化操作。
注意事项：如果类中显式定义了任何一种有参构造方法，编译器将不会再自动生成无参构造方法 ------ 这是很多初学者容易踩到的坑。
2. 显式无参构造方法
当类需要提供无参创建对象的能力时，必须显式定义无参构造方法。尤其在使用 Spring、MyBatis 这类框架时，框架需要通过反射调用无参构造方法，来实例化对象 ------ 如果类中没有无参构造方法，会直接抛出实例化异常。
3. 有参构造方法
有参构造方法是业务开发中最常用的构造方法类型，它可以在创建对象时，直接为成员变量赋予有意义的初始值，避免对象创建后再重复调用 setter 方法赋值，减少代码行数。
// 标准JavaBean类：同时提供无参+有参构造方法，适配框架和手动创建两种场景
public class User {
  // 成员变量
  private Long id;
  private String username;
  private String email;
  // 无参构造方法：供框架反射使用
  public User() {
  // 可以在这里设置成员变量的默认值
  this.status = 1;
  }
  // 全参构造方法：供业务代码手动创建对象使用
  public User(Long id, String username, String email) {
  this.id = id;
  this.username = username;
  this.email = email;
  }
}