数据流转确权平台｜数据模型、权限粒度、迭代重构问题

做过一个数据流转确权的 B 端系统，核心业务一句话能说清：谁的数据、谁能看、流转过哪些环节、出问题找谁。落到系统上，就是数据归属认定、分级授权、流转溯源、权限回收、操作审计这一整条链路。

这个项目让我最痛的一次教训，是前期的数据模型设计没想清楚，后面还债还了很久。

第一个坑：全量拷贝

初期我图省事，采用了"全量数据拷贝"的流转方案——每次数据授权流转，都生成一份完整的数据副本。短期看确实简单，但数据一多就爆了：存储空间指数级增长，查询链路越来越长，数据库 IO 被拖垮。授权一次拷贝一份，这个设计从根上就是错的。

这个坑的本质，是混淆了"业务数据"和"授权关系"两个概念。正确的模型应该是：数据本身只存一份，授权只是记录"谁有权看它"的关联关系。用"引用"代替"复制"，数据冗余的问题才能从根上解决。这也是数据架构里"单一数据源"（Single Source of Truth）原则的体现——一份数据只在一个地方真实存在，其他都是引用。

还有个连带问题：拷贝出来的副本，一旦没有同步机制，就会出现"源数据改了、副本还是旧的"的情况。你要么做同步（又是一套复杂度），要么接受副本失真（授权出去的是过期数据）。全量拷贝看着简单，实际上是在给自己挖更大的坑。

第二个坑：权限粒度太粗

第二个坑是权限粒度太粗。初期只支持全局资源授权和回收，不能分级、不能分字段、不能分时效。真正到企业场景里，需求往往是"这个部门的人能看这部分字段，权限给三个月"——粗粒度的权限根本没法用。

权限设计这里有个进阶的思路。基础是 RBAC（角色权限），但它解决不了"同一角色的人，对不同数据权限不同"的问题，所以还要叠加"数据权限"：按数据归属（本人/本部门/全公司）、按字段级别（可见/脱敏/不可见）、按时间维度（临时授权/长期授权）来精细化控制。这套东西做起来不复杂，但设计阶段就得想清楚，不然越到后期越难改。

这里尤其要提"字段级脱敏"：不是所有人都有权限看到完整数据，比如手机号、身份证这种敏感字段，低权限用户应该看到打码后的版本。这个需求几乎每个 B 端系统都会有，如果前期不在模型里留好"字段权限"的口子，后期硬加会非常痛苦。

重构后的三层模型

后来重构，我彻底换了思路，把数据模型拆成三层：

第一层是原始资源层，数据只存一份，是唯一真实数据源，不做任何拷贝；第二层是授权链路层，只存资源 ID、授权主体、时效范围、权限字段这些关联信息，用关联替代全量拷贝，数据冗余的问题从根上解决；第三层是操作审计层，记录所有授权、流转、撤销、查看行为，全链路可溯源。

权限体系也升级成细粒度 RBAC：整合角色权限、用户独立权限、时效权限、字段级可见权限，支持临时授权、分级授权、定向授权这些复杂场景，企业级的需求基本都覆盖了。权限判断用统一的服务收敛，别散落在各个业务里——集中管理，才能保证"改一处，全局生效"。

合规和审计的提醒

如果这个系统涉及个人信息或重要数据，还得把合规放进设计里。国内有《个人信息保护法》《数据安全法》这两部大法，要求数据处理的合法性、最小必要、可追溯。所以审计日志不能只是"记了就行"，要覆盖全生命周期：数据从哪来、被谁看过、流转到哪、谁撤销了授权，出问题要能倒查。这个在模型设计阶段就要留好字段和表结构，后面补审计，成本会高得多。

合规这块还有几个实操点：数据留存的期限管理（过期自动清理或归档）、导出和下载的审批留痕、权限变更的通知与确认。这些看着琐碎，但在合规审查的时候，一条都不能少。

这次教训

这次重构让我彻底记住了 B 端研发的铁律：模型设计优先于业务开发。前期数据架构和权限架构偷的懒，会在迭代中后期变成还不完的债。先把资源、授权、审计三者的关系定清楚，再写页面，比什么都强。数据平台的复杂度，从来不在页面和接口，而在"数据之间的关系"——这个关系设计错了，后面全是返工。