pageCode、actionCode、grantApis 规范

pageCode、actionCode、grantApis 是菜单权限闭环的三个关键点。下游项目必须在菜单初稿阶段就定义清楚，避免页面、按钮和接口分别使用三套名字。

pageCode

• 控制页面识别。
• 必须稳定、唯一、可读。
• PCWEB 的 registerPage 必须使用同一个 pageCode。
• APP / 小程序的页面展示也应按 app_menu 中的 pageCode 判断。

建议格式：

模块.资源.页面

示例：

demo.rule.list

actionCode

• 控制按钮或业务动作识别。
• 必须挂在具体页面或业务动作下。
• 前端按钮展示使用 canAction、ClPermissionButton 或移动端权限判断。
• 后端写接口权限应能追溯到同一动作。

建议格式：

模块.资源.动作

示例：

demo.rule.create
demo.rule.edit
demo.rule.delete
demo.rule.publish

grantApis

• 控制接口权限。
• 每个资源至少包含 resource 和 action。
• resource 必须与后端实际接口路径一致。
• action 必须与后端实际 HTTP 方法一致。
• 菜单发布和角色授权后，grantApis 应进入角色 Casbin。

示例：

{
  "resource": "/demo/platform/rule/create",
  "action": "POST"
}

对齐规则

• 菜单 JSON 的 pageCode 必须与 PCWEB registerPage、APP / 小程序页面权限判断一致。
• 菜单 JSON 的 actionCode 必须与前端按钮权限判断一致。
• 菜单 JSON 的 grantApis.resource 必须与后端接口路径一致。
• 菜单 JSON 的 grantApis.action 必须与后端请求方式一致。
• 后端 CheckPermission 的 Resource / Action 必须与 grantApis 一致。

不合格示例

• 页面只配置 .view，按钮没有 actionCode。
• 按钮有 actionCode，但没有 grantApis。
• grantApis 路径写旧接口，后端校验新接口。
• 菜单里是 POST，后端校验时传 GET。
• PCWEB 和 APP / 小程序使用不同 pageCode 描述同一个页面。