学生管理系统需明确职责分离：Student仅作纯数据载体，StudentManager负责核心逻辑，存储与交互由独立类处理；避免过早抽象和滥用继承，合理使用Map提升查询效率，重写toString、equals和hashCode保障调试与集合操作正确性。
学生管理系统不是堆类就能跑起来的，关键在职责怎么切、关系怎么建、边界怎么守——否则很快就会变成“改一个字段崩三个功能”的状态。
Student 和 StudentManager 到底谁该管什么
很多人一上来就写 Student 类塞满姓名、学号、成绩、班级、保存方法、打印方法……这等于让一个数据载体承担了数据结构、业务逻辑、I/O 操作三重责任。
-
Student应该只是纯粹的数据载体：只有私有字段、public getter/setter、必要构造器，不包含任何saveToFile()或printInfo() -
StudentManager负责增删查改逻辑：用List存数据，提供add(Student)、findByStudentId(String)等方法 - 文件读写、控制台交互等外围操作，应交给独立类（如
StudentStorage、StudentUI），避免和核心管理逻辑耦合
为什么不能直接用 ArrayList 做主存储容器
用 ArrayList 开发初期很顺，但很快会暴露问题：查学号要遍历、删人后索引错乱、并发修改抛 ConcurrentModificationException。
- 查学号频繁 → 改用
Map，以学号为 key，get()是 O(1) - 需要按录入顺序展示 → 单独维护一个
List存学号序列，或用LinkedHashMap - 多线程场景下 → 不直接暴露内部容器，
StudentManager方法加synchronized，或用ConcurrentHashMap+ 不可变Student
继承和多态在这里是不是画蛇添足
看到“学生”“教师”“管理员”，不少人立刻想搞个 Person 父类，再派生。但在学生管理系统里，这往往过早抽象。
立即学习“Java免费学习笔记（深入）”；
- 如果当前需求只管学生，没有共用字段/行为，硬加
Person只会让Student多一层无意义封装 - 真要扩展教师管理，优先考虑组合：比如
Teacher和Student都持有一个UserInfo对象，而不是继承同一父类 - 多态真正起作用的地方，是策略切换：比如不同导出方式（
ExportStrategy接口），CSVExport和JSONExport各自实现，StudentManager.export(exporter)统一调用
toString() 和 equals() 不重写，后期 debug 会踩坑
调试时打印 System.out.println(studentList) 看到一串 Student@1a2b3c，或者用 contains(new Student("001")) 总返回 false——都是没重写基础方法的典型表现。
-
toString()必须重写，至少包含关键标识字段（如学号、姓名），方便日志和调试 -
equals()和hashCode()必须成对重写，判断依据通常是不可变且唯一标识对象的字段（如学号），而非所有字段 - 用 IDE 自动生成即可，但要注意：如果学号允许为空或变更，就得重新评估 equals 的语义是否还成立
最常被忽略的其实是“什么时候不该面向对象”——比如解析一行 CSV 字符串，用静态工具方法 StudentParser.parseLine(String) 比硬套一个 StudentBuilder 类更干净。设计不是炫技，是让代码在三个月后还能被人一眼看懂在哪改、改了影响啥。
