应优先用hasnextxxx()判断再调用nextxxx()，避免流读尽后抛nosuchelementexception；读中文需显式指定utf-8编码；适合小规模结构化文本解析，大文件或高性能场景应选bufferedreader。
Scanner读文件时抛出NoSuchElementException怎么办
根本原因不是文件没找到，而是Scanner已经把输入流读完了，还继续调用next()或nextInt()这类“不带检查的读取方法”。它不会自动停，只会硬刚到流末尾然后崩。
实操建议：
立即学习“Java免费学习笔记（深入）”；
- 永远优先用
hasNextXxx()判断再读，比如hasNextLine()配nextLine()，hasNextInt()配nextInt() - 别混用
nextLine()和nextXXX()（如nextInt()），后者不吞掉换行符，下一次nextLine()会立刻返回空字符串——这是最常踩的坑 - 如果只是逐行读，直接用
while (scanner.hasNextLine()) { String line = scanner.nextLine(); ... }，绕开所有类型匹配逻辑
用Scanner读中文文本乱码怎么解决
默认编码是平台本地编码（Windows上通常是GBK），而现代文本文件基本是UTF-8。Scanner自己不猜编码，你不说，它就按系统默认来解，一读中文就变问号或方块。
实操建议：
立即学习“Java免费学习笔记（深入）”；
- 构造
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真有用武之地。
实操建议：
立即学习“Java免费学习笔记（深入）”；
- 适合结构清晰、字段分隔明确的简单文本，比如一行一个整数、空格分隔的坐标对
"12 34"、带冒号的键值"name: Alice" - 需要混合读不同类型（int + string + double）且不想手动
split()和parseInt()时，Scanner的nextXXX()省心 - 千万别用它读大文件（>1MB）或做高频IO，
Scanner内部缓冲区小，频繁触发底层read()调用，性能雪崩
关闭Scanner后文件句柄没释放？
Scanner本身不持有文件句柄，但它包装的底层InputStream或Readable才持有着。调用scanner.close()会级联关闭它包装的对象——前提是这个对象不是你自己传进去还复用的。
实操建议：
立即学习“Java免费学习笔记（深入）”；
- 如果你传的是
new FileInputStream(...)，关Scanner就等于关了流，安全 - 如果你传的是
System.in或某个被多个地方共用的InputStream，关Scanner会导致其他地方读失败——这时别关，或者确认没人再用它 - 用try-with-resources最省心：
try (Scanner sc = new Scanner(new FileInputStream("x.txt"), "UTF-8")) { ... }，异常或正常结束都会关
Scanner不是万能文本入口，它省事的地方恰恰是它脆弱的地方：类型推断依赖格式稳定，编码靠你指定，流生命周期得你理清。拿它当“快速原型解析器”很顺手，一旦需求变复杂，比如要跳过注释、处理嵌套结构、容错恢复，就得换更专业的工具了。
