Files.lines()抛IOException是因为其Stream懒加载，异常在终端操作时才暴露；应优先用Files.readAllLines()立即报错；注意路径、BOM、空行分割、中文乱码及BufferedReader优于Scanner。
Java读取诗词文本文件时，为什么Files.lines()会抛IOException？
因为Files.lines()返回的是懒加载的Stream，底层依赖文件通道；一旦文件被删除、权限变更或编码不匹配，流在终端操作（如collect()）时才真正触发读取，此时异常才暴露出来。
- 优先用
Files.readAllLines(Paths.get("poems.txt"), StandardCharsets.UTF_8)——一次性读入内存，错误立即抛出，便于定位 - 确保文件路径是相对路径时，工作目录是你运行
java命令的目录（不是.java所在目录），建议用Class.getResource("/poems.txt")加载类路径资源 - Windows下记事本保存的UTF-8文件可能带BOM，导致首行乱码，改用VS Code或Notepad++另存为“UTF-8 无BOM”
如何从文本文件中安全随机选一首诗？别直接Random.nextInt(list.size())
看似没问题，但若文件为空或只有一行（比如空行、注释行），list.size()为0会抛IllegalArgumentException；而且纯文本里诗与诗之间通常靠空行分隔，不能按行切。
- 先用
String.join(" ", lines)合并全文，再用split("\n\s*\n")按空行分割成诗块 - 过滤掉空白诗块：
Arrays.stream(poems).filter(s -> !s.trim().isEmpty()).toArray(String[]::new) - 随机前务必判空：
if (poems.length == 0) { System.out.println("未找到有效诗词"); return; }
控制台输出中文诗词时，为什么Linux/macOS显示正常，Windows CMD却乱码？
Windows CMD默认编码是GBK，而Java源文件和文件读取都用了UTF-8，输出时字节流被CMD按GBK解码，自然错乱。
java-api-doc-generator
下载
分析 Java Spring Boot 后端 Controller 代码，自动生成 Markdown 格式的接口文档。当用户说“生成 Java 接口文档”、“生成 API 文档”、“从 Spring 代码生成文档”时触发。
- 临时方案：启动CMD后执行
chcp 65001切换到UTF-8代码页（需JDK 9+支持） - 更稳方案：在Java启动参数加
-Dfile.encoding=UTF-8，并确保System.out写入前不被其他组件重定向 - 终极规避：改用
System.console().writer().println()（仅限真实终端，IDE内无效）
用Scanner逐行读还是BufferedReader？性能差多少？
对几百行的小文件，差别几乎为零；但Scanner自带词法解析开销，且默认使用平台编码（易踩坑），而BufferedReader明确可控。
立即学习“Java免费学习笔记（深入）”；
- 推荐写法：
new BufferedReader(new InputStreamReader(new FileInputStream("poems.txt"), StandardCharsets.UTF_8)) - 如果后续要支持热重载（比如文件被外部修改），
BufferedReader配合Files.getLastModifiedTime()比Scanner更容易做缓存校验 -
Scanner.hasNextLine()在流末尾可能阻塞（尤其重定向输入时），BufferedReader.readLine()返回null更明确
真正麻烦的不是读文件或选随机数，而是诗文格式不统一：有的带作者、朝代在首行，有的在末行，有的用「」有的用“”，这些得在分割后手动清洗。别想着一步到位，先保证能跑出一首不乱码的再说。
