JavaScanner读取文件方法详解

Java Scanner虽为文本解析提供便捷的类型化读取能力，但其易用性背后暗藏诸多陷阱：必须配合hasNextXxx()预判避免NoSuchElementException，需显式指定UTF-8编码以防中文乱码，且因内置词法分析和频繁IO而性能远逊BufferedReader；它仅适合小规模、结构清晰、分隔明确的简单文本解析场景，一旦涉及大文件、混合编码、流复用或复杂语法，便需转向更健壮的方案——理解Scanner的边界，恰是高效、安全使用它的开始。

Scanner读文件时抛出NoSuchElementException怎么办

根本原因不是文件没找到，而是Scanner已经把输入流读完了，还继续调用next()或nextInt()这类“不带检查的读取方法”。它不会自动停，只会硬刚到流末尾然后崩。

实操建议：

• 永远优先用hasNextXxx()判断再读，比如hasNextLine()配nextLine()，hasNextInt()配nextInt()
• 别混用nextLine()和nextXXX()（如nextInt()），后者不吞掉换行符，下一次nextLine()会立刻返回空字符串——这是最常踩的坑
• 如果只是逐行读，直接用while (scanner.hasNextLine()) { String line = scanner.nextLine(); ... }，绕开所有类型匹配逻辑

用Scanner读中文文本乱码怎么解决

默认编码是平台本地编码（Windows上通常是GBK），而现代文本文件基本是UTF-8。Scanner自己不猜编码，你不说，它就按系统默认来解，一读中文就变问号或方块。

实操建议：

• 构造Scanner时显式指定编码：new Scanner(new File("data.txt"), "UTF-8")
• 更稳妥的做法是用InputStream包装： new Scanner(new FileInputStream("data.txt"), "UTF-8")，避免File路径含空格或特殊字符时出问题
• 别依赖System.getProperty("file.encoding")，它不可靠，且不能动态改Scanner行为

Scanner比BufferedReader慢很多，什么场景还能用它

Scanner本质是带词法分析的解析器，每调一次nextXXX()都要做正则匹配、类型转换、异常捕获。BufferedReader只管按行吐字符串，快一个数量级。但Scanner真有用武之地。

实操建议：

• 适合结构清晰、字段分隔明确的简单文本，比如一行一个整数、空格分隔的坐标对"12 34"、带冒号的键值"name: Alice"
• 需要混合读不同类型（int + string + double）且不想手动split()和parseInt()时，Scanner的nextXXX()省心
• 千万别用它读大文件（>1MB）或做高频IO，Scanner内部缓冲区小，频繁触发底层read()调用，性能雪崩

关闭Scanner后文件句柄没释放？

Scanner本身不持有文件句柄，但它包装的底层InputStream或Readable才持有着。调用scanner.close()会级联关闭它包装的对象——前提是这个对象不是你自己传进去还复用的。

实操建议：

• 如果你传的是new FileInputStream(...)，关Scanner就等于关了流，安全
• 如果你传的是System.in或某个被多个地方共用的InputStream，关Scanner会导致其他地方读失败——这时别关，或者确认没人再用它
• 用try-with-resources最省心：try (Scanner sc = new Scanner(new FileInputStream("x.txt"), "UTF-8")) { ... }，异常或正常结束都会关

Scanner不是万能文本入口，它省事的地方恰恰是它脆弱的地方：类型推断依赖格式稳定，编码靠你指定，流生命周期得你理清。拿它当“快速原型解析器”很顺手，一旦需求变复杂，比如要跳过注释、处理嵌套结构、容错恢复，就得换更专业的工具了。

今天带大家了解了的相关知识，希望对你有所帮助；关于文章的技术知识我们会一点点深入介绍，欢迎大家关注golang学习网公众号，一起学习编程~