企业官网建设流程全解析

OJ题目列表里躺着“sdut-Java面向对象-10 常用类（函数题）”这种题目时，很多人的第一反应是：函数题，补个方法而已，总比写完整程序简单吧？等你连着吃了几发“编译错误”和“答案错误”之后，就会改变这个想法。这种题表面上是补代码，实际上是在精准打击你对Java常用类的掌握程度。它考的是String的某个方法会不会用、StringBuilder和StringBuffer能不能在正确场景里选对、包装类的自动装箱拆箱有没有理解透，甚至还包括Math和日期时间类这些平常不太注意的边角知识。

今天我就拿这类题当切入口，把Java面向对象课程里“常用类”这张考卷拆开揉碎。无论你是正在和sdut这类在线练习平台的测评页较劲的大二学生，还是准备Java面试却被String、包装类问住的求职者，这篇都值得耐心看完。我会把考点清单、读题门道、解题套路和避坑经验全盘倒出来，最后还会用一个完整的函数题实例，演示从读题到提交的整套流程。

1. OJ函数题的本质与“常用类”考点的深层逻辑

1.1 函数题到底在考什么：补全方法，不是从零写系统

函数题是高校OJ、练习平台里很特殊的一类题型。它不会让你从main方法开始写完整程序，而是直接给出一个类框架，或者只给一个方法签名，让你把某个方法的函数体补全。听起来很轻巧，但它精确考核的是单一知识点，评测端也只认方法逻辑对不对，不关心你有没有多余代码。

这类题型的核心其实就三件事。第一件，读懂方法签名。方法名是什么、参数是什么类型、返回值是什么类型，这三个点直接决定了你要写什么代码。第二件，知道对应的知识点有哪些可用的工具方法。比如题目要求处理字符串，你得想到String类有startsWith、substring、indexOf这些方法，想到StringBuilder的append可以高效拼接。第三件，处理各种边界情况。null、空串、负数、空字符、极长输入……这些才是函数题真正的“答案错误”重灾区。

和完整的编程题相比，函数题放弃了输入输出格式的考察，也放弃了程序整体结构的考察，把所有注意力集中在“这个知识点你会不会用”上。老师在批改时无法看到你的思考过程，只通过隐藏测试用例来判断你的方法是否正确，这就要求你不仅会写主流程，还必须把各种异常输入都考虑周全。很多同学抱怨函数题比编程题还难，正是因为编程题偶尔还能靠输出结果的运气混过去，函数题却没有任何侥幸空间。

1.2 为什么“常用类”注定是函数题的常客

高校Java课程的推进顺序，基本都遵循一条主线：先讲基本语法和流程控制，再讲类和对象、封装集成多态，然后是抽象类和接口，紧接着就是String、包装类、Math、日期时间这类“常用类”。这个位置恰好处于面向对象语法学完、还没进入集合框架的过渡带，特别适合用短小精悍的函数题来检验阶段性学习成果。

从出题人的角度看，常用类就是一座“考点富矿”。String的方法数量多到可以单独出一轮填空题，包装类有自动装箱拆箱和缓存池这种经典陷阱，Math类有一堆静态方法适合做数值运算题，日期时间类虽然出题率稍低，但随便挑一个格式化规则就能让人头疼一批人。更关键的是，这些知识点不需要庞大的程序上下文，直接给出一个方法签名就能考，和函数题的天然适配度极高。

从学生的角度看，常用类是整个Java学习链条上“承上启下”的关键环节。如果这个阶段没有把String的不可变性理解透，没有把StringBuilder的拼接效率概念建立起来，后面学集合框架时会频繁碰壁，因为集合里最常见的操作就是toString输出、map的键比较、字符串与包装类之间的转换。我在辅导时见过太多学生卡在这种地方，与其说是集合没学会，不如说是常用类的底子松了。

多说一句，这些常用类知识和Java面试八股的重合度非常高。String为什么不可变、StringBuilder如何扩容、Integer的缓存范围是多少，都是企业面试里的老熟人。所以别小看OJ里这些看似机械的函数填空题，把它们做扎实了，等于提前给面试做了一轮浅层预热。

1.3 一道标准函数题的题面结构：先看签名，再看注释，最后看样例

