插件菜单注册踩坑：权限节点少写个 `auth_rule` 前缀，后台给我整了出"薛定谔的菜单"

上周给后台管理系统写了个数据归档插件，前端页面、API 接口都调通了，就剩最后一步——把菜单挂到后台导航里。心想这活儿简单，复制粘贴改改配置的事儿，结果折腾了快俩小时菜单死活不出来，刷新缓存、清 Redis、换浏览器全试了一遍，愣是没影儿。

最后翻官方文档才瞄见一行小字：权限节点声明必须带完整前缀。我原来写的是 archive/manage，实际得写成 admin/archive/manage。就少了前面这个 admin/，菜单注册直接静默失败，连条报错日志都不给，跟玩捉迷藏似的。

更坑的是，如果你用了多级菜单，父节点的 auth_rule 还得和子节点对上。我一开始父节点写的 admin/archive，子节点手滑写成了 admin/archives/list，多了个 s，结果父菜单显示正常，点进去子菜单全灰，权限校验通不过。这种拼写错误在几百行配置里根本肉眼难辨，后来我是把数据库里 auth_rule 表导出来，用 VS Code 列模式对齐检查才揪出来的。

还有个小细节：插件安装时如果菜单已经存在，大部分框架不会自动覆盖，而是直接跳过。我调试时反复卸载重装，其实旧菜单记录还躺在库里，新配置压根没生效。现在我的习惯是，插件开发阶段必写一条 php think menu:clear --plugin=xxx 进安装脚本，暴力清完再重新注册，省得跟自己较劲。

说到路由绑定，有些系统要求菜单 URL 和实际路由名保持一致，但有些允许你菜单挂 /archive/list，实际路由是 /archive/index，这种"表里不一"的设计刚开始很容易把人绕进去。我现在每加一个菜单项，必定在注释里写清楚对应哪个 Controller 的哪个方法，三个月后再看不至于一脸懵。

你们插件菜单注册遇到过什么离谱的坑？我目前最怕的就是这种"配置对了但没完全对"的场景，表面一切正常，实际处处埋雷。