3. 输出控制策略概念
说到输出控制策略，我先问你一个问题——你写了一条规则，绑定了数据标签，配置了授权逻辑，然后呢？这些规则怎么落地？谁来执行？什么时候生效？这背后就是策略在起作用。
我个人习惯把策略比作「交警」。标签和数据是车流，策略就是那个站在路口指挥的人。没有他，车再多也乱成一团。
3.1 策略的本质
策略的本质是什么？简单说，就是一条条件-动作规则。
IF [条件满足] THEN [执行动作]
你想想看，SDK 的每一步输出，能不能出去、去哪里、怎么去，都得问策略。它不是一个静态配置，而是一个运行时决策点。
| 对比维度 | 简单配置（非策略） | 策略（动态规则） |
|---|---|---|
| 生效方式 | 启动时加载，一般不变 | 运行时评估，可热更新 |
| 条件判断 | 简单 if-else | 多因子组合 + 上下文感知 |
| 变更代价 | 需要发版 | 动态下发，零停机 |
| 粒度 | 粗粒度（全量） | 细粒度（用户/设备/时间） |
核心观点：策略不是写死的代码逻辑，而是一组可编排、可审计、可热更新的决策规则集。
我记得早期参与一个金融 SDK 项目，一开始我们把授权逻辑硬编码在 switch-case 里。结果呢？每次产品提需求都得排期发版。后来改成策略引擎，产品自己在后台配规则，当天上线。这才是真正的「输出控制能力」。
3.2 输出控制的范围
输出控制到底管什么？范围怎么划？我给大家拆成三层看。
- 功能域：哪些功能可以用。比如分享按钮、导出接口、截图动作……
- 数据域：哪些数据可以出去。比如明文手机号、脱敏后的地址、聚合后的统计值……
- 服务域：哪个后端服务可以接。比如只允许写入自己的日志服务器，禁止呼叫三方接口……
你可能会问，这三个域要不要同时控？其实多数场景下只控一个就行。但复杂业务里——比如互金、医疗——三个域经常一起上。
| 控制域 | 控制对象 | 常见策略例子 |
|---|---|---|
| 功能域 | SDK 提供的输出能力 | 仅允许「加密分享」，禁止「明文导出」 |
| 数据域 | 输出数据的字段与内容 | 手机号必须脱敏，地理坐标精度降至 1km |
| 服务域 | 数据流向的目标地址 | 只允许推到内网 kafka，禁止公网 POST |
踩坑注意：我曾经在项目中只控制了功能域，结果产品同学配了「允许导出」，但忘了加字段脱敏——明文数据直接流出去了。记住，三个域要一起审，缺一个就是漏洞。
3.3 策略生命周期
策略不是一次性写死的。它从创建到废弃，经历完整生命。我经历过一个策略在线上跑了三年没动过？其实早该废弃了，但没人敢删。所以，咱们得把生命周期管起来。
嗯，这张图把周期画清楚了。我来拆解一下关键环节：
- 策略定义：写清楚条件（谁、什么数据、什么场景）和动作（允许/拒绝/脱敏/截断）。我建议每条策略都要有唯一 ID 和版本号，要不然后期审计会疯。
- 配置部署：策略写好了，得下发到 SDK。可以是拉模式（SDK 轮询），也可以是推模式（服务端主动下发）。我个人更推荐推模式，延迟低。
- 运行时执行：SDK 拿到策略后，在输出点做实时评估。关键点——性能。不能让策略引擎拖慢主流程。
- 监控审计：策略命中没命中？命中谁的？什么结果？全量日志必须落盘。嗯，我在项目里遇到过策略配错了，全靠日志才追溯回来。
- 策略更新：业务变化了，策略要跟着改。热更新能力是硬要求，不能每次都发版。
- 策略废弃：过期的策略要及时下线。规则多了以后，冲突排查非常痛苦。
一个实用建议：在策略系统中加一条「策略血缘关系」记录。就是这条策略是谁创建的、什么时候改过、改了什么。你不加这个，后面回溯成本极高。我踩过这个坑——线上查不出规则来源，安全审计直接亮红灯。
说到生命周期，还有一件事必须提——策略冲突。多条策略都匹配同一个输出请求时，谁说了算？
我一般用两条规则来处理：第一，更精确的优先（条件更具体的 wins）；第二，如果优先级相同，拒绝优先（deny overrides）。前者保证细粒度控制，后者守住安全底线。
好，关于输出控制策略的概念，我们先把这三块吃透。后面章节会讲怎么在 SDK 中实现策略引擎，以及如何做动态授权。一步一步来，别急。