适用范围与设计依据
本文讨论结合区块链存证或查询能力的数字凭证系统。W3C可验证凭证数据模型将签发者、持有者、验证者区分为不同角色，并明确可验证不代表声明内容必然真实；其数据注册设施也可以采用数据库等形式。以太坊区块浏览器文档则说明，浏览器能够展示交易状态、区块及账户活动。这两类能力分别支持凭证验证和链上记录查询，设计时需要明确各自的边界。
误区一：上链就代表内容真实
防篡改能力不能替代签发前的事实核验。例如，学历凭证即使具有可验证的签名，接收方仍需判断签发机构是否符合业务要求。凭证中心应分别展示技术校验结果和业务认可结果，避免用一个“认证成功”涵盖所有判断。
误区二：交易成功就代表凭证有效
交易状态回答的是链上操作是否成功执行。凭证是否可接受，还涉及签发者、证明、有效期及适用的状态检查。若系统支持撤销，历史签发记录仍然存在也不意味着凭证仍有效。界面应区分存证结果、凭证状态和业务审核结果；查询失败时，应说明暂时无法确认。
误区三：把所有身份信息公开上链
公开链上的账户活动和交易数据可以被查询，长期保存的标识也可能帮助关联不同场景中的行为。设计时应先确定验证所需的最少信息，再决定公开范围。原始证件、完整个人资料与公开验证信息需要分别管理；采用摘要也不能直接等同于匿名化，仍需考虑关联风险。
误区四：默认持有者就是凭证主体
凭证描述的对象与保管、出示凭证的实体可能不同。例如，系统涉及代为持有时，需要明确持有者与主体的关系及其权限。签发、持有、出示和验证即使由同一平台承载，也应分别定义职责，避免把登录账户直接视为凭证中所有声明的主体。
误区五：有浏览器链接就完成了验证
浏览器链接适合辅助查看链上记录，但不能独立回答签发者是否可信、出示内容是否对应记录等问题。面向普通用户的页面应先说明验证对象、结果与限制，再提供链上详情入口。
常见问题：必须使用区块链吗
可验证凭证并不以区块链为必要条件。是否采用分布式账本，应依据多方共享记录和治理需求决定。若采用链上存证，还需明确链下凭证如何与记录对应，以及凭证失效、数据不可获取时如何表达结果，避免把基础设施可查询误当成完整的凭证服务。