票务平台版本更新后如何保障MD5等格式历史旧票仍可正常核验

你提出的二维码增加版本号前缀的方案完全合理，是这类无状态凭证校验场景下处理向后兼容性的首选工业界方案，优势非常突出：

• 对现有流程侵入性极低：轻量扫描App不需要做大的逻辑改动，只需要加一步分割版本号和哈希值的处理，扫描逻辑本身不需要调整；如果后端直接接收完整二维码字符串自行分割解析，App侧甚至完全不用升级，适配成本几乎为0
• 扩展性极强：后续如果再更换哈希算法（比如之后升级为SHA3）、或者调整凭证内容结构，只需要新增一个V3.0的版本分支，旧逻辑完全不需要改动，不会出现新的兼容性问题
• 排查问题效率高：如果出现检票异常，只要看版本号就能快速定位是旧票还是新票，对应排查对应校验逻辑即可

• 方案2（时间戳/长度映射）：适合已经发出去的旧票没有版本号的历史遗留场景，比如你现在手里2017-2021年发放的MD5旧票都没有版本号，就可以先用这个方案做过渡：判断如果传入的哈希长度是32位（MD5固定长度）就走MD5校验，长度是64位（SHA256固定长度）就走SHA256校验，也可以结合购票时间戳匹配校验逻辑，不需要改现有旧票就能兼容。但缺点是如果后续版本的凭证长度一致就无法区分，扩展性不如版本号方案
• 方案3（绑定唯一URL）：仅适合纯电子票、不支持实体票打印的场景，实体票场景完全不适用，而且要求用户能联网刷新票证，适用范围非常窄
• 方案4（补发新票）：除非旧凭证存在严重的安全漏洞会导致资产损失，否则完全不建议使用，用户体验差、客服成本极高，还容易引发批量客诉

如果要落地版本号方案，建议补充两个兼容处理：

1. 增加一层兜底逻辑：如果扫描到的内容没有版本号前缀，先判断长度，32位默认走V1.0的MD5校验逻辑，兼容之前已经发出去的无版本号旧MD5票，不需要用户更换旧票
2. 把校验逻辑做成可插拔的模块，后续加新版本不需要改动主流程代码，只要新增对应版本的校验函数注册进去即可，避免后续迭代把主逻辑改得越来越臃肿混乱

内容的提问来源于stack exchange，提问作者O'Niel