HTTP中间件需用chi或gorilla/mux提取路由模式（如/api/users/{id}）和method，禁用r.URL.Path直接比对；权限规则应预加载至内存两级索引map[role]map[method+pattern]struct{}，并标准化通配符；JWT须校验exp/iss/aud且roles为字符串数组；OPTIONS请求应直接放行。
Go 的 HTTP 中间件本身不内置 RBAC 支持，必须手动解析 token、查权限、比对路由与操作，且容易在路径匹配、动词判断、资源 ID 提取上出错。
如何从 http.Handler 中提取当前请求的路由模式和 HTTP 方法
标准 http.ServeMux 不暴露注册的路由模式，所以不能靠反射或逆向查表。真实项目中应使用支持路由变量提取的路由器（如 gorilla/mux 或 chi），并在中间件里通过 chi.RouteContext 或 mux.Vars(r) 拿到原始 pattern 和 method。
-
chi用户：用chi.RouteContext.FromContext(r.Context())获取RoutePattern()，它返回类似/api/users/{id}的字符串，不是最终 URL -
gorilla/mux用户：r.Method是动词，但需配合mux.CurrentRoute(r).GetPathTemplate()才能拿到定义时的 pattern - 别直接用
r.URL.Path做权限比对——它含实际 ID（如/api/users/123），而 RBAC 规则是基于抽象路径（/api/users/{id}）定义的
如何设计权限规则存储结构以支持快速匹配
把「角色 → 路径模板 → 允许方法列表」三层嵌套存成 map，会导致每次请求都要遍历所有路径做 glob 或正则匹配，性能差。更可行的是预构建一棵前缀树（trie）或用 map[string]map[string]struct{} 做两级索引。
Golang Google Wire
下载
在 Go 中使用 google/wire 实现编译时依赖注入——wire.NewSet、wire.Build、wire.Bind（接口→实现）、wire.Struct、wire.Value、wire.Interface
- 推荐结构：
map[role]map[method+pattern]struct{}，其中method+pattern拼为"GET:/api/users/{id}" - pattern 必须标准化：统一把
:id、{id}、*id都转成{id}，否则同一规则会存多份 - 避免在中间件里查数据库——权限数据应启动时加载进内存，或用带 TTL 的本地缓存（如
bigcache）
如何安全提取 JWT 中的角色并防止伪造
只验 signature 不够，必须校验 aud（目标受众）、iss（签发者）、exp（过期时间），且角色字段（如 roles）必须是字符串数组，不能是自由格式字符串。
- 用
github.com/golang-jwt/jwt/v5解析时，显式指定Claims结构体，例如Roles []string `json:"roles"` - 禁止用
MapClaims直接取值——攻击者可在 token 中塞入"roles": "admin"（字符串）而非["admin"]（数组），导致类型断言失败或静默跳过 - 如果 API 网关已做鉴权，后端中间件可跳过 JWT 解析，改从
r.Header.Get("X-Auth-Roles")读（前提是网关可信且 header 不可被客户端伪造）
为什么 OPTIONS 请求常被误拒，以及怎么绕过检查
CORS 预检请求自带 OPTIONS 方法，但它不携带业务 token，也不需要 RBAC 授权——放行即可，否则前端发不出后续请求。
- 在中间件开头加判断：
if r.Method == "OPTIONS" { next.ServeHTTP(w, r); return } - 不要试图给
OPTIONS配权限规则——它没有资源语义，只是浏览器探路 - 注意：某些前端框架（如 Angular）可能对非简单请求自动发
OPTIONS，若中间件没放行，会看到401 Unauthorized或403 Forbidden，但浏览器控制台只显示net::ERR_FAILED
最易被忽略的是路径 pattern 的标准化逻辑——不同路由器对通配符的命名不一致（:id vs {id} vs *id），而 RBAC 规则表一旦写死就很难动态适配。建议在服务启动时，用一组测试路由跑一遍转换函数，确保所有 pattern 都归一化后再载入内存。
