FastAPI后端很火，Vue3管理台却总卡在权限上，到底谁该管按钮显不显示？
最近看了vue-fastapi-admin这个项目，不是为了抄代码，是想搞明白它怎么让后端吐出来的权限，真能管到前端按钮上。我本地跑了一遍，又翻了它的Gitee仓库、issue和源码目录，发现它没吹牛，但也没全说透。
它后端不写死路由，而是开了个`/api/v1/routers/dynamic`接口，返回带`name`、`path`、`meta.permissions`的对象。前端拿到就用`addRoute()`往路由里塞，菜单、页面跳转都跟着变。这个逻辑看起来简单，但一动就全动，不像有些项目改个菜单还得前后端一起发版。
权限码是`sys:user:edit`这种格式，三段式，不带星号。后端校验时查数据库，不是光解token。登录返回的token里除了user_id，还有`role_ids`和`permission_codes`，相当于把权限快照打进了凭证里。不过查库这事挺吃性能，issue42里有人提过加Redis缓存，但到现在还没上。
按钮控制用的是自定义指令`v-auth`，比如`
接口级校验靠FastAPI的`Depends(PermissionChecker)`，每次进接口都查一次角色-权限关系。比装饰器方式更细，但每调一次接口就多一次SQL。我没压测，但看它model层没建联合索引，高并发下可能成瓶颈。
它前端`src/directives/auth.ts`和后端`app/utils/permission.py`这两个文件，可以直接拎出来用。一个管按钮显隐，一个管权限字符串解析，逻辑干净，没裹一堆无关代码。我还试了改权限码，删掉某个code，对应按钮立刻灰掉，接口也403，链路确实是通的。
但它没做多租户，所有表都没tenant_id字段。日志就写文件，没连Sentry也没推ELK。Swagger还是原生的，权限没打标，测试时没法自动过滤出“我当前角色能调哪些接口”。这些不是bug，是它压根没往那边设计。
项目里`app/log`文件夹就三四行日志配置，`docker-compose.yml`里连ELK服务都没配。构建脚本也没开JSX支持，写复杂表单得绕着走。这些都不影响它跑起来，但真用在公司项目里，后面得自己填。
它把权限拆成三层：页面靠动态路由、按钮靠v-auth指令、接口靠Depends校验。三层之间用同一个权限码串起来，改动一处，其他地方自动响应。但“自动”是有条件的——得保证后端接口返回的permissions字段结构别乱，也得保证前端解析不写错正则。
我看它README里写着“支持按钮级权限”，但没写清楚v-auth是浅比较还是深比较。后来翻了源码，发现是直接`includes()`匹配，所以`sys:user`和`sys:user:edit`会被当成一样。这点没文档，得自己试。
它没用Vue的`defineModel`，也没上Volar最新类型提示。一些composable里还用`any`接响应数据。不是写不好，是作者没把精力放这——优先保权限链路通，再保能跑，最后才轮得到开发体验。
我把它的`auth.ts`和`permission.py`复制到自己项目里，改了两处适配我司token结构，不到半小时就跑通了登录+菜单+按钮控制。但第三天发现用户换角色后菜单没刷新，查了才发现它没监听token变更事件，得自己加watch。
它没吹“开箱即用”，也没说“企业级”，就在README第一行写：“一个带RBAC的FastAPI+Vue3管理后台模板”。我照着做，真能搭出带权限的后台，但搭完得自己补监控、补多租户、补日志上报。
它的价值不是功能多，是把权限这事从“前后端各写一遍逻辑”变成“后端定义规则，前端只负责呈现”。你改数据库里的权限配置，不用动前端一行路由代码，也不用改后端每个接口的装饰器。
它暴露了所有约束：权限靠DB查就得担性能，按钮靠指令就得管缓存，动态路由就得信后端接口格式稳定。没藏着掖着，代码就摆那儿。
我看完了。
