[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"article-data-circulation-platform-retrospective":3,"article-neighbors-data-circulation-platform-retrospective":17,"article-related-data-circulation-platform-retrospective":31},{"id":4,"slug":5,"title":6,"excerpt":7,"category":8,"tags":9,"content":13,"publishedAt":14,"readingMinutes":15,"published":16},37,"data-circulation-platform-retrospective","数据流转确权平台｜数据模型、权限粒度、迭代重构问题","数据授权一次就拷贝一份副本，权限又粗到没法用——这个 B 端项目的前期债，后期还得很痛。","项目复盘",[10,11,12,8],"Vue","前端开发","业务系统","做过一个数据流转确权的 B 端系统，核心业务一句话能说清：谁的数据、谁能看、流转过哪些环节、出问题找谁。落到系统上，就是数据归属认定、分级授权、流转溯源、权限回收、操作审计这一整条链路。\n\n这个项目让我最痛的一次教训，是前期的数据模型设计没想清楚，后面还债还了很久。\n\n### 第一个坑：全量拷贝\n\n初期我图省事，采用了\"全量数据拷贝\"的流转方案——每次数据授权流转，都生成一份完整的数据副本。短期看确实简单，但数据一多就爆了：存储空间指数级增长，查询链路越来越长，数据库 IO 被拖垮。授权一次拷贝一份，这个设计从根上就是错的。\n\n这个坑的本质，是混淆了\"业务数据\"和\"授权关系\"两个概念。正确的模型应该是：数据本身只存一份，授权只是记录\"谁有权看它\"的关联关系。用\"引用\"代替\"复制\"，数据冗余的问题才能从根上解决。这也是数据架构里\"单一数据源\"（Single Source of Truth）原则的体现——一份数据只在一个地方真实存在，其他都是引用。\n\n还有个连带问题：拷贝出来的副本，一旦没有同步机制，就会出现\"源数据改了、副本还是旧的\"的情况。你要么做同步（又是一套复杂度），要么接受副本失真（授权出去的是过期数据）。全量拷贝看着简单，实际上是在给自己挖更大的坑。\n\n### 第二个坑：权限粒度太粗\n\n第二个坑是权限粒度太粗。初期只支持全局资源授权和回收，不能分级、不能分字段、不能分时效。真正到企业场景里，需求往往是\"这个部门的人能看这部分字段，权限给三个月\"——粗粒度的权限根本没法用。\n\n权限设计这里有个进阶的思路。基础是 RBAC（角色权限），但它解决不了\"同一角色的人，对不同数据权限不同\"的问题，所以还要叠加\"数据权限\"：按数据归属（本人\u002F本部门\u002F全公司）、按字段级别（可见\u002F脱敏\u002F不可见）、按时间维度（临时授权\u002F长期授权）来精细化控制。这套东西做起来不复杂，但设计阶段就得想清楚，不然越到后期越难改。\n\n这里尤其要提\"字段级脱敏\"：不是所有人都有权限看到完整数据，比如手机号、身份证这种敏感字段，低权限用户应该看到打码后的版本。这个需求几乎每个 B 端系统都会有，如果前期不在模型里留好\"字段权限\"的口子，后期硬加会非常痛苦。\n\n### 重构后的三层模型\n\n后来重构，我彻底换了思路，把数据模型拆成三层：\n\n第一层是原始资源层，数据只存一份，是唯一真实数据源，不做任何拷贝；第二层是授权链路层，只存资源 ID、授权主体、时效范围、权限字段这些关联信息，用关联替代全量拷贝，数据冗余的问题从根上解决；第三层是操作审计层，记录所有授权、流转、撤销、查看行为，全链路可溯源。\n\n权限体系也升级成细粒度 RBAC：整合角色权限、用户独立权限、时效权限、字段级可见权限，支持临时授权、分级授权、定向授权这些复杂场景，企业级的需求基本都覆盖了。权限判断用统一的服务收敛，别散落在各个业务里——集中管理，才能保证\"改一处，全局生效\"。\n\n### 合规和审计的提醒\n\n如果这个系统涉及个人信息或重要数据，还得把合规放进设计里。国内有《个人信息保护法》《数据安全法》这两部大法，要求数据处理的合法性、最小必要、可追溯。所以审计日志不能只是\"记了就行\"，要覆盖全生命周期：数据从哪来、被谁看过、流转到哪、谁撤销了授权，出问题要能倒查。这个在模型设计阶段就要留好字段和表结构，后面补审计，成本会高得多。\n\n合规这块还有几个实操点：数据留存的期限管理（过期自动清理或归档）、导出和下载的审批留痕、权限变更的通知与确认。这些看着琐碎，但在合规审查的时候，一条都不能少。\n\n### 这次教训\n\n这次重构让我彻底记住了 B 端研发的铁律：模型设计优先于业务开发。前期数据架构和权限架构偷的懒，会在迭代中后期变成还不完的债。先把资源、授权、审计三者的关系定清楚，再写页面，比什么都强。数据平台的复杂度，从来不在页面和接口，而在\"数据之间的关系\"——这个关系设计错了，后面全是返工。\n","2025-07-10T02:00:00Z",6,true,{"prev":18,"next":19},null,{"id":20,"slug":21,"title":22,"excerpt":23,"category":24,"tags":25,"publishedAt":30,"readingMinutes":15},25,"spring-session-auth-design","SpringBoot 前后端分离 JWT 认证完整落地与坑点","JWT 无状态鉴权落地不难，难的是把密钥、过期时间、敏感数据和全局拦截这些坑都填平。","工程实践",[26,27,28,29],"Spring Boot","安全","认证","PostgreSQL","2025-08-20T02:00:00Z",[32,42,54],{"id":33,"slug":34,"title":35,"excerpt":36,"category":8,"tags":37,"publishedAt":41,"readingMinutes":15},3,"certificate-system-retrospective","去中心化数据存证系统｜业务拆解、技术选型、避坑复盘","存证系统真的需要区块链吗？我用哈希加时间戳加链式关联，给出了一个轻量答案。",[38,39,40],"密码学","Java","分布式系统","2026-03-20T02:00:00Z",{"id":43,"slug":44,"title":45,"excerpt":46,"category":47,"tags":48,"publishedAt":52,"readingMinutes":53},48,"assassins-creed-ezio-trilogy","永远的单机白月光：刺客信条2艾吉奥三部曲，我的游戏启蒙与终极情怀","一款把我带进单机游戏世界的启蒙之作。十几年过去，佛罗伦萨屋顶上的那个黄昏，我到现在都记得。","杂谈",[49,50,51],"刺客信条","游戏推荐","单机","2026-08-15T02:00:00Z",7,{"id":55,"slug":56,"title":57,"excerpt":58,"category":59,"tags":60,"publishedAt":64,"readingMinutes":15},2,"notes-on-ai-learning","AI 应用开发完整学习路线","AI 这行分三条赛道，应用开发是普通开发者最该走的那条。学习顺序和判断标准，这篇说清。","AI 学习",[61,62,63],"AI","学习方法","知识管理","2026-08-08T02:00:00Z"]