常见SDK权限设计模式：内置权限、外部鉴权、混合模式
做SDK接入改造，第一步得摸清对方权限体系长什么样。我这些年至少接过七八种不同架构的SDK，总结下来，逃不出三种模式：内置权限、外部鉴权、混合模式。每种模式适配RBAC的套路完全不一样，选错方案，后期改起来简直就是噩梦。今天咱们就掰开揉碎讲清楚。
1. 内置权限模式：最省事，但改造最伤筋动骨
这种模式的SDK，权限判断代码直接嵌在库里。你调用它一个API，它在内部查一个硬编码的权限表或者配置文件，决定放不放行。说白了，它自己就是一个“迷你权限系统”。
我遇到过一个极端的例子——某支付SDK，它的权限控制写死在静态类的静态方法里，用一长串if-else判断用户类型。当时接入方要求走RBAC，我们不得不把整个权限模块抽出来替换，光测试就跑了三轮。
我曾经犯过一个错：以为内置权限模式改起来简单，直接把SDK里的权限枚举映射成RBAC权限点就完事了。结果发现SDK内部还有多处硬编码的权限组合逻辑，比如“admin才能调用退款接口”这种判断散布在五个文件里。后来我学乖了——改造前先做全量权限调用链扫描，用面向切面打桩把每处权限判断都抓出来。
这类模式适配RBAC的核心步骤：
- 提取所有权限点（permission）和角色类型（role）
- 把原来硬编码的
if(userType == ADMIN)替换成rbacService.checkPermission(role, permission) - 在SDK初始化时允许外部注入RBAC引擎
2. 外部鉴权模式：松耦合，但依赖网络
这种SDK本身不做任何权限判断，它只管发出请求，把用户的身份令牌或角色信息传到后端，由后端的统一鉴权中心（比如IAM、OAuth Server）来决策。我比较喜欢这种模式——因为RBAC的改造点完全落在服务端，SDK这边几乎不用动。
举个例子，去年我帮一个团队改造某个数据分析SDK。它的每个API都携带一个，SDK只负责透传。服务端拿到后去用户中心查角色，再根据RBAC规则决定是否返回数据。我们只改了服务端的权限模型，SDK一行代码没碰。
不过这种模式有坑：
- 如果SDK是客户端（比如移动端），网络抖动可能导致授权失败。
- 服务端的鉴权接口必须高性能、高可用，否则SDK体验直接崩。
- 我曾经遇到过一个坑——外部鉴权接口没有做统一超时处理，结果某次网络延迟导致SDK主线程卡住10秒，直接被系统看门狗杀掉。后来我们在SDK侧加了异步降级缓存，把最近一次成功鉴权结果保留30秒。
如果你的项目已经有成熟的IAM或OAuth体系，优先选择外部鉴权模式。SDK只需在初始化时接受一个“角色Provider”回调，由接入方自行实现RBAC查询逻辑。
3. 混合模式：两头兼顾，但复杂度翻倍
这类SDK既内置了一套权限策略，又可以连接外部鉴权系统做补充判定。典型场景是：联网时走外部，离线时走内置。我曾经在一款面向IoT设备的SDK上见过这种设计——设备联网时，权限由云端RBAC下发；断网时，用本地缓存的策略兜底。
混合模式的RBAC改造，需要同时改造两端，而且必须保证策略一致性。我个人习惯这么做：
- 把内置权限引擎重构为可插拔的RBAC引擎，支持热加载策略。
- 外部鉴权接口统一返回JSON格式的RBAC策略，SDK解析后合并到本地规则库。
- 在SDK内部维护一个版本号，每次外部策略更新后比对，防止旧策略覆盖新策略。
我踩过一个坑——混合模式里，内置引擎判断“允许”，外部鉴权判断“拒绝”，结果SDK用了“或”逻辑，导致权限越界。正确的做法应该是“与”逻辑：内外都通过才算通过，除非明确定义了降级策略。
三种模式对比速查
| 维度 | 内置权限 | 外部鉴权 | 混合模式 |
|---|---|---|---|
| RBAC改造工作量 | 大（需改SDK内部） | 小（改服务端即可） | 中（两端都要改） |
| 离线可用性 | 高 | 低（依赖网络） | 高（离线降级） |
| 权限粒度灵活性 | 低（需发版更新） | 高（服务端实时生效） | 高（策略可动态加载） |
| 安全性风险 | 低（完全本地） | 中（鉴权接口可能被绕） | 中（内外同步一致性） |
| 典型应用场景 | 嵌入式SDK、离线工具 | 云SDK、API网关SDK | 移动端、IoT设备SDK |
好了，这三种模式的特点和套路讲完了。你接下里拿到一个SDK，可以先把它往这三个框里套一套：权限判断代码在哪？有没有网络依赖？有没有离线和在线两套逻辑？定位清楚后，RBAC适配的路线图就清晰了。下次咱们具体讲讲每种模式下，改造时的代码落地细节——包括切面注入、策略分发、以及我最头疼的权限冲突解决。