在Java里聊“输入”很多人觉得没什么可聊的无非就是那行new Scanner(System.in)。但我带新人、改老代码、自己刷题的时候被“输入”这俩字坑过的次数真不算少nextInt()之后接nextLine()读到空串、数据量一大 Scanner 慢到怀疑人生、中文 Windows 控制台乱码、甚至程序卡住半天不知道在等什么。这篇文章我就从最底层的System.in这个字节流讲起把 Java 输入的前世今生、五种常见输入方式的选型逻辑、以及那些高频面试题和实战采坑点一次性讲透。适合刚学 Java 基础的同学建立完整认知也适合写过一阵子代码但遇到输入报错只能靠百度的朋友按图索骥把问题摁死。1. Java输入的基本盘从System.in到Scanner1.1 System.in到底是何方神圣很多同学第一次接触输入就是用 Scanner从来没想过它背后是什么。其实System类是java.lang下的一个 final 类里面有个静态字段叫in类型是java.io.InputStream。这个System.in就是标准输入流对应操作系统里的文件描述符 0正常情况下就是键盘输入但在命令行运行程序时也可以用重定向到文件用管道接收另一个程序的输出。InputStream本身是个抽象类它最核心的方法就一个read()返回int表示读到一个字节读不到就返回 -1。所以如果你直接拿System.in读用户输入体验相当原始public class RawRead { public static void main(String[] args) throws Exception { int b System.in.read(); System.out.println(读到的字节 b 对应字符 (char) b); } }运行后输入一个a回车会输出97因为a的 ASCII 码就是 97。这个 API 有两个硬伤一是每次只读一个字节输入一个中文字符要读两到三个字节才能拼完整二是要自己对字节做解码、拼装、按空格分割这套工作在 Java 1.0 时代只能靠程序员手写非常痛苦。所以 Java 标准库在InputStream之上又套了一层又一层目的就是让“读输入”这件事从“手动拼字节”变成“按行读字符串”再变成“按类型读整数、浮点数”。理解这条演化线后面所有 API 的选型就都串起来了。1.2 字节流到字符流的桥接从字节到字符中间的桥梁是InputStreamReader。它接收一个InputStream再指定一个字符集Charset完成字节到字符的解码。如果只写new InputStreamReader(System.in)它会用 JVM 默认的字符集在中文 Windows 上通常是 GBK在 macOS 和 Linux 上通常是 UTF-8这就埋下了跨平台乱码的种子。更常用的是在InputStreamReader外面再包一层BufferedReader。BufferedReader内部维护了一个默认 8192 字节的缓冲区调用readLine()时不是一个个字节地去读而是批量把数据塞进缓冲区从缓冲区里扫描换行符并切出整行字符串。这个缓冲机制是它性能远好于裸读的关键。BufferedReader reader new BufferedReader(new InputStreamReader(System.in, StandardCharsets.UTF_8)); String line reader.readLine();这一行代码解决了三件事字符集可控、按行读取、缓冲加速。但它的缺点也很明显——想读一个整数你得自己Integer.parseInt(line)想读多个数字还得自己 split所以后来 JDK 1.5 索性提供了 Scanner把这些脏活全包了。1.3 Scanner的包装逻辑Scanner 的设计思路是把输入流当成一个 token 流。什么是 token就是按分隔符切出来的一个个小块默认分隔符是空白字符包括空格、制表符、换行在正则里写作\p{javaWhitespace}。你调用nextInt()它就去找下一个 token并尝试把它解析成整数调用next()就返回下一个 token 的字符串调用nextLine()则特殊一点它不以空白为分隔而是读到换行符为止把一整行原样返回。这种设计对日常交互输入极其友好写起来像聊天一样。但代价是它的解析基于正则表达式每次nextInt()都要走一遍正则匹配再转类型高频大量读数据时开销明显。关于性能差距后面我会给一个实测对比。这里先记住一个结论面向人类输入用 Scanner面向大文件或大量结构化数据用 BufferedReader 组合方案。2. 五种输入方式横评场景、性能与选型2.1 一张表看清五种方式的定位输入方式核心 API特点适用场景Scannernew Scanner(System.in)API 友好支持 token 级解析交互式小数据量输入、学习阶段BufferedReader字节流转字符流加缓冲按行读取性能高OJ 刷题、日志处理、超大文本ConsoleSystem.console().readLine()支持密码不回显依赖真实终端命令行交互工具、密码程序命令行参数main(String[] args)启动时一次性传入无交互配置参数、批量脚本JOptionPane弹窗读入图形界面输入Swing 桌面小工具2.2 Scanner交互首选需要写一两行输入的学习代码、小工具我直接用 Scanner理由就一条省事。你不用关心字符集转换不用手动拆分字符串nextInt()、nextDouble()、nextBoolean()一把梭。比如写一个猜数字小游戏Scanner sc new Scanner(System.in); int answer (int) (Math.random() * 100) 1; int guess; do { guess sc.nextInt(); System.out.println(guess answer ? 大了 : guess answer ? 小了 : 中了); } while (guess ! answer); sc.close();这段代码读起来几乎没有噪音。但我必须提醒两个隐患第一Scanner 的close()会顺带关闭System.in而System.in是整个 JVM 共享的一旦关闭就无法重新打开一个程序里后续想再读输入就会直接崩第二如果你在循环里用nextInt()用户敲了一个非数字字符程序会抛InputMismatchException而且那个错误字符还留在缓冲区里处理不好就是死循环。2.3 BufferedReader性能与稳定性如果场景变成“从标准输入读几万行整数每行若干个数”Scanner 会明显吃力。刷过算法的朋友应该都有印象很多 OJ 题解里统一用BufferedReader br new BufferedReader(new InputStreamReader(System.in)); StringTokenizer st new StringTokenizer(br.readLine()); int n Integer.parseInt(st.nextToken());这里出现了一个不太常被新人注意的组合StringTokenizer专门负责按空白切 token比手动String.split( )略快也更省内存。StringTokenizer是遗留类但在这个场景里它仍然非常好用因为它的语义就是“逐 token 消费”不需要把整行拆成字符串数组再遍历。用 BufferedReader 还有一个隐藏收益它对输入异常更宽容。你拿到一整行之后可以先用正则或StringUtils.isNumeric之类的检查再解析而不是让底层库替你做“读到一半爆炸”的决定。对稳定性要求高的程序这个控制权很重要。2.4 Console交互和密码安全System.console()在很多教程里很少出场但它有一个 Scanner 完全替代不了的能力readPassword()可以在终端里不回显用户输入的密码返回char[]而不是String。为什么返回数组因为字符串一旦创建就不可变地留在内存里而字符数组用完可以手动Arrays.fill()清掉降低密码被内存转储抓走的概率。Console console System.console(); if (console null) { System.err.println(当前环境不支持Console比如IDE里); return; } char[] pwd console.readPassword(请输入密码); console.printf(密码长度%d%n, pwd.length); Arrays.fill(pwd, );注意console可能是null——在 IDEA 的 Run 窗口、Eclipse 的控制台或者输入被重定向时它拿不到真正的终端对象一调用就空指针。所以生产代码里必须先判空。2.5 命令行参数和图形界面的补充命令行参数适合那种“启动时一次性给参数”的程序比如指定端口号、文件路径。它根本不做交互输入发生在进程启动之前由 shell 解析后传进main方法。优点是程序内部逻辑简单不用关心阻塞和解析缺点是不能中途换参数。JOptionPane 则是完全另一条路String name JOptionPane.showInputDialog(请输入你的名字);它会弹出一个对话框把用户输入作为字符串返回。适合快速做桌面小工具或者给非技术人员用的 Swing 程序。但它依赖图形环境在无显示器环境或 Windows 服务里根本弹不出来这也是一种“环境制约”的输入方式。实践中我把五种方案的边界总结成一句话交互优先 Scanner性能优先 BufferedReader密码优先 Console启动参数走 args图形界面用 JOptionPane。没有万能方案只有是否匹配场景。3. 核心实操细节next()与nextLine()的爱恨情仇3.1 一字之差两种命运先写一段对比代码感受next()和nextLine()最直观的区别Scanner sc new Scanner(System.in); System.out.print(输入内容); // 输入hello world String a sc.next(); String b sc.next(); System.out.println(第一次next a); System.out.println(第二次next b);输入hello world后a是hellob是world。next()以空白字符为界连续调用能把一行里的多个 token 依次读走。但如果你用nextLine()String c sc.nextLine(); // 输入hello world System.out.println(一次nextLine c);c是整个hello world包括中间的空格。nextLine()的语义是“读取直到换行符为止并丢弃换行符”。所以这两个方法的分工完全不同一个面向“词”一个面向“行”。3.2 经典翻车现场nextInt()后nextLine()这是我在各种技术群里见到的第一大护法级踩坑题Scanner sc new Scanner(System.in); int age sc.nextInt(); System.out.print(输入姓名); String name sc.nextLine(); System.out.println(age , name);输入25回车然后再输入张三回车结果name是空串直接输出25,。原因要先弄明白缓冲区的状态nextInt()读到25后停下但那个回车产生的换行符还留在缓冲区里。紧接着nextLine()的任务是“读到换行符为止”它发现缓冲区里第一个字符正好是残留的换行符于是直接返回空字符串并消费掉这个换行符。你“等待”输入姓名这一步被彻底跳过了。解决思路有两个方向。方向一是消化掉残留换行int age sc.nextInt(); sc.nextLine(); // 吃掉换行符 String name sc.nextLine();方向二是干脆不用nextInt()统一用nextLine()读行再手动解析int age Integer.parseInt(sc.nextLine()); String name sc.nextLine();我这个强迫症在实际项目中只认第二种。原因很简单它规避了所有“字符串和数值跨方法残留”的问题解析失败还能在 try-catch 里给出明确提示用户体验好得多。3.3 定制分隔符与批量读取Scanner 的分隔符是可以改的。比如有个输入是需要用逗号分割的1,2,3Scanner sc new Scanner(System.in).useDelimiter([,\\s]); while (sc.hasNextInt()) { System.out.println(sc.nextInt()); }这里[,\s]表示把逗号和空白组成的分隔块整体当作分隔符于是1,2,3和1, 2, 3都能正确解析。useDelimiter接受正则表达式所以可以设计出很多灵活规则。但我不建议把分隔符设计得太花哨因为正则表达式的脆弱性和维护成本都会随之上升输入里出现一个意料外的标点解析就崩了。如果业务场景复杂优先考虑“读一行按分隔符拆拆完校验字段数”比在 Scanner 里堆正则收敛得多。处理“不知道会输入多少行”的场景时核心是hasNext()循环。程序可以是Scanner sc new Scanner(System.in); int sum 0; while (sc.hasNextInt()) { sum sc.nextInt(); } System.out.println(sum);从文件重定向输入时读到文件末尾hasNextInt()自动返回 false在命令行手动交互时Linux 终端要按CtrlD发送 EOFWindows 控制台按CtrlZ再回车程序才会结束。这个“看似卡死”的阻塞行为经常让新人误以为 bug其实是标准输入流在等结束信号。3.4 混合输入的安全姿势如果一行里既有数字又有字符串比如“3 个苹果、5 个梨”这种结构化输入我最稳的写法是三段式先nextLine()读一整行再按空格或逗号拆成数组逐段解析Scanner sc new Scanner(System.in); while (sc.hasNextLine()) { String line sc.nextLine().trim(); if (line.isEmpty()) { continue; } String[] parts line.split(\\s); // parts[0] 是数量parts[1] 是名称 int count Integer.parseInt(parts[0]); String name parts[1]; System.out.println(count 个 name); }这套写法的精髓在于你不依赖 Scanner 内部的“跨 token 状态”每一行的解析都是独立事务出错了只影响当前行不会把后续数据搞乱。这对我来说是在线上程序和刷题中都经过验证的稳如老狗方案。4. 常见问题与排查技巧实录4.1 InputMismatchException类型不匹配用户被要求输入整数结果敲了abcnextInt()直接抛InputMismatchException。更麻烦的是输入一直留在缓冲区里下一次循环还会继续读同一个坏字符导致无限崩溃。我的处理模板是Scanner sc new Scanner(System.in); while (true) { System.out.print(请输入整数); if (sc.hasNextInt()) { int n sc.nextInt(); System.out.println(你输入了 n); break; } else { System.out.println(那不是整数 sc.next()); } }先用hasNextInt()探测再用next()把坏 token 消费掉。这个模式和前面“统一 nextLine 再解析”是等价的只是 API 层面更简洁。我建议在需要反复尝试的交互逻辑里直接套这个模板。4.2 中文乱码编码问题的根源中文乱码十有八九是“编码和解码不匹配”。System.in给到的是字节流字节本身没有编码概念InputStreamReader负责解码时需要指定 Charset如果 JVM 默认字符集和你终端实际使用的字符集不一致中文就会变成或å¼ ä¸这种天书。排查步骤很固定先确认终端用的什么编码Windows 控制台通常 GBK/936 代码页Linux 终端多半 UTF-8再看 JVM 默认编码Charset.defaultCharset()能打印出来。代码里显式给字符集是最保险的做法new BufferedReader(new InputStreamReader(System.in, StandardCharsets.UTF_8));如果你用的是 Scanner可以换成new Scanner(System.in, UTF-8)。还有一种常见处理是把 Windows 控制台代码页切到 UTF-8执行chcp 65001再运行 Java 程序但这种方式对老版本终端兼容性一般不如代码层面锁死字符集来得可靠。4.3 输入过长缓冲区与内存边界“输入过长”在不同场景有不同表现。小规模交互时Scanner 的 token 长度受其内部缓冲区限制超过一定长度可能报 “Input length exceeds input buffer limit”尤其在早期 JDK 上更明显。处理大批数据时一次性把整个标准输入读成一个超大字符串再解析内存直接被吃满GC 扛不住。正确的思路是流式处理能按行读就按行读能按块读就按块读绝不把整个流存在一个 String 里。如果确实需要全量处理也要用 StringBuilder 分块追加并且时刻关注内容长度上限。我做过一个处理几千万行数据的程序深有体会BufferedReader 按行读、处理完就释放该行的引用内存峰值稳定在一两百 MB改用一次性readAllLines后JVM 堆直接飙到 2GB 以上还触发 Full GC。4.4 程序卡住不动阻塞与EOF程序运行后没有任何输出、光标一直闪极大可能是readLine()或next()正在等待输入。这种“阻塞式读取”是标准输入的正常行为不是死锁。在自动化测试里要模拟输入不要用交互式键盘直接用管道或重定向echo 123 | java Main或者java Main data.txt。如果在代码里遇到需要“不要阻塞”的输入需求例如实时检测是否有输入到来可以考虑用System.in.available()做非零判断或者引入独立线程做输入监听。4.5 性能对比实测Scanner vs BufferedReader我拿一万行、每行两个整数的数据做过简单对比Scanner 循环调用nextInt()大约需要几百毫秒BufferedReader 配StringTokenizer大概几十毫秒数量级上差 5 到 10 倍。原因不是“BufferedReader 名字里带 buffer”而是 Scanner 的nextInt()要跑正则匹配这个开销对高频解析来说是实打实的。再往上到十万行、百万行差距会被放大得更明显。所以我在 OJ 题解或者大数据预处理脚本里一律走 BufferedReader只有写交互式 demo 时才用 Scanner。4.6 顺带澄清无法定位程序输入点很多人在安装 Java 相关软件时见过 “无法定位程序输入点 setthreaddescription 于动态链接库” 这一类的弹窗。这其实是 Windows 加载 DLL 时某个 exe 或 dll 的导入表里声明要用的函数在目标 DLL 中找不到。常见原因是 DLL 版本不对、运行库缺失比如 MSVC 运行库太旧、或者一个程序混用了不同版本的工具链。处理这类问题要顺着“谁调用谁”找依赖链看报错弹窗属于哪个程序把它依赖的 C 运行库重新装一遍或升级到对应版本多半就消停了。这不是 Java 语言本身的 bug而是本地库依赖管理问题在 Java 通过 JNI 调用本地方法时也同样会碰到所以排查思路要放在“系统运行库完整性”上。5. 从输入到面试高频考点与背后原理5.1 next()与nextLine()的面试标准答案面试官一旦问到 Java 输入九成会先抛这个题。回答的要点分三层默认分隔符不同next()按空白字符切 tokennextLine()按换行符切整行对空白字符的处理不同next()会跳过开头的空白nextLine()不会跳过任何东西对缓冲区的影响不同next()之后可能残留换行符导致后续nextLine()读到空串。如果能现场画个“缓冲区状态变化”的示意图再举例子说明nextInt()之后nextLine()会翻车这个回答基本就满了。5.2 字节流到字符流的桥接考法另一个高频题是“为什么不用System.in.read()直接读”回答要从字节、字符、缓冲、类型解析四个层面展开字节流只解决“从键盘拿字节”的问题字符流解决“把字节变成我可读的字符串”的问题缓冲解决“减少系统调用、按行读”的体验问题Scanner 解决“把字符串变成 int double 等类型”的便利问题。每条对应一层包装最后形成链式关系System.in-InputStreamReader-BufferedReader- 你自己的解析逻辑。如果你能顺带提一句Scanner内部是正则驱动的 token 解析还能把为什么它慢也说清楚面试官会觉得你不是背 API 而是懂设计。5.3 大量输入和“Java是静态链接的吗”刷算法题的老手会经常聊“读入提速”这个话题。除了 BufferedReader还可以用StreamTokenizer进一步提速。StreamTokenizer读的是字节流直接用数字解析连字符串对象都省了适合“全是整数、不需要字符串”的极端场景。但它的 API 设计很别扭可读性差我只在性能瓶颈确凿时才会动用。热搜词里还有个“java是静态链接的”这个问题和输入本身关联不大但值得解释清楚传统 Java 走的是动态链接模型.class字节码在运行时由类加载器按需加载符号引用在类加载和解析阶段变成具体引用如果说的“静态链接”指 GraalVM Native Image 那种把字节码 AOT 编译成原生可执行文件的方式那类加载模型会变成静态化反射、资源访问、ServiceLoader都需要额外配置。对输入 API 来说BufferedReader和Scanner在原生镜像下都能正常用但System.console()在纯原生环境可能受终端支持影响这个细节在写命令行工具时要留意。5.4 输入处理的完整实战蓝桥杯日期天数题最后用一个经典的日期天数题把前面所有知识串起来输入年、月、日输出这是该年的第几天。BufferedReader br new BufferedReader(new InputStreamReader(System.in, StandardCharsets.UTF_8)); String line br.readLine(); String[] parts line.trim().split(\\s); int year Integer.parseInt(parts[0]); int month Integer.parseInt(parts[1]); int day Integer.parseInt(parts[2]); int[] daysInMonth {31, 28, 31, 30, 31, 30, 31, 31, 30, 31, 30, 31}; if ((year % 4 0 year % 100 ! 0) || year % 400 0) { daysInMonth[1] 29; } int dayOfYear 0; for (int i 0; i month - 1; i) { dayOfYear daysInMonth[i]; } dayOfYear day; System.out.println(dayOfYear);这个实现有清晰的输入处理链按行读、按空白拆、按规则解析、再算逻辑。如果要强调性能可以把“月度累计天数”换成前缀和数组这一步就是很典型的空间换时间优化。如果你在更自由的开发环境里也可以直接LocalDate.of(year, month, day).getDayOfYear()但是 OJ 场景通常不允许用日期库手写仍然是基本功。我在实际项目里养成的习惯是所有来自用户的标准输入先落到一行字符串再设计解析规则所有来自文件的输入始终按流式逐行处理并明确指定字符集。这套思路帮我少踩了很多莫名其妙的坑尤其是中英文混合输入和跨平台部署时。如果你只能记住这篇文章里的一句话那就记住这句Java 输入解决的不只是“怎么读到数据”而是“从哪个层级的 API 开始读、读到哪个抽象层再解析、出错时怎么让用户明白并重新输入”。把这三件事想清楚输入这块的代码就基本不会动摇。