一个标准函数题的题面通常由几部分组成：题目描述、方法功能说明、给定的代码框架、可能存在的main测试代码，以及输入输出样例。sdtu这类平台的题目编号不同，但结构大同小异。这里我写一个通用的典型题面，读完你就知道该怎么下手。

// 题目给定的类框架 public class Main { public static void main(String[] args) { System.out.println(StringUtil.handle("sdut-java")); System.out.println(StringUtil.handle("hello")); } } class StringUtil { /** * 请实现该方法： * 当字符串以 "sdut-" 开头时，返回去掉 "sdut-" 后的字符串； * 否则原样返回；若 s 为 null 或空串，返回空串 ""。 */ public static String handle(String s) { // 在这里补全代码 return null; // TODO } }

在这种题里，main方法往往是题目给的，你只需要补全那个带注释的方法体。读题顺序我建议固定成三步：第一步先看方法签名，确定传入参数类型、方法名和返回类型，这是方向；第二步再看注释描述，重点关注里面对边界情况的特殊要求，比如“null返回什么”、“空格算不算空串”；第三步才回头看main里的测试样例，通过样例反推预期行为，验证自己的理解是否和出题人一致。

函数题唯一重要的事情只有一个：方法面对各种输入时应该返回什么、做什么处理。题面描述再长，无非是在为这个方法的行为做解释，不要被那些大段的背景故事干扰。我见过不少学生花十分钟读题面，最后却没看清注释里那行小字“s可能为null，请自行判断”，结果一提交就空指针异常。读题效率，往往就决定了解题效率。

2. 高频常用类知识点逐一拆解：方法、原理和易错点

2.1 String：最熟悉也最容易踩坑的类

String是Java里出场率最高的类，没有之一，但正因为太常见，反而成了函数题里翻车最多的地方。核心原因在于它的不可变性。String底层保存字符的char数组被private final修饰（在较新版本里可能是byte数组配合编码标记，但终归不可变），每个String对象创建后内容就固定了。任何看似“修改”字符串的操作，比如replace、substring、toUpperCase，真实行为都是创建一个新的String对象，原对象纹丝不动。

这个特性带来了很多连锁反应。第一，字符串比较不能直接用==，因为比较的是对象引用地址，而不是内容。两个内容完全相同的字符串完全可能是两个不同的对象，必须用equals方法。第二，字符串常量池让字面量字符串可以复用，所以直接写出来的"abc"和"abc"往往指向同一个对象，这也导致“看起来能用==”的错觉。第三，由于每次修改都产生新对象，在循环里用+拼接字符串会把性能拖垮，这种场景下的解决方案不是优化语法，而是换工具。

函数题里String的高频考点集中在常用方法上，我按使用频率整理了一份速查清单：

做函数题时，遇到字符串操作先想清楚“这个功能对应哪个方法”，再去翻文档确认参数细节。尤其是substring的右开区间，我见过无数人栽在这上面。想取字符串s的前三个字符，应该是s.substring(0, 3)，返回的是第1到第3个字符，第4个字符不包含，这个“开区间”直觉需要特意训练。

2.2 StringBuilder与StringBuffer：可变字符串的效率担当

String不可变带来一个直接后果：频繁修改字符串时效率极差。假设你要把10000个字符拼接起来，用String的+=操作，每个字符都会创建一个新的String对象，把旧内容复制一遍，复杂度直接变成O(n²)，数据量一大就能感受到明显卡顿。StringBuilder和StringBuffer就是为解决这个问题而生的，它们的内部维护一个可变的字符数组，append操作只是在数组末尾追加内容，必要时才自动扩容。

StringBuilder的常用方法其实不多，append、insert、delete、reverse、toString、charAt、indexOf，掌握这几个基本就能应付绝大多数函数题。有一个细节值得专门强调：append方法的返回值是StringBuilder对象本身，所以支持链式调用，例如new StringBuilder().append("a").append("b").append("c")，这一特性在很多题解里都能简化代码。另外，reverse方法可以原地反转字符串序列，遇到回文、反转类题目时很好用。

