图书管理系统无需高并发IO框架，应以面向对象设计为核心：通过封装保障状态安全、继承实现权限分离、多态支持灵活扩展，并按book/user/operation/main分层明确职责。
高并发IO框架不是图书管理系统的核心需求。这类系统本质是单机命令行或轻量Web应用，用户量小、操作以增删查改为主，不涉及海量连接或实时响应压力。强行套用Netty、Vert.x等框架反而增加复杂度，掩盖面向对象设计本应解决的问题——比如职责划分不清、逻辑纠缠、扩展困难。
面向对象三大特性才是结构清爽的关键
封装、继承、多态不是概念装饰，而是组织代码的实用工具：
- 封装：Book类把name、author、price、isBorrowed设为private，只暴露getter/setter和业务方法（如borrow()、returnBook()），外部无法直接修改状态，借阅逻辑统一收口
- 继承：User抽象父类定义通用字段（id、name、password）和共用方法（login()），AdminUser和NormalUser分别继承并重写getOperation()，自然区分权限边界
- 多态：所有功能操作（AddOperation、FindOperation、BorrowOperation等）都实现同一个IOperation接口；主程序根据用户类型调用user.doOperation()，底层自动执行对应子类逻辑，新增功能只需加个类，不改调度代码
分层架构让结构真正清爽
不靠框架堆砌，靠清晰分包与职责隔离：
- book包：只放Book、BookList，纯数据载体，无IO、无控制流
- user包：User（抽象）、AdminUser、NormalUser，专注身份与行为差异
- operation包：每个操作一个类，全部实现IOperation，单一职责，可独立测试
- main包：仅保留Text类作为入口，负责登录、菜单循环、调用operation，不掺杂业务细节
高并发IO框架什么时候才需要？
只有当系统演进到以下阶段时才考虑引入：
- 支持千级以上并发Web用户在线借阅，且需WebSocket实时推送归还通知
- 对接分布式缓存（如Redis）做热门图书计数，要求毫秒级响应
- 与微服务生态集成，通过gRPC暴露图书查询接口供其他系统调用
现阶段，用好Scanner读输入、ArrayList存数据、接口+多态调度操作，就是最稳、最易懂、最易维护的“清爽”。
