📚 课程目录第4章标记生成算法

标记生成算法：哈希算法在标记生成中的应用、随机数生成、时间戳绑定

好，咱们直接进入正题。标记生成是整个溯源系统的起点，也是“第一道防线”。你生成的标记如果本身就有缺陷，后续所有验证手段都是白搭。标记生成算法通常是把三种核心技术揉在一起：哈希算法、随机数生成、时间戳绑定。这三板上阵，才能做到全局唯一、抗篡改、防伪造。

下面咱们一个一个拆开看。

哈希算法在标记生成中的应用

哈希算法，又叫散列函数。它的输入可以是任意长度的二进制值，输出是固定长度的摘要，比如 SHA-256 的输出就是 256 位，也就是 32 字节。我最早接触它是在做数据完整性校验，后来才发现它在标记生成里简直是个宝。

为什么这么说？因为哈希有三大特性刚好对路：

确定性：同样的输入，永远得到同样的输出。
单向性：从输出几乎不可能反推出输入。
抗碰撞性：很难找到两个不同输入得到相同输出。

在实际溯源系统中，我们不会直接把原材料数据（比如产品名称、生产批次、生产厂家）当成标记，那样太容易被仿冒了。我的习惯是：先取这些标识数据（比如全局唯一的产品编码），再取种子数据（生产日期、流水号），把它们拼接起来，最后喂给哈希函数。这样生成的摘要就是标记的核心指纹。

我的小技巧：设计标记时，尽量把信息都塞进去，但不要暴露明文。哈希后的摘要既保留了数据的唯一性，又隐藏了原始信息。比如你可以用 SHA-256 算一遍，输出前 8 个字节作为短标记。我曾在项目中这样做过，既保证了 64 位的空间足够分发，又保留了冲突率极低的特性。

这里有一个常见的对比表，我总结了一下常见哈希算法在标记生成中的区别：

算法	输出长度	碰撞概率（百万分之一）	计算速度	我建议的场景
SHA-256	256 位（32 字节）	极低	中等	高安全性溯源（药品、食品）
SM3	256 位（32 字节）	极低	中等（国密标准）	必须遵守国标要求的项目
CRC32	32 位（4 字节）	很高	极快	内部临时标记（不能做长期验证）

我曾经踩过的坑：用 MD5 做标记生成。MD5 碰撞已经被攻破好多年了，如果你标记被人伪造碰撞，整个溯源链条就崩塌了。所以千万别图快用 MD5，至少上 SHA-256 或者 SM3。

随机数生成

光靠哈希还不够。如果所有标记都是通过对固定数据哈希得来的，那么产品的编码一旦泄露，攻击者就能反推出整个标记结构。这时候就需要随机数登场。

随机数在标记生成中的作用很简单：增加不可预测性。你在种子数据里塞入一个足够强的随机数，攻击者就算拿到了所有明文信息，也无法预先计算或伪造后续生成的标记。

但随机数生成不是随便写一行 Math.random() 就行。我把它分成两类：

真随机数生成器（TRNG）：依赖物理现象，比如热噪声、量子效应。安全性最高，但硬件成本高。我一般在芯片级设备上才会用。
伪随机数生成器（PRNG）：用一个种子通过算法扩展出序列。种子质量决定了安全级别。在服务端，我最常用的是 /dev/urandom（Linux）或 CryptGenRandom（Windows）。

举个例子，在生成标记时，我会这样构造输入：

标记输入 = 产品编码 + 生产批次 + 时间戳 + 随机数(256位)
标记哈希 = SHA-256(标记输入)
最终标记 = 取标记哈希的前 64 位 + 时间戳前 32 位

为什么要在哈希前塞随机数？说白了，这样做让标记不再仅仅是数据的函数，还融合了随机因子。这样即便两个完全一样的产品，在不同时间点生产，标记也完全不同。

嗯，这里要注意：随机数本身也得持久化存储。你生成标记的同时，要把这个随机数一并存入数据库，否则后续验证阶段你会找不到它。我早期在一个项目中忘记记录它，结果验证时死活对不上，查了两天才发现这个大窟窿。

时间戳绑定

时间戳的作用很简单：给标记一个生命周期。没有时间戳，一个标记可以无限期使用，攻击者可以将其复制后反复提交，或者老产品冒充新产品。

我的做法是：把时间戳（Unix 时间戳，精确到秒甚至毫秒）当作哈希输入的一部分。同时，把时间戳的明文也编码进标记本身（通常是前几个字节）。这样，在验证标记时，你可以直接读取时间戳，判断其在不在有效窗口内。

