先判断业务是否需要共同维护记录
讨论成都区块链溯源需要注意哪些问题，首先应明确业务目标：需要追踪什么对象，哪些主体提供数据，发生争议时需要核对哪些证据。本文讨论适用于成都相关业务的通用技术原则，不代表当地具体平台已经具备相应能力。
NIST《区块链技术概述》将区块链描述为具有篡改可察觉和抗篡改特性的分布式账本。它适合讨论多方共享记录的问题，但是否采用区块链，仍应结合参与方之间的信任关系、核验需求和维护成本判断。
上链之前，先确认数据与实物的关系
记录难以被事后改动，并不意味着录入时就真实。人工填写的产地、设备采集的数据、机构出具的检测结果，都需要各自的可信依据。项目设计应明确数据由谁产生、依据什么提交，以及出现错误由谁负责。
实物与数字记录之间也需要可靠关联。例如，扫码查到某批次信息，只能说明系统返回了与该标识关联的记录；如果标签被复制、替换，或者商品装错包装，单凭链上记录无法排除这些问题。
核验凭证时，同时审查签发方与声明内容
W3C可验证凭证数据模型区分签发者、持有者和验证者，并明确指出：凭证能够被验证，不等于其中的声明必然真实。验证者仍需依据业务规则，评估签发者、证明和声明。
用于溯源时，可将这一原则落实到检测报告、供应商资质等材料：既检查凭证是否被改动，也检查签发主体是否适合证明相关事项、凭证是否仍然有效，以及它对应的对象是否就是当前商品。可验证凭证可以使用不同类型的登记系统，并非必须依赖区块链。
区分公众查询内容与受限业务信息
溯源记录可能包含联系人、物流位置和商业往来信息。设计查询页面时，应先确定消费者、合作企业与管理人员分别需要看到什么，避免为了展示完整链路而公开过多信息。
W3C规范提醒，可长期保存且容易关联的数字信息可能增加隐私风险。因此，项目需要评估哪些内容有必要共享、共享到什么范围，以及不同记录能否被拼接识别到个人。采用数字签名或区块链，并不会自动解决这些问题。
预先约定权限、纠错和持续核验机制
系统应明确谁可以提交记录、谁负责审核、谁能调整参与方权限。还应考虑密钥失效、参与方退出和错误录入后的处理方式，使查询者能够辨认记录的当前状态。
对于需要保留历史的业务，可以设计追加更正记录并关联原记录的流程，同时说明更正原因与责任主体。具体能否实现、如何呈现，需要核对平台设计，不能仅凭“不可篡改”的宣传判断。
常见问题：扫码是否等于验真
扫码通常只是进入查询或核验流程。判断结果是否可靠，还要看标识与实物的绑定方式、原始证据、提交主体及验证规则。页面显示“已上链”，本身不足以证明商品质量、产地或所有流转环节均真实。
评估此类项目时，关键是让每项展示结论都有对应证据，并清楚标明尚未核验的部分。多方能够共同使用记录、理解验证结果并承担相应责任，溯源系统才具备实际业务价值。