[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"article-certificate-system-retrospective":3,"article-neighbors-certificate-system-retrospective":17,"article-related-certificate-system-retrospective":40},{"id":4,"slug":5,"title":6,"excerpt":7,"category":8,"tags":9,"content":13,"publishedAt":14,"readingMinutes":15,"published":16},3,"certificate-system-retrospective","去中心化数据存证系统｜业务拆解、技术选型、避坑复盘","存证系统真的需要区块链吗？我用哈希加时间戳加链式关联，给出了一个轻量答案。","项目复盘",[10,11,12],"密码学","Java","分布式系统","去年做了个数据存证的小系统，做完最大的感悟是：做技术选型之前，先想清楚你到底要什么。\n\n当时需求很简单，四个词就能说清：数据不可篡改、操作全程可溯源、凭证可核验、行为可举证。说白了，就是别人动了你的数据，你能拿出证据。\n\n这个需求一提出来，几乎所有人第一反应都是——用区块链。我一开始也这么想，还认真调研了一轮，结果发现：对我们这种中小体量的业务来说，区块链属于典型的杀鸡用牛刀。它要分布式共识、多节点冗余、区块记账，这些能力我们一个都用不上，反而带来了巨大的算力开销、部署门槛和运维成本。折腾半天，就为了一个\"防篡改\"，不值。\n\n### 先搞懂哈希到底能干什么\n\n要理解为什么不用区块链也能防篡改，得先懂一个底层概念——哈希。SHA-256 这类哈希算法，能把任意长度的数据压缩成一个固定长度的\"指纹\"，而且有两个关键性质：第一，输入任何一点变化，输出就完全不同（雪崩效应）；第二，几乎不可能从哈希反推出原始数据（单向性）。这两条性质，就是\"数据不可篡改\"的数学基础——你改了数据，指纹就对不上，一验就知道。\n\n更妙的是，哈希可以\"链\"起来：把上一条记录的哈希写进当前这条记录，形成一条链。任何一环的数据被改，它后面的每一环校验都会断掉——因为每条都依赖前一条的哈希。这就是\"链式哈希\"，也是区块链底层用的\"默克尔链\"思路的简化版。中小业务要的\"防篡改 + 可追溯\"，这套轻量方案完全够用。\n\n这里顺便说下区块链为什么\"贵\"：它用共识机制（工作量证明、权益证明等）保证\"没有一个中心说了算\"，这是为了让互不信任的节点共同信任同一份账本。可企业内部存证，本来就是\"我自己信任自己的系统\"，根本不需要去中心化——你把\"不需要的能力\"当作\"必选项\"，就是过度设计。这也是我这次最深的教训：先分清\"我到底要不要去中心化\"，再决定要不要上区块链。\n\n### 三层架构怎么搭\n\n架构我拆成了三层。业务数据层照常落 MySQL，该怎么读写怎么读写，业务迭代不受影响；指纹存证层对核心数据生成 SHA-256 哈希摘要，数据里任何一个字符变了，哈希值就完全不同，篡改从算法层面就被堵死；时序审计层把时间戳绑定到权威时间源，杜绝本地时钟造假，同时把上一条存证的哈希写进当前这条，形成一条链——你改任何一环，整条链的校验就会断掉。\n\n时间戳这里也有讲究。不能用自己的服务器时间，得对接权威时间戳服务（类似 RFC 3161 定义的时间戳协议 TSA），用第三方的时间作为\"证据\"，才能证明\"这条数据在那个时间点确实存在过\"。道理很简单：你自己服务器的时间可以随便改，改了就没人能证明\"这条记录是什么时候写的\"。绑定权威时间源，等于给每条存证盖上一个\"可信的时间章\"。\n\n### 落地时的几个坑\n\n落地的时候有几个坑，我都踩过，给你排掉：\n\n第一，只存哈希，不存原始数据。存证表里就放 `data_hash` 和 `prev_hash`，原始数据留在业务表，别图省事把整份数据塞进去。一来节省存储，二来避免敏感数据扩散——存证表本身不成为泄露源。\n\n第二，更新走增量，不走覆盖。业务数据修改后生成一条新存证，旧记录保留。这样任何时候的历史都是可验证的，改掉重写是自毁证据。这里有个细节：修改后的新哈希跟旧哈希一起存，形成\"版本链\"，这样才能证明\"这条数据从哪版改到了哪版\"。\n\n第三，校验逻辑和业务逻辑彻底解耦。校验单独做成一个服务，别混在业务代码里。链式校验就是从最后一条往前，逐条比对 `prev_hash` 是否等于上一条的 `data_hash`，对不上就抛异常。校验做成独立服务还有个好处：可以对外提供\"验真接口\"，让第三方也能验证你的存证是否可信——这在需要向监管或对方举证的时候很有用。\n\n### 最终结论\n\n对比下来，这套轻量方案没有算力开销、没有部署门槛、没有运维压力，对中小业务来说性价比拉满。区块链的优势在于\"去中心化的信任\"，而大多数企业内部的存证需求，其实只需要\"中心化的可信 + 可验证\"，根本不需要去中心化。\n\n技术选型的核心原则就一句话：匹配业务体量。盲目堆热门技术，只会换来一身架构债。能用哈希解决的问题，就别急着上区块链。\n","2026-03-20T02:00:00Z",6,true,{"prev":18,"next":30},{"id":19,"slug":20,"title":21,"excerpt":22,"category":23,"tags":24,"publishedAt":29,"readingMinutes":15},24,"vue-request-cache-implementation","Vue 全局请求缓存工程级实现、过期策略与脏数据规避","给 Vue 项目加全局缓存时踩过的坑：过期策略、脏数据、并发去重，一篇讲清楚。","工程实践",[25,26,27,28],"Vue","TypeScript","缓存","性能","2026-01-25T02:00:00Z",{"id":31,"slug":32,"title":33,"excerpt":34,"category":23,"tags":35,"publishedAt":39,"readingMinutes":15},32,"personal-site-feature-bloat","个人项目如何规避「功能废墟」工程问题","功能越加越多，项目却越来越难改，最后重构比重写还贵——这是我踩过的\"功能废墟\"坑。",[36,37,38],"个人网站","工程管理","维护","2026-05-15T02:00:00Z",[41,50,62],{"id":42,"slug":43,"title":44,"excerpt":45,"category":8,"tags":46,"publishedAt":49,"readingMinutes":15},37,"data-circulation-platform-retrospective","数据流转确权平台｜数据模型、权限粒度、迭代重构问题","数据授权一次就拷贝一份副本，权限又粗到没法用——这个 B 端项目的前期债，后期还得很痛。",[25,47,48,8],"前端开发","业务系统","2025-07-10T02:00:00Z",{"id":51,"slug":52,"title":53,"excerpt":54,"category":55,"tags":56,"publishedAt":60,"readingMinutes":61},48,"assassins-creed-ezio-trilogy","永远的单机白月光：刺客信条2艾吉奥三部曲，我的游戏启蒙与终极情怀","一款把我带进单机游戏世界的启蒙之作。十几年过去，佛罗伦萨屋顶上的那个黄昏，我到现在都记得。","杂谈",[57,58,59],"刺客信条","游戏推荐","单机","2026-08-15T02:00:00Z",7,{"id":63,"slug":64,"title":65,"excerpt":66,"category":67,"tags":68,"publishedAt":72,"readingMinutes":15},2,"notes-on-ai-learning","AI 应用开发完整学习路线","AI 这行分三条赛道，应用开发是普通开发者最该走的那条。学习顺序和判断标准，这篇说清。","AI 学习",[69,70,71],"AI","学习方法","知识管理","2026-08-08T02:00:00Z"]