从一张表开始设计商品模型做商品管理核心就是管好三件东西——叫什么、卖多少钱、剩多少货。我们先把这张表落地字段尽量精简方便后面看生成器的效果。CREATE TABLE product ( id BIGINT AUTO_INCREMENT PRIMARY KEY COMMENT 主键ID, name VARCHAR(255) NOT NULL COMMENT 商品名称, price DECIMAL(10, 2) NOT NULL COMMENT 售价, stock INT NOT NULL DEFAULT 0 COMMENT 库存数量, create_time DATETIME DEFAULT CURRENT_TIMESTAMP COMMENT 创建时间, update_time DATETIME DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP COMMENT 更新时间 ) COMMENT商品信息表;这里用了DECIMAL存价格避免浮点精度问题stock给个默认零防止空值干扰业务判断。建完表之后就可以交给 JeecgBoot 的代码生成器了。代码生成器四步出活JeecgBoot 的代码生成器藏在「低代码开发 Online 开发 代码生成器」菜单里。点进去整个流程可以拆成四步熟练之后确实十分钟内能跑通。第一步导入表结构在生成器首页点击「导入数据库表」选择刚才创建的product表。系统会自动读取字段类型、注释、主键信息不需要手动再录一遍。第二步配置模块与包路径这一步决定代码生成到哪里。重点填两个地方模块名比如填product最终前端路由、后端包名都会带这个前缀包路径通常保持默认的org.jeecg.modules即可项目规范有要求再改第三步勾选生成范围JeecgBoot 支持按需勾选建议首次全选看看完整产出生成项作用后端代码Entity、Mapper、Service、Controller前端代码API 接口、Vue 页面、表单组件菜单 SQL自动插入系统菜单表省去手动挂载第四步点击生成确认后系统会弹出下载链接拿到一个压缩包。解压后能看到清晰的目录结构后面细说。代码落位前后端对应关系把压缩包里的文件按目录拷进项目对应关系如下后端jeecg-boot模块org.jeecg.modules.product/ ├── entity/ │ └── Product.java # 实体类字段与表结构映射 ├── mapper/ │ └── ProductMapper.java # MyBatis-Plus 数据访问层 ├── service/ │ └── impl/ │ └── ProductServiceImpl.java └── controller/ └── ProductController.java # REST 接口自带 Swagger 注解前端jeecgboot-vue3项目src/ ├── api/ │ └── product/ │ └── index.ts # 封装 axios 请求对应后端 Controller └── views/ └── product/ └── index.vue # 列表页含表格、搜索、分页 └── ProductModal.vue # 新增/编辑弹窗表单这种分层很标准有 Spring Boot 基础的开发者一眼就能看懂。生成器做的其实是把重复劳动模板化但代码风格和工程结构并没有妥协。重启验证菜单自动挂载文件拷贝完成后重启后端服务前端执行npm run dev刷新页面。进入系统后会发现左侧菜单已经多出了「商品管理」入口——这就是生成时勾选「菜单 SQL」的效果系统把路由、权限、页面关联一次性配置好了。点进去能看到完整的列表页表格展示name、price、stock顶部有搜索框右侧是新增/编辑/删除按钮。试着新增一条数据表单校验、提交、刷新列表的流程都是通的。如果需要调整字段展示或查询条件重点改这几个地方列表展示字段前端views/product/index.vue里的表格列配置搜索条件同文件的searchFormSchema部分表单字段ProductModal.vue里的表单 schema后端查询逻辑ProductServiceImpl.java的自定义方法或直接在 Controller 层加RequestParam参数手写 vs 生成省下的不只是时间对比纯手写 CRUD生成器的价值可以量化来看工作项手写耗时生成器处理实体类 Mapper Service Controller30-40 分钟自动完成前端列表页 表单页 API 封装1-2 小时自动完成菜单配置 权限挂载10-15 分钟SQL 自动插入联调基础接口20-30 分钟开箱可用保守估计一个标准单表模块能省下2-3 小时的纯编码时间。但这不意味着可以当甩手掌柜——生成后的代码与平台存在几个耦合点需要留意一是字段注释依赖。生成器读取的是数据库注释如果表注释写得潦草前端列表的列标题就会显得业余。建表时养成写注释的习惯后面省心很多。二是字典值处理。如果stock这种字段后续要改成状态枚举如 0-无货、1-少量、2-充足需要手动在前端配置字典映射生成器不会自动识别业务语义。三是复杂查询场景。生成器默认提供的是单表等值查询如果需要联表、范围查询或自定义排序还是要回到ServiceImpl里手写QueryWrapper。把这些边界摸清楚生成器才能真正成为效率工具而不是埋坑的捷径。下次需要搭类似模块时先让生成器跑通骨架再集中精力处理业务特殊逻辑这个节奏会比较舒服。