StringBuffer和StringBuilder的功能几乎一模一样，唯一区别是StringBuffer的方法都加了synchronized关键字，线程安全但性能略低。在OJ函数题和绝大多数单线程场景下，优先选择StringBuilder就好，这也是面试时的高频考点。相关八股问题往往长这样：“StringBuilder默认容量是多少？”“扩容机制怎么实现的？”答案是默认容量16，当容量不足时新容量为旧容量乘以2再加2，然后通过Arrays.copyOf把原数组内容复制进新数组。

从源码层面理解StringBuilder有两个好处。一是遇到需要手动预设容量的大拼接场景时，你可以通过构造方法直接指定初始容量，避免多次扩容。二是能真正理解为什么循环里用+拼接是坏习惯，为什么用append在性能上能甩开几条街。函数题一般不直接考你写扩容代码，但如果你能在题解里用到StringBuilder并保证不溢出、不超时，就已经和其他同学拉开差距了。

2.3 包装类：自动装箱拆箱背后的隐藏陷阱

Java是一门面向对象语言，但基本类型int、double、char并不是对象。为了让这些基本类型也能以对象形式出现，才有了对应的包装类：Integer、Double、Character、Boolean等等。函数题里经常需要在这两者之间来回倒腾，比如把字符串“123”转成数字123，或者把字符数组里的数字字符转成对应数值，这就涉及包装类的核心操作。

自动装箱和拆箱是编译器提供的语法糖。当你写下Integer a = 100时，编译器实际执行的是Integer.valueOf(100)；当你写下int b = a时，编译器实际执行的是a.intValue()。这种机制平时很贴心，但也埋了一颗雷：valueOf方法会使用缓存。Integer的valueOf在入参范围-128到127之间时，直接返回常量池里缓存的同一个对象；超出这个范围，就new一个全新对象。

这就导致了经典翻车现场：

Integer a = 100; Integer b = 100; System.out.println(a == b); // true，命中缓存 Integer c = 200; Integer d = 200; System.out.println(c == d); // false，超出缓存区间，是两个不同对象

这种差异在函数题里极其隐蔽。题目让你判断两个“整数”是否相等，你想着用==比较简单，结果测试数据一过127就翻车。正确姿势只有一个：包装类之间的比较一律用equals，或者先拆箱成基本类型再用==比较。如果你需要在函数题里做数值运算，请非常小心地处理字符串和包装类型的互相转换，Integer.parseInt是把字符串解析成基本类型int，Integer.valueOf是返回包装对象，这两个方法名字相近，返回类型不同，用错了直接编译报错。

包装类的另一个考点是各种静态工具方法。Integer.toBinaryString、Integer.toHexString、Double.parseDouble、Character.isDigit、Character.isLetter，这些方法在OJ题目里经常作为跳板出现。拿到一个包装类题目，先想想它考的是“缓存陷阱”“自动装箱实现原理”，还是“静态方法使用”，对症下药会快很多。

2.4 Math、日期时间类与System类：容易被忽略的组合考点

除了String和包装类，常用类这个章节还会捎带考Math类、日期时间类和System类。Math类是个纯工具类，构造方法是私有的，所有方法都是静态的，直接通过类名调用就行。函数题最常见的用法包括：Math.PI计算圆面积、Math.max和min找最大值、Math.abs求绝对值、Math.pow算幂、Math.sqrt开根号、Math.random生成[0.0, 1.0)随机数。这些方法本身没有太多坑，但要注意Math.round是返回long类型，取整规则是“四舍五入但负数特殊”，别和Math.floor混用。

日期时间类在函数题里出镜率中等，但一旦出现就是难点。老API有Date和Calendar，新API有LocalDate、LocalDateTime和DateTimeFormatter，新老API之间切换很容易让人懵。做这类题时，先确定题目期望的是哪种API，再看具体操作方法。比如要获取年份，Calendar得用calendar.get(Calendar.YEAR)，LocalDate直接localDate.getYear()，写法完全不同。如果题目允许使用新API，优先用LocalDate系列，代码更简洁直观，可读性也更好。

System类在函数题里偶尔作为“工具人”出现。System.currentTimeMillis()返回当前时间戳毫秒数，经常用来测量方法执行耗时；System.arraycopy是数组复制的高效底层方法，它在源码层面被ArrayList.copyOf大量调用。有些题目会让你实现数组复制逻辑，你完全可以用System.arraycopy代替手写for循环，既简洁又不会被挑出性能毛病。

