一、为什么后台系统容易写成重复劳动

做后台管理系统时，真正耗时间的往往不是复杂算法，而是大量重复模块：列表、搜索、详情、编辑、权限点、菜单、按钮控制和接口联调。

这些代码本身不难，但每个业务表都要重复一遍。项目越往后，越容易出现“不是不会写，而是不想再写一遍”的情况。

二、一个常见的业务表

比如用户资料表，结构大概如下：

CREATE TABLE user_profile ( id bigint PRIMARY KEY AUTO_INCREMENT, username varchar(64) NOT NULL COMMENT '用户名', nickname varchar(64) DEFAULT '' COMMENT '昵称', status tinyint DEFAULT 1 COMMENT '状态', created_at datetime, updated_at datetime );

如果完全手写，通常要补齐这些内容：

• 后端 Model、Service、Controller
• 分页查询、新增、编辑、删除接口
• 菜单权限、按钮权限、接口权限
• 前端列表页、搜索表单、编辑弹窗
• 接口联调和字段校验

三、代码生成器真正省掉的是什么

代码生成器不是替代业务逻辑，而是先把基础链路跑通：

数据库表 ↓ 后端 Model / Service / Controller ↓ 接口路由与权限点 ↓ 前端列表页 / 表单页 ↓ 菜单、按钮、接口权限联动

这样开发者可以先拿到一个能跑的 CRUD 页面，再把时间放到状态流转、审批规则、数据权限等真正的业务部分。

四、GoFrame + Vue3 的实际体验

GoFrame 的工程结构对后端开发者比较友好，Vue3 + Element Plus 做中后台页面也足够成熟。实际项目里，我更倾向于先生成基础 CRUD，再手写复杂业务逻辑。

这次用到的示例项目是 XYGo Admin，它是一个 GoFrame + Vue3 后台项目，内置代码生成器、RBAC 权限、菜单管理和常见后台模块。

项目地址：GitHub - z312193608/xygo-admin: Open-source admin framework built with GoFrame v2 and Vue 3, featuring RBAC, full-stack CRUD code generation, MySQL/PostgreSQL, plugins, and single-binary deployment. · GitHub

五、小结

我的结论是：后台 CRUD 不一定要全部手写。基础模块可以交给生成器，复杂业务逻辑继续由开发者掌控。这样既能保留灵活性，也能减少大量样板代码。

你们团队做后台系统时，是完全手写，还是先生成基础 CRUD 再改业务？