crypto/rand.Read() 是生成哈希输入的唯一安全入口，必须用其填充原始字节以确保不可预测性，严禁混用 math/rand、避免字符串拼接、正确处理错误且不可 fallback。
crypto/rand.Read 是生成哈希输入的唯一安全入口
所谓“防止哈希碰撞”，本质不是哈希函数本身（如 sha256）出问题，而是输入缺乏足够熵——时间戳、计数器、math/rand.Intn() 都不行。必须用 crypto/rand.Read() 填充原始字节，才能确保每次哈希的输入不可预测、不可复现。
常见错误是把 rand.Read() 和 math/rand 混用：比如先用 math/rand 生成一个“随机”种子再去初始化另一个东西，这等于绕过安全层。只要涉及 salt、nonce、token 或任何参与哈希计算的输入，crypto/rand.Read() 必须是第一行代码。
- 必须传入已分配的切片：
buf := make([]byte, 32)，不能传nil或未初始化变量，否则 panic - 必须检查
err：即使概率极低（如容器缺失/dev/urandom），rand.Read()也可能返回io.ErrUnexpectedEOF或其他错误 - 别重复调用：
rand.Read(buf)一次就满熵，多次调用不增加安全性，反而可能掩盖首次失败
别在哈希前做“看似无害”的字符串拼接
很多开发者习惯把随机字节转成 hex 或 base64 后再拼上时间戳、用户 ID 等字段，再喂给 sha256.Sum256()。这种拼接本身不破坏熵，但极易引入可预测成分——比如 "user123_" + hex.EncodeToString(buf)，攻击者一旦知道 user ID 格式，就能缩小搜索空间。
真正安全的做法是：只用 crypto/rand.Read() 生成的原始字节作为哈希输入，其他上下文信息（如用户 ID、时间）应通过 HMAC 或 KDF 单独处理，而不是简单字符串拼接。
立即学习“go语言免费学习笔记（深入）”；
- 错误示例：
sha256.Sum256([]byte(fmt.Sprintf("%s-%x", userID, buf))) - 正确方向：用
hmac.New(sha256.New, key)把 userID 作为消息、随机 buf 作为 key，或反之 - 若必须组合多个源，用
hash.Hash.Write()分段写入，而非先拼字符串——避免隐式编码、截断或空格污染
哈希表种子随机化 ≠ 替代输入随机化
Go 运行时对 map 的哈希种子做了启动时随机化（runtime.hashseed），这能缓解 DoS 类型的哈希碰撞攻击，但它和密码学哈希（如 sha256）完全无关。你在代码里调用 sha256.Sum256() 时，它的输出只取决于输入字节，不受运行时 map 种子影响。
混淆这两者会导致严重误判：以为开了 GODEBUG=hashrandom=1 就万事大吉，结果仍用 time.Now().Unix() 当 salt，哈希值照样可被批量预测。
- map 种子防的是攻击者构造大量 key 打满某个 bucket；它不提供密码学熵
- 密码学哈希的抗碰撞性依赖输入熵，不是 runtime 参数
- 两者解决的问题域不同，不能互相替代，也不能合并成“双重保险”
容器环境里 /dev/urandom 缺失时的行为差异
绝大多数 Docker/Podman 镜像默认挂载 /dev/urandom，crypto/rand.Read() 正常工作。但 distroless、scratch 或某些嵌入式镜像可能没有该设备节点，此时行为取决于 Go 版本：
- Go < 1.22：
rand.Read()返回errors.ErrNoEntropy - Go ≥ 1.22：
rand.Read()直接返回 error（不再 panic），但错误类型未标准化，需用errors.Is(err, io.ErrUnexpectedEOF)或直接判断非 nil - 别指望 fallback 到
math/rand：那只是把问题从“无熵”变成“可预测”，更糟
真正可行的应对只有两个：构建镜像时显式挂载 /dev/urandom，或在 CI/CD 流程中验证目标镜像是否包含该设备节点——靠运行时探测加 fallback 是自欺欺人。
