81 lines
4.4 KiB
Markdown
81 lines
4.4 KiB
Markdown
# 1.2 为什么选择我们
|
||
|
||
:::tip 概述
|
||
选择一个后台管理基座，核心看三点：架构是否经得起二次开发、功能是否开箱即用、工程是否可持续维护。EasyGoAdmin 在这三点上均有明确的设计决策与工程约束。
|
||
:::
|
||
|
||
## 六大核心优势
|
||
|
||
### 1. Go 语言高性能后端
|
||
|
||
基于 GoFrame v2 企业级框架，原生并发能力 + 静态编译单文件部署。中间件链、泛型基座、反射注解均以 Go 惯用法实现，无 PHP/Java 式框架侵入。
|
||
|
||
```text
|
||
go build -o bin/admin-server.exe main.go # 单文件产物
|
||
./bin/admin-server.exe # :8000 直接运行
|
||
```
|
||
|
||
### 2. 声明式 CRUD 基座
|
||
|
||
ModuleSpec 泛型基座把「筛选、排序、树形、字典文本、文件字段、唯一校验、数据权限」全部声明化。一个标准模块的业务方法只需三行委托：
|
||
|
||
```go
|
||
func (s *sJob) Page(ctx context.Context, req *v1.JobPageReq) (*v1.JobPageRes, error) {
|
||
list, total, err := jobSpec.Page(ctx, req, req.GetPageNo(), req.GetPageSize())
|
||
// ...
|
||
return v1.NewPageData(req.GetPageNo(), req.GetPageSize(), total, derefSlice(list)), nil
|
||
}
|
||
```
|
||
|
||
差异进声明与钩子，写不进钩子就手写（合法逃生舱），基座永不出现"按模块分支"的代码。
|
||
|
||
### 3. gmeta 注解即事实
|
||
|
||
请求结构体上的一个 gmeta 标签同时驱动四件事：路由注册、权限校验、操作日志、OpenAPI 文档。杜绝"代码、路由表、权限表、文档"四处不一致的行业顽疾。
|
||
|
||
```go
|
||
gmeta.Meta `method:"get" path:"/api/user/page" summary:"用户分页"
|
||
permission:"sys:user:page" log:"用户管理-查询分页记录" logType:"query"`
|
||
```
|
||
|
||
### 4. 全局钩子横切，业务零感知
|
||
|
||
审计字段盖章、软删除改写、租户隔离三类横切逻辑全部在 gdb 模型钩子层完成。`dao.{X}.Ctx(ctx)` 是唯一查询入口，业务代码不写一行 del_flag/tenant_id 条件。
|
||
|
||
### 5. 代码生成器全流程打通
|
||
|
||
不只是生成代码——同步创建菜单、权限节点、字典数据、路由注册行（全部幂等）。生成的 logic 是 ModuleSpec 基座风格的完整可用实现，`go build` 后即可运行。
|
||
|
||
### 6. 五数据库 + 整库迁移实测
|
||
|
||
五方言驱动运行时切换；内置整库迁移器（内省 → 中间表示 → 方言 DDL → 分批搬运 → 序列修复），mysql→pgsql/sqlite/mssql 均有实测日志留档。
|
||
|
||
## 与常见方案的对比
|
||
|
||
| 维度 | EasyGoAdmin（GoFrame） | 传统 PHP 后台 | 通用 Go Admin 项目 |
|
||
|------|----------------------|--------------|-------------------|
|
||
| 部署形态 | 单二进制文件 | 运行时 + 依赖目录 | 单二进制文件 |
|
||
| CRUD 开发量 | 声明式基座 + 生成器 | 基类继承 + 手写 | 多数需手写 |
|
||
| 注解体系 | gmeta 反射（路由/权限/日志/OpenAPI 一体） | Attribute 注解 | 通常仅路由 |
|
||
| 多租户 | 全局钩子自动隔离，9 张租户级表 | 基类手动处理 | 需自行集成 |
|
||
| 数据权限 | 四档角色数据权限，一行声明接线 | 通常无或插件 | 部分支持 |
|
||
| 多数据库 | 五方言 + 整库迁移器 | 通常 MySQL 为主 | 多数 1-2 种 |
|
||
| 限流防护 | 固定窗口 + 认证入口独立阈值 + 受信代理 | 通常依赖扩展 | 部分支持 |
|
||
| 在线用户 | 双令牌拉黑强退，防刷新复活 | Session 方案 | 部分支持 |
|
||
|
||
## 工程纪律保障
|
||
|
||
项目对"容易腐化的地方"有明确的硬约束，这些约束写在代码结构里，不靠口头约定：
|
||
|
||
+ **依赖方向单向**：task→logic 允许、logic→task 禁止；middleware 不 import 业务包（函数变量接线）；migrate 不走 dao（不触发钩子）
|
||
+ **service 接口手维护**：禁止整体运行 gf gen service，接口文件即文档
|
||
+ **base.go 导出函数上限 15 个**：超出按能力拆子包，防止共享层膨胀成垃圾抽屉
|
||
+ **唯一真值原则**：并发唯一性靠数据库 uk_* 索引（预检仅为 UX）；字典文案唯一真相在字典管理页；权限判定唯一入口 HasPerm
|
||
+ **软删统一**：删除接口全部软删（del_flag=1），物理删除只在定时清理任务中出现
|
||
|
||
## 谁在使用本项目
|
||
|
||
+ 需要快速交付的软件公司：生成器 + 基座把 CRUD 开发压缩到分钟级
|
||
+ 有 SaaS 需求的创业团队：租户隔离 + 开户事务 + 用户上限开箱即用
|
||
+ 学习 Go 企业级开发的团队：分层、钩子、泛型、反射注解的真实工程样本
|