用泛型接口构建可扩展dao层，核心是分离操作行为与数据类型：定义idao统一crud，业务接口如iuserdao继承并扩展，实现类复用mybatis-plus basemapper或jpa jparepository，辅以反射动态解析字段。
用泛型接口构建可扩展的DAO层，核心是把“操作行为”和“数据类型”分开定义，让一套方法能适配任意实体，同时保留按需扩展的能力。
定义统一的泛型DAO接口
声明一个带类型参数 T 的接口，约束所有实现必须支持基础CRUD，不绑定具体表或字段：
- 方法签名只依赖 T 和主键标识（如 Serializable 或自定义 IdField）
- 例如：
void save(T entity)、T findById(Serializable id)、List<t> findAll()</t> - 可要求 T extends BaseEntity，确保实体自带
getId()等通用契约
分层继承：通用接口 + 业务专用接口
避免“大而全”的单接口，采用组合式设计：
- 基础接口
IDao<t></t>提供标准增删改查 - 业务接口如
IUserDao extends IDao<user></user>可额外定义List<user> findByStatus(String status)</user> - 实现类只需实现
IUserDao，自动获得通用方法，又不污染基础层
配合框架做轻量实现
不从零手写SQL，优先复用成熟能力：
- 用 MyBatis-Plus：各 Mapper 直接
extends BaseMapper<user></user>，开箱即用 - 需统一逻辑（如软删除）时，封装
GenericMapper<t> extends BaseMapper<t></t></t>，再由具体 Mapper 继承 - 若用 JPA，定义
JpaDao<t id> extends JpaRepository<t id></t></t>，再通过@Query或方法名派生补充查询
反射辅助动态能力（按需启用）
当需要运行时解析字段生成条件查询等通用逻辑时，用反射补足泛型静态限制：
- 在抽象实现类中，通过
ParameterizedType获取子类传入的 T 类型 - 用
Class.getDeclaredFields()扫描字段，构建动态 WHERE 条件或 INSERT 字段列表 - 注意缓存元数据、使用命名参数防注入、避免高频反射影响性能
