中间件应加载用户权限数据并注入context，不执行校验；登录后查出Permission.Code存入map[string]struct{}，用类型安全key（如permKey）调c.Set()注入，handler中通过c.Get(permKey)安全断言获取。
Go Echo 中间件里怎么加载用户权限数据
权限校验必须快，不能每次请求都查库。中间件只负责“加载并注入”，不负责“判断是否放行”。关键动作是：登录成功后，一次性查出该用户所有 Permission.Code（如 "user:read"、"order:delete"），塞进 map[string]struct{}，再挂到 echo.Context 上。
常见错误是直接把 Role 名或 User 结构体塞进去——后续鉴权还得再查关联表，性能崩了；也有人用 context.WithValue 传裸字符串 key，导致类型断言失败 panic。
- 定义类型安全的 key：
type permissionKey string; const permKey permissionKey = "rbac_perms" - 中间件中加载完后调用：
c.Set(permKey, perms)（perms是map[string]struct{}） - 业务 handler 里取值：
if perms, ok := c.Get(permKey).(map[string]struct{}); ok { ... }，务必先判ok - 别在中间件里写
if !has("xxx") { c.NoContent(403) }——这会让中间件职责过重，且无法支持按钮级等细粒度判断
路由级权限控制怎么绑定到 Echo.Group
RBAC 的路由控制不是靠装饰器自动扫描，而是显式声明。Echo 没有内置注解机制，所以得靠 Group.Use() + 自定义中间件组合，再配合路由注册时的语义化命名。
比如管理后台的用户模块，所有路由前缀是 /api/v1/users，那就在创建 group 时统一加权限检查：
users := e.Group("/api/v1/users")
users.Use(RequirePermission("user:read"))
users.GET("", listUsersHandler)
users.GET("/:id", getUserHandler)
users.POST("", createUserHandler)
users.PUT("/:id", updateUserHandler)
其中 RequirePermission("user:read") 是一个返回 echo.MiddlewareFunc 的函数，它从 c.Get(permKey) 取出权限 map，检查是否存在对应 key。注意：这里传的不是角色名，是具体权限 code。
- 不要传
"admin"或"manager"这类角色名——角色是配置层概念，鉴权层只认权限 code - 一个路由可能需要多个权限（如编辑需
"user:read"+"user:update"），那就用RequirePermissions("user:read", "user:update") - GET 列表页和 GET 单条用同一个权限 code 是常见偷懒做法，但实际应区分——
"user:list"和"user:detail"更利于后期审计与灰度
为什么 Enforce() 总返回 false？Casbin 在 Echo 里怎么调才对
用 Casbin 接入 Echo 时，enforcer.Enforce() 返回 false 的根本原因几乎都是策略没加载或参数错位。Casbin 不关心你是谁、从哪来，只认三个 string 参数：user、resource、action。
开箱即用的技能链路由引擎。13 条预定义链覆盖搜索、开发、审查、MLOps、法律、创意等场景，三层路由架构（触发词→SAD反馈→DAG编排），recall@10=96.97%。配置驱动（chains.yaml），零代码扩展。pip install skill-weave-chains 一键安装。
典型错误场景：
- 把完整 URL 当 resource 传进去，比如
/api/v1/users?id=123，但策略里写的是/api/v1/users—— query string 不匹配，直接 fail - 误把 HTTP 方法当 action，却传了大写
"GET"，而策略里是小写"get"，或用了"read"这种业务语义词，没对齐 - 没调
enforcer.LoadPolicy()，或者只在init()里调了一次，数据库改了权限但内存没更新 - 用
gorm-adapter时，忘记在服务启动后主动触发一次加载，或 adapter 初始化时连接池未就绪，静默失败
正确做法是：在用户登录后，用 enforcer.AddNamedGroupingPolicy("g", userID, roleName) 动态加角色归属，再用 enforcer.AddNamedPolicy("p", roleName, resource, action) 同步权限变更；日常鉴权只走 enforcer.Enforce(userID, resource, action)。
按钮级权限为什么不能只靠后端拦截
后端路由拦截只能拦住请求，拦不住前端页面上按钮的显示与点击。如果只做路由级控制，攻击者绕过前端、直接发 POST /api/v1/users 请求，照样能执行操作。
按钮级权限必须前后端双重落地：
- 后端提供接口返回当前用户拥有的全部权限 code 列表（如
GET /api/v1/me/permissions），前端缓存并用于控制 UI 元素显隐 - 前端按钮点击时，仍要校验本地权限列表（避免闪现后隐藏），但最终提交仍需后端再次鉴权
- 权限 code 命名要有层次感但不嵌套，比如
"user:create"、"user:import"、"user:export"，而不是"user:admin:create"——后者无法按前缀批量授权，也难做按钮分组 - 特别注意：导出按钮常被忽略权限控制，结果造成敏感数据批量泄露，这是生产事故高发点
最易被忽略的一点：权限缓存失效时机。用户在后台改了角色，前端不知道，仍显示旧按钮。解决方案不是轮询，而是在权限变更时通过 WebSocket 或短轮询通知前端刷新权限列表 —— 这个链路一旦断掉，按钮级控制就形同虚设。
