先说一个很多同学容易忽略的事实在 SDUT 的 OJ 平台上凡是标题里带“函数题”三个字的 Java 题目和你在牛客、力扣上刷的算法题是两个玩法。这类题往往不给完整需求文档而是给一段已经写好的类框架让你补全某一个方法。你提交的代码甚至不需要包含 main 方法只要方法签名和判题代码对得上就能判对。但正是因为这样它踩坑的方式特别多——类名、方法名、参数顺序、返回类型任何一个字母写错直接编译失败。这篇文章我把这类题从头到尾的考点、常踩的坑和一套可以复用的模板给你梳理出来适合那些刚学到 Java 面向对象、正在刷常用类函数题的初学者也适合已经写了不少题但总是卡在细枝末节上的同学。1. 函数题的真面目你在补全一个被调用的方法1.1 从“写完整程序”到“补全方法”场景差异很多同学第一次见到“函数题”三个字会愣一下觉得这不就是编程题吗其实差别很大。普通编程题要求你从零开始写一个完整程序包括 import、main 方法、输入输出逻辑全部自己搞定而函数题是提前把外部框架搭好了你的任务只是实现其中一个方法。打个比方这就像你去一家餐厅应聘不是让你从买菜、洗菜、切菜、炒菜全流程负责而是只需要你做“炒菜”这一步配菜已经码好放在灶台边上了。SDUT 平台上的 Java 函数题题目描述里通常会明确写出“请实现 xxx 方法该方法的功能是……”有的还会给出一个方法签名比如public static String getName(String id)。你的任务就是补全方法体。更关键的是判题系统会用它自己的测试代码来调用你这个方法这些测试代码你看不到但你的方法签名必须和题目描述里给的一模一样。实际刷题时我见过不少同学在这上面栽跟头方法名少写一个字母、参数类型写错、返回类型写成 void、静态方法忘了加 static、权限修饰符从 public 改成了 private。这些错误在本地 IDE 里可能不会立刻暴露因为你自己写 main 方法测试时怎么调都能通过但一旦提交判题系统的编译阶段就直接失败了。所以函数题的第一条铁律是签名不是参考是契约。1.2 面向对象视角契约思维与封装函数题出现在“Java 面向对象”这个章节里本身就很有深意。面向对象的核心之一就是封装封装意味着对外暴露接口、隐藏实现细节。函数题恰恰在训练这一点调用方只关心你的方法输入什么、输出什么不关心你内部用 for 循环还是用 stream也不关心你定义了几个临时变量。我经常跟学生说做函数题要建立“被调用者心态”。你不是在写一个自嗨的程序而是在实现一个别人看不见但一定会调用的接口。比如题目让你写一个方法统计字符串中单词的数量你的方法可能被传入空字符串、全空格字符串、带标点符号的字符串、甚至是 null。如果你只测了正常情况就提交判题数据分分钟教你做人。这种心态其实非常接近企业里的真实开发。后端同学写一个接口给前端调用你定义了参数和返回结构就不能随意改动你做底层工具类给别人复用就必须考虑各种异常输入。所以函数题表面上是在考 String、StringBuilder 这些常用类的 API实际上是在考察你有没有面向对象的契约意识。理解了这一层再去刷题思路会清晰很多。2. 常用类考点拆解函数题爱考的其实就那么多2.1 String 类equals 和 这一关必须过函数题里出现频率最高的类就是 String。字符串判断相等、截取、替换、分割、大小写转换翻来覆去就是这些操作。但有一个知识点是出题人非常喜欢埋雷的equals和的区别。很多学生到现在还背不清楚比较的是引用地址equals比较的是内容。这话说起来简单放在函数题里就完全不是一回事。假设题目要求判断两个字符串是否相等你写了if (a b)本地测的时候恰好两个字符串都是字面量赋值Java的常量池机制让它们指向同一个对象结果判断为 true提交上去却错了。为什么因为判题数据里的字符串可能是通过new String(...)或者从某个方法返回值拿到的它们的内容一样但地址不同就直接返回 false。这里有两条实操建议。第一条凡是比较字符串内容一律用equals不要有任何侥幸心理。第二条如果被比较的一方是字面量常量把常量写在前面写成expected.equals(input)这样即使input是 null 也不会抛空指针只会返回 false。这是我在改学生代码时最喜欢强调的一个小细节看起来不起眼但在函数题里能帮你稳稳多拿几个测试点。String 还有一个高频考点是charAt()和substring()的边界问题。很多函数题会让遍历字符串里的每个字符比如判断字符类型、转换大小写、统计字符个数。这里要注意charAt(i)的下标是从 0 到length()-1一不留神写成 length()就会抛StringIndexOutOfBoundsException。另一个是substring(beginIndex, endIndex)它是左闭右开的substring(0, 2)取的是第 1 个和第 2 个字符不包括第 3 个初学者经常在这里差一个数。我的习惯是遇到这种题目先在草稿纸上写下索引边界宁可慢几秒也不要反复提交试错。2.2 StringBuilder循环拼接字符串的重灾区函数题里凡是涉及“拼接字符串”这个需求我都会直接建议用StringBuilder。你可能会问直接用拼接不行吗下面这行代码在 Java 里语法上完全合法String result ; for (int i 0; i n; i) { result data[i]; }但你要知道Java 的 String 是不可变对象每一次都会创建一个新的 String 对象然后把旧字符串的内容复制过去。如果循环 1000 次你就创建了 1000 个中间字符串对象前面的 999 个都成了垃圾等着 GC 来回收。在 OJ 平台上数据量一大这种做法轻则拖慢运行时间重则触发内存问题直接超时或超内存。用StringBuilder就不一样了它内部是一个可变的字符数组append()方法直接在数组末尾追加不需要反复创建新对象。我这里给一个典型写法StringBuilder sb new StringBuilder(); for (int i 0; i len; i) { sb.append(chars[i]); } return sb.toString();注意最后要调用toString()转换回 String因为方法返回值类型是 String。另外还有一个StringBuffer它是线程安全的方法上加了synchronized关键字但单线程场景下没必要用性能反而不如StringBuilder。函数题基本都是单线程判题所以默认选StringBuilder就够了。除了拼接StringBuilder的reverse()方法在“字符串反转”这类函数题里非常好用一行代码搞定比你手动写循环交换字符靠谱多了。还有setCharAt()方法可以修改指定位置的字符适合做“把某个位置的字符替换掉”之类的操作比先截取再拼接要干净得多。2.3 包装类、Math 与日期时间类容易被忽略的送分题常用类章节的另一个重要分支是包装类。Integer.parseInt(String)把字符串转成 intDouble.parseDouble(String)把字符串转成 double这俩在函数题里出镜率相当高。反过来String.valueOf(int)可以把 int 转成字符串比i 的方式更规范也不会触发编译器关于字符串拼接的警告。这里有一个坑要单独拿出来说Integer.parseInt遇到无法转换的字符串时会抛NumberFormatException。比如调用方传了一个12a进来如果你直接parseInt整个程序就崩了。判题数据里出现这种输入时通常题目要求你自己判断处理常见做法是先做校验或者用try-catch捕获异常后返回一个默认值。我在做这类函数题时会先看题目描述里有没有“输入保证为数字”这句话没有的话就要按异常输入来防御。Math类也是函数题常客。Math.round()四舍五入、Math.abs()取绝对值、Math.max()和Math.min()取较大较小值这些方法没有太多理解成本但有一个细节容易记混Math.round(11.5)返回 12Math.round(-11.5)返回 -11因为它的规则是“四舍五入”实际上是“向正无穷方向取最接近的整数”。如果题目明确要求“四舍五入到个位”用Math.round没问题如果要求“保留两位小数”需要配合DecimalFormat或者BigDecimal。日期时间类在函数题里出现的频率略低但一旦出现就是整套题里最容易慌的。传统的SimpleDateFormat是非线程安全的在单方法实现里虽然影响不大但我更推荐新的java.time包里的LocalDate、DateTimeFormatter。比如解析一个2024-01-15格式的日期用LocalDate.parse(input, DateTimeFormatter.ofPattern(yyyy-MM-dd))就可以了代码简洁也不容易出错。很多刚学到常用类的同学还没接触过这套新 API我建议提前了解一下面试题里也爱考新旧 API 的区别。3. 一道典型函数题的完整解题演示3.1 题目形式与读题步骤为了把上面的理论落到实地我模拟一道典型函数题来走一遍完整流程。题目描述大概是这样的请实现Main类中的capitalizeFirstLetter方法该方法接收一个字符串参数sentence返回一个新字符串要求将字符串中每个单词的首字母转为大写其余字母保持原样。单词之间可能有多个空格。如果传入字符串为null返回null。读这种题目千万不要直接上手写代码我先教你一个三步读题法。第一步圈出输入类型和返回类型。这里是接收 String返回 String说明方法签名大概率是public static String capitalizeFirstLetter(String sentence)。第二步圈出边界条件。题目明确写了“可能有多个空格”“传入 null 返回 null”这两条是隐藏的判题数据很可能就是区分及格和满分的分水岭。第三步圈出核心规则。“每个单词的首字母大写”这意味着你需要识别单词的边界而不是简单地调用toUpperCase()处理整个字符串。读题这步花两分钟写代码可能只要五分钟但很多同学把顺序搞反了拿起键盘就敲最后反复提交反复错白白消耗判题次数。我做这类题的经验是先在注释里把方法骨架和边界情况列出来再开始填空思路会清晰很多。3.2 代码实现与逐行注释直接用 StringBuilder 实现顺便演示一下前面说的知识点。完整代码如下public class Main { /** * 将字符串中每个单词的首字母转为大写其余保持不变。 * 单词由空白字符分隔多个连续空格按多个分隔符处理。 */ public static String capitalizeFirstLetter(String sentence) { // 边界条件null 直接返回 null if (sentence null) { return null; } StringBuilder sb new StringBuilder(); boolean needCapital true; for (int i 0; i sentence.length(); i) { char c sentence.charAt(i); // 遇到空白字符说明下一个非空白字符才可能是新单词的开头 if (Character.isWhitespace(c)) { sb.append(c); needCapital true; } else { // 单词开头则转大写否则原样保留 if (needCapital) { sb.append(Character.toUpperCase(c)); needCapital false; } else { sb.append(c); } } } return sb.toString(); } }这段代码的核心思路是用一个boolean needCapital标记状态遇到空白字符就置为 true遇到非空白字符时检查这个标记为 true 说明当前字符是一个新单词的首字母就转大写然后立刻标记为 false为 false 说明还在同一个单词内部保持原字符。这个用法叫“状态标记法”不用切割字符串也不用正则表达式时间和空间复杂度都是 O(n)在函数题里是最稳的方案。如果你非要处理多个空格这段代码天然支持因为连续空格也好单个空格也好每次遇到空白都会把标记设为 true但真正执行大写转换只会在下一个非空白字符到来时发生。这也解释了为什么题目强调“多个空格”不用怕状态标记法不会因为多余空格而出错。3.3 提交前的三处细节检查代码写完之后先别急着提交花三十秒做三个检查。第一检查方法签名。public static两个关键字都在不在方法名是不是capitalizeFirstLetter参数类型是不是String返回类型是不是String。我在 SDUT 上批改过很多次作业发现最大的编译失败原因是修饰符漏写。有些人写着写着把static丢了因为本地测试时通过创建对象来调用也可以但判题代码是直接用Main.capitalizeFirstLetter(...)来调用的没有static就编译不过。第二检查边界分支。sentence null的分支有没有写如果判题数据真的传了 null这一条不写直接就会空指针。再看空字符串的情况代码里 for 循环一次都不执行直接返回空字符串符合预期没问题。再看全是空格的情况循环里每个字符都是空白全部原样追加needCapital始终为 true返回的也是原字符串也符合预期。第三检查输出格式。函数题一般不需要你打印任何东西方法返回值本身就是判题依据。但有些平台变种会要求你在 main 方法里读入数据并输出这时候就要检查输出是否有额外的空格、换行。我见过不少学生把调试用的System.out.println留在代码里没删结果判题系统把调试输出也当成答案的一部分直接判错。提交前把调试输出全部删干净这是个好习惯。4. 常见错误与排查技巧实录4.1 编译期错误速查表函数题的编译错误是最容易排查的因为 OJ 系统会返回错误信息但很多初学者看不懂。我根据经验整理了一张高频编译错误对照表你下次遇到可以直接对号入座。OJ 返回信息真实原因解决方案找不到符号方法名或变量名拼写错误对照题目描述逐字检查方法签名类 X 是公共的应在文件 X.java 中声明一个 Java 文件里写了多个 public 类只保留一个 public 类其他类去掉 public无法将类 X 中的方法应用到给定类型参数数量或类型与方法签名不一致检查参数顺序和参数类型不兼容的类型返回类型和声明不一致检查方法声明处的返回类型需要返回 String 类型某个分支缺少 return 语句检查是否所有路径都有返回值这里有一个很多人不知道的细节Java 要求 public 类的名字必须和文件名一致。在 OJ 平台上判题系统一般用Main.java这个文件名来编译你提交的代码所以主类名必须叫Main。如果你提交的代码里写的是public class Test哪怕代码逻辑全对编译也会报错。这个错误在本地 IDE 里不会出现因为你新建文件时就可能叫别的名字所以提交前务必检查类名是不是Main。另一个容易忽略的是 import 语句。如果题目要求使用Scanner但你只写了import java.util.*;这没问题但如果你完全没写 import直接用Scanner编译就会报找不到符号。我建议在做题时把可能用到的包都列进 import比如java.util.*和java.io.*既能覆盖绝大多数情况也不会影响判题。4.2 运行期错误与输出格式问题编译通过了但判题错误这种情况更让人头疼因为系统可能只给你一个模糊的“答案错误”提示连哪个测试点挂了都不告诉你。这里需要你自己做排查。先说运行期异常。最常见的三种是NullPointerException、StringIndexOutOfBoundsException、ArrayIndexOutOfBoundsException。空指针通常发生在没有判断 null 就直接调用方法的情景下比如sentence.trim().isEmpty()这条链式调用如果sentence是 null还没执行到trim()就已经炸了。索引越界则多半是边界条件没想清楚比如字符串长度是 5你循环写成了i length()最后一次访问charAt(5)就越界了。还有一类异常是NumberFormatException出现频率也很高。题目要求你把字符串转成数字你直接用Integer.parseInt结果判题数据里混入了一个带空格的字符串比如 123parseInt并不总是能容忍前导空格不同版本 JDK 表现也可能有差异结果就抛异常了。我遇到这类问题时会先判断题目描述里是否声明了“输入保证合法”没声明的话就先用trim()处理一下再转换。再来看输出格式问题。这类问题通常发生在“函数题变体”——虽然大部分函数题不需要直接输出但有的题目会嵌套一个 main 方法让你输入输出。比如题目要求打印结果后换行你正好多打了一个空格判题系统用的是严格比对你输出的是Hello World标准答案是HelloWorld直接判错。这种问题排查起来最耗时间我的经验是先跑一遍样例把样例输入复制进去看输出用眼睛逐字符比对。在 OJ 上多次提交试错不如先把自己这关过了。4.3 一套实用的自查清单踩过这么多坑之后我总结出了一套提交前的固定检查流程。每次写完全部代码我会按这个顺序过一遍非常省心。类名是不是Main有没有多余的 public 类方法签名方法名每个字母都和题目一致吗权限是public吗需要static吗参数类型、个数、顺序对不对返回类型对吗import用到的类有没有导入通配符导入在简单题里更省心。边界条件null 处理了吗空字符串处理了吗极端输入全空格、超长字符串、负数、0处理了吗返回值每个分支都有 return 吗没有死循环吗调试痕迹System.out.println删干净了吗临时测试代码删了吗输入输出如果要打印结果格式和样例完全一致吗最后一行的换行符加了吗这套清单看着简单实际上每一条背后都有学生踩坑的案例。就拿“调试痕迹”这条来说我印象很深有一次一个学生代码逻辑全对但中间打印了一句调试的System.out.println(debug: result)提交了三次都判错最后帮他删掉这行再提交一次就过了。从此我自己写题也养成了习惯写完代码先体检式自查再提交基本一次通过率能到九成以上。我个人在实际操作中的体会是函数题的核心从来不是算法难度而是细致程度。它考核的是你在一个给定的上下文里能否按照约定把一个方法实现得正确、健壮且高效。刷这类题最有效的方法不是海量刷而是每做一道就认真分析一遍边界情况和方法签名错一次就把教训记到自查清单里。等你养成了这套习惯不只是 SDUT 的函数题以后在任何 OJ 平台、哪怕是在工作里写接口都能少走很多弯路。最后再分享一个小技巧如果连续两次提交都错在同一个奇怪的测试点上试着在不改变功能的前提下把循环遍历换成不同的实现方式比如用toCharArray()替代charAt()有时候能帮你避开 Java 版本或平台实现上的细微差异。希望这篇文章能帮你彻底整明白函数题到底怎么玩。
