做农产品溯源这个方向三年，被问得最多的一句话是「你们是不是也上区块链」。问的人通常已经认定区块链是这套系统的核心，我要说的是：链只解决一小段问题，而且是最容易做对的那一段。真正让一个溯源系统活过第二年的，是批次编码、数据入口的采集质量，以及验真时的失败处理。
下面按我们自己在项目里踩出来的顺序讲，讲的是工程口径，不是方案书。
农产品溯源系统实际在存什么
很多人对溯源的想象是「一颗菜从种子到餐桌全程可视」。真做起来你会发现，全程可视在数据侧根本不存在，因为农业生产链条里有一大半环节是不产生数据的：谁在几点掐了尖，用了多少人工，当天风大不大。这些只能靠人填，人填的东西就有抽样、有滞后、有错。
所以我们先把「能自动采集的」和「只能人录的」分开。环境类的温湿度、棚内光照、水质参数属于自动化来源，采集频率高，但要注意它反映的是「传感器所在位置」的环境，不等于整棚。农事操作、投入品使用、采收分级属于人录来源，这类数据我们只保证「谁在什么时候录的」可查，不假装它精确。把这两类的可信等级在页面上明确标出来，是我们做过的最有用的一个设计决定。客户第一次看到「此条为人工录入」的标注时有点不高兴，觉得显得系统不专业，但后来监管来查的时候，这一栏救过他。
批次是这套数据的主键。所有环节的数据最终都要挂到一个批次上，挂不上的数据等于没采集。
批次号怎么设计，才追得下去
设计批次编码时最容易犯的错，是把它当成一个好看的流水号。编号规则里塞进基地、地块、作物、年份、采收轮次之后，看着很规范，但改不动。地块合并了、作物换茬了、一个批次跨了两个地块，规则立刻崩。我们中间换过一次编码规则，代价是历史批次和单据要做一轮映射，那两周基本在补数据。
现在的做法是把「业务属性」和「编号」解耦：编号只保证唯一和有序，基地、地块、品种这些属性单独存字段，可以随业务调整。代价是肉眼看不出一串编号代表什么，得点进详情看。我们接受这个代价，因为改一次编码规则的代价比多看一次详情大得多。
另一个判断是批次粒度。源头做不到精确到单株，我们的口径是「同一地块、同一品种、同一管理措施、同一采收窗口」为一个批次。采收窗口我们按天算，不是按小时。按小时分批次在纸面上更精确，实际会让批次数量成倍膨胀，最后没人维护得住。这里我认为按天是对的，除非你的产品单价高到值得为小时级追溯付人力。
为什么明细留在链下，只把指纹放到链上
这是被问得最多、也是争论最凶的一处。我们的选择是：链上只放批次维度的摘要指纹和关键事件的哈希，明细数据、图片、质检报告全部留在链下数据库和对象存储里。
理由三条。链上写入有成本，也有延迟，把每条环境记录都上链，一个中等规模基地一天的数据量就够把写入队列堆起来。链上的数据不可改，但农业数据经常需要纠正，比如质检结论录错、采收数量录错，这类更正如果发生在链上，你只能在链上再写一条「以此为准备注」，时间久了链上全是修正记录，可读性直接崩掉。还有隐私和体量，图片和报告这类内容本来就不适合链上。
代价是：验真的强绑定只到批次层，单条明细的防篡改是靠「明细的哈希被批次摘要覆盖」间接保证的。理论上，谁同时改了链下明细和本地哈希缓存，在下次批量校验之前是看不出来的。这个窗口就是这套方案的软肋，也是我提醒过客户的实话。用高频批量校验能把窗口压短，但压不到零。
反过来，如果你追求「每条数据都上链」，我认为在农业这个场景里不成立，除非规模很小（几十个点位、一天几百条记录），或者你是拿链给外部机构看的展示型项目。
冷链断链的证据链怎么留
冷链是溯源里最容易被问出破绽的一段。链条上至少有三个角色：产地预冷、干线运输、销地仓储。三个角色各用一套设备，各有一套时钟。
我们的做法是要求运输环节的温度记录以「设备时间 + 上传时间」双时间戳存在，两个时间差超过阈值就标为「时间不可信」。这不是洁癖。我们遇到过车上记录仪时间被手动改过、导致整趟运输的曲线整体位移的情况，只看单条数据完全正常，是两条时间线的落差不一致才露的马脚。发现之后我们把双时间戳变成了硬性要求，并把「时间不可信」的批次在验真页上显式标注。
断链判定不能只靠「有没有超过温度上限」。超限是快速判定，还有一类是「没有数据」：断网、断电、设备被人为拔掉。这类缺失在原始数据里表现为空档，如果不做缺采判定，验真页会显示成一段平滑曲线，等于把断链洗白了。所以我们把「缺失」当成一种独立状态，和「正常」「超限」并列。
二维码验真：扫出来的是什么
消费端扫一个码，期望三秒内看到结果。这个页面的工程难点不在展示，在「扫到什么」、「扫不到什么」怎么说。
码里我们只放批次标识，不带任何业务明细，也不带客户信息。数据全靠服务端查。这样做的好处是码可以被复制、被贴错，但不会泄露任何东西；坏处是扫码必须联网。线下验收的时候我们试过把查询结果缓存到本地做离线展示，后来放弃了，因为缓存过期后显示的是旧状态，消费者看到「检测合格」而实际批次已被召回，这比打不开页面严重。
扫码验真的状态设计我用一句话总结：任何一环不可用，页面都不能显示「已验真成功」。查不到批次就说查不到，校验接口失败就说暂时无法校验，不允许把失败渲染成通过。这条和我们做虫情识别时的原则是同一条：系统在不确定的时候必须显式失败，而不是给一个好看的结果。想了解这条原则在别处的落地，可以看我们整理的环境数据质量那部分农业环境监测。
存证密钥这件事，没人一开始会想到
链上放的是摘要，摘要要能被验证，就离不开密钥的编解码与版本管理。这块我们吃过一次苦头。
早期我们把存证内容直接用一套密钥编码，密钥本身存在配置里。后来需要换密钥，历史批次立刻验不过。用户看到的现象是「昨天还能验真的批次今天说校验不通过」，第一反应是我们的链坏了。根因不在链，在密钥版本没有和摘要一起留存：新密钥解不了老数据。
修法是在存证记录里带上编码版本，验真时按记录里的版本选择对应密钥；密钥轮换时老密钥不删除，只标记为只读。事后我们还加了一条防线：每次轮换后自动跑一批历史批次的抽样验真，失败就报警。
可迁移的结论在这里：任何和「不可变数据」配套的密钥管理，版本必须随数据留痕，否则不可变性会反过来咬你。这条和区块链没关系，和对象存储的加密轮换、代码签名是一样的道理。
什么情况下不需要区块链
说完这些，回到最开始那个问题。我的判断是：如果你只是想让内部几个角色看清楚一个批次经历了什么，那不需要链，一张批次表加权限就够了，成本差一个数量级。如果监管或采购方明确要求「第三方不可篡改的证据」，链才开始有价值，因为它的价值在「不归你控制的取证方」那里，不在你自己的数据库里。
规模也有个界线。几十个批次、单一销售渠道的阶段，我们把溯源做成批次加单据的常规功能，不上链。批次量上到几千、渠道跨到第三方平台、要与外部监管系统对接时，链和验真接口才值得投。中间这段路我们建议先把手录数据的质量管住，那比链的先手重要得多。
还有一件事必须说清楚：数据上链只能证明「记录没有被改」，不能证明「记录是真的」。源头那台传感器如果被人放进一盆温水里，链上的曲线照样完美。溯源系统能兜住的是「有没有被事后涂改」，兜不住「当初有没有作假」。跟客户谈需求的时候，我每次都会先讲这一句，讲完之后双方对系统的期待才对得上。
具体的批次、物流、冷链、扫码验真这几块能力，我们整理在农产品溯源与存证；批次出入库和效期相关的部分在农产品库存与三级货位。