菜单归属与保护

这一页解决什么问题：应用声明的菜单落进 sys_menu 之后就是普通行 —— 「系统管理 → 菜单管理」里谁都能改 path / component / perms，也能直接删掉。 本页讲清三件都能自己核对的事：

1. 平台怎么认出一行菜单属于哪个应用（四张表反查，不需要给 sys_menu 加列）；
2. 哪些操作会被拒（只有三类操作，其中两类被拒，其余一律放行）；
3. 为什么归属必须连后代一起算（按钮那层不在映射表里）。

菜单清单本身怎么写不在这里，见 菜单与权限 与 应用清单 app.json。

归属从哪来：app_version_menu 的四表反查复制标题链接

菜单同步时已经把 (version_id, menu_id, menu_key) 写进了 app_version_menu， 它就是权威记录。反查链是四跳：

app_install（本租户装了哪些应用，这张表带 tenant_id）
  → app_info（app_code / app_name）
  → app_version（这些应用的**所有**版本）
  → app_version_menu（version_id → menu_id）

app_version_menu 的列与约束（DDL 在 wujies-platform/script/sql/update/app_market.sql）：

唯一键 uk_version_menu (version_id, menu_id)、uk_version_menu_key (version_id, menu_key)， 另有 idx_version_menu_menu (menu_id) —— 归属反查走的就是这条索引。

接线一共四处：

租户边界：带 tenant_id 的只有第一跳复制标题链接

AppMenuOwnershipProvider 的类注释写「租户过滤交给 MyBatis-Plus 插件（不 ignore）」—— 这句话是对的，但看代码时要接着看清一件事：四张表里只有 app_install 带 tenant_id， app_info / app_version / app_version_menu 都在 tenant.excludes 里（平台级全局表， 见 wujies-platform/wujies-admin/src/main/resources/application.yml 与 配置项）。

所以实际效果是：A 租户装的应用，不会让 B 租户的同名菜单被保护， 差别只产生在 app_install 那一跳；目录与映射本身是全部署共用一份的。

另一个容易误判的点：归属查询只排除 del_flag='1'，不按安装状态过滤。 所以停用（disabled）的应用，它的菜单仍受保护 —— 它随时可能被重新启用； 「卸载（保留数据）」同理，安装记录还在，菜单行也还在，归属自然还在。

保护策略：只有三类操作复制标题链接

判据在 SysMenuServiceImpl.assertAppMenuEditable：它逐字段比对「库里的当前行」与「本次提交的 BO」， 只有真的变了才计入。BO 里传 null 表示"本次不修改该字段"（与 MyBatis-Plus updateById 忽略 null 一致），不会被当成"要改成 null"—— 否则只改菜单名的请求也会被误拦。

被拒时抛的是 ServiceException，原文如下（可直接拿来对日志）：

菜单「<菜单名>」由应用「<应用名>」安装，不能修改<路由地址、组件路径、权限标识、菜单类型、上级菜单里变了的那些>。
这些字段与插件代码和前端路由绑定，改了会导致页面打不开或权限失效。
如需调整，请修改该应用的 app.json 后重新打包升级；只改名称、图标、排序、显隐是可以的。

菜单 <menuId>（<应用名>） 由应用安装，不能在菜单管理里删除 ——
删掉之后只能靠重装或升级该应用恢复。如果只是想让它不显示，请改为「停用」或停用该应用。

归属要连后代一起算（AppMenuTreeExpander）复制标题链接

映射表里只有清单声明过的菜单，而 sys_menu 里还有一层： 按钮（menu_type='F'，例如 gallery:image:query）—— 它们历史上来自平台初始化 SQL， 从来不在映射表里。只看映射表会同时坏两件事，而且都是静默的：

所以归属计算的第 5 步是下钻：AppMenuOwnershipProvider.ownedMenus() 调 AppMenuTreeExpander（同一个类也被 AppPurgeService 用来决定"该删哪些菜单行"， 避免两边各写一份然后分叉）。

• withDescendants(roots)：返回「roots 自己 + 全部层级后代」；
• descendantsOf(roots)：只要后代；
• 下钻是广度优先 + LinkedHashSet 去重，数据被手工改坏成环（A 的父是 B、B 的父是 A） 也不会死循环；
• loadChildrenByParent() 一次读全表 sys_menu（只取 menu_id / parent_id）建索引， 并在 TenantHelper.ignore(...) 里跑，避免调用方上下文（定时任务等）干扰。

回归测试：wujies-platform/wujies-modules/wujies-app-market/src/test/java/cn/wujies/appmarket/service/AppMenuTreeExpanderTest.java （5 项，纯函数、不启 Spring、不连库：多层下钻 / 多根不串门 / 叶子 / 空输入 / 环）。

两个容易搞错的点复制标题链接

1. 保护必须在服务端复制标题链接

菜单管理页（plus-ui/src/views/system/menu/index.vue）会禁用删除按钮、 编辑弹窗里也会禁用路由字段并给一条 el-alert 提示，但接口是同权限可调的 （其它客户端、直接 curl）。页面禁用只是"提前说清楚能改什么"，不是安全边界； 真正的收口点是 SysMenuServiceImpl。