这些类有一个共同点：方法多而杂，但每个方法都很固定。备考策略不是死记硬背所有方法签名，而是建立“功能到方法”的索引。遇到“求绝对值”想到Math.abs，遇到“复制数组”想到System.arraycopy，遇到“生成随机数”想到Math.random，形成了这个索引，做题速度会明显提升。

3. 从读题到提交：手把手解题实操全流程

3.1 做题三步法：签名、注释、边界，一个都不能少

函数题的解题流程完全可以标准化，我总结了一个三步法，每次拿到题都按这个顺序执行，效率和准确率都能稳定。

第一步，读签名。先盯着方法定义看十秒钟，问自己三个问题：方法名是什么？参数有几个、各是什么类型？返回值是什么类型？这三个答案决定了后续所有代码的走向。比如方法签名是public static int countChar(String s, char c)，那你要返回的就一定是一个int，计算内容是统计字符c在字符串s中出现的次数。签名都没看清就急着写方法体，是最常见的低级失误。

第二步，读注释。函数题的注释通常就是“出题人的意图说明书”，里面往往写着最重要的行为约束。比如“若s为null，返回0”“忽略大小写”“不包含空格”……这些句子少看一个，隐藏测试用例就多一分击穿的风险。我习惯把注释里的关键约束条件提取到草稿纸上，或者直接复制到代码注释里，保证自己不会忘。

第三步，想边界。这一步是区分“写得出来”和“写得对”的分水岭。函数题的测试用例分为可见样例和隐藏用例，隐藏用例专门挑你主流程没覆盖到的地方下手。拿到题后，不要急着写核心逻辑，先问：参数可能是null吗？可能是空串吗？负数应该返回什么？最大值会溢出吗？这些边界想清楚再动笔。

这三步看起来简单，但实际做题时很多人会跳过第二步和第三步。我自己刷题经验里，十个“答案错误”里至少有七个和边界有关，真正因为核心算法写错的反而少。把这三步写进肌肉记忆，相当于给OJ增加了一层保险。

3.2 实操案例一：字符串前缀处理（String常用方法组合）

为了让你看清楚完整的解题链路，我设计一道典型函数题，和sdut常用类函数题的风格一致。

实现StringUtil类的handle方法：当字符串s以"sdut-"开头时，返回去掉该前缀后的字符串；否则返回原字符串。若s为null或空串，返回空串""。

拿到方法，先排定方案：用startsWith判断前缀，用substring截取剩余部分。再看边界条件，注释明确说null和空串要返回空串，所以开头必须先做判空。代码如下：

public static String handle(String s) { if (s == null || s.isEmpty()) { return ""; } if (s.startsWith("sdut-")) { return s.substring(5); } return s; }

逐行分析一下。第一行判断null和空串，注意先判断null再判断isEmpty，顺序不能反，否则null调用isEmpty会空指针异常。第二行用startsWith判断前缀，参数是"sdut-"，长度为5。第三行用substring(5)跳过前5个字符，这里必须算准长度，s-d-u-t-刚好是5个字符，如果前缀写成"sdut"就是4，一个字符之差直接决定答案对错。

测试能覆盖的场景也很清晰。输入"sdut-java"返回"java"；输入"sdut-"返回空串，因为去掉5个字符后剩余长度为0，substring(5)合法返回""；输入"hello"返回"hello"；输入null返回""。这四种情况分别对应了正常路径、边界前缀、无前缀、空值四种分支，正好覆盖了判断题面的四个隐藏考点。

我在这个题上还有一个独家小技巧：本地自测时不要只跑题目给的样例，要自己补几组“刁钻”输入。比如前缀只出现一半的字符串"sdut"，它不以"sdut-"开头，应该返回"sdut"本身，这个用例能检查你前缀判断的严谨性。再比如字符串就是"sdut-"本身，这个用例能检验substring在截取到空串时不抛异常。把这些额外用例跑通，提交时的信心会大很多。

3.3 实操案例二：提取数字字符串（StringBuilder场景）

再看一道需要用StringBuilder的题目，这类题和在线评测平台的性能要求联系更紧密。

