Go mod 好菜系列 - 0x10 casbin 这口权限模型别只会写 if role == admin

很多项目最开始做权限控制时，写法都差不多：

if user.Role != "admin" {
    return errors.New("forbidden")
}

这种写法起步当然快，但只要角色一多、资源一多、操作一多，很快就会变成一地权限 if/else。到那时你会发现，问题已经不是“能不能判断”，而是“这套判断还有没有组织”。这就是 casbin 经常出场的地方。

casbin 是在解决什么问题

它解决的是 授权，更准确地说，是“谁对什么资源能做什么操作”的规则表达和判断问题。

它不是拿来做登录的，也不是拿来发 token 的。它和 JWT 的关系更像：

• JWT 告诉你这个人是谁
• casbin 告诉你这个人能干什么

为什么 casbin 会常见

因为一旦系统角色和资源开始多起来，权限逻辑就很容易散。你今天在 handler 判一次，明天在 service 判一次，后天在前端又判一次，最后谁都不确定系统真实规则到底在哪。

casbin 的价值，就是试图把这套规则集中成一层明确的模型和策略。

最常见的模型：RBAC

casbin 支持很多模型，但项目里最常见的还是 RBAC，也就是基于角色的访问控制。

你可以粗暴理解成：

• 用户属于某个角色
• 角色拥有某些权限
• 系统根据角色决定用户能做什么

一个非常简化的规则感

模型文件和策略文件是 casbin 的典型味道。你先定义“规则长什么样”，再填“具体谁能做什么”。

[request_definition]
r = sub, obj, act

[policy_definition]
p = sub, obj, act

[role_definition]
g = _, _

[matchers]
m = g(r.sub, p.sub) && r.obj == p.obj && r.act == p.act

虽然初看有点像在看小型 DSL，但一旦理解了，其实就是把权限判断从散落在代码里的 if/else 抽成了一套规则描述。

代码里用起来是什么感觉

ok, err := enforcer.Enforce("alice", "/articles", "read")
if err != nil {
    return err
}
if !ok {
    return errors.New("forbidden")
}

这个 API 本身很朴素，重点不在调用有多复杂，而在于背后的权限规则开始被统一管理了。

casbin 特别适合什么场景

• 角色和资源开始多起来
• 权限逻辑已经散在多个地方
• 团队希望把授权规则单独抽层
• 后续还有“谁能看、谁能改、谁能删”的大量细分需求

如果你的项目目前只有“管理员”和“普通用户”两个角色，且权限差异很小，那未必现在就得上它。

它不能替你想清楚业务权限

这点特别重要。casbin 很擅长承载权限规则，但规则本身还是你来设计。它不会替你决定“文章作者能不能删已发布文章”“客服能不能看财务数据”这种业务问题。

工具可以让规则表达更清晰，但不会替你把规则想对。

小结

casbin 这道菜本质上是权限工程化工具：

• 它解决的是授权，不是认证
• 很适合把散乱的权限判断集中起来
• RBAC 是最常见的落地方式
• 规则设计本身仍然要靠业务理解，不靠工具替你拍板

下一篇我们讲 ginkgo/gomega。前面说了 testify，这次换另一派测试风格，看看为什么有团队会更喜欢行为式描述。