简介这是一份面向Java开发者的MyBatis-Plus 3.0代码生成案例资源演示借助逆向工程自动生成映射器接口、XML映射文件、服务接口及实现类、控制器并完成SpringBoot整合。资源基于3.0版本相比2.3在代码结构与性能上有较大改变集成JDK8以上新特性支持Lambda表达式与Lombok简化开发同时给出主键生成策略和日期映射策略的配置方法。压缩包共28个文件主要文件类型包括Java源码、XML配置、properties属性文件、Maven构建文件、Eclipse工程设置等整体大小66KB轻量易用工程麻雀虽小五脏俱全包含生成器启动类、pom依赖和Maven包装器脚本Windows下可直接构建运行。已有572人学习下载适合正在使用或计划迁移至MyBatis-Plus 3.0的SpringBoot开发者可作为代码生成器搭建、数据库表配置、输出目录与包名调整的参考帮助快速搭建数据访问层代码生成环境。1. 为什么说 MyBatis-Plus 3.0 是单表 CRUD 的最优解接手一个后台管理系统业务表三十多张联系人和订单这类表字段还特别多。按以前手写 MyBatis 的习惯每张表都要写实体、Mapper 接口、XML 文件接口里再套一层 Service光单表增删改查就能占掉整个工期的一半。后来在项目里引入 MyBatis-Plus 3.0单表的增删改查基本不写 SQL条件构造器直接生成 where 条件再配合代码反向生成从数据表到 Service/Controller 代码只要几分钟。这套方案适合三类人正在做后台管理类课设或毕设的学生想把手写 XML 工作量降下来的从业者以及需要用代码生成器统一团队代码风格的小组。这篇方案会从环境搭建、核心模块实现、代码反向生成一直写到验收答辩照着做就能落地。2. 工程搭建与核心依赖三分钟跑通一个可用的 Dao 层先别管业务把最基础的依赖、配置和一条链路跑通。这里说的“跑通”指的是实体类能插入、能按条件查询、能分页。这三件事通了后面所有模块都建立在同一套机制上不会再为“为什么我这个 SQL 不生效”反复排查。2.1 依赖引入与版本选型boot starter 还是 spring 版本MyBatis-Plus 的官方坐标是 com.baomidou它维护的 starter 会根据你的 Spring Boot 版本自动装配大部分组件。我用的是 Spring Boot 2.7 对应 3.5.3.2 这一档pom 里这样引dependency groupIdcom.baomidou/groupId artifactIdmybatis-plus-boot-starter/artifactId version3.5.3.2/version /dependency dependency groupIdmysql/groupId artifactIdmysql-connector-java/artifactId scoperuntime/scope /dependency如果你用的是 Spring Boot 3就换成 mybatis-plus-spring-boot3-starter两个坐标的包内容略有差别后者依赖 jakarta 一套规范。选型上最容易踩的坑是版本强行对齐mybatis-plus 的 3.x 是一个大版本线内的持续迭代3.0.x 和 3.5.x 的 API 有变化比如生成器的写法从 AutoGenerator 变成了 FastAutoGenerator分页插件也从旧的 PaginationInterceptor 改成了 MybatisPlusInterceptor。我的建议是直接选 3.4 以上的稳定版别停留在 3.0.0因为早期版本没有 lambda 条件构造器的一些增强代码生成器也需要独立引入 generator 依赖。注意starter 版本和 mybatis-plus-generator 版本必须保持一致否则会出现“生成器生成的代码用了新 API而工程里加载的是旧实现”这种编译能过但运行报错的怪问题。2.2 核心配置与分页插件注册一个拦截器解决大半问题MyBatis-Plus 3.x 的插件机制统一走 MybatisPlusInterceptor分页、乐观锁、防全表更新这些能力都是往这个拦截器链上挂。下边这段配置类放在启动类的同包或子包下Spring 启动时就会注册Configuration public class MybatisPlusConfig { Bean public MybatisPlusInterceptor mybatisPlusInterceptor() { MybatisPlusInterceptor interceptor new MybatisPlusInterceptor(); PaginationInnerInterceptor pagination new PaginationInnerInterceptor(DbType.MYSQL); pagination.setMaxLimit(500L); interceptor.addInnerInterceptor(pagination); return interceptor; } }DbType 一定要和实际数据库匹配mysql 和 postgresql 的分页方言不一样配错了生成的 limit 语句会直接报错。setMaxLimit 是安全护栏防止有人不小心把 size 传成 100000 把整张表拉出来。这一步很多人漏掉漏掉的后果是 selectPage 不会自动拼 limit方法调用看起来正常实际返回的是全量数据。然后配置 application.yml 里的命名映射和逻辑删除全局项mybatis-plus: configuration: map-underscore-to-camel-case: true global-config: db-config: logic-delete-field: deleted logic-delete-value: 1 logic-not-delete-value: 0map-underscore-to-camel-case 让 user_name 自动映射到 userName这是所有实体字段映射的基础。logic-delete-field 是全局逻辑删除字段名下面 3.3 节会用到这里先占位。这套配置完了MyBatis-Plus 基本开箱可用剩下就是写第一个实体和 Mapper。2.3 第一个实体类与 BaseMapper先跑通一条链路实体类直接用 Lombok 注解省掉 getter/setter表名和字段名都按下划线命名让全局配置去转换。下面是我在项目里的最小写法Data TableName(sys_user) public class User { TableId(type IdType.ASSIGN_ID) private Long id; private String username; private String nickname; TableLogic private Integer deleted; private LocalDateTime createTime; }TableId 的 ASSIGN_ID 用雪花算法生成分布式 ID避免了手动 set id 的麻烦如果表是自增主键改成 IdType.AUTO。TableLogic 标记逻辑删除字段后续所有 MP 内置的删除操作都会变成 UPDATE查询会自动追加 deleted 0。Mapper 接口继承 BaseMapper 之后就拿到了十几个现成方法Mapper public interface UserMapper extends BaseMapperUser { }这个接口即使里面一个方法都不写也能做 insert、updateById、deleteById、selectById、selectList、selectPage。Service 层再继承 IService得到的封装更多包括批量 saveBatch、链式查询 lambdaQuery 这些日常很省事的 API。第一次跑通可以这样验证User user new User(); user.setUsername(demo01); user.setNickname(演示账号); userMapper.insert(user);插入成功后观察数据库id 自动生成、deleted 默认 0、create_time 如果数据库有默认值也能写入。把这条链路跑通说明依赖、配置、命名映射都对了后边模块再往上是往同一套机制上叠功能而不是另起炉灶。3. 核心功能模块实现条件构造器、分页、逻辑删除与乐观锁的落地写法这一章是业务里被调用次数最多的四个模块也是平时问题最多的地方。每一节都按“写法 容易错的点”来讲照这个结构写基本能覆盖一个后台管理系统里 80% 的单表数据访问场景。3.1 条件构造器QueryWrapper 与 LambdaQueryWrapper 的正确姿势条件构造器解决的是“查询条件动态拼 SQL”这个老问题。以前用 MyBatis 时每个查询都要在 XML 里配 if 判断字段一多 XML 就变得很长。MP 里直接用对象链式拼接最推荐的是 LambdaQueryWrapper因为它用方法引用代替字符串字段名改了能立刻编译报错不给你运行时才发现的机会。LambdaQueryWrapperUser wrapper new LambdaQueryWrapper(); wrapper.eq(User::getStatus, 1) .like(User::getNickname, 张) .between(User::getCreateTime, startTime, endTime) .orderByDesc(User::getCreateTime); ListUser list userMapper.selectList(wrapper);这段代码生成的 SQL 是 status 1 AND nickname LIKE %张% AND create_time BETWEEN ? AND ? ORDER BY create_time DESC。eq、ne、gt、lt、ge、le、in、notIn、like、between 这些方法对应 SQL 里的比较和范围条件orderBy 方法对应排序。有一点要注意like 是双模糊只要字段内容包含“张”就会命中如果需要左模糊或右模糊要用 likeRight 或 likeLeft比如 likeRight 生成 LIKE 张%配合索引更友好。OR 的优先级是这里最容易翻车的地方。链式调用里 or 的粒度是整个条件组不是单个条件// 实际SQL: status 1 OR type 2不是你以为的 status1 AND (type2 OR ...) wrapper.eq(User::getStatus, 1).or().eq(User::getType, 2); // 想要 status1 AND (type2 OR source3)要这样写 wrapper.eq(User::getStatus, 1) .and(w - w.eq(User::getType, 2).or().eq(User::getSource, 3));and 方法接收一个子条件构造器把内部的小条件用括号包起来这样拼出来的 SQL 才符合预期。更新场景用 LambdaUpdateWrapper它只有 set 和条件方法目的是不让整条 SQL 把其他字段也带更新LambdaUpdateWrapperUser update new LambdaUpdateWrapper(); update.set(User::getStatus, 0) .likeRight(User::getUsername, temp); userMapper.update(null, update);注意 update 的第一个参数传 null表示“实体字段不参与 set”全部 set 交给 UpdateWrapper 控制这样批量改状态时不会误更新其他字段。提示条件构造器生成的 SQL 最终都会被打印到日志里调试时把 mybatis-plus.configuration.log-impl 配成 StdOutImpl直接看控制台 SQL 就能确认优先级是否符合预期。3.2 分页查询拦截器原理与 Page 对象的参数细节MP 的分页不是业务代码里写 limit而是 selectPage 传一个 Page 对象分页插件在 SQL 执行前自动做两件事生成一条 count 查询统计总数把原 SQL 拼接成 limit 语句。先看标准写法PageUser page new Page(1, 10); LambdaQueryWrapperUser wrapper new LambdaQueryWrapper(); wrapper.like(User::getUsername, admin); IPageUser result userMapper.selectPage(page, wrapper); ListUser records result.getRecords(); long total result.getTotal(); long pages result.getPages();Page 构造器的两个参数分别是 current当前第几页和 size每页条数。查询完records 是结果列表total 是总记录数pages 是总页数这几个值正是前端表格组件要的数据。有人习惯把 total 直接从列表长度取那是错的当前页永远只有 size 条总数必须是 count 查询的结果。分页插件默认会对 selectPage 方法做拦截但如果你在 XML 里自己写了带 limit 的 SQL再套一层 Page 参数就会拼出两条 limit这是分页相关的第二常见问题。做法是二选一要么全走 MP 的 selectPage要么自定义 SQL 时只在方法参数里放 Page不在 SQL 里写 limit。针对 3.5.9 之后的版本还有个历史包袱要提一下官方把分页插件的一部分实现移到了 mybatis-plus-jsqlparser 这个依赖里如果你升级到这个版本后发现分页突然失效先检查是不是少引了这个包这个问题放到第 5 章专门展开。3.3 逻辑删除与乐观锁两个高频业务的配置顺序后台管理里的“删除”几乎都是假删除MP 的逻辑删除把这件事做成了透明机制你调用 deleteById它执行的是 UPDATE user SET deleted 1 WHERE id ?你调用 selectList它自动追加 AND deleted 0。配置分两步实体字段加 TableLogic然后全局配置里配好删除和未删除的值2.2 节已经配过了。如果想让数据库默认值也参与可以在实体类的 deleted 字段上加 TableField(select false) 避免每次查询把该字段带回来减少一点传输量。乐观锁解决的是更新丢失问题。比如两个人同时编辑同一张订单后提交的人覆盖先提交的人。方案是实体加 Version 字段同时往拦截器链上注册乐观锁插件二缺一都不生效。更新流程是// 先查出当前数据拿到 version Order order orderMapper.selectById(1001L); // 业务处理 order.setStatus(2); order.setAmount(newAmount); // 更新返回值是影响行数 int rows orderMapper.updateById(order); if (rows 0) { // 说明 other 事务已经改过这条数据需要提示用户重试 }updateById 生成的实际逻辑是 UPDATE table SET status ?, amount ?, version version 1 WHERE id ? AND version ?。执行成功version 就加了 1执行不成功说明 WHERE 里的 version 和当前库里的不一致更新被跳过。它比悲观锁好在不需要长时间占数据库连接适合高并发读多写少的场景。注意乐观锁的版本号要么是 int/long要么是时间戳别用 String 类型否则类型转换会出问题。3.4 自定义 SQLMapper 文件与 MP 内置方法如何共存MP 不是银弹多表关联、分组统计、复杂子查询还是得写 SQL。它的设计允许自定义方法和内置方法并存只要你 XML 的 namespace 和 Mapper 接口全限定名一致。举个例子用户表关联最近一笔订单这种查询适合在 XML 里写mapper namespacecom.example.system.mapper.UserMapper select idselectUserWithLastOrder resultTypecom.example.system.entity.UserOrderVO SELECT u.id, u.username, o.last_order_time FROM sys_user u LEFT JOIN ( SELECT user_id, MAX(create_time) AS last_order_time FROM sys_order GROUP BY user_id ) o ON o.user_id u.id WHERE u.deleted 0 /select /mapperMapper 接口里对应加一个方法 selectUserWithLastOrder参数和返回值自己定义。这里有个很容易漏的细节逻辑删除条件在自定义 SQL 里不会自动追加上面 SQL 里我手动写了 u.deleted 0如果忘了就会把已删除用户的数据也查出来。另外xml 文件默认在 resources/mapper 目录下要确定 classpath 扫描配置把目录指对了不然启动时会报“Invalid bound statement”错误。提示自定义 SQL 和 MP 内置方法共存的边界是——单表、无复杂关联用条件构造器有多表 join、窗口函数、动态排序时再写 XML别把简单查询硬写成 SQL那样等于放弃 MP 的价值。4. 代码反向生成实战从数据表到 Service/Controller 的一键产出代码反向生成是 MP 生态里最实用的部分也是关键词里“baomidou3.0 代码反向生成”指向的核心功能。选型阶段你可能纠结过手写还是生成我的经验是基础 CRUD 层全部交给生成器之后的手写代码集中在业务校验和多表查询上这样既快又能保证风格统一。4.1 FastAutoGenerator 配置数据源、包名与表策略3.5.1 之后的版本推荐用 FastAutoGenerator链式配置比旧版 AutoGenerator 清晰得多。下面是一个可以直接改数据库连接就跑的生成器FastAutoGenerator.create( jdbc:mysql://localhost:3306/demo?useUnicodetruecharacterEncodingutf8serverTimezoneAsia/Shanghai, root, 123456) .globalConfig(builder - builder .outputDir(/workspace/codegen/java) .author(team) .dateType(DateType.TIME_PACK) .enableSwagger()) .packageConfig(builder - builder .parent(com.example.admin) .moduleName(system) .entity(entity) .mapper(mapper) .service(service) .serviceImpl(service.impl) .controller(controller)) .strategyConfig(builder - builder .addInclude(sys_user, sys_order, sys_pay) .addTablePrefix(sys_) .entityBuilder() .logicDeleteColumnName(deleted) .versionColumnName(version) .controllerBuilder() .restStyle()) .templateEngine(new VelocityTemplateEngine()) .execute();拆解一下几个关键配置globalConfig 里的 outputDir 是生成文件的根目录author 会写进类注释dateType 决定实体时间字段用 LocalDateTime 还是 java.util.DateTIME_PACK 对应前者能减少之后类型转换成本。packageConfig 的 parent 和 moduleName 拼出包路径 com.example.admin.system下面各层子包名按它的规则生成。strategyConfig 的 addInclude 指定要生成哪几张表addTablePrefix 会把表前缀 sys_ 去掉最终实体类名是 SysUser 而不是 TSysUser 这种难看的名字。logicDeleteColumnName 和 versionColumnName 会让实体自动带上 TableLogic 和 Version对应第 3 章的配置。执行 main 方法前确认工程的 mybatis-plus-generator 依赖版本和 mybatis-plus 主依赖一致。很多第一次跑的人在这里翻车生成器代码是从示例里复制的但依赖版本是旧的运行时报找不到方法其实不是代码的问题是版本错位。4.2 自定义模板把生成结果改成团队风格默认模板生成的 Controller 带 Swagger 注解、Service 接口和实现类齐全大多数团队能用但总有几个地方想改比如类注释格式、是否生成 Service 接口、Controller 里加不加统一返回。FastAutoGenerator 支持两种方式改一种是 enableSwagger 之后依赖里要有 swagger 相关 jar另一种是自定义模板文件。模板放在 resources/templates 下文件名和默认模板对应用 Velocity 引擎时模板后缀是 .vm。以下是一个简化版 Controller 模板示例package ${package.Controller}; import ${package.Service}.${entity}Service; import com.example.common.Result; import org.springframework.web.bind.annotation.*; /** * ${entity} 控制器 */ RestController RequestMapping(/${entity}) public class ${entity}Controller { private final ${entity}Service service; public ${entity}Controller(${entity}Service service) { this.service service; } GetMapping(/list) public Result list() { return Result.ok(service.list()); } }模板变量和 Java 代码混排输出的文件就是 Controller 源码。自定义模板的意义不只是改样式它还能统一返回类型生成器默认生成直接返回实体对象如果你项目里要求所有接口包一层 Result不改模板就得每次生成后手动改几十个文件。我一般会把模板里写死 com.example.common.Result 这个包路径保证生成出来就能编译过。注意Velocity 模板的变量语法是 ${xxx}和 Java 字符串拼接长得像但完全不同第一次写模板报错时先检查是不是少了头注释看日志里模板编译异常的具体行号。4.3 生成后的代码评审哪些要保留、哪些要手写生成器跑完工程里会多出这样一套文件com/example/admin/system/ ├── controller/SysOrderController.java ├── entity/SysOrder.java ├── mapper/SysOrderMapper.java ├── mapper/xml/SysOrderMapper.xml ├── service/ISysOrderService.java └── service/impl/SysOrderServiceImpl.java评审原则通常是这样的。实体类是信任度最高的字段注解都来源于数据库列基本不用改唯一要检查的是逻辑删除和乐观锁注解是否正确生成。Mapper 接口和 XML 可以接受但 XML 默认只有空内容复杂查询往里补就行。Service 接口和实现类通常会包含 MP 的模板方法如果你的业务需要事务控制在实现类方法上加 Transactional 是常见操作。Controller 是最需要检查的生成器给的只是标准 CRUD 接口项目实际需要的参数校验、权限注解往往要手写补充。还有一条血泪经验生成器重复执行会覆盖同名文件如果你在生成后的 Controller 里手写了业务逻辑再跑一次生成器手写内容全没了。所以我把生成器和手写代码在物理路径上分开生成目录固定为 codegen 前缀的独立包手写扩展类放在业务包即使覆盖也只影响生成层损失的只是重新处理一下格式而不是丢掉业务逻辑。这个习惯帮我躲过好几次“代码突然消失”的危机。5. 常见问题与避坑升级 3.0 后最容易翻车的五个点这一章写的是我接手过和实际遇到的五类高频问题每条按“现象、原因、解决”来讲。这些问题不解决往往表现为“代码明明对着文档写的怎么就是不生效”把排查思路理清后五分钟内基本能定位。5.1 现象一分页插件不生效查询结果把整表拉回来了现象调用 selectPage 返回的 total 等于整表行数records 也是全量或者控制台里根本没有 count 查询。原因最常见的是 MybatisPlusInterceptor 没有注册成 Bean3.x 之前的旧 PaginationInterceptor 写法在 3.0 后面已经不推荐另一个隐蔽原因是 3.5.9 之后分页插件实现拆到了独立依赖 mybatis-plus-jsqlparser只升级主依赖没引这个包启动时可能会报缺失类分页自然失效。解决确认存在第 2.2 节的配置类同时检查依赖里是否有对应版本的分页支持包dependency groupIdcom.baomidou/groupId artifactIdmybatis-plus-jsqlparser/artifactId version${mybatis-plus.version}/version /dependency排查时先看启动日志有没有 MybatisPlusInterceptor 相关的初始化信息再看控制台 SQL 是否带 LIMIT两步就能定位。别把分页插件当黑匣子它本质就是 SQL 改写日志里能看到完整证据。5.2 现象二逻辑删除字段失效已删数据仍能查到现象调 deleteById 方法后数据库里 deleted 变成了 1但同一个接口再查数据还是出现在列表里。原因这种情况十有八九是逻辑删除只配了一半——实体字段没加 TableLogic 注解或者全局配置里 logic-delete-field 和实体字段名对不上。MP 追加逻辑删除条件依赖注解识别光在 yaml 里写全局配置有些版本并不对所有实体生效这是个坑点。解决实体字段加注解是最稳定的做法TableLogic private Integer deleted;另外自定义 XML 里的 SQL 不会自动带 deleted 0这点在 3.4 节强调过凡是手写 SQL 的查询要自己补条件。如果是既走了 MP 又写了 XML 的混合查询排查顺序是先看实体注解再看 XML最后看全局配置基本能覆盖全部原因。5.3 现象三条件构造器拼接 OR查询结果比预期多现象查询“状态正常且类型是会员或者来源是 app”的用户结果把“类型是会员”或“来源是 app”的用户全查出来了包括状态不正常的。原因链式调用的 or 是 SQL 层面的 OR不是条件组逻辑。wrapper.eq(status, 1).or().eq(type, 2) 生成的 SQL 是 status 1 OR type 2优先级被 OR 拆开和人的直觉不一致。解决用 and 把同类条件包成括号这部分写法在 3.1 节给过核心是记住一条原则——同一逻辑组内的小条件先放一个 consumer再整体参与外层 and 或 or 拼接。调试时打印 SQL 验证优先级别凭感觉猜测。5.4 现象四自动填充的创建时间始终为 null现象实体里设置了 createTime 字段数据库对应列也有默认值但 insert 之后这个字段还是 null。原因MP 的自动填充不是靠数据库默认值实现的它是把实体对象里的字段在 insert 前写入值。如果你只在实体字段上标注了 fill 属性却没实现 MetaObjectHandler填充逻辑根本不会被调用。解决加一个处理器组件Component public class MyMetaObjectHandler implements MetaObjectHandler { Override public void insertFill(MetaObject metaObject) { this.strictInsertFill(metaObject, createTime, LocalDateTime.class, LocalDateTime.now()); } Override public void updateFill(MetaObject metaObject) { this.strictUpdateFill(metaObject, updateTime, LocalDateTime.class, LocalDateTime.now()); } }同时实体字段上加 TableField(fill FieldFill.INSERT) 和 TableField(fill FieldFill.INSERT_UPDATE)。strict 系列方法只在带 fill 注解的字段上生效不会把所有实体都强刷一遍这个设计比较安全。排查时先看有没有这个组件被 Spring 扫描到有时包路径放错组件没注册填充自然不生效。5.5 现象五生成器跑完手写代码和生成代码互相覆盖现象在生成后的 Controller 里加了接口重新执行生成器后改动消失甚至编译报错。原因FastAutoGenerator 默认对同名文件是覆盖写入而且生成顺序是固定的手写内容没有任何后悔药。解决核心思路是隔离生成代码输出到独立目录手写代码放业务包或者至少约定“手写扩展一律新建类不修改生成类”。我自己的做法是在 packageConfig 里把生成根包设为 com.example.gen业务类放 com.example.biz虽然多了一层对象转换的对象但换来了重复生成的安全性。另外一个更工程化的做法是生成器脚本固定放在工程根目录的 codegen 模块里业务模块依赖它生成的产物而不是混在同一个模块里被反复重写。6. 验收与答辩用一条主线功能链证明方案可用验收不要逐个方法看按一条完整的功能链走一遍效果远好于罗列功能点。我建议的准备顺序是先写库表结构再跑一次代码生成器然后启动工程做接口验证最后演示逻辑删除和乐观锁这两个“看起来很简单但很容易错”的点。验收项操作步骤预期结果基础 CRUD对用户表调 insert、selectById、updateById数据落库字段自动映射无需手写 SQL分页查询调 selectPage 并传页码、条数返回 total 和当前页 recordsSQL 带 LIMIT逻辑删除调 deleteById 后再次查询数据不再出现库中 deleted 变为 1乐观锁开两个事务同时更新同一条记录后提交的更新影响行数为 0版本号正确递增代码反向生成对订单表执行生成器生成完整分层代码编译通过接口可访问答辩时可以讲一个对比同样一个用户分页查询手写 MyBatis 要写 Mapper 接口、XML 映射、动态 SQL 条件判断大概四十到五十行代码用 MP 的条件构造器加 selectPage核心代码不到十行。这个对比不是语法糖层面的花哨而是把“每个查询都要维护一个 SQL 文件”的维护成本直接砍掉把时间留给真正的业务逻辑。另外一个技巧是现场演示生成器连接测试库执行 main 方法展示生成的代码结构评委能直观看到这套方案的可交付性。如果被问到“为什么不用纯 JDBC 或 JPA”可以从单表效率、团队上手成本、和 MyBatis 生态兼容三个角度回别陷入框架之争。最实用的一招是把第 5 章的问题准备成“我遇到过的问题”来讲分页插件失效、逻辑删除字段漏配这些是真实项目里最常见的翻车点能说清楚原因和排查过程比报出一堆功能列表更有说服力。从那以后我每次初始化工程都强制把生成器脚本和拦截器配置先跑一遍再写业务宁可多花十分钟搭脚手架也不在业务写到一半时发现基础层有洞。希望帮到你。本文还有配套的精品资源点击获取