权限对接方法👑

生成代码内置的权限体系——三种权限模型、配置入口、以及怎么接入你自己的角色体系。

生成的代码自带一套基于角色的权限体系，分操作权限、字段权限、数据权限三层。配置集中在 permissions.json，改配置即生效，不用改业务代码。

权限模型

配置入口：permissions.json

生成的代码里有一份 permissions.json，结构是 角色 → 表 → 操作 → 字段。一个最小示例：

{
  "admin": { "users": { "query": true, "create": true, "update": true, "delete": true } },
  "user":  { "users": { "query": true, "update": true } }
}

• admin 对 users 全操作
• user 只能查、改，不能删

改这个文件，权限随即生效——这是改配置即生效的最小改动点。

代码里的落地方式

权限规则在各语言里有对应的实现机制：

你不需要逐表写 if 判断，权限校验在框架层统一处理。

对接你自己的角色体系

方案 A：复用默认角色，只改配置 直接用生成代码里的角色（如 admin / user），把 permissions.json 改成你的规则即可。

方案 B：接入现有用户/角色表 如果你已有用户与角色体系：

1. 让登录态带上当前用户的角色（见《登录对接方法`)
2. 把角色值映射到 permissions.json 里的键
3. 权限校验按映射后的角色读取配置

最小改动点就是“登录态 → 角色 → permissions.json”这一条链路，其余由框架层处理。

接入你自己的权限数据源

如果 permissions.json 满足不了你的场景——权限存在你自己的数据库里、按用户组动态计算、或对接外部权限系统——生成代码留了一个权限数据源接入点：每个后端都有一两个固定的判断函数，默认实现读 permissions.json，改写它们就等于换了权限数据源。中间件、DAO、字段裁剪都调用这几个函数，改一处全链路生效。

统一契约：(role, table, op) → { allowed, maskedFields }——不管数据源是什么，只回答「这个角色在这张表上能不能做这个操作、屏蔽哪些字段」。

Java 是 Spring 容器，PermissionService 本身是个 Bean——不想改生成文件的话，直接在你的代码里加一个标 @Primary 的同名 Bean 覆盖即可；Go / TypeScript / Python 直接在对应文件里改写。

三种接法

1. 完全换源：改写判断函数，直接查你自己的权限表 / 用户组 / 外部接口
2. 扩展默认配置：判断函数里先按 permissions.json 算一遍，再合并你自己的源（例如：默认没禁止的，再由你的库表决定）
3. 异构模式：你自己的角色模型和默认角色不同——只需守住上面的契约，角色怎么定义、角色 ↔ 权限怎么映射都由你实现

最小示例（Go，改查你自己的权限表）

// 改写 CheckOpAccess，把数据源换成你自己的权限表
func CheckOpAccess(role, table, op string) bool {
	var allowed bool
	// 换成你自己的查询（示意，db 为你的连接）
	err := db.QueryRow(
		"SELECT COALESCE(MAX(allowed), false) FROM sys_role_permission WHERE role=$1 AND tbl=$2 AND op=$3",
		role, table, op,
	).Scan(&allowed)
	if err != nil { return false } // 查不到 → 拒绝（可按需改成默认放行）
	return allowed
}

每个后端权限文件的头部都有同样的「接入点」注释，打开代码就能看到要改哪几个函数。重新生成会覆盖这些文件——用 git 管理你的改动，重新生成后 merge 即可（见《常见问题》）。

字段与数据权限

• 字段权限：在配置里指定某角色对某表屏蔽/只读哪些字段，响应层自动裁剪
• 数据权限：配合数据所有权（见《高级设置》）使用，按归属过滤查询结果

注意

• 功能权限配置在**工作台的「功能权限」**里操作（订阅功能），生成的 permissions.json 是落地的结果
• 基础版生成的代码中权限为占位逻辑，完整权限需订阅后生成