中间件通过解析请求头（如Authorization）获取用户身份，并存入context.Context；请求路径用r.URL.Path获取，注意其为原始路径、不含查询参数。
中间件怎么拿到用户身份和请求路径
Go 的 HTTP 中间件本质是函数套函数，http.Handler 或 http.HandlerFunc 类型。权限控制的前提是：你得先知道「谁在访问」和「想访问什么」。常见做法是在认证中间件（如 JWT 解析）之后挂权限中间件，靠 context.Context 透传用户信息——比如把解析出的 userID、roles 或 permissions 存进 ctx，再在权限中间件里取出。
请求路径用 r.URL.Path 拿，注意它不含查询参数，也未自动处理路由变量（如 /users/{id} 中的 {id}），所以权限规则最好基于静态路径前缀或预定义的路由名，而不是原始路径字符串做模糊匹配。
常见错误：直接从 Header 重复解析 token，既浪费又可能和上游认证逻辑不一致；或者把用户角色硬编码在中间件里，导致无法动态更新权限。
- 用
context.WithValue存用户数据，键建议用自定义类型（如type userKey string），避免字符串键冲突 - 路径匹配优先用
strings.HasPrefix判断前缀（如/admin/），比正则轻量且可控 - 如果用了 Gin/Echo 等框架，别绕过其上下文（
c.Request.Context()），否则拿不到上游塞的数据
如何设计权限检查逻辑：RBAC 还是 ABAC
简单服务用 RBAC（基于角色）就够了：每个角色对应一组预设的 resource:action 规则，比如 user:read、post:write。ABAC（基于属性）更灵活但复杂度高，需要实时评估用户属性、资源属性、环境条件，一般在中大型系统才引入。
Go 里实现 RBAC 权限检查，核心是一个映射结构：map[role][]string，或者更清晰地用结构体封装：
type Permission struct {
Resource string
Action string
}
type RolePermissions map[string][]Permission
中间件里查当前用户角色（从 ctx 取），再查该角色是否包含当前请求所需的 Resource（如 "order"）和 Action（如 "delete"）。注意大小写和命名约定要统一，比如全部小写加下划线。
- 避免在每次请求时读文件或查 DB 加载权限配置——启动时加载进内存，用
sync.RWMutex保护更新 - 不要把权限判断写死在中间件函数里，抽成独立函数（如
CanAccess(ctx context.Context, resource, action string) bool），方便单元测试 - 对
GET /health、OPTIONS等公共接口，应显式放行，别让权限逻辑兜底
HTTP 状态码和错误响应怎么写才不翻车
权限拒绝必须返回明确的状态码：401 Unauthorized 表示没登录或 token 无效；403 Forbidden 表示已认证但无权操作。混淆这两者会让前端无法正确跳转登录页或提示权限不足。
响应体建议保持简洁，JSON 格式即可，不需要堆叠业务字段。例如：
{"error": "permission denied", "code": "forbidden"}
常见错误：返回 200 OK + 错误信息，前端以为成功；或返回 500 Internal Server Error，掩盖了其实是权限问题；还有人在拒绝时直接 panic 或 log.Fatal，导致整个服务中断。
- 用
w.WriteHeader(http.StatusForbidden)显式设状态码，别只靠json.NewEncoder(w).Encode(...)默认的 200 - 避免在中间件里调用
http.Error，它会写死状态码为 500 或 400，不满足 401/403 区分需求 - 日志里记录被拒的
userID、r.Method、r.URL.Path和缺失的权限项，但别打明文密码或 token
中间件顺序和框架兼容性要注意什么
权限中间件必须放在认证中间件之后、业务 handler 之前。顺序错了，要么拿不到用户信息（ctx 为空），要么权限检查被跳过（比如 panic 恢复中间件吞掉了错误）。
原生 net/http 下链式调用很直观：
http.Handle("/api/", authMiddleware(permissionMiddleware(apiHandler)))
但 Gin 中要用 c.Next() 控制流程，Echo 则依赖 next(c)；如果混用多个中间件（如 CORS、日志、熔断），务必确认它们不覆盖或清空 context.Context 中的关键值。
- Gin 用户注意：别在权限中间件里用
c.Abort()后还执行c.Next()，会导致 panic - 所有中间件都应有明确的「短路退出」路径，比如 token 解析失败就立即返回 401，别继续往下走
- 如果 API 路由用了通配符（如
/:id），权限规则需提前归一化路径（如把/users/123映射为/users/{id}），否则每条 ID 都要单独配权限
权限不是越细越好，路径层级、动词粒度、角色数量三者之间要平衡。一个被忽略的点是：删除权限往往隐含读取权限，但代码里不会自动继承——得靠设计时显式声明，或在检查时做规则合并。