2. 框架自带的检查会先拦住大多数删除复制标题链接

SysMenuController 在进入 service 之前就有两道判断（原文）：

所以实测归属保护时必须先摘掉角色分配、先删掉子菜单，否则根本走不到归属检查 —— 归属检查是最后一道，专治"菜单成了孤儿"（没有子菜单、也没有角色分配，但仍然是应用装的）。

「安装成功、状态 enabled，但一个菜单都没有」复制标题链接

这是实测踩到过的一类静默失败，根因是死映射：某条归属映射挂在软删除的旧版本上 （version_id 已不在目录里），「彻底删除」清映射时按"本次删掉的菜单"（menu_id）和 "清单声明的键"（menu_key）两条线索都找不到它。

而菜单同步是按 appId 跨版本解析 key → menu_id 的，于是下次安装 / 升级会复用它指向的 已删除菜单 ID：updateById 影响 0 行、映射照样写回。

两处修法（都在代码里，缺一不可）：

自愈那一步的日志文案（用来确认"上游映射没清干净"）：

应用[<appId>]有 N 条菜单归属指向已不存在的菜单行，已按新菜单重建（原映射没清干净）: [<key>→<menuId>, ...]

卸载 / 彻底删除时，归属同时是删除依据复制标题链接

菜单行是全局行（sys_menu 在 tenant.excludes 里，不分租户），所以删除比保护严格得多， AppPurgeService.purge(...) 先过两道闸：

1. 别的租户还在用就不动全局的东西：还有别的 app_install 记录（del_flag='0' 且状态非 uninstalled，且排除自己那一条）时，菜单 / 表 / 迁移记录 / 产物全部跳过， 只把原因写进任务日志；
2. 平台表前缀受保护：只删迁移脚本声明过的表，命中 sys_ / app_ 等前缀一律跳过并告警。

菜单这一侧的对应关系：

菜单删除、数据表删除的结果都会写进任务日志，直接在 应用任务中心 看，不用翻服务端日志。

怎么自己核对复制标题链接

看某一行菜单归谁复制标题链接

GET /app/console/owned-menus      # 权限 system:menu:list
→ [{menuId, appCode, appName}, ...]   按 menuId 升序

返回的是 AppMenuOwnershipProvider.ownedMenus() 的全部结果，已经含后代 —— 所以它的条数通常比下面这条 SQL 多，多出来的就是"清单没声明、被连坐保护"的按钮。

用 SQL 复刻反查（不含后代下钻）复制标题链接

SELECT avm.menu_id, avm.menu_key, ai.app_code, ai.app_name
  FROM app_version_menu avm
  JOIN app_version av ON av.version_id = avm.version_id AND av.del_flag = '0'
  JOIN app_info    ai ON ai.app_id     = av.app_id      AND ai.del_flag = '0'
  JOIN app_install i  ON i.app_id      = ai.app_id      AND i.del_flag  = '0'
 WHERE i.tenant_id = '000000'          -- 换成你在查的租户
 ORDER BY avm.menu_id;

查单个菜单是不是映射登记过的：

SELECT ai.app_code, ai.app_name, avm.menu_key
  FROM app_version_menu avm
  JOIN app_version av ON av.version_id = avm.version_id AND av.del_flag = '0'
  JOIN app_info    ai ON ai.app_id     = av.app_id      AND ai.del_flag = '0'
 WHERE avm.menu_id = <menuId>;

查不到不等于不受保护 —— 它可能是某个被托管菜单的后代。以端点结果为准。

手工验一遍三类操作复制标题链接

1. 找一条带应用标签的菜单，把 path 改一个字符 → 应被拒（对上面第一条原文）；
2. 只改名称 / 图标 / 排序 / 显隐 → 应放行；
3. 删除 → 先把它的子菜单和角色分配摘掉，再删，才会触达归属检查被拒。

跑下钻的单测复制标题链接

根 pom 默认 skipTests=true，必须显式打开并指定 profile：

& $mvn -pl wujies-modules/wujies-app-market -B test "-DskipTests=false" "-Dprofiles.active=dev" `
    "-Dtest=AppMenuTreeExpanderTest"

MenuOwnershipProvider 在测试源码里没有引用：SysMenuServiceImpl 的拦截本身没有自动化测试， 回归靠上面的单测（覆盖下钻）+ 手工实测。

相关阅读复制标题链接

• 菜单与权限 —— 清单怎么写、menu_key 的约束、授权规则
• 应用清单 app.json —— menus[] 字段表与校验报错速查
• 数据库表 —— sys_menu 与 app_version_menu 的列、第 12 节的三点推导
• HTTP 接口索引 —— owned-menus / sync-menus 的权限与出入参
• 应用生命周期 —— 卸载与彻底删除的完整步骤与顺序
• 应用任务中心 —— 删除类操作的结果看哪里
• 配置项 —— tenant.excludes 里哪些表是全局表
• 必须遵守的不变量 —— 菜单相关硬约束的清单