1. 大文件不直接上链。

比如视频、图片等。主要是因为区块链作为一种分布式账本技术，在多个节点（甚至所有节点）都在本地存储了区块链完整的历史数据。如果我们将1GB的视频直接上链，那么这个视频将会在每个节点都占用1GB的磁盘空间，而且一旦上链是无法删除该交易的，所以我们还不能去删除该数据，强行删除将会导致区块链数据不完整，新节点加入同步并检查历史账本数据时将会因为数据丢失而校验失败。所以我们一般来说区块链都会限制交易的大小和区块的大小，比如我们要求每个交易不能超过1MB，每个区块不能超过8MB，从而杜绝大文件直接上链导致的磁盘急剧膨胀的问题。如果我们的大文件有上链的需求，可以采用哈希上链的方式，要么直接计算哈希值，然后将哈希上链，要么结合IPFS去中心化存储技术，将大文件存储到IPFS网络中，然后IPFS会给出一个特殊的哈希值，将该哈希值上链。

2. 机密、敏感数据不直接上链。

比如合同内容、订单内容。因为我们的区块链账本是分布式存储在各个节点的，所以如果我们将机密敏感的数据直接上链了，那么所有节点都会同步到上链的数据，在他们本地节点就可以查看上链后的敏感机密信息。如果有上链的需求，我们可以将数据存储在私有的数据库或者IPFS中，然后哈希上链，也可以通过密码学的方法进行加密，然后密文上链。

3. 大量、冗余重复的数据不直接上链。

比如系统日志。一般系统日志如果开到DEBUG级别，每秒几千几万笔日志记录是很正常的，而且这些日志的价值信息很低，基本都是很细节的，冗余重复的日志。而区块链本身是一个性能有限的网络，一般TPS都是在千级别，能做到上万TPS的都已经是很厉害的了。而如果我们将大量冗余重复的数据上链，那么将会占用大量带宽，导致真正有价值的数据淹没在日志交易中，排队等待打包，从而影响我们正常业务的运行。而且大量日志上链也会导致区块链磁盘占用快速膨胀，对所有节点的存储也是挑战。我们如果有日志上链的需求，一般可以按批次，将日志进行IPFS存储、计算哈希，或者通过一种叫KSI（无密钥签名基础设施）的方式，对批量日志建立哈希树，将哈希根上链。