应统一用 nextLine() 读输入并手动转类型，或在 nextInt() 后立即调用 nextLine() 清缓冲；部门职级用 enum 仅适用于固定值，需预留 code 字段；查员工须用 HashMap 而非 ArrayList 遍历；main() 应只负责初始化、启动菜单和异常处理，配置与功能需分层抽取。
用 Scanner 读输入时别卡在换行符上
控制台系统最常崩在用户输完数字按回车，下一次 nextLine() 突然读到空字符串——因为 nextInt()、nextDouble() 不吞掉换行符，nextLine() 直接捡了个空。这不是 bug，是 Scanner 的设计逻辑。
- 统一用
nextLine()读所有输入，再手动转类型：Integer.parseInt(scanner.nextLine().trim()) - 如果必须混用，每次调用
nextInt()后立刻补一句scanner.nextLine()清缓冲 - 避免用
hasNextInt()做循环判断，它不阻塞，容易空转；改用hasNextLine()+ 字符串校验更稳
员工类该不该用 enum 管理部门和职级
用 enum 定义 Department 和 PositionLevel 是对的，但别只图语法简洁。真实 HR 系统里，部门可能要支持新增、停用、父子结构，职级可能关联薪资带宽和审批流。
- 纯展示/固定枚举（如“技术部”“测试部”）适合
enum，但得预留code字段，比如TECH("TECH", "技术部")，别只靠name() - 如果后期要从文件或数据库加载部门列表，就别硬编码
enum，改用普通类 + 静态集合缓存，否则热更新做不到 enum无法继承、不能动态实例化，一旦出现“外包岗”“实习岗”这种临时分类，硬塞进枚举会污染主模型
增删改查操作为什么总在 ArrayList 上卡住
新手爱把所有员工存在一个 ArrayList<Employee> 里，查 ID 就遍历，删人就 removeIf()，数据一过百条，控制台明显卡顿——不是 JVM 慢，是算法复杂度没压下去。
- 按 ID 查找必须用
HashMap<String, Employee>，key 是员工编号，O(1) 定位，别碰ArrayList.indexOf() - 需要按部门查？建个
Map<Department, List<Employee>>，增员时同步更新两个结构，别等查的时候再过滤 - 删除操作别直接
list.remove(obj)，先从 Map 里取到引用，再从所有相关集合中移除，避免漏删或重复遍历
启动入口写成 main() 方法但没法自动重载配置
控制台程序重启才能生效新配置，这没问题；但很多人把菜单逻辑、数据初始化全塞进 main()，结果加个日志、改个提示都得重编译——其实只是没分层。
main()只做三件事：初始化数据容器（如EmployeeRepository）、启动主菜单循环、捕获顶层异常并打印友好提示- 把“添加员工”“查询统计”这些功能拆成独立方法或小类，哪怕暂时不写接口，也别让
main()超过 20 行 - 配置项（如默认薪资、试用期月数）抽到
Config.java里，用public static final，比散落在各处的魔法数字好维护得多
对象设计不是堆 private String name，而是想清楚谁该负责读、谁该负责校验、哪部分可能变——比如员工离职状态变更，最好由 Employee 自己提供 resign(Date) 方法，而不是让外部直接设 status = "LEAVED"。
