最轻量角色-权限映射用 map[string][]string 实现，需加 sync.RWMutex 保障并发安全，权限字符串统一小写冒号分隔；多角色应从 JWT 的 roles 数组提取并合并权限；复杂场景推荐 Casbin，注意初始化加载策略、校验签名及 token 失效机制。
用 map[string][]string 实现角色-权限映射最轻量
不需要引入框架或数据库时，直接用内存映射是最快速落地的方式。角色名作为键，权限列表作为值，比如 "admin" 对应 ["user:read", "user:write", "config:edit"]，"viewer" 对应 ["user:read"]。
注意点：
-
map非并发安全，多 goroutine 写入需加sync.RWMutex - 权限字符串建议统一小写、用冒号分隔资源与动作（如
post:delete），避免大小写或空格导致匹配失败 - 不要用嵌套结构（如
map[string]map[string]bool）——增加判断复杂度且不易序列化
中间件里调用 checkPermission(r *http.Request, required string) 做路由级拦截
HTTP 处理前检查当前用户是否拥有该接口所需权限。典型做法是把用户角色从 session 或 JWT 中取出，再查上面的权限映射表。
示例逻辑：
立即学习“go语言免费学习笔记（深入）”；
func checkPermission(r *http.Request, required string) bool {
role := getUserRoleFromRequest(r) // 从 context 或 header 提取
perms, ok := rolePermissions[role]
if !ok {
return false
}
for _, p := range perms {
if p == required {
return true
}
}
return false
}
常见坑：
- 忘记在 handler 前调用，或误放在日志/认证之后——权限检查必须在业务逻辑执行前完成
- 把
required写成硬编码字符串（如"user:write"），后续难维护；建议定义常量const UserWrite = "user:write" - 未处理匿名用户场景，直接 panic 或返回 500；应明确返回
401或403
用 github.com/casbin/casbin/v2 替代手写逻辑应对 RBAC 扩展需求
当出现“某角色对某资源的某操作是否允许”这类细粒度控制，或需要支持策略持久化、动态更新时，手写映射很快会失控。Casbin 是 Golang 生态中事实标准的权限库。
WOC开源网站运营管理系统1.2
下载
WOC是基于zend framework1.6框架所开发的一款开源简易网站运营管理系统。它允许进行网站管理、主机管理、域名管理、数据库管理、邮箱管理以及用户管理、角色管理、权限管理等一系列功能，适合中小企业进行网站运营管理。目前版本为V1.2，新版本正在开发中，同时欢迎大家参与到开发中来！ WOC升级说明： 1.1在1.0的基础上进行了代码规范并增加了配置数据缓存，以提高访问速度 注意：升级时要重
它核心靠三元组：sub（用户/角色）、obj（资源）、act（动作）。模型文件（如 rbac_model.conf）定义规则结构，策略数据可存于内存、文件或数据库。
关键提醒：
- 初始化时务必调用
enforcer.LoadPolicy()，否则策略为空，所有请求都拒绝 - Casbin 默认不校验用户是否存在，只管策略匹配；角色继承、资源层级等高级功能需在模型中显式启用
- 若用
gorm-adapter，注意数据库字段名与 Casbin 要求一致（如p_type,v0,v1,v2），否则策略加载失败但无报错
JWT token 中嵌入 roles 字段而非单个 role 支持多角色叠加
真实系统中用户往往兼具多个角色（如既是 editor 又是 moderator），仅存一个 role 字段会导致权限丢失或逻辑绕过。
推荐 JWT payload 结构：
{
"sub": "u_123",
"roles": ["editor", "moderator"],
"exp": 1735689600
}
这样在权限检查时可遍历所有角色合并权限：
func getEffectivePermissions(roles []string) map[string]bool {
perms := make(map[string]bool)
for _, r := range roles {
for _, p := range rolePermissions[r] {
perms[p] = true
}
}
return perms
}
容易被忽略的细节：
-
前端传来的 JWT 不可信，
roles字段必须由服务端签发并验证签名，不能由客户端构造 - token 过期时间不宜过长（尤其含敏感权限时），建议搭配短期 token + refresh token 机制
- 如果用 Casbin，可将
roles数组传给enforcer.GetImplicitPermissionsForUser()自动合并策略
if 判断，而是权限数据来源是否可信、变更是否可追溯、边界场景（如用户被移除角色后旧 token 是否立即失效）有没有覆盖。这些地方一旦漏掉，再“正确”的逻辑也形同虚设。 
