做 Java 这么多年面试过别人也被别人面试过“输入”这两个字几乎每次都绕不开。很多人觉得 Java 输入不就是Scanner scanner new Scanner(System.in)加一句nextLine()吗真到了写算法题、处理高并发日志、或者被面试官追问“你这个输入方式在高数据量下会怎样”的时候才发现自己对 Java 输入的理解还停在“会用”而不是“用好”。这篇内容我就从实际开发、算法竞赛、面试三个场景出发把 Java 输入这件事的方方面面拆开讲透包含完整代码模板、性能对比、常见翻车现场和排查思路新手可以当教程看有经验的朋友可以当查漏补缺的清单用。1. Java 输入的全家桶四种主流方式怎么选1.1 Scanner日常开发首选但不是万能Scanner 是绝大多数人接触 Java 输入的第一个类它内部基于正则表达式做分词默认用空白字符空格、制表符、换行作为分隔符。这种设计让它用起来极其舒服Scanner scanner new Scanner(System.in); int n scanner.nextInt(); String name scanner.next(); String line scanner.nextLine();但这里藏着一个很多人没意识到的性能问题Scanner 的每个nextInt()、next()都会走正则匹配流程数据量小的时候没感觉一旦需要读几万行、几十万行数字速度会明显慢下来。我之前用 Scanner 读一个包含 20 万行整数的测试文件耗时接近 1800 毫秒而同样的数据用 BufferedReader 手动解析不到 400 毫秒就能读完。这个差距在竞赛评测和批量处理场景里就是致命的。所以我的建议是日常写小工具、做练习、写交互式命令行应用放心用 Scanner它够简单、够直观。但如果你知道自己要面对大量数据或者是在写性能敏感的代码趁早切到 BufferedReader 方案。1.2 BufferedReader高性能场景的硬核选手BufferedReader 是字符流它的核心方法是readLine()按行读取文本。它本身不做任何分词所以速度远快于 Scanner。要拿到“数字”“单词”这类结构化输入需要我们自己拆BufferedReader reader new BufferedReader(new InputStreamReader(System.in)); StringTokenizer st new StringTokenizer(reader.readLine()); int a Integer.parseInt(st.nextToken()); int b Integer.parseInt(st.nextToken());这套组合在算法竞赛里是标准配置我叫它“快读模板”。它快的原因有两个一是readLine()直接读行没有正则开销二是StringTokenizer比String.split()快后者会编译正则表达式前者只是简单地按分隔符切分。用 BufferedReader 还有一个额外的好处可以精确控制读取过程。比如你想读固定长度的字符数组、想处理超长行、想指定字符集编码Scanner 都很难做到BufferedReader 天生就支持。1.3 Console 与 System.in被忽略的两种路径System.console()这个 API 被很多人遗忘它特别适合做密码输入因为readPassword()不会回显输入内容。但有个大坑在 IDEA、Eclipse 这类 IDE 里直接运行程序System.console()经常返回null因为它要求程序运行在真正的终端环境里。所以这个类可以用来做生产环境的交互脚本但别在 IDE 里测试一测一个空指针。System.in本身是字节流read(byte[])方法可以读原始字节。它在 Java 里用得少但在处理二进制输入、管道重定向输入这些场景时是绕不开的。比如cat data.bin | java -jar processor.jar这种管道模式读标准输入就得用字节流配合 BufferedInputStream 来做。1.4 不同场景输入方式选型速查表我整理了下面这张表按场景给结论直接用就行使用场景推荐方案核心原因练习、小工具、交互式程序ScannerAPI 简单省心算法竞赛、海量文本解析BufferedReader StringTokenizer性能高可控性强密码输入System.console()不回显安全性好二进制/管道输入System.in BufferedInputStream字节级控制生产环境读取配置参数文件、环境变量、命令行参数稳定可运维不用标准输入原则很简单能用文件、参数传递的数据就不要用标准输入标准输入更适合交互式场景真要用标准输入读大量数据就选 BufferedReader。先定场景再选工具别一上来就Scanner梭哈。2. 输入数据的校验与字符串处理从“能用”到“健壮”2.1 判断字符类型字母、数字还是特殊符号面试和实际业务里经常要判断一个输入里是不是“只包含字母和数字”。最简单的做法是直接用Character类char c a; System.out.println(Character.isLetter(c)); // true System.out.println(Character.isDigit(c)); // false System.out.println(Character.isLetterOrDigit(c)); // true但这里有一个容易踩的雷Character.isLetter()对 Unicode 的支持非常宽泛只要是一个字母字符它就返回true。换句话说一个中文汉字调用isLetter()也会返回true。如果你要的“字母”严格限定为英文字母 a-z、A-Z用正则表达式更可靠String input abc123; boolean ok input.matches([a-zA-Z0-9]); System.out.println(ok); // true这套判断逻辑在注册表单、ID 校验、日志脱敏检测里都很常见。我的建议是输入校验统一走“先 trim 去空白再正则整体匹配”的路子Character系列方法适合做单字符的现场判断不适合直接定义整段输入的合法规则。2.2 限制输入长度从源头防住“输入过长”我在搜索热词里看到“输入过长”出现频率很高这确实是实战里经常被问到的点。控制台输入本质上无法在读取前限制长度只能读取后校验并处理String line reader.readLine(); if (line.length() 100) { System.out.println(输入长度超限已截断); line line.substring(0, 100); }如果用的是 GUI 组件比如 Swing 里的JTextField可以设置文档过滤器在键入阶段就限制字符数量。但在纯控制台场景里程序没有“输入框”的概念只能靠事后检查。另一个容易被忽略的“过长”问题出现在文件读取如果用byte[]一次性读一个大文件很可能内存溢出。这种场景应该用带缓冲的流式读取边读边处理不要一次性把整份输入装进内存。2.3 字符串中间插入字符避开性能陷阱搜索热词里有“中间输入字母”“会把后面的取代”“如何中间加字母”这通常是“在字符串的指定位置插入内容”的需求。比如手机号 13800138000 想格式化成 138 0013 8000或者银行卡号每四位加一个空格。最直觉的写法是用StringBuilder.insert()StringBuilder sb new StringBuilder(13800138000); sb.insert(3, ); sb.insert(8, ); System.out.println(sb.toString()); // 138 0013 8000注意insert()的时间复杂度是 O(n)因为每次插入都会把后续字符整体后移。如果你要在一个很长的字符串里插入几十个位置循环里频繁调用insert()会非常浪费。更推荐的做法是倒序遍历原字符串用一个新的StringBuilder从尾部往前拼接或者用正则一步到位String phone 13800138000; String formatted phone.replaceAll((\\d{3})(\\d{4})(\\d{4}), $1 $2 $3); System.out.println(formatted); // 138 0013 8000这里没有“取代后面字符”的诡异行为——只要不反复使用同一个下标做插入就不会串位。最容易犯的错误是“先插了一个字符再按原下标插第二个”结果位置全乱了。要么从后往前插要么每次插入后重新计算位置。2.4 数字输入的边界溢出、异常与精度控制台输入的数字本质是字符串要转成数值就得自己处理边界。最典型的两个问题一是Integer.parseInt(99999999999)会直接抛NumberFormatException因为超出 int 范围二是Double.parseDouble(0.1)做累加时出现精度问题。我的做法是“先捕获、再判断、最后兜底”String numStr scanner.next(); try { int n Integer.parseInt(numStr); System.out.println(解析成功 n); } catch (NumberFormatException e) { System.out.println(不是合法整数或超出 int 范围); }如果业务上明确需要处理超大整数用BigInteger需要精确的金额计算用BigDecimal不要用double。这是很多生产事故的根源尤其是金融相关的功能线上“差一分钱”的问题绝大多数是浮点数精度造成。3. 高频实战解析从算法题到面试手写代码3.1 算法竞赛“快读模板”一套代码吃遍数据量题看到热词里有“蓝桥杯”“冒泡排序 java”“java 蓝桥杯 数字题目”我可以很肯定地说无论蓝桥杯还是 ACM第一题往往不是难在算法而是难在“怎么稳定快速地读入数据”。数据规模上去了Scanner 会超时这是无数新手第一次在评测系统里 TLE超时的原因。我长期使用的模板如下直接复制就可以用import java.io.*; import java.util.*; public class FastIO { public static void main(String[] args) throws IOException { BufferedReader br new BufferedReader(new InputStreamReader(System.in)); StringTokenizer st; StringBuilder out new StringBuilder(); String line; while ((line br.readLine()) ! null !line.isEmpty()) { st new StringTokenizer(line); int a Integer.parseInt(st.nextToken()); int b Integer.parseInt(st.nextToken()); out.append(a b).append(\n); } System.out.print(out); } }这个模板有三个关键设计BufferedReader按行缓冲避免逐字节读取的系统调用开销StringTokenizer按空白符切分单词比split()快StringBuilder缓存所有输出最后一次打印避免大量System.out.println()。整个过程用try-with-resources或 throws 声明都行但注意不要在循环里创建新对象否则 GC 会让你的快读慢回去。3.2 一道经典题输入日期算出是这一年的第几天热词里有一句很显眼“输入一个日期的年、月、日计算并输出这天是该年的第几天”。这类题几乎是所有大学 Java 实验和蓝桥杯初赛的常客它考的核心是“闰年判断 月份天数累加”。闰年规则是能被 400 整除或能被 4 整除但不能被 100 整除。写成代码boolean isLeap(int year) { return (year % 400 0) || (year % 4 0 year % 100 ! 0); }然后配置每月天数表int[] days {31, 28, 31, 30, 31, 30, 31, 31, 30, 31, 30, 31}; if (isLeap(year)) { days[1] 29; }最后累加前 month-1 个月的天数再加上 day。这个实现里最容易错的地方有两个一是二月的天数必须根据闰年动态决定不能写死二是数组下标从 0 开始month 减一才是正确的月份索引。我给一个完整版本public static int dayOfYear(int year, int month, int day) { int[] days {31, 28, 31, 30, 31, 30, 31, 31, 30, 31, 30, 31}; if ((year % 400 0) || (year % 4 0 year % 100 ! 0)) { days[1] 29; } int sum 0; for (int i 0; i month - 1; i) { sum days[i]; } return sum day; }配合前面说的BufferedReader StringTokenizer模板读取三个数字输入输出部分和算法部分就齐了。这类题在考场上的分数差异往往不是算法本身而是能不能稳定地处理输入边界和闰年逻辑。3.3 面试高频考点输入处理相关的手写题面试中输入处理很少单独出一道题但它经常作为“环境题”出现。常见的五个必问考点第一nextLine 与 nextInt 混用问题。这是最经典的“输入翻车”场景面过 Java 的都见过Scanner sc new Scanner(System.in); int n sc.nextInt(); String s sc.nextLine(); // 这里读不到想要的字符串原因很简单nextInt()只读取数字本身把数字后面的换行符留在了缓冲区紧接着的nextLine()读到的就是那个残留换行于是返回空字符串。解决方案有两种一是先nextLine()再手动解析数字二是nextInt()之后手动吞掉换行int n sc.nextInt(); sc.nextLine(); // 消费掉换行符 String s sc.nextLine();第二输入流的关闭时机。Scanner包装了System.in一旦scanner.close()System.in也被关闭后面想再读就什么也读不到。所以小程序随意但复杂程序里不要贸然关闭标准输入流。第三编码问题。new InputStreamReader(System.in)默认使用平台字符集在 Windows 中文环境下可能出现乱码。稳妥做法是指定 UTF-8BufferedReader br new BufferedReader(new InputStreamReader(System.in, StandardCharsets.UTF_8));第四System.console() 的空指针陷阱。上面提过IDE 里运行经常返回 null面试官喜欢问“为什么System.console()在某些环境是 null”答出“非交互终端/IDE 重定向了标准输入输出”基本就过关。第五大数量输入的优化思路。面试官如果追问“百万行输入怎么处理更快”你要能从字节流、字符流、缓冲、分词几层往下拆System.in→BufferedInputStream→InputStreamReader→BufferedReader→ 手动解析或StringTokenizer。能把这套链路讲明白说明你真的理解输入的本质而不只是会调 API。4. 输入相关的报错排查与 Java 环境配置实战4.1 nextLine 与 next 混用最经典的翻车现场我在 3.3 里提了原理这里给一个完整排查实录。某次我帮同事调试一段代码他反复说“读了第一行整数后第二行字符串总是少一个”代码长这样Scanner sc new Scanner(System.in); System.out.print(请输入人数); int count sc.nextInt(); String[] names new String[count]; for (int i 0; i count; i) { System.out.print(请输入姓名); names[i] sc.nextLine(); }运行效果是第一次循环里names[0]直接是空串后面才正常。这就是典型的“nextInt 残留换行”问题。修法是在读完整数后立刻加一行sc.nextLine();或者在输入量不大时干脆全用nextLine()读取后自行Integer.parseInt()转换。从健壮性角度我推荐后者因为把“读哪一行”和“解析成什么类型”彻底分开逻辑更清晰。4.2 “无法定位程序输入点”与 JDK 环境变量配置搜索热词里“无法定位程序输入点 setthreaddescription 于动态链接库”出现多次这类报错在 Windows 上多见于两种情形一是某个软件或游戏缺少对应版本的系统运行库二是 JDK 工具和系统库位数不匹配。如果你在命令行执行java -version时遇到类似“无法定位程序输入点于动态链接库”先不要怀疑 Java 代码而是检查系统是否能正确找到 JVM 的 DLL。排查顺序我习惯这样第一步运行java -version和javac -version确认两个命令来自同一套 JDK。注意这里有个常见坑java命令可能来自C:\Windows\System32下的旧版 Java而javac来自你新装的 JDK两个版本不对应。第二步查看环境变量JAVA_HOME是否指向真实的 JDK 安装目录路径里不要有中文、空格和尾部反斜杠。第三步把%JAVA_HOME%\bin加到Path变量最前面覆盖系统自带的旧 Java。第四步重新打开命令行窗口确保不是旧的缓存环境。配置完可以用下面的命令验证where java where javac echo %JAVA_HOME% java -version如果where java显示的不是%JAVA_HOME%\bin\java说明 PATH 顺序不对继续调整。这类问题和我见过的“操作系统找不到已输入的环境选项”很类似本质都是环境变量没配置好或者版本冲突先冷静排查路径不要急着卸载重装。4.3 我踩过的一些输入相关的小坑这些坑很多是常规教程不会写、但实际调试时一定会遇到的第一hasNext()在控制台交互场景下可能“卡住”。如果你写while (scanner.hasNext())然后在 IDE 里跑程序会一直等待输入因为 IDE 控制台不会自动发送“流结束”信号。想结束得手动输入特殊字符Windows 下是 CtrlZ 后回车Linux/macOS 下是 CtrlD。理解这一点标准输入不关闭hasNext()就一直是true。第二读文件时不要用Scanner默认字符集。尤其对接外部系统生成的 CSV、TXT 时文件可能是 UTF-8、GBK 或带 BOM用默认字符集读很容易出现首字符是\uFEFF、中文乱码之类的问题。建议用new Scanner(file, StandardCharsets.UTF_8)显式指定编码。第三字符串判空不要直接s.equals()。用户可能输入空格、制表符要先trim()。有一次我排查数据导入问题发现一批“空值”其实是全角空格正则\s默认不匹配全角空格要用replaceAll([\\s\\u3000], )处理。第四读取超长行时readLine()并不会截断它会完整返回一整行字符串。如果输入文件里有一行几百 MB 的超长文本内存会被瞬间打爆。生产环境应使用read(char[], off, len)分块读取或在业务层面对单行长度做限制。第五用System.in做生产级输入要非常谨慎。线上 Java 进程的标准输入往往被容器、服务管理脚本占用直接Scanner读会一直阻塞或者读取到意外内容。更好的做法是把“输入源”抽象成InputStream参数测试时传入文件流生产时传入配置或其他来源而不是写死System.in。最后分享一个我自己攒下来的小经验如果你经常参加线上笔试或算法竞赛提前准备一个自己的FastIO模板文件把输入和输出封装成两个静态方法比赛时直接复制能省下大量调试时间。我个人在实际项目里很少真的从标准输入读业务数据但“输入处理”作为基本功的价值在于它逼着你理解字节流、字符流、缓冲、编码、解析错误处理一整条链路。哪天真碰上文件导入、消息解析、外部接口对接你会感谢当初把输入这关看得足够细。
做 Java 这么多年面试过别人也被别人面试过“输入”这两个字几乎每次都绕不开。很多人觉得 Java 输入不就是Scanner scanner new Scanner(System.in)加一句nextLine()吗真到了写算法题、处理高并发日志、或者被面试官追问“你这个输入方式在高数据量下会怎样”的时候才发现自己对 Java 输入的理解还停在“会用”而不是“用好”。这篇内容我就从实际开发、算法竞赛、面试三个场景出发把 Java 输入这件事的方方面面拆开讲透包含完整代码模板、性能对比、常见翻车现场和排查思路新手可以当教程看有经验的朋友可以当查漏补缺的清单用。1. Java 输入的全家桶四种主流方式怎么选1.1 Scanner日常开发首选但不是万能Scanner 是绝大多数人接触 Java 输入的第一个类它内部基于正则表达式做分词默认用空白字符空格、制表符、换行作为分隔符。这种设计让它用起来极其舒服Scanner scanner new Scanner(System.in); int n scanner.nextInt(); String name scanner.next(); String line scanner.nextLine();但这里藏着一个很多人没意识到的性能问题Scanner 的每个nextInt()、next()都会走正则匹配流程数据量小的时候没感觉一旦需要读几万行、几十万行数字速度会明显慢下来。我之前用 Scanner 读一个包含 20 万行整数的测试文件耗时接近 1800 毫秒而同样的数据用 BufferedReader 手动解析不到 400 毫秒就能读完。这个差距在竞赛评测和批量处理场景里就是致命的。所以我的建议是日常写小工具、做练习、写交互式命令行应用放心用 Scanner它够简单、够直观。但如果你知道自己要面对大量数据或者是在写性能敏感的代码趁早切到 BufferedReader 方案。1.2 BufferedReader高性能场景的硬核选手BufferedReader 是字符流它的核心方法是readLine()按行读取文本。它本身不做任何分词所以速度远快于 Scanner。要拿到“数字”“单词”这类结构化输入需要我们自己拆BufferedReader reader new BufferedReader(new InputStreamReader(System.in)); StringTokenizer st new StringTokenizer(reader.readLine()); int a Integer.parseInt(st.nextToken()); int b Integer.parseInt(st.nextToken());这套组合在算法竞赛里是标准配置我叫它“快读模板”。它快的原因有两个一是readLine()直接读行没有正则开销二是StringTokenizer比String.split()快后者会编译正则表达式前者只是简单地按分隔符切分。用 BufferedReader 还有一个额外的好处可以精确控制读取过程。比如你想读固定长度的字符数组、想处理超长行、想指定字符集编码Scanner 都很难做到BufferedReader 天生就支持。1.3 Console 与 System.in被忽略的两种路径System.console()这个 API 被很多人遗忘它特别适合做密码输入因为readPassword()不会回显输入内容。但有个大坑在 IDEA、Eclipse 这类 IDE 里直接运行程序System.console()经常返回null因为它要求程序运行在真正的终端环境里。所以这个类可以用来做生产环境的交互脚本但别在 IDE 里测试一测一个空指针。System.in本身是字节流read(byte[])方法可以读原始字节。它在 Java 里用得少但在处理二进制输入、管道重定向输入这些场景时是绕不开的。比如cat data.bin | java -jar processor.jar这种管道模式读标准输入就得用字节流配合 BufferedInputStream 来做。1.4 不同场景输入方式选型速查表我整理了下面这张表按场景给结论直接用就行使用场景推荐方案核心原因练习、小工具、交互式程序ScannerAPI 简单省心算法竞赛、海量文本解析BufferedReader StringTokenizer性能高可控性强密码输入System.console()不回显安全性好二进制/管道输入System.in BufferedInputStream字节级控制生产环境读取配置参数文件、环境变量、命令行参数稳定可运维不用标准输入原则很简单能用文件、参数传递的数据就不要用标准输入标准输入更适合交互式场景真要用标准输入读大量数据就选 BufferedReader。先定场景再选工具别一上来就Scanner梭哈。2. 输入数据的校验与字符串处理从“能用”到“健壮”2.1 判断字符类型字母、数字还是特殊符号面试和实际业务里经常要判断一个输入里是不是“只包含字母和数字”。最简单的做法是直接用Character类char c a; System.out.println(Character.isLetter(c)); // true System.out.println(Character.isDigit(c)); // false System.out.println(Character.isLetterOrDigit(c)); // true但这里有一个容易踩的雷Character.isLetter()对 Unicode 的支持非常宽泛只要是一个字母字符它就返回true。换句话说一个中文汉字调用isLetter()也会返回true。如果你要的“字母”严格限定为英文字母 a-z、A-Z用正则表达式更可靠String input abc123; boolean ok input.matches([a-zA-Z0-9]); System.out.println(ok); // true这套判断逻辑在注册表单、ID 校验、日志脱敏检测里都很常见。我的建议是输入校验统一走“先 trim 去空白再正则整体匹配”的路子Character系列方法适合做单字符的现场判断不适合直接定义整段输入的合法规则。2.2 限制输入长度从源头防住“输入过长”我在搜索热词里看到“输入过长”出现频率很高这确实是实战里经常被问到的点。控制台输入本质上无法在读取前限制长度只能读取后校验并处理String line reader.readLine(); if (line.length() 100) { System.out.println(输入长度超限已截断); line line.substring(0, 100); }如果用的是 GUI 组件比如 Swing 里的JTextField可以设置文档过滤器在键入阶段就限制字符数量。但在纯控制台场景里程序没有“输入框”的概念只能靠事后检查。另一个容易被忽略的“过长”问题出现在文件读取如果用byte[]一次性读一个大文件很可能内存溢出。这种场景应该用带缓冲的流式读取边读边处理不要一次性把整份输入装进内存。2.3 字符串中间插入字符避开性能陷阱搜索热词里有“中间输入字母”“会把后面的取代”“如何中间加字母”这通常是“在字符串的指定位置插入内容”的需求。比如手机号 13800138000 想格式化成 138 0013 8000或者银行卡号每四位加一个空格。最直觉的写法是用StringBuilder.insert()StringBuilder sb new StringBuilder(13800138000); sb.insert(3, ); sb.insert(8, ); System.out.println(sb.toString()); // 138 0013 8000注意insert()的时间复杂度是 O(n)因为每次插入都会把后续字符整体后移。如果你要在一个很长的字符串里插入几十个位置循环里频繁调用insert()会非常浪费。更推荐的做法是倒序遍历原字符串用一个新的StringBuilder从尾部往前拼接或者用正则一步到位String phone 13800138000; String formatted phone.replaceAll((\\d{3})(\\d{4})(\\d{4}), $1 $2 $3); System.out.println(formatted); // 138 0013 8000这里没有“取代后面字符”的诡异行为——只要不反复使用同一个下标做插入就不会串位。最容易犯的错误是“先插了一个字符再按原下标插第二个”结果位置全乱了。要么从后往前插要么每次插入后重新计算位置。2.4 数字输入的边界溢出、异常与精度控制台输入的数字本质是字符串要转成数值就得自己处理边界。最典型的两个问题一是Integer.parseInt(99999999999)会直接抛NumberFormatException因为超出 int 范围二是Double.parseDouble(0.1)做累加时出现精度问题。我的做法是“先捕获、再判断、最后兜底”String numStr scanner.next(); try { int n Integer.parseInt(numStr); System.out.println(解析成功 n); } catch (NumberFormatException e) { System.out.println(不是合法整数或超出 int 范围); }如果业务上明确需要处理超大整数用BigInteger需要精确的金额计算用BigDecimal不要用double。这是很多生产事故的根源尤其是金融相关的功能线上“差一分钱”的问题绝大多数是浮点数精度造成。3. 高频实战解析从算法题到面试手写代码3.1 算法竞赛“快读模板”一套代码吃遍数据量题看到热词里有“蓝桥杯”“冒泡排序 java”“java 蓝桥杯 数字题目”我可以很肯定地说无论蓝桥杯还是 ACM第一题往往不是难在算法而是难在“怎么稳定快速地读入数据”。数据规模上去了Scanner 会超时这是无数新手第一次在评测系统里 TLE超时的原因。我长期使用的模板如下直接复制就可以用import java.io.*; import java.util.*; public class FastIO { public static void main(String[] args) throws IOException { BufferedReader br new BufferedReader(new InputStreamReader(System.in)); StringTokenizer st; StringBuilder out new StringBuilder(); String line; while ((line br.readLine()) ! null !line.isEmpty()) { st new StringTokenizer(line); int a Integer.parseInt(st.nextToken()); int b Integer.parseInt(st.nextToken()); out.append(a b).append(\n); } System.out.print(out); } }这个模板有三个关键设计BufferedReader按行缓冲避免逐字节读取的系统调用开销StringTokenizer按空白符切分单词比split()快StringBuilder缓存所有输出最后一次打印避免大量System.out.println()。整个过程用try-with-resources或 throws 声明都行但注意不要在循环里创建新对象否则 GC 会让你的快读慢回去。3.2 一道经典题输入日期算出是这一年的第几天热词里有一句很显眼“输入一个日期的年、月、日计算并输出这天是该年的第几天”。这类题几乎是所有大学 Java 实验和蓝桥杯初赛的常客它考的核心是“闰年判断 月份天数累加”。闰年规则是能被 400 整除或能被 4 整除但不能被 100 整除。写成代码boolean isLeap(int year) { return (year % 400 0) || (year % 4 0 year % 100 ! 0); }然后配置每月天数表int[] days {31, 28, 31, 30, 31, 30, 31, 31, 30, 31, 30, 31}; if (isLeap(year)) { days[1] 29; }最后累加前 month-1 个月的天数再加上 day。这个实现里最容易错的地方有两个一是二月的天数必须根据闰年动态决定不能写死二是数组下标从 0 开始month 减一才是正确的月份索引。我给一个完整版本public static int dayOfYear(int year, int month, int day) { int[] days {31, 28, 31, 30, 31, 30, 31, 31, 30, 31, 30, 31}; if ((year % 400 0) || (year % 4 0 year % 100 ! 0)) { days[1] 29; } int sum 0; for (int i 0; i month - 1; i) { sum days[i]; } return sum day; }配合前面说的BufferedReader StringTokenizer模板读取三个数字输入输出部分和算法部分就齐了。这类题在考场上的分数差异往往不是算法本身而是能不能稳定地处理输入边界和闰年逻辑。3.3 面试高频考点输入处理相关的手写题面试中输入处理很少单独出一道题但它经常作为“环境题”出现。常见的五个必问考点第一nextLine 与 nextInt 混用问题。这是最经典的“输入翻车”场景面过 Java 的都见过Scanner sc new Scanner(System.in); int n sc.nextInt(); String s sc.nextLine(); // 这里读不到想要的字符串原因很简单nextInt()只读取数字本身把数字后面的换行符留在了缓冲区紧接着的nextLine()读到的就是那个残留换行于是返回空字符串。解决方案有两种一是先nextLine()再手动解析数字二是nextInt()之后手动吞掉换行int n sc.nextInt(); sc.nextLine(); // 消费掉换行符 String s sc.nextLine();第二输入流的关闭时机。Scanner包装了System.in一旦scanner.close()System.in也被关闭后面想再读就什么也读不到。所以小程序随意但复杂程序里不要贸然关闭标准输入流。第三编码问题。new InputStreamReader(System.in)默认使用平台字符集在 Windows 中文环境下可能出现乱码。稳妥做法是指定 UTF-8BufferedReader br new BufferedReader(new InputStreamReader(System.in, StandardCharsets.UTF_8));第四System.console() 的空指针陷阱。上面提过IDE 里运行经常返回 null面试官喜欢问“为什么System.console()在某些环境是 null”答出“非交互终端/IDE 重定向了标准输入输出”基本就过关。第五大数量输入的优化思路。面试官如果追问“百万行输入怎么处理更快”你要能从字节流、字符流、缓冲、分词几层往下拆System.in→BufferedInputStream→InputStreamReader→BufferedReader→ 手动解析或StringTokenizer。能把这套链路讲明白说明你真的理解输入的本质而不只是会调 API。4. 输入相关的报错排查与 Java 环境配置实战4.1 nextLine 与 next 混用最经典的翻车现场我在 3.3 里提了原理这里给一个完整排查实录。某次我帮同事调试一段代码他反复说“读了第一行整数后第二行字符串总是少一个”代码长这样Scanner sc new Scanner(System.in); System.out.print(请输入人数); int count sc.nextInt(); String[] names new String[count]; for (int i 0; i count; i) { System.out.print(请输入姓名); names[i] sc.nextLine(); }运行效果是第一次循环里names[0]直接是空串后面才正常。这就是典型的“nextInt 残留换行”问题。修法是在读完整数后立刻加一行sc.nextLine();或者在输入量不大时干脆全用nextLine()读取后自行Integer.parseInt()转换。从健壮性角度我推荐后者因为把“读哪一行”和“解析成什么类型”彻底分开逻辑更清晰。4.2 “无法定位程序输入点”与 JDK 环境变量配置搜索热词里“无法定位程序输入点 setthreaddescription 于动态链接库”出现多次这类报错在 Windows 上多见于两种情形一是某个软件或游戏缺少对应版本的系统运行库二是 JDK 工具和系统库位数不匹配。如果你在命令行执行java -version时遇到类似“无法定位程序输入点于动态链接库”先不要怀疑 Java 代码而是检查系统是否能正确找到 JVM 的 DLL。排查顺序我习惯这样第一步运行java -version和javac -version确认两个命令来自同一套 JDK。注意这里有个常见坑java命令可能来自C:\Windows\System32下的旧版 Java而javac来自你新装的 JDK两个版本不对应。第二步查看环境变量JAVA_HOME是否指向真实的 JDK 安装目录路径里不要有中文、空格和尾部反斜杠。第三步把%JAVA_HOME%\bin加到Path变量最前面覆盖系统自带的旧 Java。第四步重新打开命令行窗口确保不是旧的缓存环境。配置完可以用下面的命令验证where java where javac echo %JAVA_HOME% java -version如果where java显示的不是%JAVA_HOME%\bin\java说明 PATH 顺序不对继续调整。这类问题和我见过的“操作系统找不到已输入的环境选项”很类似本质都是环境变量没配置好或者版本冲突先冷静排查路径不要急着卸载重装。4.3 我踩过的一些输入相关的小坑这些坑很多是常规教程不会写、但实际调试时一定会遇到的第一hasNext()在控制台交互场景下可能“卡住”。如果你写while (scanner.hasNext())然后在 IDE 里跑程序会一直等待输入因为 IDE 控制台不会自动发送“流结束”信号。想结束得手动输入特殊字符Windows 下是 CtrlZ 后回车Linux/macOS 下是 CtrlD。理解这一点标准输入不关闭hasNext()就一直是true。第二读文件时不要用Scanner默认字符集。尤其对接外部系统生成的 CSV、TXT 时文件可能是 UTF-8、GBK 或带 BOM用默认字符集读很容易出现首字符是\uFEFF、中文乱码之类的问题。建议用new Scanner(file, StandardCharsets.UTF_8)显式指定编码。第三字符串判空不要直接s.equals()。用户可能输入空格、制表符要先trim()。有一次我排查数据导入问题发现一批“空值”其实是全角空格正则\s默认不匹配全角空格要用replaceAll([\\s\\u3000], )处理。第四读取超长行时readLine()并不会截断它会完整返回一整行字符串。如果输入文件里有一行几百 MB 的超长文本内存会被瞬间打爆。生产环境应使用read(char[], off, len)分块读取或在业务层面对单行长度做限制。第五用System.in做生产级输入要非常谨慎。线上 Java 进程的标准输入往往被容器、服务管理脚本占用直接Scanner读会一直阻塞或者读取到意外内容。更好的做法是把“输入源”抽象成InputStream参数测试时传入文件流生产时传入配置或其他来源而不是写死System.in。最后分享一个我自己攒下来的小经验如果你经常参加线上笔试或算法竞赛提前准备一个自己的FastIO模板文件把输入和输出封装成两个静态方法比赛时直接复制能省下大量调试时间。我个人在实际项目里很少真的从标准输入读业务数据但“输入处理”作为基本功的价值在于它逼着你理解字节流、字符流、缓冲、编码、解析错误处理一整条链路。哪天真碰上文件导入、消息解析、外部接口对接你会感谢当初把输入这关看得足够细。
