如果你问我Java初学者的分水岭在哪里我的答案永远是方法。变量、运算符、if、for循环这些都是零件而方法教你怎样把零件组装成模块让你的程序第一次拥有结构。我带过不少新人在学方法之前写代码都是“叙事体”——main方法从头写到尾一屏塞不下改一个逻辑要找半天。学会方法之后代码才真正变得能维护、能复用、能给别人看。这篇文章从定义、调用、参数传递一路讲到重载和递归最后分享一些我在实际代码评审里反复强调的设计原则。不管你是刚学Java的在校生还是工作后想补基础的转行者这套思路应该都能帮到你。1. 为什么代码非要拆成方法一段“面条式”代码的重构实录1.1 一个典型的main方法膨胀现场很多初学者写程序习惯是“从头写到尾”。比如一个学生成绩处理程序需求很简单录入5个学生成绩算平均分再找最高分。新手版本往往长这样import java.util.Scanner; public class Test { public static void main(String[] args) { Scanner sc new Scanner(System.in); int[] scores new int[5]; for (int i 0; i scores.length; i) { scores[i] sc.nextInt(); } int sum 0; for (int i 0; i scores.length; i) { sum scores[i]; } double avg sum / 5.0; System.out.println(平均分: avg); int max scores[0]; for (int i 1; i scores.length; i) { if (scores[i] max) { max scores[i]; } } System.out.println(最高分: max); } }这段代码功能完全正确但问题也肉眼可见所有逻辑统统挤在main里中间没有一处停顿。如果明天需求改成“录入10个学生成绩”那么循环、平均分的除数和数组长度都要跟着改。要是这段逻辑还被复制了几份改起来就是灾难。这就是典型的“面条式代码”像一碗面条一样拉出来一根带出一堆。1.2 拆完之后的样子用方法重构后main方法变得非常“克制”import java.util.Scanner; public class Test { public static void main(String[] args) { Scanner sc new Scanner(System.in); int[] scores new int[5]; for (int i 0; i scores.length; i) { scores[i] sc.nextInt(); } System.out.println(平均分: average(scores)); System.out.println(最高分: max(scores)); } // 计算平均分接收成绩数组返回double结果 public static double average(int[] scores) { int sum 0; for (int score : scores) { sum score; } return sum / (double) scores.length; } // 找出最高分接收成绩数组返回int结果 public static int max(int[] scores) { int max scores[0]; for (int score : scores) { if (score max) { max score; } } return max; } }现在main方法只做三件事录入数据、调average、调max。计算平均分的细节被关进了average方法里找最高分的细节关进了max方法里。以后哪个功能要复用同样逻辑直接一行调用就行不用再把循环抄一遍。1.3 方法最核心的价值复用与抽象方法解决的两个核心问题第一个是复用第二个是抽象。复用很好理解一段逻辑写一次调用无数次。但抽象往往被新手忽略。当我写好average方法后调用方根本不需要关心“平均分怎么算出来的”只需要知道“传入成绩数组就能拿回平均分”。这就是把复杂问题拆成小问题每个小问题只通过输入输出去理解。我在实际教学里判断一个方法拆得好不好只看两件事第一main方法能不能在5句话内说清楚整个程序的流程第二每个方法的名字能不能直接回答“这个方法干嘛的”。如果方法名要想两秒才说得清说明这个方法的职责还不够专一。这个标准从第一天写方法开始就可以养。2. 方法定义与调用语法骨架、执行流程和容易看漏的细节2.1 方法签名里每一部分都是什么意思完整的方法定义长这样public static int add(int a, int b) { return a b; }一个方法签名由几个部分组成缺一不可组成例子作用访问修饰符public控制谁能调用public是公开private是私有静态修饰符static有它属于类没它属于对象返回值类型int方法计算完返回什么类型的值void表示什么都不返回方法名add调用时的标识遵循小驼峰命名参数列表int a, int b调用时需要传入的数据每个参数都必须声明类型方法体return a b;具体执行的逻辑调用时代码就很简单了int result add(3, 5); // 3和5是实参 System.out.println(result); // 8这里需要分清一个几乎所有面试都会问到的基础概念形参和实参。定义方法时写的int a、int b叫形参形式参数它们是占位符调用方法时传的3、5叫实参实际参数它们的值在调用发生时会复制给形参。搞清楚这个概念参数传递那节就不会迷糊了。2.2 从调用栈理解“方法调用”发生了什么方法调用背后是JVM的栈帧机制。每次调用一个方法JVM会为这次调用分配一块栈帧里面存放局部变量和临时计算数据方法执行完栈帧出栈里面的数据全部失效。这就是为什么方法内定义的局部变量方法一结束就“消失”了。我在讲这个点的时候喜欢做一个比喻每次方法调用就像开一个临时会议室进会议室时可以带一些资料形参在会议室里可以做自己的事局部变量会议结束人走灯灭所有资料清空。主方法开着的会议不受影响因为各开各的会。有个初学者经常踩的坑在main里定义了一个变量想在一个方法里直接访问它结果编译报错“找不到符号”。原因就是两个方法各占各的栈帧main里的变量在main的栈帧里根本不在子方法的栈帧里。要让方法访问main里的数据只能通过参数传进去通过返回值拿回来。2.3 static最常被问的“我到底要不要加”讲方法绕不开static。我遇到最多的问题是“为什么main方法必须static我写的方法要不要加”main是程序入口JVM启动时还没有创建任何对象所以main必须是静态的由类直接调用。而普通方法加不加static取决于它是否依赖于对象的成员。方法里要访问实例变量如this.name就不能加static方法只依赖传入的参数不访问任何成员变量加static反而更合适——可以直接用类名调用比如Math.abs()、Arrays.sort()一眼就知道这是工具方法。从设计角度看static方法属于“面向过程”的工具函数虽然Java是面向对象语言但工具类里放静态方法非常常见。我自己写项目时抽出来的纯计算逻辑不涉及任何成员属性都会加static既省去创建对象的麻烦也明确表达“这个方法与对象状态无关”。如果方法用到对象的属性那就不加static让它作为实例方法存在。还有一个容易忽略的细节非static方法可以调用static方法但static方法不能直接调用非static方法。原因很简单——static方法执行时可能还没有任何对象存在而非static方法必须依附于对象。所以你在main方法里直接写一个非static方法的名字编译会直接报错。很多人第一次见到这个错就懵了其实就是这个原因。3. 参数传递的真相Java只有值传递但引用类型会“改到对象”3.1 先记住结论所有参数都是复制Java官方的说法是Java只有值传递没有引用传递。这个“值”要分两种情况看。基本类型变量存的是值本身传递时复制值引用类型变量存的是对象的地址传递时复制地址。所以准确地说一切传递都是复制只是复制的“东西”不同。这个点之所以绕是因为新手会直观地把“引用类型”理解成“可以直接改外面的变量”。实际上引用类型变量在赋值、传参时复制的是指向对象的地址而不是对象本身。理解了这个底层逻辑很多“诡异”的现象都能解释。3.2 基本类型交换两个变量的经典翻车现场看这段代码public class Test { public static void main(String[] args) { int a 1; int b 2; swap(a, b); System.out.println(a a , b b); // 输出 a1, b2 } public static void swap(int x, int y) { int temp x; x y; y temp; } }很多人第一次写swap方法时看到输出没变整个人都傻掉。原因其实很简单调用swap(a, b)时是把a的值1复制给了x把b的值2复制给了y。swap方法里交换的是x、y和main里的a、b毫无关系。方法结束后x、y随栈帧一起销毁a和b还是原来的1、2。要在Java里实现“交换两个变量的值”基本类型变量传参是做不到的。常见做法两种一是让方法返回交换后的结果由调用方接收二是把a、b封装成对象再传拿对象的成员来交换。后者其实已经沾到引用类型的边了。3.3 引用类型改得到对象但改不了指向看数组的例子import java.util.Arrays; public class Test { public static void main(String[] args) { int[] arr {1, 2, 3}; change(arr); System.out.println(Arrays.toString(arr)); // 输出 [10, 2, 3] } public static void change(int[] data) { data[0] 10; // 通过复制来的地址修改了堆里同一个数组对象 } }输出变成了[10, 2, 3]。原因arr存的是数组对象在堆里的地址调用change(arr)时把地址复制给datadata和arr指向同一个数组对象。data[0] 10是顺着地址找到堆里的对象修改了它的第一个元素。调用方再看arr当然能看到变化。但注意只改变量“指向”是不行的public static void change(int[] data) { data new int[]{9, 9, 9}; // 只是让data指向新数组arr的指向没动 }调用完之后arr依然是[1, 2, 3]。用生活化的比喻引用类型传参就像把家里的地址写在纸条上撕一张复印件给快递员。快递员拿着复印件能找到你家甚至能帮你动一下门口的花盆。但他就算把纸条上的地址全涂掉你的家也不会位移。方法内“换对象”就是改纸条外部完全感知不到。3.4 String的一个特例和一道高频面试题还有一个面试高频点String是引用类型但方法内对String的修改外部也看不到。public class Test { public static void main(String[] args) { String s hello; append(s); System.out.println(s); // 输出 hello } public static void append(String str) { str str !!!; // 产生新字符串对象str指向新对象 } }原因是String不可变。str !!!会生成一个新的String对象然后赋值给局部变量str而s还是指向原来的hello。本质和“引用变量重新指向新对象外部看不到”是同一个道理。顺带一个实操判断方法以后遇到“方法能不能改到外部数据”的题不要死记按三步走参数是基本类型吗是——外部不会变。参数是引用类型吗是——看方法内是“修改对象的属性/元素”还是“给参数重新赋值”。前者外部变后者不变。参数是String吗是——因为不可变外部不会变。把这三步练熟参数传递相关的笔试和面试题基本能拿下了。4. 方法重载与递归同名方法的匹配规则和自己调用自己的边界4.1 重载的本质同名不同参重载Overload是指同一个类里可以定义多个同名方法但它们的参数列表必须不同。参数不同包括参数个数不同、参数类型不同、参数顺序不同。满足其一即可。public class Calculator { public static int add(int a, int b) { return a b; } public static int add(int a, int b, int c) { return a b c; } public static double add(double a, double b) { return a b; } }调用add(1, 2)是匹配到第一个方法add(1, 2, 3)匹配到第二个add(1.0, 2.0)匹配到第三个。这种设计的价值在于调用方不用记住“整数加法方法”和“小数加法方法”分别叫什么名字统一叫addJava会自动匹配合适的版本。日常开发里的println、String.valueOf本质上也都是重载家族的典型。4.2 为什么重载不能只看返回值一个高频报错现场有人先写了int add(int a, int b)又写了String add(int a, int b)想“重载”结果编译直接报“重复方法”。因为编译器在解析调用时是看方法名和参数列表来定位方法的返回值类型不参与匹配。道理很简单如果只有返回值类型不同调用add(1, 2)时编译器根本不知道该选int版还是String版。调用方可以忽略返回值那么这两个方法对调用方来说就完全无法区分。所以只有返回值不同而参数列表相同不构成重载。顺带区分一下重载和重写Override重载发生在同一个类里多个方法同名不同参是编译期行为重写发生在父子类之间子类方法签名与父类方法完全一致是运行期多态的体现。面试被问到“Overload和Override的区别”先说清楚“一个同类同名不同参、一个父子类同签名”再说一个编译期一个运行期基本就稳了。4.3 递归先把出口写好再写调用递归就是方法在自己方法体内调用自己。最经典的例子是阶乘public static int factorial(int n) { if (n 1) { return 1; } return n * factorial(n - 1); }factorial(5)的展开过程是factorial(5) 5 * factorial(4) 5 * (4 * factorial(3)) 5 * (4 * (3 * factorial(2))) 5 * (4 * (3 * (2 * factorial(1)))) 5 * (4 * (3 * (2 * 1))) 120递归最重要的就是出口条件也就是“不再调用自己”的那个分支。我把这个分支叫做“刹车”。每次递归调用都必须向着“刹车”靠近否则就会出现无限循环调用最终栈溢出StackOverflowError。一个比较隐蔽的坑是出口条件写错。比如我见过有人写n 0才返回但调用factorial(0)时卡在了n 1永远不满足直接栈溢出。写递归方法我的习惯是先写出口那一行再写递归调用那一行这样能从结构上保证“刹车”存在。4.4 递归不是万能的什么时候该换成循环递归解决的是“问题能拆成同类型子问题”的场景比如遍历目录树、解析JSON嵌套结构、树的深度优先搜索。但递归有个代价每次调用都要压栈深度太大会栈溢出。以斐波那契数列为例教科书式递归public static long fib(int n) { if (n 2) return 1; return fib(n - 1) fib(n - 2); }算fib(50)会慢到怀疑人生因为大量重复计算。fib(45)被反复计算了无数次时间复杂度是恐怖的指数级。这种时候用循环动态规划思想反而更清晰public static long fib(int n) { if (n 2) return 1; long a 1, b 1; for (int i 3; i n; i) { long temp a b; a b; b temp; } return b; }我的建议是面对树形结构和嵌套递归的天然场景优先用递归面对“数列递推”和“单纯循环能解决”的场景别为了炫技硬用递归。工程代码里可读性和稳定性比“写法酷”重要得多。如果确实要递归又担心深度可以考虑用显式的栈来模拟递归过程风险会小很多。5. 方法设计里容易踩的坑命名、拆分、返回值与参数设计的实战经验5.1 命名方法名必须能回答“我干什么”Java方法命名规范是小驼峰第一个单词动词开头比如getUserById、sendEmail、calculateTotalPrice。命名里的动词越具体越好像do、deal、handle这种“万能词”建议少用因为你看到doSomething根本不知道它到底做了什么。我以前代码评审时遇过一个真实案例新同事写了个方法叫syx说是“所有学生的拼音首字母”全组人对着这个名字猜了十分钟。方法名在团队里就是自带的文档宁可长一点、啰嗦一点不能让人猜。还有一次见到updateAndSave和update两个方法其实前者内部做了保存、后者也做了保存两个名字没有任何区分度。看到这种命名的第一反应就是先停下来重新梳理方法职责。一个实用的复查方法写完方法回头读一遍名字如果方法名描述的行为和实现有出入比如叫getUserById但内部条件没传参却查了全表这就是误导性命名必须改。5.2 拆分一个方法只做一件可以命名的事如果方法名里出现“And”或“和”字比如processAndSave、validateAndNotify大概率这个方法干了不止一件事。拆分的核心标准是能否用一句话说清这个方法做什么。能——就保持不能——就拆。拆的时候按“步骤”拆这个思路很实用入参校验、核心计算、结果转换、持久化操作各抽一个方法。举个例子一个注册方法如果同时做了“校验用户名是否合法”“校验用户名是否重复”“加密密码”“插入数据库”四个职责捏在一个方法里任何一个环节出错整个方法都是黑盒。拆开之后每个方法都短小清晰单元测试也好写。但“一个方法只做一件事”也不是教条。如果两个步骤密切相关、几乎不可能单独复用强行拆开反而让调用链啰嗦。我一般看两个硬指标方法体超过50行或者嵌套层数超过3层就必须考虑拆分。反过来二三十行、逻辑清晰没必要为了拆而拆。5.3 返回值什么时候该抛异常返回值的处理方式直接影响代码健壮性。先说最简单的原则方法没有可返回的结果就用void有结果就声明对应类型遇到异常情况别动不动返回什么都没有的null。我见过太多因为方法返回null而引发的空指针事故。比如一个findUserById方法查到用户返回用户对象查不到返回null。调用方写user.getName()时一旦用户不存在直接NPE。后来我把这种“查不到”的行为改成抛异常public static User findById(int id) { User user userDao.findById(id); if (user null) { throw new IllegalArgumentException(用户不存在: id); } return user; }这样调用方就不会傻傻往下走。当然工程上也有另一种思路如果“查不到”是正常业务分支用Optional 或者约定返回null都可以关键是团队必须统一规范不能同一套代码里今天返回null明天抛异常。我的个人习惯是“不应该发生”的情况抛异常“可能发生且需要走业务分支”的情况用Optional或null并明确在方法注释里写清楚。5.4 参数设计超过5个就考虑封装方法参数不仅影响调用体验也影响扩展性。当一个方法参数超过5个或者参数之间关系紧密时就该封装成对象了。对比一下一个是散装参数public static void createOrder(String userId, String productId, int quantity, double price, String address, String phone) { // ... }调用方要精确记住每个位置的类型和含义写错位置编译器都不一定能发现。另一个是对象参数public class OrderRequest { private String userId; private String productId; private int quantity; private double price; private String address; private String phone; // getter/setter 省略 } public static void createOrder(OrderRequest request) { // ... }调用方先构造一个OrderRequest再传给方法参数的含义一目了然。以后加字段比如加“收货人姓名”只需在OrderRequest里加一个属性方法签名不用动。这在日常需求迭代里特别省心。还有一个容易忽略的实践参数类型尽量用接口而不是具体实现。比如参数写List 而不是ArrayList 这样调用方传LinkedList、Arrays.asList返回的List都可以方法内部也只依赖List接口的方法不依赖ArrayList特有能力耦合度更低。这算一种面向接口编程的体现从方法参数就能看出一个开发者的设计意识。5.5 可变参数一个语法糖和它的限制可变参数Varargs让你能接收不定数量的参数public static int sum(int... numbers) { int total 0; for (int num : numbers) { total num; } return total; }调用时sum(1, 2, 3)、sum()、sum(5)都可以。可变参数本质上是数组的语法糖编译后int... numbers会被当成int[] numbers处理。所以sum里直接用增强for循环遍历没问题。使用时有三个限制必须记住可变参数只能放在参数列表最后面比如void test(String name, int... nums)合法但void test(int... nums, String name)编译失败一个方法最多只有一个可变参数可变参数可能接收到null循环前最好判空处理。最后一个限制我是亲身踩过坑的。业务上约定调用方传空数组表示“不传参数”但有一次上游服务反序列化后往这里传了个null方法一进入for循环直接NPE。后来我在方法入口加了一行判断把null当成空数组处理问题才彻底解决。如果你的方法会被外部系统调用入口判空几乎是必须的别把“调用方一定懂规矩”当默认设定。6. 写在最后把方法学透Java才算真正入门方法这一章是很多人从“能写代码”到“会写代码”的转折点。前面学的都是零散语法方法开始教你如何组织代码结构。我能给的三条练习建议第一找之前写过的一个几百行的main方法程序强制拆成至少5个方法每个方法只做一件事第二写一个工具类用重载处理不同类型参数比如整数、小数、字符串分别提供同名方法第三找一道目录遍历或树形结构的题目分别用递归和栈两种方式实现对比两种写法的代码量和运行过程。我自己的体会是方法设计得好不好看两件事就知道方法名能不能不用注释就说清职责方法体有没有一条清晰的逻辑主线。如果你写完一个方法还需要大段注释来解释“它到底干了啥”那大概率这个方法的拆分还不够好。最后分享一个我自己实践很久的小习惯每次写完一个方法回头问自己三个问题——别人只看方法名能猜到它在做什么吗参数是不是还需要调用方做额外的类型转换或拆解如果需求未来发生变化这个方法的改动范围是不是足够集中三个问题都回答得清楚这个方法基本就过关了。把这套基本功打扎实后面无论学面向对象、集合框架还是并发编程你都会发现一切都建立在“会写方法”这个地基上。 
长河君 · 2026/9/28 19:00:22 · 阅读 1.2k Java方法入门到进阶：参数传递、重载递归与设计实践
如果你问我Java初学者的分水岭在哪里我的答案永远是方法。变量、运算符、if、for循环这些都是零件而方法教你怎样把零件组装成模块让你的程序第一次拥有结构。我带过不少新人在学方法之前写代码都是“叙事体”——main方法从头写到尾一屏塞不下改一个逻辑要找半天。学会方法之后代码才真正变得能维护、能复用、能给别人看。这篇文章从定义、调用、参数传递一路讲到重载和递归最后分享一些我在实际代码评审里反复强调的设计原则。不管你是刚学Java的在校生还是工作后想补基础的转行者这套思路应该都能帮到你。1. 为什么代码非要拆成方法一段“面条式”代码的重构实录1.1 一个典型的main方法膨胀现场很多初学者写程序习惯是“从头写到尾”。比如一个学生成绩处理程序需求很简单录入5个学生成绩算平均分再找最高分。新手版本往往长这样import java.util.Scanner; public class Test { public static void main(String[] args) { Scanner sc new Scanner(System.in); int[] scores new int[5]; for (int i 0; i scores.length; i) { scores[i] sc.nextInt(); } int sum 0; for (int i 0; i scores.length; i) { sum scores[i]; } double avg sum / 5.0; System.out.println(平均分: avg); int max scores[0]; for (int i 1; i scores.length; i) { if (scores[i] max) { max scores[i]; } } System.out.println(最高分: max); } }这段代码功能完全正确但问题也肉眼可见所有逻辑统统挤在main里中间没有一处停顿。如果明天需求改成“录入10个学生成绩”那么循环、平均分的除数和数组长度都要跟着改。要是这段逻辑还被复制了几份改起来就是灾难。这就是典型的“面条式代码”像一碗面条一样拉出来一根带出一堆。1.2 拆完之后的样子用方法重构后main方法变得非常“克制”import java.util.Scanner; public class Test { public static void main(String[] args) { Scanner sc new Scanner(System.in); int[] scores new int[5]; for (int i 0; i scores.length; i) { scores[i] sc.nextInt(); } System.out.println(平均分: average(scores)); System.out.println(最高分: max(scores)); } // 计算平均分接收成绩数组返回double结果 public static double average(int[] scores) { int sum 0; for (int score : scores) { sum score; } return sum / (double) scores.length; } // 找出最高分接收成绩数组返回int结果 public static int max(int[] scores) { int max scores[0]; for (int score : scores) { if (score max) { max score; } } return max; } }现在main方法只做三件事录入数据、调average、调max。计算平均分的细节被关进了average方法里找最高分的细节关进了max方法里。以后哪个功能要复用同样逻辑直接一行调用就行不用再把循环抄一遍。1.3 方法最核心的价值复用与抽象方法解决的两个核心问题第一个是复用第二个是抽象。复用很好理解一段逻辑写一次调用无数次。但抽象往往被新手忽略。当我写好average方法后调用方根本不需要关心“平均分怎么算出来的”只需要知道“传入成绩数组就能拿回平均分”。这就是把复杂问题拆成小问题每个小问题只通过输入输出去理解。我在实际教学里判断一个方法拆得好不好只看两件事第一main方法能不能在5句话内说清楚整个程序的流程第二每个方法的名字能不能直接回答“这个方法干嘛的”。如果方法名要想两秒才说得清说明这个方法的职责还不够专一。这个标准从第一天写方法开始就可以养。2. 方法定义与调用语法骨架、执行流程和容易看漏的细节2.1 方法签名里每一部分都是什么意思完整的方法定义长这样public static int add(int a, int b) { return a b; }一个方法签名由几个部分组成缺一不可组成例子作用访问修饰符public控制谁能调用public是公开private是私有静态修饰符static有它属于类没它属于对象返回值类型int方法计算完返回什么类型的值void表示什么都不返回方法名add调用时的标识遵循小驼峰命名参数列表int a, int b调用时需要传入的数据每个参数都必须声明类型方法体return a b;具体执行的逻辑调用时代码就很简单了int result add(3, 5); // 3和5是实参 System.out.println(result); // 8这里需要分清一个几乎所有面试都会问到的基础概念形参和实参。定义方法时写的int a、int b叫形参形式参数它们是占位符调用方法时传的3、5叫实参实际参数它们的值在调用发生时会复制给形参。搞清楚这个概念参数传递那节就不会迷糊了。2.2 从调用栈理解“方法调用”发生了什么方法调用背后是JVM的栈帧机制。每次调用一个方法JVM会为这次调用分配一块栈帧里面存放局部变量和临时计算数据方法执行完栈帧出栈里面的数据全部失效。这就是为什么方法内定义的局部变量方法一结束就“消失”了。我在讲这个点的时候喜欢做一个比喻每次方法调用就像开一个临时会议室进会议室时可以带一些资料形参在会议室里可以做自己的事局部变量会议结束人走灯灭所有资料清空。主方法开着的会议不受影响因为各开各的会。有个初学者经常踩的坑在main里定义了一个变量想在一个方法里直接访问它结果编译报错“找不到符号”。原因就是两个方法各占各的栈帧main里的变量在main的栈帧里根本不在子方法的栈帧里。要让方法访问main里的数据只能通过参数传进去通过返回值拿回来。2.3 static最常被问的“我到底要不要加”讲方法绕不开static。我遇到最多的问题是“为什么main方法必须static我写的方法要不要加”main是程序入口JVM启动时还没有创建任何对象所以main必须是静态的由类直接调用。而普通方法加不加static取决于它是否依赖于对象的成员。方法里要访问实例变量如this.name就不能加static方法只依赖传入的参数不访问任何成员变量加static反而更合适——可以直接用类名调用比如Math.abs()、Arrays.sort()一眼就知道这是工具方法。从设计角度看static方法属于“面向过程”的工具函数虽然Java是面向对象语言但工具类里放静态方法非常常见。我自己写项目时抽出来的纯计算逻辑不涉及任何成员属性都会加static既省去创建对象的麻烦也明确表达“这个方法与对象状态无关”。如果方法用到对象的属性那就不加static让它作为实例方法存在。还有一个容易忽略的细节非static方法可以调用static方法但static方法不能直接调用非static方法。原因很简单——static方法执行时可能还没有任何对象存在而非static方法必须依附于对象。所以你在main方法里直接写一个非static方法的名字编译会直接报错。很多人第一次见到这个错就懵了其实就是这个原因。3. 参数传递的真相Java只有值传递但引用类型会“改到对象”3.1 先记住结论所有参数都是复制Java官方的说法是Java只有值传递没有引用传递。这个“值”要分两种情况看。基本类型变量存的是值本身传递时复制值引用类型变量存的是对象的地址传递时复制地址。所以准确地说一切传递都是复制只是复制的“东西”不同。这个点之所以绕是因为新手会直观地把“引用类型”理解成“可以直接改外面的变量”。实际上引用类型变量在赋值、传参时复制的是指向对象的地址而不是对象本身。理解了这个底层逻辑很多“诡异”的现象都能解释。3.2 基本类型交换两个变量的经典翻车现场看这段代码public class Test { public static void main(String[] args) { int a 1; int b 2; swap(a, b); System.out.println(a a , b b); // 输出 a1, b2 } public static void swap(int x, int y) { int temp x; x y; y temp; } }很多人第一次写swap方法时看到输出没变整个人都傻掉。原因其实很简单调用swap(a, b)时是把a的值1复制给了x把b的值2复制给了y。swap方法里交换的是x、y和main里的a、b毫无关系。方法结束后x、y随栈帧一起销毁a和b还是原来的1、2。要在Java里实现“交换两个变量的值”基本类型变量传参是做不到的。常见做法两种一是让方法返回交换后的结果由调用方接收二是把a、b封装成对象再传拿对象的成员来交换。后者其实已经沾到引用类型的边了。3.3 引用类型改得到对象但改不了指向看数组的例子import java.util.Arrays; public class Test { public static void main(String[] args) { int[] arr {1, 2, 3}; change(arr); System.out.println(Arrays.toString(arr)); // 输出 [10, 2, 3] } public static void change(int[] data) { data[0] 10; // 通过复制来的地址修改了堆里同一个数组对象 } }输出变成了[10, 2, 3]。原因arr存的是数组对象在堆里的地址调用change(arr)时把地址复制给datadata和arr指向同一个数组对象。data[0] 10是顺着地址找到堆里的对象修改了它的第一个元素。调用方再看arr当然能看到变化。但注意只改变量“指向”是不行的public static void change(int[] data) { data new int[]{9, 9, 9}; // 只是让data指向新数组arr的指向没动 }调用完之后arr依然是[1, 2, 3]。用生活化的比喻引用类型传参就像把家里的地址写在纸条上撕一张复印件给快递员。快递员拿着复印件能找到你家甚至能帮你动一下门口的花盆。但他就算把纸条上的地址全涂掉你的家也不会位移。方法内“换对象”就是改纸条外部完全感知不到。3.4 String的一个特例和一道高频面试题还有一个面试高频点String是引用类型但方法内对String的修改外部也看不到。public class Test { public static void main(String[] args) { String s hello; append(s); System.out.println(s); // 输出 hello } public static void append(String str) { str str !!!; // 产生新字符串对象str指向新对象 } }原因是String不可变。str !!!会生成一个新的String对象然后赋值给局部变量str而s还是指向原来的hello。本质和“引用变量重新指向新对象外部看不到”是同一个道理。顺带一个实操判断方法以后遇到“方法能不能改到外部数据”的题不要死记按三步走参数是基本类型吗是——外部不会变。参数是引用类型吗是——看方法内是“修改对象的属性/元素”还是“给参数重新赋值”。前者外部变后者不变。参数是String吗是——因为不可变外部不会变。把这三步练熟参数传递相关的笔试和面试题基本能拿下了。4. 方法重载与递归同名方法的匹配规则和自己调用自己的边界4.1 重载的本质同名不同参重载Overload是指同一个类里可以定义多个同名方法但它们的参数列表必须不同。参数不同包括参数个数不同、参数类型不同、参数顺序不同。满足其一即可。public class Calculator { public static int add(int a, int b) { return a b; } public static int add(int a, int b, int c) { return a b c; } public static double add(double a, double b) { return a b; } }调用add(1, 2)是匹配到第一个方法add(1, 2, 3)匹配到第二个add(1.0, 2.0)匹配到第三个。这种设计的价值在于调用方不用记住“整数加法方法”和“小数加法方法”分别叫什么名字统一叫addJava会自动匹配合适的版本。日常开发里的println、String.valueOf本质上也都是重载家族的典型。4.2 为什么重载不能只看返回值一个高频报错现场有人先写了int add(int a, int b)又写了String add(int a, int b)想“重载”结果编译直接报“重复方法”。因为编译器在解析调用时是看方法名和参数列表来定位方法的返回值类型不参与匹配。道理很简单如果只有返回值类型不同调用add(1, 2)时编译器根本不知道该选int版还是String版。调用方可以忽略返回值那么这两个方法对调用方来说就完全无法区分。所以只有返回值不同而参数列表相同不构成重载。顺带区分一下重载和重写Override重载发生在同一个类里多个方法同名不同参是编译期行为重写发生在父子类之间子类方法签名与父类方法完全一致是运行期多态的体现。面试被问到“Overload和Override的区别”先说清楚“一个同类同名不同参、一个父子类同签名”再说一个编译期一个运行期基本就稳了。4.3 递归先把出口写好再写调用递归就是方法在自己方法体内调用自己。最经典的例子是阶乘public static int factorial(int n) { if (n 1) { return 1; } return n * factorial(n - 1); }factorial(5)的展开过程是factorial(5) 5 * factorial(4) 5 * (4 * factorial(3)) 5 * (4 * (3 * factorial(2))) 5 * (4 * (3 * (2 * factorial(1)))) 5 * (4 * (3 * (2 * 1))) 120递归最重要的就是出口条件也就是“不再调用自己”的那个分支。我把这个分支叫做“刹车”。每次递归调用都必须向着“刹车”靠近否则就会出现无限循环调用最终栈溢出StackOverflowError。一个比较隐蔽的坑是出口条件写错。比如我见过有人写n 0才返回但调用factorial(0)时卡在了n 1永远不满足直接栈溢出。写递归方法我的习惯是先写出口那一行再写递归调用那一行这样能从结构上保证“刹车”存在。4.4 递归不是万能的什么时候该换成循环递归解决的是“问题能拆成同类型子问题”的场景比如遍历目录树、解析JSON嵌套结构、树的深度优先搜索。但递归有个代价每次调用都要压栈深度太大会栈溢出。以斐波那契数列为例教科书式递归public static long fib(int n) { if (n 2) return 1; return fib(n - 1) fib(n - 2); }算fib(50)会慢到怀疑人生因为大量重复计算。fib(45)被反复计算了无数次时间复杂度是恐怖的指数级。这种时候用循环动态规划思想反而更清晰public static long fib(int n) { if (n 2) return 1; long a 1, b 1; for (int i 3; i n; i) { long temp a b; a b; b temp; } return b; }我的建议是面对树形结构和嵌套递归的天然场景优先用递归面对“数列递推”和“单纯循环能解决”的场景别为了炫技硬用递归。工程代码里可读性和稳定性比“写法酷”重要得多。如果确实要递归又担心深度可以考虑用显式的栈来模拟递归过程风险会小很多。5. 方法设计里容易踩的坑命名、拆分、返回值与参数设计的实战经验5.1 命名方法名必须能回答“我干什么”Java方法命名规范是小驼峰第一个单词动词开头比如getUserById、sendEmail、calculateTotalPrice。命名里的动词越具体越好像do、deal、handle这种“万能词”建议少用因为你看到doSomething根本不知道它到底做了什么。我以前代码评审时遇过一个真实案例新同事写了个方法叫syx说是“所有学生的拼音首字母”全组人对着这个名字猜了十分钟。方法名在团队里就是自带的文档宁可长一点、啰嗦一点不能让人猜。还有一次见到updateAndSave和update两个方法其实前者内部做了保存、后者也做了保存两个名字没有任何区分度。看到这种命名的第一反应就是先停下来重新梳理方法职责。一个实用的复查方法写完方法回头读一遍名字如果方法名描述的行为和实现有出入比如叫getUserById但内部条件没传参却查了全表这就是误导性命名必须改。5.2 拆分一个方法只做一件可以命名的事如果方法名里出现“And”或“和”字比如processAndSave、validateAndNotify大概率这个方法干了不止一件事。拆分的核心标准是能否用一句话说清这个方法做什么。能——就保持不能——就拆。拆的时候按“步骤”拆这个思路很实用入参校验、核心计算、结果转换、持久化操作各抽一个方法。举个例子一个注册方法如果同时做了“校验用户名是否合法”“校验用户名是否重复”“加密密码”“插入数据库”四个职责捏在一个方法里任何一个环节出错整个方法都是黑盒。拆开之后每个方法都短小清晰单元测试也好写。但“一个方法只做一件事”也不是教条。如果两个步骤密切相关、几乎不可能单独复用强行拆开反而让调用链啰嗦。我一般看两个硬指标方法体超过50行或者嵌套层数超过3层就必须考虑拆分。反过来二三十行、逻辑清晰没必要为了拆而拆。5.3 返回值什么时候该抛异常返回值的处理方式直接影响代码健壮性。先说最简单的原则方法没有可返回的结果就用void有结果就声明对应类型遇到异常情况别动不动返回什么都没有的null。我见过太多因为方法返回null而引发的空指针事故。比如一个findUserById方法查到用户返回用户对象查不到返回null。调用方写user.getName()时一旦用户不存在直接NPE。后来我把这种“查不到”的行为改成抛异常public static User findById(int id) { User user userDao.findById(id); if (user null) { throw new IllegalArgumentException(用户不存在: id); } return user; }这样调用方就不会傻傻往下走。当然工程上也有另一种思路如果“查不到”是正常业务分支用Optional 或者约定返回null都可以关键是团队必须统一规范不能同一套代码里今天返回null明天抛异常。我的个人习惯是“不应该发生”的情况抛异常“可能发生且需要走业务分支”的情况用Optional或null并明确在方法注释里写清楚。5.4 参数设计超过5个就考虑封装方法参数不仅影响调用体验也影响扩展性。当一个方法参数超过5个或者参数之间关系紧密时就该封装成对象了。对比一下一个是散装参数public static void createOrder(String userId, String productId, int quantity, double price, String address, String phone) { // ... }调用方要精确记住每个位置的类型和含义写错位置编译器都不一定能发现。另一个是对象参数public class OrderRequest { private String userId; private String productId; private int quantity; private double price; private String address; private String phone; // getter/setter 省略 } public static void createOrder(OrderRequest request) { // ... }调用方先构造一个OrderRequest再传给方法参数的含义一目了然。以后加字段比如加“收货人姓名”只需在OrderRequest里加一个属性方法签名不用动。这在日常需求迭代里特别省心。还有一个容易忽略的实践参数类型尽量用接口而不是具体实现。比如参数写List 而不是ArrayList 这样调用方传LinkedList、Arrays.asList返回的List都可以方法内部也只依赖List接口的方法不依赖ArrayList特有能力耦合度更低。这算一种面向接口编程的体现从方法参数就能看出一个开发者的设计意识。5.5 可变参数一个语法糖和它的限制可变参数Varargs让你能接收不定数量的参数public static int sum(int... numbers) { int total 0; for (int num : numbers) { total num; } return total; }调用时sum(1, 2, 3)、sum()、sum(5)都可以。可变参数本质上是数组的语法糖编译后int... numbers会被当成int[] numbers处理。所以sum里直接用增强for循环遍历没问题。使用时有三个限制必须记住可变参数只能放在参数列表最后面比如void test(String name, int... nums)合法但void test(int... nums, String name)编译失败一个方法最多只有一个可变参数可变参数可能接收到null循环前最好判空处理。最后一个限制我是亲身踩过坑的。业务上约定调用方传空数组表示“不传参数”但有一次上游服务反序列化后往这里传了个null方法一进入for循环直接NPE。后来我在方法入口加了一行判断把null当成空数组处理问题才彻底解决。如果你的方法会被外部系统调用入口判空几乎是必须的别把“调用方一定懂规矩”当默认设定。6. 写在最后把方法学透Java才算真正入门方法这一章是很多人从“能写代码”到“会写代码”的转折点。前面学的都是零散语法方法开始教你如何组织代码结构。我能给的三条练习建议第一找之前写过的一个几百行的main方法程序强制拆成至少5个方法每个方法只做一件事第二写一个工具类用重载处理不同类型参数比如整数、小数、字符串分别提供同名方法第三找一道目录遍历或树形结构的题目分别用递归和栈两种方式实现对比两种写法的代码量和运行过程。我自己的体会是方法设计得好不好看两件事就知道方法名能不能不用注释就说清职责方法体有没有一条清晰的逻辑主线。如果你写完一个方法还需要大段注释来解释“它到底干了啥”那大概率这个方法的拆分还不够好。最后分享一个我自己实践很久的小习惯每次写完一个方法回头问自己三个问题——别人只看方法名能猜到它在做什么吗参数是不是还需要调用方做额外的类型转换或拆解如果需求未来发生变化这个方法的改动范围是不是足够集中三个问题都回答得清楚这个方法基本就过关了。把这套基本功打扎实后面无论学面向对象、集合框架还是并发编程你都会发现一切都建立在“会写方法”这个地基上。