写方法这件事，几乎是每个Java开发者的第一道基本功。我见过太多新手，循环嵌套写得飞起，一到抽方法就卡壳：参数不知道传几个，返回值不知道怎么写，更要命的是，重构时动一个方法牵扯出一堆问题。这篇文章专门聊Java方法，从最基础的语法到重载、递归、可变参数，再到真正生产环境里的设计习惯，一次讲透。
方法说白了就是给一段代码起名字，然后反复调用。它解决的核心问题有三个：复用、分层、可读性。没有方法的话，你写一个排序逻辑，每次用都要复制一遍，改一处要改十处，迟早会翻车。有了方法，逻辑集中管理，调用方只关心传入什么、得到什么，中间的复杂性被隔离起来，代码自然清晰了。这篇文章适合所有阶段的Java开发者，尤其是刚入门的同学，或者准备Java面试、想搞清楚方法底层细节的人。
1. 方法的基础结构：从声明到调用
1.1 方法声明的五个要素
一个标准的方法声明长这样：
public static int add(int a, int b) { return a + b; }从左往右拆：public是访问修饰符，static是静态修饰符，int是返回值类型，add是方法名，括号里的int a和int b是形式参数，花括号里是方法体。
初学者最容易迷糊的是：返回值类型和参数类型能不能不写？不能。Java是强类型语言，每个方法必须声明返回什么类型，没有返回值就用void。参数列表可以为空，但括号不能省——void sayHello()和void sayHello是两回事，后者直接编译报错。
方法名的命名规范不用多说，小驼峰，动词开头，getUserById、calculateTotalPrice这种。但有一点很多人忽视：方法名要能自解释。看了名字就知道干什么，不要用doIt、handle这种含糊的名字。我见过一个老项目，一个叫process的方法干了六百行，后来维护的人恨不得把电脑扔了。
1.2 方法的调用机制
方法写出来不调用就是死代码。调用分两种：同类内直接调用，跨类调用需要对象或类名。静态方法用类名调用，实例方法用对象调用：
// 同类内 int result = add(3, 5); // 静态方法跨类 int result = MathUtils.add(3, 5); // 实例方法跨类 MathUtils utils = new MathUtils(); int result = utils.add(3, 5);这里有个关键点：Java方法的参数传递是值传递。基本类型传的是值的副本，引用类型传的是引用的副本——记住，引用本身是值，对象才是引用指向的东西。所以方法内修改基本类型参数不会影响外部变量，但修改引用类型参数的属性会影响外部对象。这个问题面试必问，后面专门展开。
调用方法时，JVM会为每次调用分配一个栈帧，方法执行完毕栈帧弹出，局部变量随之销毁。这就是为什么方法内定义的变量方法结束就没了。递归就是这个机制的极端情况——每一层递归都有自己的栈帧，深度太大会栈溢出。
2. 参数传递：值传递还是引用传递
2.1 基本类型的值传递
看段代码：
public static void main(String[] args) { int num = 10; changeNum(num); System.out.println(num); // 输出10 } public static void changeNum(int x) { x = 20; }运行结果还是10。原理很简单：num把值10复制了一份给x，x怎么变都影响不到num。就像你给同事一份文件的复印件，同事在复印件上涂改，原件不受影响。
有些同学问：那Integer呢？Integer是引用类型，但它是不可变的，内部value字段是final的，所以你在方法里重新赋值x = 20，实际上是让x指向了一个新的Integer对象，外部引用没变。结论和基本类型一样，外层不受影响。
2.2 引用类型的传递
public static void main(String[] args) { StringBuilder sb = new StringBuilder("hello"); appendWorld(sb); System.out.println(sb.toString()); // hello world } public static void appendWorld(StringBuilder s) { s.append(" world"); }输出是hello world。因为sb把引用的副本传给了s，两个引用指向同一个对象，s修改对象内容，外部通过sb能看到变化。但注意：
public static void reassign(StringBuilder s) { s = new StringBuilder("new value"); }这样改，外部sb还是原来的对象。因为你只是把s指向了新对象，外部引用还指向旧对象。这就是值传递的本质：传过去的始终是副本，只是引用类型的副本恰好指向同一个对象。
这个点面试官很喜欢引申一个经典问题：Java到底是值传递还是引用传递？标准答案是：Java只有值传递。引用类型传的是引用的值，不是对象本身。这个答案能拦住一大半人。
3. 方法重载：同名不同参的艺术
3.1 重载的规则与原理
方法重载是Java多态性的重要体现。规则很简单：方法名相同，参数列表不同（参数类型、个数、顺序至少有一个不同），返回类型可以不同但绝不参与区分调用。
public int add(int a, int b) { return a + b; } public int add(int a, int b, int c) { return a + b + c; } public double add(double a, double b) { return a + b; } public long add(int a, long b) { return a + b; }为什么重载能工作？因为JVM编译时根据方法名和参数类型就能确定调用哪个版本，这属于静态分派。你写add(1, 2)，编译器一看参数是int,int，直接编译时绑定了第一个方法，运行前就确定了。所以重载不依赖运行时类型，这也是重写和重载的根本区别——重写是运行时多态，重载是编译时多态。
3.2 重载的常见误区和设计建议
有个坑必须提醒：重载方法参数类型有继承关系时，调用会有优先级问题。
public void print(String s) { System.out.println("String"); } public void print(Object o) { System.out.println("Object"); } print("hello"); // 输出String，精确匹配优先但如果你传null，就要小心了：
print(null); // 编译报错，ambiguous因为null既可以是String也可以是Object，编译器分不清。所以设计重载时要避免这种语义模糊的情况。
重载设计建议：参数含义保持一致，只是类型或数量不同。add(int, int)和add(String, String)如果都叫add但逻辑完全不同，那就是灾难。工具类如StringUtils里大量重载，本质都是为了调用方的便利：不传参数有默认行为，传一个参数覆盖默认值，传两个参数完整控制。这种从简到全的递进设计，是最常见的重载模式。
4. 可变参数与递归
4.1 可变参数的使用与限制
可变参数让方法可以接收不定数量的参数，语法是类型... 参数名：
public static int sum(int... numbers) { int total = 0; for (int n : numbers) { total += n; } return total; } System.out.println(sum(1, 2, 3)); // 6 System.out.println(sum(1, 2, 3, 4, 5)); // 15本质上，可变参数就是一个数组的语法糖。int... numbers相当于int[] numbers，但调用方可以不用构造数组，直接把元素列出来。注意三点：
- 可变参数必须是方法参数列表的最后一个。
- 调用时可以不传参数，得到一个长度为0的数组。
- 可变参数和数组重载会冲突：
sum(int...)和sum(int[])同时定义会编译报错。
有个性能细节：可变参数每次调用都会创建数组，高频调用场景有轻微开销。不是瓶颈就别纠结，但如果你写一个每秒调用百万次的工具方法，建议用明确的重载版本。
4.2 递归：方法调用自身的艺术
递归是方法的一种特殊调用形态——方法体内调用自己。经典例子是斐波那契数列：
public static long fibonacci(int n) { if (n <= 1) { return n; } return fibonacci(n - 1) + fibonacci(n - 2); }写递归必须有两个要素：基线条件（递归出口）和递推关系（向出口逼近）。缺少基线条件就是死循环，栈溢出StackOverflowError跑不掉。
递归虽然代码优雅，但性能不一定好。上面那个斐波那契，n=45的时候已经要算很久了。原因是大量重复计算：fibonacci(40)会重复计算同规模的子问题。优化思路要么加缓存（记忆化搜索），要么改成递推循环。所以生产环境里，我一般建议：递归深度可控用递归，深度不可控或性能敏感用循环和栈模拟。递归最大的优势是可读性，尤其是树形结构遍历、目录扫描、JSON解析这些天然递归的场景。
5. 常见方法使用场景实战
5.1 排序方法：从冒泡到工具类
排序是Java面试的高频题，很多同学在纸上写冒泡排序：
public static void bubbleSort(int[] arr) { int n = arr.length; for (int i = 0; i < n - 1; i++) { boolean swapped = false; for (int j = 0; j < n - 1 - i; j++) { if (arr[j] > arr[j + 1]) { int temp = arr[j]; arr[j] = arr[j + 1]; arr[j + 1] = temp; swapped = true; } } if (!swapped) { break; } } }这里有个容易犯的错：数组是引用类型，方法内交换元素会直接改变原数组，不需要返回值。很多新手非要在方法里return一个新数组，反而把代码搞复杂了。
真正开发中，直接使用Arrays.sort()：
int[] arr = {5, 3, 8, 1}; Arrays.sort(arr); // 升序 Integer[] arr2 = {5, 3, 8, 1}; Arrays.sort(arr2, (a, b) -> b - a); // 降序，需用包装类型Arrays.sort对基本类型用的是双轴快速排序，对引用类型用的是归并排序（TimSort），性能足够稳。自己写排序方法的场景一般是：面试考手写、处理特殊数据分布、或者学习算法原理。
5.2 字符串处理方法：contains与判断技巧
字符串处理里有个高频场景：判断字符串是否包含某个子串。直接上contains：
String email = "dev@example.com"; if (email.contains("@")) { // 处理 }但contains区分大小写。不区分大小写可以用toLowerCase()处理后判断，或者用正则matches("(?i).*@.*")。需要注意的是contains底层调用的是indexOf，没有匹配返回-1，底层走的是朴素匹配，对于长文的复杂模式匹配性能不如正则引擎，但常规场景已经够用。
还有个高频需求：判断字符串中是否包含非字母和数字的字符。正则是最简单的方案：
public static boolean hasSpecialChar(String s) { return !s.matches("[a-zA-Z0-9]*"); }这里matches要求整个字符串匹配，所以"[a-zA-Z0-9]*"表示全由字母数字组成。取反就是存在特殊字符。注意matches每次都会编译正则，循环里大量调用建议预编译成Pattern对象：
private static final Pattern SPECIAL_CHAR = Pattern.compile("[^a-zA-Z0-9]"); public static boolean hasSpecialChar(String s) { return SPECIAL_CHAR.matcher(s).find(); }这种细节就是性能和可维护性的区别。写工具方法时养成预编译正则的习惯，长期收益很大。
6. 方法的进阶技巧与实战经验
6.1 重写方法必须牢记的规则
说到方法就不能不提重写。子类重写父类方法时，有五个规则必须遵守：
- 方法名、参数列表必须完全一致。
- 返回值类型可以缩小但不能扩大（协变返回）。
- 访问修饰符不能比父类更严格：父类是
public，子类不能写成protected。 - 抛出的异常不能比父类更宽泛。
- 父类的私有方法不能被重写，static方法也不叫重写，那叫隐藏。
运行时多态怎么实现的？JVM在调用实例方法时查虚方法表，根据对象的实际类型找到对应的方法实现。这就是为什么List list = new ArrayList(); list.add(...)，add是实际的ArrayList版本。写框架、写扩展点时理解这个机制很关键，Spring的AOP本质上就是靠代理对象和方法的动态分派。
重写方法时建议加@Override注解。不加也能重写，但加了能让编译器帮你检查——方法签名写错了，没有@Override照样编译通过，你以为重写了，其实是个新方法，这种bug非常隐蔽。
6.2 方法设计的实用原则
方法设计得好不好，直接决定代码的维护体验。几个原则我这些年深有体会：
- 方法要小。一个方法超过50行就有点危险了。你说你业务复杂，那也要拆成几步：解析参数、校验、核心逻辑、组装结果，各用一个方法。
- 方法只做一件事。判断合法性和修改数据分开，读取和写入分开，这是单一职责原则在方法层面的体现。
- 参数尽量少。超过3个参数就想办法封装成一个对象。
createUser(String name, int age, String email, String phone)不如createUser(User user)清晰。 - 不要用
null表示异常业务分支。找不到返回Optional.empty()，这是Java 8之后的标准做法。
举个例子，一个坏味道很重的方法可能是这样的：
public void saveUser(String name, int age, boolean vip, String address, String phone, String email, String remark, Date createTime, Date updateTime) { // 50行代码，包含校验、拼接SQL、日志、发送消息 }你应该拆成这样：
public void saveUser(User user) { validate(user); User normalized = normalize(user); userDao.insert(normalized); sendNotificationIfNeeded(normalized); }一眼望过去，调用方知道流程是什么，想改某一环节直接改对应方法。这才是方法该有的样子。
6.3 方法参数的可读性优化
参数类型模糊、含义不清楚，是团队协作里最让人头疼的问题之一。我看到不少代码是这样的：
public void updateStatus(String id, int status, boolean force) { ... }调用方得猜：status的int有什么取值范围？force强制的什么？更好的做法是枚举和布尔参数拆分：
public enum UserStatus { ACTIVE, DISABLED, PENDING } public void updateStatus(String id, UserStatus status, UpdatePolicy policy) { ... }调用变成：
updateStatus("1001", UserStatus.ACTIVE, UpdatePolicy.FORCE);读代码的人不用猜，这就是可读性。有些同学嫌麻烦，觉得枚举和类太多了不好，但代码写出来是给人看的，尤其是给三个月后的自己看的。妥协的写法是给方法设计良好的javadoc注释，或者用链式调用的风格。
7. 调用方法与性能的坑
7.1 方法内的局部变量与线程安全
局部变量是线程安全的。每个线程调用方法时都有自己的栈帧，局部变量存在栈帧里，天然隔离。但成员变量就有并发风险：
public class Counter { private int count = 0; public void increment() { count++; // 非原子操作，线程安全需要加锁 } }如果你在方法里只操作局部变量，不用考虑线程安全问题。但一旦方法访问了成员变量或静态变量，就要考虑并发。这也是为什么工具类方法大多是纯静态的、只操作传入参数——天然线程安全，这也是设计上一种刻意为之的优雅。
7.2 方法调用的性能消耗
方法调用本身有开销：栈帧创建、参数压栈、跳转、返回。但这个开销在现在的JVM面前几乎可以忽略不计，因为JIT会做内联优化——热点方法直接展开到调用方。你真正要担心的不是方法调用本身，而是方法内部的逻辑。
有几个性能陷阱值得注意：
- 循环里重复调用昂贵方法。比如
for循环里每次都getUserById查数据库，改成批量查询。 - 递归深度过大导致的栈溢出，考虑改迭代。
- 可变参数的高频调用造成数组分配，考虑用固定参数版本。
- 大对象作为参数传递虽然传的是引用，但修改对象属性会带来副作用，必要时返回新对象而不是改传入对象。
我在实际项目里测过，一个简单方法调用百万次，耗时大概几十毫秒，真的不是瓶颈。不要为了微优化牺牲可读性，先跑起来，再分析基准数据决定要不要优化。
8. 一个练习项目：从方法设计到重构
讲了这么多，动手练一遍比看十篇文章都管用。我给你一个实际场景：写一个工具类，实现用户列表的过滤、排序和分页。
先看一个初学者的写法，全部逻辑堆在一个方法里：
public static List<User> filterAndSort(List<User> users, String keyword, String sortBy, int page, int size) { List<User> result = new ArrayList<>(); for (User u : users) { if (u.getName().contains(keyword) || u.getEmail().contains(keyword)) { result.add(u); } } result.sort((a, b) -> a.getAge() - b.getAge()); int start = (page - 1) * size; if (start > result.size()) { return Collections.emptyList(); } int end = Math.min(start + size, result.size()); return result.subList(start, end); }这个写法能用，但问题一堆：搜索、排序硬编码，无法扩展；方法长度不短且混杂了三种职责；测试不方便。重构成多方法：
public static List<User> searchUsers(List<User> users, String keyword) { if (keyword == null || keyword.isEmpty()) { return new ArrayList<>(users); } String kw = keyword.toLowerCase(); return users.stream() .filter(u -> u.getName().toLowerCase().contains(kw) || u.getEmail().toLowerCase().contains(kw)) .collect(Collectors.toList()); } public static void sortUsers(List<User> users, Comparator<User> comparator) { users.sort(comparator); } public static List<User> paginate(List<User> users, int page, int size) { int start = (page - 1) * size; if (start >= users.size()) { return Collections.emptyList(); } int end = Math.min(start + size, users.size()); return new ArrayList<>(users.subList(start, end)); } // 主流程组合 public static List<User> pageUsers(List<User> users, String keyword, Comparator<User> comparator, int page, int size) { List<User> searched = searchUsers(users, keyword); sortUsers(searched, comparator); return paginate(searched, page, size); }重构的好处立竿见影：每个方法单独测试很容易，搜索逻辑改了不影响排序，排序传不同的Comparator就能按年龄、按名字、按创建时间排。这就是方法设计的实战价值——拆开之后，系统变得灵活了。
你在团队里Review别人的代码时，看到长方法下意识应该问：能拆吗？怎么拆？拆出来的方法是否职责单一？参数是否合理？这套思维方式，就是从一个会写方法的人走向一个会设计方法的人的标志。
方法本身不难，多写多练自然熟练。但方法设计的思想需要刻意练习：每写一个方法前想三秒，它的输入输出是什么，职责是否单一，命名是否准确。做到这些，你的代码质量自然上一个台阶。
