Go crypto/rand 生成短期令牌怎么做：编码长度、熵预算与过期校验

临时下载链接、邮箱验证入口、导入任务回查地址，常见做法都是发一个只活几分钟的随机令牌。这个令牌如果用时间戳、递增 ID 或普通伪随机数拼出来，长度看着够长，实际猜测空间可能并不大。Go 里应先用 crypto/rand 取得不可预测的随机字节，再选择不会被 URL 转义破坏的编码，并在服务端记录过期和消费状态。

先定短期令牌的用途和失效边界

假设一个导出任务完成后，接口返回一个 10 分钟内有效的下载地址。这个地址需要满足三件事：拿不到数据库主键就不能推导出令牌；链接被复制后只能在很短时间内使用；成功下载一次后，旧链接不能继续领取同一份文件。

因此令牌表至少要有这些字段：

这里的设计重点是“令牌只是一把随机钥匙”。它不应该把用户 ID、权限等级或文件路径直接编码到字符串里；这些关系由服务端记录决定，撤销和审计也更容易。

用 crypto/rand 生成足够的随机字节

下面的函数生成 32 字节随机值，再用无填充的 URL 安全 Base64 编码。32 字节提供 256 位随机空间，实际应用里即使令牌只活 10 分钟，也不应为了缩短链接而退回到时间戳加用户编号。

package token

import (
    "crypto/rand"
    "encoding/base64"
    "fmt"
    "io"
)

func New() (string, error) {
    raw := make([]byte, 32)
    if _, err := io.ReadFull(rand.Reader, raw); err != nil {
        return "", fmt.Errorf("generate token bytes: %w", err)
    }
    return base64.RawURLEncoding.EncodeToString(raw), nil
}

io.ReadFull的作用是确保缓冲区被完整填满；生成失败时要把错误交给调用方，不能悄悄返回空字符串或使用降级随机源。RawURLEncoding使用 URL 安全字符集，并去掉末尾填充，适合放进查询参数或路径。

32 字节编码后通常是 43 个字符。这个数字只是表现形式，不能反推所有令牌都应该固定为 43 个字符；如果场景明确要求更短，应该重新评估随机字节预算和碰撞风险，而不是随便裁剪字符串。

把熵预算和令牌长度分开看

令牌安全性可以先用一个简单的估算来沟通：随机空间约为 2^(8n)，其中 n 是随机字节数。16 字节是 128 位空间，32 字节是 256 位空间。Base64 只是把字节变成可传输文本，不会增加随机性。

func NewWithBytes(size int) (string, error) {
    if size  64 {
        return "", fmt.Errorf("token byte size out of range")
    }
    raw := make([]byte, size)
    if _, err := io.ReadFull(rand.Reader, raw); err != nil {
        return "", fmt.Errorf("generate token bytes: %w", err)
    }
    return base64.RawURLEncoding.EncodeToString(raw), nil
}

对普通短期链接，16 字节通常已经给出足够大的随机空间；涉及高价值文件、公开接口或长期并发签发时，32 字节更容易留下安全余量。不要把“令牌会过期”当成减少随机性的理由：过期降低暴露窗口，但不能替代不可猜性。

服务端校验要覆盖用途、过期和一次性消费

收到令牌后，不要只判断字符串是否存在。一个可复用的校验过程应该把明文令牌先做摘要，再带上用途查询记录，并在同一条更新里抢占消费权。示例使用 SHA-256 作为数据库索引摘要，数据库查询和更新的具体语法可按项目存储层替换。

func TokenHash(value string) [32]byte {
    return sha256.Sum256([]byte(value))
}

// 伪代码：UPDATE ... WHERE consumed_at IS NULL AND expires_at > now
func Validate(now time.Time, rec Record, purpose string) error {
    if rec.Purpose != purpose {
        return ErrWrongPurpose
    }
    if !rec.ExpiresAt.After(now) {
        return ErrExpired
    }
    if rec.ConsumedAt != nil {
        return ErrConsumed
    }
    return nil
}

生产代码还要把数据库的“检查并更新”做成原子操作：两个并发请求同时拿到未消费记录时，只有一个请求能把 consumed_at 从空值更新为当前时间。第二个请求根据受影响行数得到失败结果，不能依赖应用层先查后写的两步操作。

如果下载本身允许重复读取，可以不设置一次性消费，而改为每次只检查过期时间；这应当是明确的业务选择，而不是因为实现方便就默认复用令牌。

日志里记录结果，不要记录明文令牌

排查下载链接问题时，日志需要能关联请求，却不能变成令牌泄露源。推荐记录令牌摘要的前几位、用途、任务 ID、校验结果和失败原因；不要记录完整查询参数，也不要把令牌拼进异常消息。

logger.Info("download token checked",
    "token_prefix", hex.EncodeToString(hash[:4]),
    "purpose", rec.Purpose,
    "result", "expired",
)

日志字段也应避免把用户输入原样写回。若反向代理、链路追踪或错误采集系统会自动收集 URL，需要额外配置脱敏规则，把 token 查询参数替换为固定占位符。

上线前用四组边界用例核对

• 生成 10000 个令牌，检查长度符合预期且没有重复；测试只用于验证实现，不代表生产可以省略随机源错误处理。
• 同一令牌分别以正确用途、错误用途、已过期和已消费状态请求，确认返回结果互相区分。
• 并发发送两个消费请求，确认只有一个请求能拿到文件，数据库的受影响行数与响应一致。
• 检查访问日志、应用日志、追踪字段和反向代理记录，确认没有完整令牌、查询字符串或文件路径泄露。

常见问题

为什么不能用时间戳加用户 ID 生成令牌？

这类内容通常可被猜测或枚举，攻击者还可能从公开信息推断用户和时间。时间戳可以作为记录字段，但不应承担令牌的随机性。

Base64 编码会让令牌更安全吗？

不会。编码只改变表现形式，安全强度来自生成前的随机字节数。URL 安全编码解决的是传输和解析问题。

令牌过期后还要删除数据库记录吗？

可以先让校验逻辑拒绝过期记录，再按保留期限批量清理。日志和审计需要保留多久，应由业务合规和排障要求决定。

令牌泄露后能不能立刻撤销？

如果服务端记录有撤销状态或消费状态，可以立即标记失效；没有服务端状态的纯自包含字符串，很难在过期前单独撤销。

把短期令牌做成可撤销的服务端状态

Go 的 crypto/rand 只负责提供不可预测的随机材料，URL 编码负责稳定传输，服务端记录负责用途、过期、撤销和消费边界。把这三层分开后，令牌长度、有效期和一次性策略都能按场景调整，也能在测试中逐项验收。