很多团队在做权限系统时，最容易混淆的是“登录认证”和“资源授权”到底该由谁负责。Casbin 的定位比较明确：它不接管账号体系，而是专门处理访问控制；看完它支持哪些语言、具备哪些能力、又刻意避开什么职责，基本就能判断它适不适合放进你的项目里。
Casbin 支持哪些语言实现
Casbin 是一个高效的开源访问控制框架，同一套理念已经落地到多种编程语言中，适合在不同技术栈里复用权限模型。
目前可见的语言实现包括：
Casbin（Golang）：可用于生产环境jCasbin（Java）：可用于生产环境node-Casbin（Node.js）：可用于生产环境PHP-Casbin（PHP）：可用于生产环境PyCasbin（Python）：可用于生产环境Casbin4D（Delphi）：experimentalCasbin-Net（.NET）：WIPCasbin-RS（Rust）：WIP
如果你的系统已经横跨多种服务语言，这一点很实用：权限设计不必随着语言切换而重做，只需要在各自实现里沿用同一套访问控制思路即可。
Casbin 负责什么
Casbin 的重点是把“谁能对什么资源做什么操作”这件事抽象出来，并用统一模型表达。默认请求格式是 {subject, object, action}，也就是主体、资源、动作三元组，但它并不把这个格式写死，允许按业务实际情况自定义请求结构。
在能力上，Casbin 主要覆盖以下几个方面：
- 支持自定义请求格式，默认格式为
{subject, object, action}。 - 负责访问控制模型及其策略的存储。
- 支持 RBAC 中的多层角色继承，而且不仅主体可以有角色，资源本身也可以具有角色。
- 支持超级用户，例如
root或Administrator，这类用户可以不受授权策略约束访问任意资源。 - 提供多种内置操作符，例如
keyMatch，方便管理路径式资源。比如/foo/bar可以映射到/foo*。
这意味着 Casbin 既适合常见的角色权限控制，也适合资源路径较多、接口规则较复杂的系统。尤其是像 keyMatch 这样的匹配能力，可以减少大量手工枚举路径策略的工作量。
Casbin 不负责什么
理解 Casbin 的边界，和理解它的能力同样重要。它并不是一个“大而全”的权限平台，而是刻意把职责收得很窄。
- 它不做身份认证
authentication，也就是不负责验证用户名、密码。身份认证应该由专门组件完成，Casbin 只在认证完成后负责访问控制，两者是配合关系。 - 它不管理用户列表或角色列表。Casbin 认为这些内容更适合由业务系统自己维护。用户通常还关联密码等敏感信息，而 Casbin 的设计目标并不是充当这类数据容器，它更关注的是 RBAC 方案里用户与角色之间的映射关系。
换句话说，Casbin 更像授权层，而不是账号中心。若你的系统已经有登录、用户管理、组织架构或角色维护模块，那么 Casbin 的接入方式通常会更自然：认证继续由原系统负责，Casbin 专注做授权判定。
