Aether 的 RBAC 权限设计从数据库到 UI 全链路之前赶工期花 3 天写了一个权限系统。if (user.role admin)写满了整个项目。第 7 个角色加进来的时候代码已经改不动了。第 15 个页面加进来的时候我决定重写。你问我当时怎么想的年轻呗觉得权限不就是判断一下角色嘛。结果被现实狠狠教育了。一、if-else 权限 vs RBAC 权限先说那个让我崩溃的版本。❌ 坏例子权限判断散落在各个页面// 3天赶出来的权限系统——散落在 30 多个文件里voidMainWindow::initNavBar(){// 到处是这种硬编码判断if(user.roleadmin||user.rolesupervisor){addNavButton(nav.settings);}if(user.roleadmin){addNavButton(nav.permission);// ← 只有 admin 能看权限页addNavButton(nav.audit);}if(user.roleoperator||user.roleengineer){addNavButton(nav.production);addNavButton(nav.recipe);}}voidRecipePage::onLoad(){// 另一个文件的另一个判断boolcanEdit(user.roleadmin||user.roleengineer);m_btnSave-setVisible(canEdit);// 但配方删除权限更严格boolcanDelete(user.roleadmin);// ← 又写一遍m_btnDelete-setVisible(canDelete);}问题在哪权限逻辑和业务代码绑死了。加一个角色 → 你得翻遍所有文件找if (role ...)改一遍改一个角色的权限 → 你得知道所有涉及的文件新页面的开发者 → 他得猜自己的权限判断要怎么写上线后想调整 → 改代码、编译、发版3 天起第 7 个角色进来的时候项目里的if-else嵌套已经像一盘意大利面。第 15 个页面加进来的时候我彻底放弃了。✅ 好例子统一授权 运行时查询// 改造后再也不散落判断了voidRecipePage::onLoad(){// 全都问同一个服务——PermServicem_btnSave-setVisible(PS-canAction(recipe.save));m_btnDelete-setVisible(PS-canAction(recipe.delete));m_btnExport-setVisible(PS-canAction(recipe.export));}voidMainWindow::initNavBar(){// 导航栏也统一问for(autonav:m_allNavItems){nav.button-setVisible(PS-canNav(nav.titleKey));}}看到区别了吗改造后加角色 → 不用改代码在角色管理里勾选就行调权限 → 不涉及编译改数据库一条记录新开发者 → 只需要知道PS-canNav()和PS-canAction()两个 API上线后想调整 → 管理后台点几下即时生效这就是 RBAC 的核心把谁能做什么从代码里抽出来变成数据。对比维度旧方式RBAC 方式加角色改所有文件数据库加一行调权限改代码发版管理后台勾选新人上手猜角色体系问 PermService审计追溯没有自动记录测试成本每个页面单独测统一测权限层二、Aether 的权限架构三步走改完后的架构说起来很简单——注册、分配、查询。┌─────────────────────────────────────────────────────────────┐ │ 三步权限架构 │ │ │ │ ① 注册 ② 分配 ③ 查询 │ │ 插件启动时 管理员在后台 运行时每个页面 │ │ 告诉框架 给角色勾选 问框架 │ │ 我有这些页面 角色A能看到X 当前用户能看X吗 │ │ 这些操作 角色B能操作Y 能执行操作Y吗 │ │ │ │ 写入目录 写入关联表 查 grants 集合 │ │ (perm_permission) (perm_role_permission) (QSetQString) │ └─────────────────────────────────────────────────────────────┘第 1 步注册插件告诉框架自己有什么资源每个插件启动时用PermCatalogScope声明自己的资源// AOI 插件启动时注册自己的页面和操作voidAoiPlugin::extensionsInitialized(){aoi::setPluginName(pluginSpec()-name());PermCatalogScopescope(aoi::pluginName());// 注册导航页PS-registerNav(nav.aoi,AOI 检测,10);PS-registerNav(nav.recipe,配方管理,20);PS-registerNav(nav.production,生产管理,30);// 注册子页面PS-registerSubPage(sub.aoi.main,nav.aoi,检测主界面,10);PS-registerSubPage(sub.aoi.log,nav.aoi,检测日志,20);PS-registerSubPage(sub.recipe.edit,nav.recipe,配方编辑,10);// 注册操作资源PS-registerAction(recipe.save,sub.recipe.edit,保存配方);PS-registerAction(recipe.delete,sub.recipe.edit,删除配方);PS-registerAction(recipe.export,sub.recipe.edit,导出配方);}关键点这里只声明有这个资源不决定谁能用。决定权在管理员手里。第 2 步分配管理员在后台勾选管理员登录后在权限管理页面看到所有已注册的资源树nav → sub_page → action给每个角色勾选需要的资源保存后数据写入perm_role_permission关联表联动规则取消 nav下面的子页和操作全部取消。勾了 action它的父级必须已勾选。这套规则叫 normalize防止数据库里出现逻辑上不可能的组合。第 3 步查询运行时每个页面问用户登录时// 登录成功后PS-reloadForUser(userId);// 内部做了什么// 1. 查用户绑定的角色// 2. 查该角色的全部 grants// 3. 缓存到 QSetQString m_grants// 4. 发射 permissionsChanged 信号// 所有窗口收到信号后重新检查显隐然后每个页面问PS-can(key)回答只有 yes/no。三、PermService 核心源码这个全局单例是整个权限系统的枢纽。核心方法没多少行但设计很讲究。// PermService 全局单例宏 PS 就是它的快捷方式#definePS(PermService::instance())classPermService:publicQObject{Q_OBJECTpublic:staticPermService*instance();// 全局单例// ---------- 查询运行时高频调用 ----------boolcan(constQStringresourceKey)const;// 三个快捷方法底层都走 can()boolcanNav(constQStringnavTitleKey)const{returncan(navTitleKey);}boolcanSubPage(constQStringsubPageKey)const{returncan(subPageKey);}boolcanAction(constQStringactionKey)const{returncan(actionKey);}// ---------- 注册插件初始化时调用 ----------boolregisterNav(constQStringkey,constQStringdisplayName,intsortOrder0);boolregisterSubPage(constQStringkey,constQStringparentNavKey,constQStringdisplayName,intsortOrder0);boolregisterAction(constQStringkey,constQStringpageKey,constQStringdisplayName);// ---------- 生命周期 ----------voidreloadForUser(qint64 userId);// 登录时加载 grantsvoidlogout();// 登出 → 回到最小用户voidreloadAsMinimalUser();// 冷启动用signals:voidpermissionsChanged();// 权限变化 → UI 重新检查显隐private:QSetQStringm_grants;// 当前有效身份的全部 grants// 运行时 can() 只查这个集合O(1) 查询};can() 的实现就一行boolPermService::can(constQStringresourceKey)const{if(!isReady()||resourceKey.isEmpty())returnfalse;returnm_grants.contains(resourceKey);}reloadForUser 的实现也不复杂voidPermService::reloadForUser(qint64 userId){// 1. 找用户的角色qint64 roleId0;m_backend-primaryRoleIdForUser(userId,roleId);// 2. 加载该角色的全部 grantsm_effectiveUserIduserId;m_effectiveRoleIdroleId;autokeysm_backend-loadGrantKeysForRole(roleId);m_grantskeys;// ← QSetQString 直接赋值// 3. 通知所有 UI 刷新emitpermissionsChanged();}注意一个设计细节registerNav可能在权限插件还没初始化完就被调用。Aether 的处理是——先排队boolPermService::registerNav(constQStringkey,constQStringdisplayName,intsortOrder){if(m_catalogRegistrarm_catalogRegistrar-isReady())returnm_catalogRegistrar-registerNav(key,displayName,sortOrder);// 还没准备好先缓存起来PendingCatalogEntry entry;entry.kindPendingCatalogEntry::Kind::Nav;entry.keykey;entry.displayNamedisplayName;entry.sortOrdersortOrder;m_pendingCatalog.append(entry);returntrue;}权限插件初始化完成后调用flushPendingCatalog()一次性把缓存的注册全部刷进去。这样插件的初始化顺序就不影响了——A 插件先跑还是 B 插件先跑结果都一样。四、JSON 配置驱动的权限目录资源注册到哪了不写在代码里存在数据库。但是运行时我们需要一个权限目录快照——也就是当前系统有哪些 nav、哪些 sub_page、哪些操作它们的父子关系是什么。这个目录在 Aether 里虽然是 DB 存的但理解时完全可以想象成 JSON{navs:[{key:nav.aoi,displayName:AOI 检测,sortOrder:10,children:[{key:sub.aoi.main,displayName:检测主界面,actions:[aoi.inspect.start,aoi.inspect.stop]},{key:sub.aoi.log,displayName:检测日志,actions:[aoi.log.query,aoi.log.export]}]},{key:nav.recipe,displayName:配方管理,sortOrder:20,children:[{key:sub.recipe.edit,displayName:配方编辑,actions:[recipe.save,recipe.delete,recipe.export]}]}]}这套结构的好处菜单 权限目录。菜单的结构和权限的树结构是同一个东西。不再需要维护两份配置。新的业务模块加入时加一个 nav 节点下面挂 sub_page 和 action结构一清二楚。导航框架拿到这个结构就能渲染菜单不需要额外逻辑。管理员在管理后台看到的权限树就是这个结构在 UI 上的渲染。五、前端拦截 后端校验权限不能只靠 UI 隐藏。万一有人直接调接口呢Aether 做了两层防护第 1 层UI 隐藏防君子// 导航栏没权限就不显示voidMainWindow::onPermissionsChanged(){for(autonav:m_navItems){nav.button-setVisible(PS-canNav(nav.titleKey));}}// 按钮没权限也不显示或灰掉m_btnSave-setVisible(PS-canAction(recipe.save));// Command 按钮自动绑定权限m_saveCommand-setName(recipe.save);// → FunctionalCommand::canExecute() 会自动检查 PS-can(recipe.save)// → 没权限时按钮灰掉且不会触发执行和审计第 2 层Command 中间件防小人用户走到 UI 隐藏但还有办法绕过——比如直接调接口、注入事件、改浏览器控制台如果是 Web 端。Aether 的 MVVM 框架里所有操作走Command::run()中间有一层全局中间件Command::run() → 权限中间件: PS-can(name())? 不行就拦截 → 审计中间件: 记下谁在什么时候做了什么 → execute(): 真正的业务逻辑就算 UI 上的按钮被某种方式点到了中间件也会再拦一道。不被 UI 绑死同一个 Command 可以被菜单、快捷键、工具栏等多处触发权限判定统一走中间件不会漏掉。六、一些你可能也会踩的坑按钮灰了还点得了检查是否绑定的是run()而不是execute()。run()走中间件execute()直接跳过。登录后权限没生效确认调了reloadForUser(userId)。只是登录成功还不够grants 得重新加载。未登录时不该看到的页面出现了冷启动时默认用minimal角色的 grants可能给了太多。检查minimal角色的授权范围。加了新操作但角色管理里看不到检查插件里是否调了registerAction而且PermCatalogScope是否包住了注册代码。花 3 天写个凑合能用的权限系统不难。花 3 天写一个能撑到 30 个页面、10 个角色、不用改代码的权限系统几乎不可能。Aether 的这套 RBAC 设计核心思路就一句话把谁有什么权限从代码里踢出去变成数据让管理员来决定让系统来执行。如果你也在做权限相关的设计或者被 if-else 权限坑过评论区聊聊你的方案。觉得有用点个在看让更多人看到也鼓励我继续写下去。下一篇我们拆解 Aether 的 i18n 架构。做了全球市场才知道国际化不只是翻译的问题——日期格式、数字千分位、图片嵌文字……还有哪些坑等你踩系列目录第 1 篇从 0 到 1 写一个插件化架构第 2 篇插件系统的 6 种死法第 3 篇DLL 地狱与依赖倒置第 4 篇服务容器new 是病得治第 5 篇MVVM 模式落地实战第 6 篇DataBinding 绝不等于 Qt 信号槽第 7 篇中间件AOP 的正确打开方式第 8 篇3天写完的权限系统上线第一天就崩了第 9 篇做了海外项目才懂国际化根本不是翻译的问题预告 3天写完的权限系统，上线第一天就崩了
Aether 的 RBAC 权限设计从数据库到 UI 全链路之前赶工期花 3 天写了一个权限系统。if (user.role admin)写满了整个项目。第 7 个角色加进来的时候代码已经改不动了。第 15 个页面加进来的时候我决定重写。你问我当时怎么想的年轻呗觉得权限不就是判断一下角色嘛。结果被现实狠狠教育了。一、if-else 权限 vs RBAC 权限先说那个让我崩溃的版本。❌ 坏例子权限判断散落在各个页面// 3天赶出来的权限系统——散落在 30 多个文件里voidMainWindow::initNavBar(){// 到处是这种硬编码判断if(user.roleadmin||user.rolesupervisor){addNavButton(nav.settings);}if(user.roleadmin){addNavButton(nav.permission);// ← 只有 admin 能看权限页addNavButton(nav.audit);}if(user.roleoperator||user.roleengineer){addNavButton(nav.production);addNavButton(nav.recipe);}}voidRecipePage::onLoad(){// 另一个文件的另一个判断boolcanEdit(user.roleadmin||user.roleengineer);m_btnSave-setVisible(canEdit);// 但配方删除权限更严格boolcanDelete(user.roleadmin);// ← 又写一遍m_btnDelete-setVisible(canDelete);}问题在哪权限逻辑和业务代码绑死了。加一个角色 → 你得翻遍所有文件找if (role ...)改一遍改一个角色的权限 → 你得知道所有涉及的文件新页面的开发者 → 他得猜自己的权限判断要怎么写上线后想调整 → 改代码、编译、发版3 天起第 7 个角色进来的时候项目里的if-else嵌套已经像一盘意大利面。第 15 个页面加进来的时候我彻底放弃了。✅ 好例子统一授权 运行时查询// 改造后再也不散落判断了voidRecipePage::onLoad(){// 全都问同一个服务——PermServicem_btnSave-setVisible(PS-canAction(recipe.save));m_btnDelete-setVisible(PS-canAction(recipe.delete));m_btnExport-setVisible(PS-canAction(recipe.export));}voidMainWindow::initNavBar(){// 导航栏也统一问for(autonav:m_allNavItems){nav.button-setVisible(PS-canNav(nav.titleKey));}}看到区别了吗改造后加角色 → 不用改代码在角色管理里勾选就行调权限 → 不涉及编译改数据库一条记录新开发者 → 只需要知道PS-canNav()和PS-canAction()两个 API上线后想调整 → 管理后台点几下即时生效这就是 RBAC 的核心把谁能做什么从代码里抽出来变成数据。对比维度旧方式RBAC 方式加角色改所有文件数据库加一行调权限改代码发版管理后台勾选新人上手猜角色体系问 PermService审计追溯没有自动记录测试成本每个页面单独测统一测权限层二、Aether 的权限架构三步走改完后的架构说起来很简单——注册、分配、查询。┌─────────────────────────────────────────────────────────────┐ │ 三步权限架构 │ │ │ │ ① 注册 ② 分配 ③ 查询 │ │ 插件启动时 管理员在后台 运行时每个页面 │ │ 告诉框架 给角色勾选 问框架 │ │ 我有这些页面 角色A能看到X 当前用户能看X吗 │ │ 这些操作 角色B能操作Y 能执行操作Y吗 │ │ │ │ 写入目录 写入关联表 查 grants 集合 │ │ (perm_permission) (perm_role_permission) (QSetQString) │ └─────────────────────────────────────────────────────────────┘第 1 步注册插件告诉框架自己有什么资源每个插件启动时用PermCatalogScope声明自己的资源// AOI 插件启动时注册自己的页面和操作voidAoiPlugin::extensionsInitialized(){aoi::setPluginName(pluginSpec()-name());PermCatalogScopescope(aoi::pluginName());// 注册导航页PS-registerNav(nav.aoi,AOI 检测,10);PS-registerNav(nav.recipe,配方管理,20);PS-registerNav(nav.production,生产管理,30);// 注册子页面PS-registerSubPage(sub.aoi.main,nav.aoi,检测主界面,10);PS-registerSubPage(sub.aoi.log,nav.aoi,检测日志,20);PS-registerSubPage(sub.recipe.edit,nav.recipe,配方编辑,10);// 注册操作资源PS-registerAction(recipe.save,sub.recipe.edit,保存配方);PS-registerAction(recipe.delete,sub.recipe.edit,删除配方);PS-registerAction(recipe.export,sub.recipe.edit,导出配方);}关键点这里只声明有这个资源不决定谁能用。决定权在管理员手里。第 2 步分配管理员在后台勾选管理员登录后在权限管理页面看到所有已注册的资源树nav → sub_page → action给每个角色勾选需要的资源保存后数据写入perm_role_permission关联表联动规则取消 nav下面的子页和操作全部取消。勾了 action它的父级必须已勾选。这套规则叫 normalize防止数据库里出现逻辑上不可能的组合。第 3 步查询运行时每个页面问用户登录时// 登录成功后PS-reloadForUser(userId);// 内部做了什么// 1. 查用户绑定的角色// 2. 查该角色的全部 grants// 3. 缓存到 QSetQString m_grants// 4. 发射 permissionsChanged 信号// 所有窗口收到信号后重新检查显隐然后每个页面问PS-can(key)回答只有 yes/no。三、PermService 核心源码这个全局单例是整个权限系统的枢纽。核心方法没多少行但设计很讲究。// PermService 全局单例宏 PS 就是它的快捷方式#definePS(PermService::instance())classPermService:publicQObject{Q_OBJECTpublic:staticPermService*instance();// 全局单例// ---------- 查询运行时高频调用 ----------boolcan(constQStringresourceKey)const;// 三个快捷方法底层都走 can()boolcanNav(constQStringnavTitleKey)const{returncan(navTitleKey);}boolcanSubPage(constQStringsubPageKey)const{returncan(subPageKey);}boolcanAction(constQStringactionKey)const{returncan(actionKey);}// ---------- 注册插件初始化时调用 ----------boolregisterNav(constQStringkey,constQStringdisplayName,intsortOrder0);boolregisterSubPage(constQStringkey,constQStringparentNavKey,constQStringdisplayName,intsortOrder0);boolregisterAction(constQStringkey,constQStringpageKey,constQStringdisplayName);// ---------- 生命周期 ----------voidreloadForUser(qint64 userId);// 登录时加载 grantsvoidlogout();// 登出 → 回到最小用户voidreloadAsMinimalUser();// 冷启动用signals:voidpermissionsChanged();// 权限变化 → UI 重新检查显隐private:QSetQStringm_grants;// 当前有效身份的全部 grants// 运行时 can() 只查这个集合O(1) 查询};can() 的实现就一行boolPermService::can(constQStringresourceKey)const{if(!isReady()||resourceKey.isEmpty())returnfalse;returnm_grants.contains(resourceKey);}reloadForUser 的实现也不复杂voidPermService::reloadForUser(qint64 userId){// 1. 找用户的角色qint64 roleId0;m_backend-primaryRoleIdForUser(userId,roleId);// 2. 加载该角色的全部 grantsm_effectiveUserIduserId;m_effectiveRoleIdroleId;autokeysm_backend-loadGrantKeysForRole(roleId);m_grantskeys;// ← QSetQString 直接赋值// 3. 通知所有 UI 刷新emitpermissionsChanged();}注意一个设计细节registerNav可能在权限插件还没初始化完就被调用。Aether 的处理是——先排队boolPermService::registerNav(constQStringkey,constQStringdisplayName,intsortOrder){if(m_catalogRegistrarm_catalogRegistrar-isReady())returnm_catalogRegistrar-registerNav(key,displayName,sortOrder);// 还没准备好先缓存起来PendingCatalogEntry entry;entry.kindPendingCatalogEntry::Kind::Nav;entry.keykey;entry.displayNamedisplayName;entry.sortOrdersortOrder;m_pendingCatalog.append(entry);returntrue;}权限插件初始化完成后调用flushPendingCatalog()一次性把缓存的注册全部刷进去。这样插件的初始化顺序就不影响了——A 插件先跑还是 B 插件先跑结果都一样。四、JSON 配置驱动的权限目录资源注册到哪了不写在代码里存在数据库。但是运行时我们需要一个权限目录快照——也就是当前系统有哪些 nav、哪些 sub_page、哪些操作它们的父子关系是什么。这个目录在 Aether 里虽然是 DB 存的但理解时完全可以想象成 JSON{navs:[{key:nav.aoi,displayName:AOI 检测,sortOrder:10,children:[{key:sub.aoi.main,displayName:检测主界面,actions:[aoi.inspect.start,aoi.inspect.stop]},{key:sub.aoi.log,displayName:检测日志,actions:[aoi.log.query,aoi.log.export]}]},{key:nav.recipe,displayName:配方管理,sortOrder:20,children:[{key:sub.recipe.edit,displayName:配方编辑,actions:[recipe.save,recipe.delete,recipe.export]}]}]}这套结构的好处菜单 权限目录。菜单的结构和权限的树结构是同一个东西。不再需要维护两份配置。新的业务模块加入时加一个 nav 节点下面挂 sub_page 和 action结构一清二楚。导航框架拿到这个结构就能渲染菜单不需要额外逻辑。管理员在管理后台看到的权限树就是这个结构在 UI 上的渲染。五、前端拦截 后端校验权限不能只靠 UI 隐藏。万一有人直接调接口呢Aether 做了两层防护第 1 层UI 隐藏防君子// 导航栏没权限就不显示voidMainWindow::onPermissionsChanged(){for(autonav:m_navItems){nav.button-setVisible(PS-canNav(nav.titleKey));}}// 按钮没权限也不显示或灰掉m_btnSave-setVisible(PS-canAction(recipe.save));// Command 按钮自动绑定权限m_saveCommand-setName(recipe.save);// → FunctionalCommand::canExecute() 会自动检查 PS-can(recipe.save)// → 没权限时按钮灰掉且不会触发执行和审计第 2 层Command 中间件防小人用户走到 UI 隐藏但还有办法绕过——比如直接调接口、注入事件、改浏览器控制台如果是 Web 端。Aether 的 MVVM 框架里所有操作走Command::run()中间有一层全局中间件Command::run() → 权限中间件: PS-can(name())? 不行就拦截 → 审计中间件: 记下谁在什么时候做了什么 → execute(): 真正的业务逻辑就算 UI 上的按钮被某种方式点到了中间件也会再拦一道。不被 UI 绑死同一个 Command 可以被菜单、快捷键、工具栏等多处触发权限判定统一走中间件不会漏掉。六、一些你可能也会踩的坑按钮灰了还点得了检查是否绑定的是run()而不是execute()。run()走中间件execute()直接跳过。登录后权限没生效确认调了reloadForUser(userId)。只是登录成功还不够grants 得重新加载。未登录时不该看到的页面出现了冷启动时默认用minimal角色的 grants可能给了太多。检查minimal角色的授权范围。加了新操作但角色管理里看不到检查插件里是否调了registerAction而且PermCatalogScope是否包住了注册代码。花 3 天写个凑合能用的权限系统不难。花 3 天写一个能撑到 30 个页面、10 个角色、不用改代码的权限系统几乎不可能。Aether 的这套 RBAC 设计核心思路就一句话把谁有什么权限从代码里踢出去变成数据让管理员来决定让系统来执行。如果你也在做权限相关的设计或者被 if-else 权限坑过评论区聊聊你的方案。觉得有用点个在看让更多人看到也鼓励我继续写下去。下一篇我们拆解 Aether 的 i18n 架构。做了全球市场才知道国际化不只是翻译的问题——日期格式、数字千分位、图片嵌文字……还有哪些坑等你踩系列目录第 1 篇从 0 到 1 写一个插件化架构第 2 篇插件系统的 6 种死法第 3 篇DLL 地狱与依赖倒置第 4 篇服务容器new 是病得治第 5 篇MVVM 模式落地实战第 6 篇DataBinding 绝不等于 Qt 信号槽第 7 篇中间件AOP 的正确打开方式第 8 篇3天写完的权限系统上线第一天就崩了第 9 篇做了海外项目才懂国际化根本不是翻译的问题预告