不要把大文件直接写入主链
区块链的核心优势是由网络参与者共同维护一致状态，但这也意味着链上数据通常需要被节点复制、验证和保存。数据量越大，对节点存储、同步和交易执行的负担越高；把图片、视频、日志或大量业务记录全部写入主链，往往会带来明显的资源消耗和使用成本。
更常见的架构是链上链下结合：链上保存数据摘要、内容标识、权限状态或版本信息，原始文件放在链下数据库、对象存储或去中心化存储网络中。摘要可以用于校验取回的数据是否被篡改，但它本身不能保证原始文件一定长期可用，因此不能把“可验证”误认为“已永久保存”。
先确认数据能保存多久
选择存储方案时，应区分两类持久性机制。一类由区块链本身承担，数据随着链的状态被网络持续复制；另一类依靠存储合约、节点承诺或其他服务安排，由多个节点在约定期限内保存数据，并可能需要续期或重新支付。两者在成本、维护责任和失效方式上并不相同。
使用基于内容寻址的分布式文件系统时，还要确认是否存在固定、复制或长期存储机制。仅把文件发布到网络，并不自动意味着会有节点一直保留它；运行自己的节点、使用固定服务，或采用带有存储激励与验证机制的方案，承担的责任也不同。项目设计应明确保存期限、复制数量、续期流程、节点故障处理和数据恢复方式。
验证节点是否真的持有数据
“去中心化”不能只看宣传名称，还要考察数据保留如何被检查。部分系统会向存储节点发起加密挑战，要求节点证明自己仍然持有相应数据；无法通过验证时，节点可能受到惩罚或失去收益。这类机制能提高可验证性，但仍需结合节点数量、故障恢复、数据检索能力和运营依赖进行评估。
还应观察控制权是否集中在少数服务商、节点加入是否受限、数据访问是否依赖单一网关，以及关键服务停止后能否迁移。节点数量多不必然代表实际运行足够分散，缺少公开、可复核的运营信息时，应把“去中心化程度”作为需要持续验证的风险项，而不是既定事实。
哈希、签名与JSON格式必须稳定
如果链上记录的是JSON数据的哈希或签名，生成摘要前必须保证输入字节完全一致。同一组业务含义的数据，如果字段顺序、空白、数字表示或转义方式不同，直接序列化后可能产生不同字节，进而得到不同哈希。验证方若采用另一种序列化方式，就可能误判数据已被修改。
JSON规范化方案的基本思路，是为对象属性排序，统一空白和基础类型的序列化，并限制输入符合可互操作的JSON子集。实现时应拒绝重复属性名，谨慎处理超出双精度范围的整数，并避免使用JSON不允许的NaN或Infinity。Unicode字符串也要保持一致，不能让不同程序在规范化前擅自改写内容。
工程上应固定一套规范化库和版本，明确哈希输入是原始文件、规范化JSON，还是包含元数据的封装对象，并为跨语言实现准备测试向量。验证时应先检查编码、字段类型和规范化结果，再比较哈希或验证签名。
适用条件与常见问题
对于需要公开证明某份记录未被改动、但文件体积较大的应用，链上保存摘要、内容标识和版本信息通常更合适。对于高频写入、涉及个人隐私或需要严格删除的数据，则应先评估合规要求和链上不可变特性，避免把不应长期公开的数据直接写入公共链。
常见问题一：把文件哈希写入链上，是否就等于文件永久存在？不等于。哈希主要证明某份文件与登记摘要是否匹配，文件本体仍需要可靠的保存和取回机制。
常见问题二：使用IPFS一类系统后是否无需备份？不应这样理解。应确认文件是否被持续固定、由哪些节点复制，以及服务不可用时是否能从其他节点或备份恢复。
常见问题三：为什么JSON看起来内容一样，签名却不同？通常是序列化字节不同，例如属性顺序、数字表示、转义或空白不同。签名系统应在签名前统一规范化，并让签名方和验证方采用相同规则。