do-while 循环必须用 break 跳出，否则容易死循环
Java 的 do-while 先执行后判断，菜单逻辑天然适合它——用户至少看到一次菜单才决定是否退出。但新手常把退出条件写在循环体末尾却忘了加 break，或把 while 条件写成恒真（比如 while (true)）又没配 break，结果卡死在控制台。
正确做法是：把退出逻辑放在循环体内，用 break 主动跳出，while 条件只负责兜底校验。
- 不要写
while (true)然后靠if (choice == 0) break;—— 这样可以，但可读性差，且容易漏掉break - 推荐写法：
while (!"q".equals(choice) && !"Q".equals(choice))，配合循环内Scanner.nextLine()获取输入 - 注意：
Scanner读数字后接字符串，会残留换行符，导致下一次nextLine()立即返回空字符串——这是最常被忽略的坑
Scanner.nextLine() 和 nextInt() 混用时的换行符残留问题
交互式菜单常要处理数字选项（如“1. 查看列表”）和字符指令（如“q 退出”），一旦混用 nextInt() 和 nextLine()，nextInt() 不吞掉回车，nextLine() 就立刻读到空行，菜单直接跳过输入、反复刷新。
解决方案不是换用别的类，而是主动清理缓冲区：
立即学习“Java免费学习笔记（深入）”；
- 每次调用
nextInt()或nextDouble()后，紧跟一句scanner.nextLine(); - 更稳妥的做法：统一用
nextLine()读所有输入，再用Integer.parseInt()转数字——失败时捕获NumberFormatException并提示重输 - 避免在循环里反复创建
Scanner实例，一个实例复用即可
菜单选项分支中忘记清屏或分隔，导致输出混乱
纯命令行菜单没有 GUI 刷新机制，连续操作后屏幕堆满历史记录，用户找不到当前菜单位置。这不是语法错误，但严重影响练手体验和调试效率。
- Java 本身不提供跨平台清屏 API，别尝试
Runtime.getRuntime().exec("cls")或"clear"——Windows/Linux/macOS 行为不一致，还可能抛异常 - 简单有效做法：输出 20 个空行（
System.out.println("\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n");），视觉上等效清屏 - 或者，在每次显示主菜单前打印一行分隔线：
System.out.println("─".repeat(40));（Java 11+ 支持String.repeat()） - 如果用 IDE 运行（如 IntelliJ），终端默认不支持 ANSI 清屏码，硬塞
\033[2J\033[H也没用
退出前没关闭 Scanner，可能引发资源警告或阻塞
Scanner 包装了 System.in，虽然 JVM 退出时会自动释放，但在某些环境（如单元测试、IDE 内嵌终端）中，不显式关闭会导致资源未释放警告，甚至让程序“假死”在等待输入状态。
- 在
do-while循环结束后、程序退出前调用scanner.close(); - 不要在循环体内关闭——关了就再也读不到下一次输入
- 如果菜单逻辑封装成方法，建议用 try-with-resources？不行：
System.in是静态流，关了整个应用就无法再读标准输入，所以只能手动在最后关一次
真正麻烦的从来不是 do-while 语法本身，而是输入流状态管理、跨平台行为差异、以及人眼对滚动输出的容忍度——这些细节不处理好，菜单跑起来就像在迷雾里点按钮。