时间戳有几种常见格式：

Unix 时间戳（秒级）：占用 4 字节。适用于有效期较长的商品。
Unix 时间戳（毫秒级）：占用 6-8 字节。适用于高频流转场景。
自定义格式化时间（如 YYYYMMDDHHmmss）：占用 14 字节。可读性强，但长度大。

这里有个实战小细节：绑定时不要把时间戳直接明文暴露在标记里，否则攻击者可以伪造。正确的做法是：把时间戳与哈希摘要混在一起编码，比如用 Base64 编码把时间戳和哈希结果打包成一个字符串。

我曾经疏忽的教训：一个项目里，我把时间戳直接拼在标记的尾部，没做任何保护。结果攻击者收集到一批标记后，解析出时间戳模式，推算出了生成算法。后来我改成把时间戳先哈希，再与随机数拼接，才堵住这个漏洞。记住，时间戳必须作为哈希输入的一部分，永远不要只当附属字段。

三者结合：标记生成核心流程

好，说到这里，我们可以把三个技术串起来了。下面这张图展示了标记生成的核心逻辑：

你看，核心就这么简单：把标识数据、随机数、时间戳拼成一条长字符串，然后用 SHA-256 哈希，得到一个 256 位的摘要。最后把摘要和时间戳编码打包，形成最终标记。这个过程我称之为“三元组绑定”。

实战案例：一个简易的标记生成实现

好，理论说完了，咱们看看实际怎么写。下面是一段 Python 示例，我把关键部分加上了注释：

import hashlib
import os
import time
import base64

def generate_mark(product_code: str, batch: str) -> str:
    # 生成 256 位（32字节）的强随机数
    random_bytes = os.urandom(32)
    
    # 获取当前时间戳（毫秒级，共14位）
    timestamp = int(time.time() * 1000)
    
    # 构造输入：产品编码 + 批次 + 随机数(hex) + 时间戳
    raw_input = f"{product_code}|{batch}|{random_bytes.hex()}|{timestamp}"
    
    # 计算 SHA-256 哈希摘要
    hash_digest = hashlib.sha256(raw_input.encode()).digest()
    
    # 取前 8 字节（64位）作为标记的主体
    short_hash = hash_digest[:8]
    
    # 将 8 字节哈希 + 8 字节时间戳 打包
    payload = short_hash + timestamp.to_bytes(8, byteorder='big')
    
    # Base64 编码，去除填充符 '='
    mark = base64.urlsafe_b64encode(payload).rstrip(b'=').decode()
    
    return mark

# 生成一个标记
mark = generate_mark("PROD-001", "BATCH-202410")
print(mark)  # 类似输出：B3YxR51zT8UwMDAwMDAw

这里我特别注意了几点：

随机数生成：用了 os.urandom(32)，这是一个系统级的强随机数，来自操作系统的密码学安全随机源。
时间戳绑定：时间戳被转成 8 字节大端序，和哈希结果拼接。在验证端，你可以直接解析出时间戳，判断是否在有效期内。
编码选择：用 Base64 url-safe 编码，避免了普通 Base64 中的 '+' 和 '/' 字符。我在一个电商项目里就遇到过这种问题，标记中含有 '+' 被 URL 解析器吞掉的情况。

我的一个小技巧：在生产环境中，可以把时间戳再拆出来一个“有效期字段”，比如你只允许标记在生成后 7 天内有效。验证时直接比较时间戳是否超过 7 天，超期就废弃。这样做既能防重放攻击，又能实现标记的自动过期。

常见误区和避坑指南

做标记生成这几年，我见过不少翻车的情况。这里列几个最常见的：

误区一：随机数每次一样 —— 有些开发图省事在程序启动时生成一次随机数，然后所有标记共用。这等于没有随机性。我曾经在代码审查时抓到过这种情况，必须用 os.urandom 每次生成新种子。
误区二：时间戳格式不一致 —— 标记生成用秒级，验证用毫秒级，结果对不上。解决方案很简单：全部统一用毫秒级 Unix 时间戳，并在文档中写明。
误区三：忽略编码问题 —— 明文拼接时要注意字符串编码统一用 UTF-8，否则不同系统和语言之间会有差异。

好，标记生成算法到这就差不多了。记住一句话：哈希保证唯一性，随机数防止预测，时间戳划定时效。三者缺一不可。后面验证算法会用到你生成的标记结构，所以这里的设计一定要把格式定死，后续改不了了。嗯，那咱们下节再见。