1. 两种模式到底在说什么先抛结论核心代码模式就是平台已经帮你把输入读好了、输出检查也准备好了你在编辑器里只需要写完那个函数体ACM模式则是把整个题目从标准输入到标准输出的链路全部交给你数据要自己读进来结果要自己打印出去评测系统再对你的完整输出做比对。一句话概括核心代码模式只考算法逻辑ACM模式额外考你处理输入输出的基本功。这个区别刷题刷得少的人可能感受不深。比如长期用LeetCode刷题一上来就是class Solution函数签名都给你摆好了你只填中间那几行逻辑提交完事整个过程很舒服。但一旦到了某些公司的机试环节题目打开一看模板是空的连main函数都要自己写还得手写Scanner或者BufferedReader如果平时根本没碰过这种模式哪怕算法会人也容易当场懵掉。这几年很多银行、国企、互联网大厂的技术岗笔试以及华为OD这类外包岗机试都明确要求ACM模式。两种模式都不陌生才能稳着上考场。1.1 核心代码模式你只需要写完函数核心代码模式的代表就是LeetCode。你打开一道题页面左边是题目描述右边是一个已经定义好参数和返回值的函数class Solution { public: vectorint twoSum(vectorint nums, int target) { } };你不用操心数据是从哪来的也不用管结果要怎么输出。平台会在后台悄悄调用你这个函数把测试数据传进去再把函数的返回值和标准答案做比对一致就给过。这种模式的本质是把“算法题评测”做成了一次远程函数调用。你提交的代码对评测系统来说就是个黑盒子入参传进去出参返回回来逻辑对了就通过。好的一面是写起来干净适合一门心思搞算法、练思路不用反复去做繁琐的IO体操。坏的一面也很明显长期只在这种模式下刷题的人很容易产生一种错觉以为写算法就是“写那几个函数”但真实工程中数据不会自己变成函数参数结果也不会自动被交到别人手里尤其在机试环境里这些活儿全得你来。1.2 ACM模式从输入到输出全包ACM模式这个名字源于ACM国际大学生程序设计竞赛真实比赛里没有任何“模板”一切从零开始。选手拿到题目之后自己决定数据结构、自己写读取逻辑、自己写输出逻辑。评测系统会起一个进程跑你编译出来的程序把你的输出和标准输出逐字符比较差一个空格、差一个换行都可能是 Wrong Answer。举个例子同样是“两数之和”这道题ACM模式的题干会写得特别具体第一行输入一个正整数 n表示数组长度第二行输入 n 个整数代表数组第三行输入一个目标值 target。输出两个整数下标中间用空格分隔。那么你要提交的代码就长这样import java.util.Scanner; public class Main { public static void main(String[] args) { Scanner sc new Scanner(System.in); int n sc.nextInt(); int[] nums new int[n]; for (int i 0; i n; i) { nums[i] sc.nextInt(); } int target sc.nextInt(); MapInteger, Integer map new HashMap(); for (int i 0; i n; i) { int diff target - nums[i]; if (map.containsKey(diff)) { System.out.println(map.get(diff) i); return; } map.put(nums[i], i); } } }看到没有除了那几行算法核心逻辑你还得额外处理包名问题、类名问题、输入没给对怎么办、数组读取顺序是不是和题干一致等等。很多基础不错但没练过ACM模式的同学栽就栽在这层额外的“包装”上。1.3 两种模式解决的其实是同一个问题把话说透一点两种模式不管怎么变背后的算法需求是一样的。你在核心代码模式里会写的二分查找、滑动窗口、动态规划到了ACM模式一样要会。核心差异只有两个点数据怎么读进来、结果怎么交出去。所以不要把它们理解成两套完全不同的武功它们只是同一个“解题过程”的两种不同外壳。你核心代码模式写得溜拿到ACM模式算法逻辑一样能用反过来你ACM模式写得多去面试写核心代码模式反而会觉得更轻松因为函数签名已经帮你处理掉了最烦人的输入格式问题。真正该练的是一眼识别出“这道题在核心代码模式下要反什么数、在ACM模式下要读什么数据”然后用一种最不容易出错的方式把它写出来。下面我逐一展开。2. 为什么刷题平台会同时保留这两种模式很多同学会好奇既然核心代码模式用起来这么舒服为什么还会有平台坚持用ACM模式为什么面试笔试的时候那些公司偏偏要选看起来更麻烦的那种这里面有历史原因也有非常现实的用人考量。2.1 核心代码模式的由来与好处核心代码模式是随着LeetCode这类在线刷题平台兴起而普及的。它的目标用户是很明确的一群人准备面试的人。面试考算法的时候面试官想看的是你能不能快速想到解法、能不能把代码写干净而不是看你浪费10分钟在那边处理输入输出。于是平台把IO全部封装起来给你一个函数签名你只要聚焦在算法本身。这种模式在“刷题练习”和“面试模拟”这两个场景下特别好用。因为刷题高频场景是“一天刷好几道”如果把时间都花在读输入上人很快就会疲劳效率也低。核心代码模式把每个题目的“坑”尽量留在算法层面该考察你链表操作就考链表操作该考动态规划就考动态规划不会被无关细节干扰。另外从平台技术上来说核心代码模式也更容易做自动判定。平台可以直接调用你提交的代码把返回值拿过来比较不需要启动完整进程、比较标准输出判定效率和稳定性都更高。2.2 ACM模式为什么到现在还没退场那ACM模式为什么到现在还很常见我觉得有三个原因第一它更贴近真实竞赛和部分公司机试的传统。很多公司做技术笔试时出的题本来就是从竞赛题改编过来的题库沿用早期ACM/ICPC或蓝桥杯风格。直接把题目带数据格式迁移过来最省事用核心代码模式反而要额外改造一遍得不偿失。第二ACM模式能筛掉一部分“只背了模板”的人。这话说起来不好听但实际筛选效果确实存在。有些候选人核心代码模式刷得滚瓜烂熟但让他自己写个带标准输入输出的完整程序他连BufferedReader为什么比Scanner快都说不出来读一行字符串的时候还总被nextLine()的换行坑到。企业招人想找的是能写完整工程代码的人不是只会写函数片段的人所以更愿意用ACM模式来筛。第三一些特定领域的要求比如华为OD机试、银行技术岗笔试多年以来一直沿用ACM模式已经形成了固定的出题风格和判题系统。改变成本高双方出题方和应试方也都习惯了所以短时间内很难被替代。2.3 两种模式整体对比对比维度核心代码模式ACM模式代表平台LeetCode牛客、华为OD机试、蓝桥杯、ACM竞赛代码结构只写类方法完整可运行程序class Main main方法输入处理平台自动注入自己从 stdin 读取输出处理平台代收返回值自己精确控制 stdout 格式刷题效率高聚焦算法低需额外处理IO面试还原度偏向算法面试偏向机试、工程素养考查常见坑对函数签名理解不到位输入读取错误、输出格式错误这张表值得存一下。每次遇到不同类型的题目环境先想一想自己现在处于表格的哪一行再决定写代码的重心放在哪里。3. 同一道题用两种模式各写一遍光说不练假把式。这里我拿一道很经典的“两数之和”变体把两种模式完整走一遍。你最好跟着把代码在本地敲一遍重点感受两种写法之间的差异。3.1 题目描述给出一个整数数组nums和一个目标值target在数组中找出和为target的两个数返回它们的下标。核心代码模式版本给定一个整数数组nums和一个整数目标值target请你在该数组中找出和为目标值的两个整数并返回它们的下标。你可以假设每种输入只会对应一个答案返回任意顺序即可。ACM模式常见变体版第一行一个正整数 n表示数组长度第二行 n 个整数表示数组第三行一个整数 target。输出一行包含两个整数分别是两个数的下标中间用空格隔开顺序无所谓。注意ACM版本里“n”必须自己读这是和核心代码模式最大的区别。在LeetCode版本中数组长度早就隐藏在nums.length里了你根本不需要读。3.2 核心代码模式写法Java版本import java.util.HashMap; import java.util.Map; class Solution { public int[] twoSum(int[] nums, int target) { MapInteger, Integer map new HashMap(); for (int i 0; i nums.length; i) { int diff target - nums[i]; if (map.containsKey(diff)) { return new int[]{map.get(diff), i}; } map.put(nums[i], i); } return new int[0]; } }核心代码模式下这个方法写完就结束了。当你写return new int[]{map.get(diff), i};的时候平台自动知道你要返回什么它会拿这个数组和预期答案做对比。你的职责到 return 就为止了。就算本地你忘了写main提交上去照样能过因为评测端根本不跑你的main。3.3 ACM模式写法Java版本import java.util.HashMap; import java.util.Map; import java.util.Scanner; public class Main { public static void main(String[] args) { Scanner sc new Scanner(System.in); int n sc.nextInt(); int[] nums new int[n]; for (int i 0; i n; i) { nums[i] sc.nextInt(); } int target sc.nextInt(); MapInteger, Integer map new HashMap(); for (int i 0; i n; i) { int diff target - nums[i]; if (map.containsKey(diff)) { System.out.println(map.get(diff) i); return; } map.put(nums[i], i); } sc.close(); } }Python版本import sys def main(): data sys.stdin.read().strip().split() if not data: return idx 0 n int(data[idx]) idx 1 nums [] for _ in range(n): nums.append(int(data[idx])) idx 1 target int(data[idx]) seen {} for i, num in enumerate(nums): diff target - num if diff in seen: print(seen[diff], i) return seen[num] i if __name__ __main__: main()注意Python这个写法用sys.stdin.read()一次性把整个输入读进来再统一分割处理。这比input()一行行读更稳在数据量大的时候也更快。ACM模式下你的代码是一个完整的程序。评测系统会像你在命令行里执行java Main一样去运行它把准备好的测试数据放到标准输入里然后抓取你的标准输出做比对。稍有差池整个程序可能直接报错或者输出对不上。3.4 输入边界情况一定要想清楚这道题如果ACM模式给的n和你实际读到的数组元素数量不一致会发生什么假如第一行写了3第二行只有2个数字那么sc.nextInt()第二次的时候就会抛出异常。反过来如果第一行写3第二行给了4个数字多出来的那个数字会被下一行读取逻辑吞掉造成莫名其妙的结果。这几乎是ACM模式新手最容易踩的坑。核心代码模式下这类问题完全不存在因为平台已经把入参封装好了不可能出现“读多了”或“读少了”的诡异状态。所以ACM模式写多了你会自然养成一个习惯先看清楚输入格式有几行每行几个数用不用处理“多组测试用例”的情况用不用处理字符串里的空格。这些看起来是“细枝末节”但实际考试里往往就是这些细节决定你是一遍过还是改到天荒地老。4. 实战中最容易翻车的地方现在进入本文最有价值的部分。我把这几年在网上、周围朋友以及自己刷题过程中遇到的高频翻车场景一条一条整理出来。很多坑不是因为算法难纯粹是模式切换不熟练造成的非常可惜。4.1 本地运行正常切换到ACM模式就报错最常见的表象在IDE里用核心代码模式写好了方法测试也测了然后把方法复制到ACM模式的编辑器里外面套了一个main结果一跑就各种报错。排查方向通常有三个第一类名和包名。ACM模式的判题系统一般要求public class Main类名必须精确。你要是复制代码的时候顺手把原来的class Solution留着或者文件名和类名不一致编译直接失败。Java尤其严格带package声明也是大忌。第二函数签名发生变化。核心代码模式的函数签名是由平台定死的比如public int[] twoSum(int[] nums, int target)但ACM模式里函数名、形参名都没人管你重要的是你自己main里面别把数据的顺序读错。最常见的错误是先读target再读数组或者是把n和数组元素搞混。第三运行方式差异。你在IDE里点击运行IDE可能已经自动帮你处理了工作目录、环境变量、编码格式到了OJ环境所有东西都是裸的。最简单也最有效的做法是在本地自己开一个命令行终端手动编译运行一次把输入用管道喂进去看输出是否符合预期。这能模拟出80%的OJ环境。4.2 读字符串最容易踩的坑next()和nextLine()的区别每次说完都有人拍大腿。next()读取下一个被空白字符分隔的“单词”遇到空格、Tab、换行就停。nextLine()读取一整行直到遇到换行符。问题出在混用。比如你先调nextInt()读了整数紧接着调nextLine()想读一行字符串结果往往拿到的是空字符串。为什么因为nextInt()读到整数后光标正好停在“换行符之前的空白”位置nextLine()读到的就是那个残留的换行符直接返回空行。解决办法有三个在nextInt()后面再补一个nextLine()把这个残留换行消费掉全部用nextLine()读进来再手动用Integer.parseInt转换避免在同一个程序里混用这两类方法能统一就统一。第三种是最省心的。很多老选手的习惯是要么全程Scanner的next系方法处理所有输入要么干脆用BufferedReader配合split一次性处理所有行根本不给混用留机会。4.3 输出格式和空白字符的处理ACM模式的输出要求严到让人抓狂。少一个空格、多一个换行、末尾多一个Tab都可能导致Wrong Answer。最经典的是“这是道要输出n行的题但中间某行结尾多了一个空格”。我的一个笨办法是如果题目要求“输出每个结果占一行”那我就用StringBuilder把结果拼好最后统一输出最后再加一个彻底trim()或者精确控制分隔符。例如要求输出数字之间用空格分隔我就写成StringBuilder sb new StringBuilder(); for (int i 0; i n; i) { if (i 0) { sb.append( ); } sb.append(arr[i]); } System.out.println(sb);这样永远不会出现最后一个元素后面多加空格的问题。还有一类题是“输出结果也可能是一个特殊符号”例如-1表示找不到那么你就老老实实输出那一个数字就好不要在中间穿插任何调试信息。调试的时候可以System.out.println随便打但提交前一定要把调试输出删干净。另外提醒一句不管代码里是System.out.println(答案是 ans)还是print(ans \n)OJ都只看最终标准输出。很多人自查半天没发现问题最后发现是调试信息没删干净白白浪费好几次提交机会。4.4 高效读入Scanner还是BufferedReader如果是几十上百个数的输入Scanner完全够用。但笔试里偶尔会出现那种丧心病狂的数据规模比如读入10万个整数再做查询操作。这时候Scanner就非常吃力了可能会超时。而使用BufferedReader一次性读入再用split解析速度会有很明显的提升。import java.io.BufferedReader; import java.io.IOException; import java.io.InputStreamReader; public class Main { public static void main(String[] args) throws IOException { BufferedReader br new BufferedReader(new InputStreamReader(System.in)); String line; while ((line br.readLine()) ! null) { String[] parts line.trim().split(\\s); // 处理 parts } br.close(); } }经验法则除非题目数据量特别大比如n到了10^5甚至10^6级别或者循环查询次数多到离谱否则Scanner也够用。但如果真的对性能没把握直接用BufferedReader一定更安全。只是要注意抛异常和资源关闭的问题别忙中出错。Python这边也是同理能用sys.stdin.read()就别用input()逐行读。input()在数据量大时慢得离谱一次性读入再拆分是更好的方案。5. 两种模式都要稳日常怎么练想笔试不慌光看文章没用关键还是得练。但练也有练的方法。我是建议“两条腿走路”核心代码模式保持手感ACM模式定期熟悉不要等到考前几天才临时抱佛脚。5.1 刷题时的练习组合如果你平时用LeetCode刷每日一题我的建议是每周至少挑两到三道题手动改写成ACM模式在牛客网的在线笔试系统或者自己的IDE里跑一遍完整的输入输出。具体做法是从LeetCode找一道题先按核心代码模式把解法写出来看题解的“输入输出示例”自己设计ACM模式的输入格式新建一个Main类把解法逻辑改造成从标准输入读取、标准输出打印的完整程序用几个样例自测包括空数组、边界值、大数、重复元素等有条件的话拿到一个支持自定义输入的OJ上提交一遍看是否通过。这个流程大概每次多花15分钟。但坚持两周后你对ACM模式的恐惧会明显消失因为你已经形成了固定的“模板记忆”。我自己常用的一组固定模板是这样的先写好read input的部分再写好solve逻辑最后是output。这样就算题目变了模板骨架不动只需要改中间的处理逻辑。import java.util.*; public class Main { public static void main(String[] args) { Scanner sc new Scanner(System.in); while (sc.hasNext()) { // 1. 读入 int n sc.nextInt(); int[] arr new int[n]; for (int i 0; i n; i) { arr[i] sc.nextInt(); } // 2. 计算 int result solve(arr); // 3. 输出 System.out.println(result); } sc.close(); } static int solve(int[] arr) { // 算法逻辑 return 0; } }这套“读入-计算-输出”三段式是ACM模式最稳的结构。遇到复杂输入格式多改几行模板就好核心逻辑永远集中在solve里。5.2 笔试机试前的环境准备考前一定去目标公司或平台模拟一遍笔试环境。有些平台的IDE是不带代码补全的或者编译用的JDK版本和你本地不一样。曾经有人因为本地是JDK 17用了List.of()等新特性考试平台是JDK 8一提交编译直接失败。这种事最冤。我还建议你养成一个习惯写ACM代码时类名统一用Main不要加包名不要写package。所有封装的输入逻辑都自己写不依赖任何第三方库。有些企业笔试环境比较简陋除了标准库什么都不给你要是有奇奇怪怪的依赖肯定跑不过去。另外提前准备好几段速查模板比如读取单行整数数组、读取多行不定长整数、读取字符串数组、输出带分隔符的一行结果。这些片段就像英语作文里的万能句式上了考场直接改数据就行非常省时间。5.3 考试时的策略与心态ACM模式笔试通常题目多、时间紧别按顺序硬刷先花两分钟把所有题都看一遍按难度排序。第一原则先把第一题做出来。笔试的第一题通常是最简单的只要能AC心态稳一半。第二原则遇到读半天没读明白的输入格式直接跳过先做后面的不要在一道题上浪费超过20分钟。第三原则如果算法思路不完整先把输入输出写对拿部分分。很多OJ是“分点得分”的你输出格式对了、样例能过也能捞到一点分。最怕的是那种“代码写了一半卡在输入读取上连样例都跑不过”的局面。所以随手把分段读入、分段处理的结构学好真的很值。还有一点提交前务必看清题目的输出说明。让输出索引从0开始还是从1开始排序要求是升序还是降序是不是要处理多组测试用例直到EOF。这些坑比算法bug更致命。6. 常见问题速查这一节整理几个关于两种模式的高频疑问遇到类似情况可以快速查阅。6.1 核心代码模式刷多了会不会导致ACM模式写不动代码很多人担心长期用LeetCode刷题是不是会让自己的工程编码能力退步。我的看法是不至于但确实会“手感生疏”。核心代码模式把输入输出封装掉了你长期不碰IO操作真到了要自己写的时候速度会慢容易出小错。解决办法就是上面说的每周找个两三天把题改写成ACM模式练一遍保持手感。核心代码模式本身不是问题问题是你有没有刻意去做模式切换的练习。6.2 遇到没有给测试用例数量的输入怎么处理有一种输入格式是有多行数据但没告诉你到底有几行读到文件末尾为止。这时候千万别想着for (int i 0; i n; i)得用while (sc.hasNext())或者while ((line br.readLine()) ! null)。例如题目要求每行输入两个数a和b输出它们的和直到输入结束。Scanner sc new Scanner(System.in); while (sc.hasNext()) { int a sc.nextInt(); int b sc.nextInt(); System.out.println(a b); } sc.close();这种写法要牢记它是ACM模式的一个特高频考点。6.3 我应该用哪种语言应对ACM模式更好就我接触的经验Java和C在ACM模式下都很常见Python现在也越来越多地被许多机试平台接受了。选语言的核心标准不是“哪个最强”而是“哪个你写得更熟、更不容易出错”。如果你已经对Java比较熟建议继续用Java。Java的Scanner虽然比C的cin慢但非极限数据完全够用用BufferedReader就能覆盖大数据场景。C的效率高但指针和内存管理的坑也更多平时不熟的话别临时换。Python写起来最快但如果你对sys.stdin.read()和列表推导式不熟悉反而容易写出效率极低的代码。一句话别在考场上换枪。最后说点实在的。我自己最早也是只刷核心代码模式第一次参加某平台机试时光输入输出格式就折腾了半天最后一道很有把握的题都没写完。后来学乖了每次刷题都顺手想想“这题如果改成ACM模式输入该怎么读”慢慢就形成了条件反射。现在看到任何一道题第一反应不再是算法代码本身而是先把数据流在脑子里过一遍入口在哪、出口在哪、中间要跑什么逻辑。这个习惯我觉得比单纯记住“两种模式的区别”更有用也建议你尽早养成。