多级菜单应采用单个while(true)主循环配合switch分支实现状态驱动，每级用独立内层循环处理输入，复用scanner，用map/list存分类与订单，输入前trim()校验，数字选项范围检查，删除用迭代器避免漏项。
怎么用 Scanner 实现多级菜单的循环嵌套
控制台点餐系统的多级菜单本质是「状态驱动」，不是靠递归或复杂类设计撑起来的。核心在于用一个 while (true) 主循环 + 若干 switch 分支控制流转，每级菜单退出时明确返回上一级（比如输入 "back" 或 "0"），而不是靠函数调用栈自动回退。
常见错误是把每级菜单写成独立方法后盲目 return，结果主循环卡死或直接退出程序；或者用递归导致栈溢出（哪怕只是 5 级菜单，用户反复进出几次就容易崩）。
- 主循环里用
Scanner.nextLine()统一读输入，避免nextInt()留下换行符导致后续nextLine()读空 - 每级菜单开头先打印当前层级标题（如
"【主菜单】"），结尾统一提示"输入 0 返回上一级" - 所有数字选项用
String接收再转int，捕获NumberFormatException后友好提示，不抛异常中断流程 - 不要在子菜单里重新 new Scanner，复用同一个
Scanner实例
菜品分类与订单数据该用什么结构存
别一上来就建 Dish、Category、OrderItem 类——控制台系统没 ORM，过度建模只会让增删改查逻辑散落在各处，调试时连当前菜单显示的是哪份数据都搞不清。
真实高效的做法是：分类用 Map<string list>></string>（键是分类名如 "主食"，值是菜名列表），当前订单用 List<map object>></map>，每个 Map 存 "dishName"、"price"、"count"。够用、易遍历、打印方便。
立即学习“Java免费学习笔记（深入）”；
- 初始化分类数据直接硬编码在 main 方法里，例如：
categories.put("热菜", Arrays.asList("宫保鸡丁", "麻婆豆腐")) - 订单项中的价格别存字符串，统一用
double或int（单位为分），避免"18.5"字符串计算出错 - 用户加菜时，先检查是否已存在同名项，存在则
count++，不存在才新增，别无脑add - 清空订单别用
list = new ArrayList()，用list.clear()，否则之前引用可能还在其他地方挂着
为什么 switch 里不能直接 case "1": 就跳进子菜单
因为 switch 是单次分支，case 执行完就跳出，没法“停留”在子菜单里持续响应输入。你看到的“进入子菜单”，其实是靠在 case 块里再套一层 while (true) 循环实现的——这个内层循环才是真正的子菜单运行体。
典型错误是 case 里只写几行打印和一次 nextLine()，然后期待下次输入还能进这个 case，结果主循环又从头开始，用户得重新选 1 才能再进一次，体验断裂。
- 每个子菜单必须自包含完整循环：打印 → 提示输入 → 读入 → 判断 → 执行动作 → 判断是否退出（如输入
"0"则break跳出内层循环） - case 块末尾不要写
break，否则内层循环一结束就掉到下一个 case；要用break outerLoop;这种带标签的跳出，或者更稳妥地用方法封装子菜单逻辑 - 如果用了方法封装，该方法必须返回一个标识（如
boolean表示是否继续主循环），别让它静默执行完就完事
输入校验和边界情况最容易漏哪几处
用户输个空格、输个中文顿号、输个负数、输个超长数字——这些不是“异常场景”，是每天都会发生的默认行为。不处理它们，系统看起来就像随时会崩的纸糊架子。
最常被跳过的其实是空输入和首尾空格：用户按了回车没打字，nextLine() 返回空字符串，直接 .equals("1") 永远 false，但程序不会报错，只是默默跳过，用户以为系统卡了。
- 所有输入先做
trim()，再判空：if (input.trim().isEmpty()) { System.out.println("请输入有效选项"); continue; } - 数字选项校验别只看是否为数字，还要看范围：
int opt = Integer.parseInt(input); if (opt menuSize) { ... } - 价格输入用
Double.parseDouble()前，先用正则input.matches("\d+(\.\d{1,2})?")粗筛，避免用户输"18.555"或"abc" - 删除订单项时，别用
list.remove(i)后还继续i++，要改用迭代器或倒序遍历，否则跳过下一项
多级菜单真正难的不是嵌套几层，而是每一层退出时，上下文状态是否干净、输入缓冲区是否残留、用户下一步操作会不会触发意料之外的分支。这些细节堆起来，才决定它到底算个玩具，还是能真拿去给餐厅老板试用两天。