实现extractDigits方法：从给定字符串中提取所有数字字符，按原顺序拼接成新字符串返回。如果没有数字字符，返回空串""；入参为null也返回空串""。

初看这题，一个朴素方案是遍历字符串，用+把数字字符拼接起来。比如遍历到char'3'就执行result += "3"。这个方案在字符串很短时没问题，但一旦输入长度达到几千甚至几万，就会产生大量中间String对象，性能会很差。正确做法是用StringBuilder：

public static String extractDigits(String input) { if (input == null || input.isEmpty()) { return ""; } StringBuilder sb = new StringBuilder(); for (int i = 0; i < input.length(); i++) { char c = input.charAt(i); if (c >= '0' && c <= '9') { sb.append(c); } } return sb.toString(); }

代码不长，关键点在四个地方。第一是判空逻辑，null和空串都返回空串。第二是字符判断，c >= '0' && c <= '9'比调用Character.isDigit更直白，范围判断在字符编码表上是连续的，这个写法既高效又不容易出错。第三是拼接方式，用StringBuilder的append，在遍历过程中不断追加字符，不会产生中间垃圾对象。第四是最后一定要调用toString()转换回String，因为方法签名要求的返回类型是String，不转换就会编译错误。

这个题还有一个常见的变形：要求提取数字后去重，或者要求统计数字个数而不返回字符串。变形题的核心逻辑仍然是遍历、判断、存储这几步，只是存储载体从StringBuilder变成了Set或者计数器。理解了StringBuilder在拼接场景的地位，这类变形题基本可以顺手拿下。

3.4 提交前的自检清单：让评测一次通过

写完之后不要立刻点提交，先花三十秒做一遍自检，我有六条清单，按顺序问自己。

第一，方法签名是否完全一致。函数题的死穴是签名不匹配，哪怕只是返回类型从String写成了StringBuilder，或者是参数类型从String写成了CharSequence，都可能直接编译失败。第二，边界条件是否处理齐全。null、空串、负值、最大值，这些在题面注释里有没有明确要求，如果没写也要自己补上。第三，字符串比较是否用了equals。写代码时扫一眼，凡是字符串内容比较，检查有没有误用==。第四，循环里有没有性能隐患。尤其检查String拼接，如果有，改写成StringBuilder。第五，返回值是否齐全。所有分支都要有return语句，编译器才不会报“缺少返回语句”。第六，没有多余输出。函数题里多写一行println会导致OJ把输出和预期比对时直接判答案错误，除非题目明确要求方法内部输出，否则一律不要打印。

这六条我称为“自检六连”，每次在OJ上提交函数题之前过一遍，能轻松过滤掉大半低级错误。真正的老手会把这套自检融入写代码的过程里，写完即检，提交就像喝水一样自然。

4. 常见问题排查与避坑经验实录

4.1 OJ三大错误类型速查表：编译错误、答案错误、运行超时

在OJ上刷题，最磨人的不是不会做，而是“做了但过不了”。不管是sdut还是其他在线评测平台，函数题的报错通常集中在这么几类，我用表格总结一下：

说实话，OJ平台给出的错误提示往往很简略，有些甚至只告诉你“答案错误”，却不告诉你是哪一条用例挂的。这种时候最有效的排查手段不是在OJ上瞎猜，而是回到本地IDE把自己的实现跑一遍，把所有你能想到的边界输入都喂给它，看哪一条输出和预期不一致。大多数“答案错误”都可以这样在本地被定位。

有一个细节值得单独提醒：部分函数题允许你在提交的代码里拥有额外的辅助方法，但题目给的类名和方法签名必须原封不动。有些同学为了测试方便，在方法体里写了main方法，提交时忘了删，结果类里出现了两个public方法或者main方法，直接编译失败。提交前检查一下，代码里只保留题目要求的类和最必要的方法，不要夹带测试代码。

4.2 我在做这类题时踩过的真实坑

这些坑全是我当年在学Java时真实踩过的，每一个都对应着一段线上评测“红色页面”的回忆。

第一个坑是字符串内容比较用错==。有一道反转字符串的题，我需要判断反转前和反转后是否相等，当时觉得StringBuffer的reverse完事之后直接==比较就行，本地跑通，提交后答案错误。后来才明白，内容相同的两个String对象可能是不同实例，必须用equals或者equalsIgnoreCase。从那以后我养成了习惯：只要看到字符串比较，第一反应就是equals。

