应使用闭包中间件在业务逻辑前校验权限，统一解析token/session获取userID和roles，结合RBAC配置map实现{resource}:{action}格式的细粒度控制，并确保静态资源也经权限校验。
用 net/http 中间件做路由级权限拦截
Go 原生 http.ServeMux 不支持中间件，但你可以用闭包封装 handler，把权限逻辑塞进请求处理链路最前端。关键不是“加权限”，而是“在哪个环节拒绝”——必须在业务逻辑执行前返回 http.StatusForbidden 或重定向，否则校验就失效了。
常见错误是把权限判断写在 handler 内部末尾，或者只校验登录态却漏掉角色/资源维度：
- 用户已登录 ≠ 有权限访问
/admin/users - 用
session.Get("role")取值后没判空，导致 panic 或绕过校验 - 硬编码角色字符串（如
"admin"），后续改权限模型时散落在多处
推荐做法：定义一个 func(http.Handler) http.Handler 类型的中间件，统一提取 token 或 session，解析出 userID 和 roles []string，再传给具体路由的权限检查函数。
基于角色的资源访问控制（RBAC）怎么落地
别一上来就搞数据库建 roles、permissions、role_permissions 三张表。小项目直接用 map + 配置更轻量、易调试：
立即学习“go语言免费学习笔记（深入）”；
var rolePermissions = map[string][]string{
"user": {"post:read", "comment:create"},
"editor": {"post:read", "post:update", "comment:read"},
"admin": {"*:*"},
}
注意几个实际卡点：
-
"*:*"是通配符，但得自己实现匹配逻辑，不能依赖strings.HasPrefix—— 否则"post:read"会被"post:"错误匹配 - 资源 ID 级控制（比如只允许编辑自己发的帖子）必须结合 URL 参数或请求体解析，不能只靠角色查表
- 权限字符串建议统一格式为
"{resource}:{action}"，避免出现"can_edit_post"和"edit_post"混用
gorilla/sessions 里存角色信息的安全隐患
Session 数据默认用 cookie 存储，如果没设 Options.HttpOnly=true、Options.Secure=true（HTTPS 环境下），攻击者可通过 XSS 读取并伪造角色字段。更危险的是直接把 role 当字符串存进 session：
session.Values["role"] = "admin" // ❌ 易被篡改
正确姿势是只存不可伪造的标识，比如 userID，然后每次请求都查库或缓存获取其真实权限集：
- 查库太慢？用 Redis 缓存
user:123:permissions，设置合理 TTL（如 10 分钟） - 怕缓存不一致？在用户权限变更时主动删掉对应 key
- 完全不想查库？用 JWT 替代 session，把权限列表 encode 进 token，但要注意签名密钥保密和过期时间
为什么 http.HandlerFunc 里做权限校验容易漏掉静态文件
如果你用 http.Handle("/static/", http.StripPrefix("/static/", http.FileServer(http.Dir("./static")))) 这类方式暴露静态资源，它会绕过所有自定义 handler 中间件。结果是：CSS/JS 被正常加载，但某个 JS 里调用的 /api/delete-post 接口被拦截，而 /static/admin.js 却能被未授权用户下载，里面可能泄露接口路径或权限逻辑。
解决方法只有两个：
- 静态资源也走同一套路由注册逻辑，用中间件包裹
http.FileServer - 把敏感前端资源（如 admin 页面）不放 public 目录，改由后端 handler 渲染并校验权限后再返回内容
真正难的不是写几行 if 判断，而是想清楚哪些资源该被保护、哪些可以公开，以及保护边界是否被 HTTP 路由配置悄悄绕开。