第二个坑是substring的区间界限。有一次统计子串出现次数，需要判断某个位置之后是否还剩指定长度的字符串，我写的是if (i + len < s.length())，边界差了一位，导致最后一个可能匹配的子串被漏掉。这类问题根本不用猜，直接把substring的源码语义背下来：substring(beginIndex, endIndex)返回从beginIndex到endIndex的前一位，即左闭右开的区间，然后在实际使用中多验证边界位置。

第三个坑是Integer的缓存陷阱，这也是我前面提到过的经典坑。那年做一个判断两个整数是否相等的函数题，我拿Integer c == Integer d直接比较，测试数据刚好都在-128到127之间就通过了，我还挺高兴。结果换一批测试数据直接翻车，一百多行代码看起来都对，就是AC不了。当时花了整整一个晚上才定位到==比较包装类这一点。之后我在这类题里彻底放弃了用==比较两个包装对象，一律equals或者拆箱。

第四个坑是StringBuilder忘了toString。有一次我实现的方法返回类型是String，我在方法末尾直接return sb;，编译器立刻报错，因为sb是StringBuilder类型。这个坑其实是好事，编译错误比答案错误好查得多。但它提醒我：StringBuilder只是一个中间容器，永远记得最终要转成String交付给外部。

第五个坑是循环字符串拼接导致超时。那是第一次遇到大数据的字符串拼接题，输入长达几万字符，我用result += c拼了半天，本地跑着还行，一上OJ直接运行超时。后来的教训是：只要拼接次数可能超过几十次，就别用+，直接上StringBuilder。这个习惯我一直带到工作中，处理日志拼接、SQL组装时都用builder，几乎没再遇到过拼接性能问题。

4.3 从函数题到面试题：常用类学习的第二阶段

函数题能帮你建立的更多是“会用”层面的能力，但仅仅会做OJ题还不足以应对真正的面试，因为面试官会把问题问到“为什么”的深度。这是学习常用类的第二阶段，也是最容易拉开差距的阶段。

先看面试的常见追问。String为什么设计成不可变的？答案可以从安全性、线程安全、字符串常量池复用、hashCode缓存几个角度答，随便展开一个方向都比只会背结论要强。StringBuilder是如何做到高效拼接的？这就要说到内部字符数组和扩容机制，默认容量是16，扩容策略是旧容量乘2加2。Integer的缓存范围为什么是-128到127？这是JVM规范建议的范围，网络传输和数值统计里的小整数更常见，缓存能有效减少对象创建。

要把这些“为什么”学透，我的建议是代码压缩包的深度阅读。打开IDE，按住Ctrl，点进StringBuilder源码，你能看到append方法、扩容方法、toString方法的完整实现；点进Integer源码，你能看到valueOf方法里的缓存判断逻辑。不需要每个类都通读，挑高频的几个类看核心方法就够了。看完再用小demo验证，比如写个程序打印Integer缓存的边界现象，这种“源码+实验”的组合会让你记得非常牢。

技术社区里关于Java基础、面向对象、常用类的文章和教程很多，挑质量高的进行补充。比如可以搜Java面试题、Java八股文相关内容，它们会把零散知识点串联成体系。但请注意，直接背八股不如自己动手写几个验证demo，把知识点转成自己的理解，才是面试时能自信表达的基础。

如果你现在还被sdut这类常用类函数题折腾，其实是一件好事。这意味着你正在面向对象课程最关键的阶段筑基，等这些题做完，后面的集合类和IO流学习会顺很多。函数题不会白刷，每一个查漏补缺的瞬间，都在变成你面试时脱口而出的底气。

最后再分享一个坚持了很多年的小习惯：做函数题时，我会把“应该处理哪些边界输入”直接写在代码注释里，然后写完方法立刻测试五组数据——null、空串、一个字符、全数字、超长字符串。这五组能过，基本就不会被隐藏用例击穿。这个习惯后来被我带进工作中，写任何工具方法都先想边界，花不了两分钟，却能省下大量排查时间。常用类这波题做扎实了，后面Java的学习会轻松很多。