Go crypto/rand.Reader 读取随机字节时怎么处理短读

给登录令牌、密钥或 nonce 分配固定长度缓冲区时，最容易误判的是把一次 Read 当成“必定填满”。crypto/rand.Reader 的类型是 io.Reader，调用方必须尊重 Reader 允许返回少于缓冲区长度的规则。需要严格得到 32 个字节时，直接使用 io.ReadFull(rand.Reader, buf)；只有 err == nil 且 n == len(buf) 才把结果交给后续逻辑。

为什么一次 Read 不等于填满随机缓冲区

线上代码通常写成 buf := make([]byte, 32)，然后把 rand.Reader.Read(buf) 的返回值忽略。问题在于 io.Reader 只承诺“最多写入 len(p) 个字节”，当数据暂时不足时可以返回 n 。调用者应先处理已经读到的 n > 0 字节，再判断错误。

crypto/rand.Reader 是并发安全的全局加密随机源，默认实现会接入操作系统随机接口。但它暴露给调用方的仍然是 io.Reader；全局变量也可以被测试或应用替换。因此，业务层不应依赖某一次底层调用恰好填满缓冲区。

固定长度读取用 io.ReadFull 收口

io.ReadFull 会持续读取，直到填满目标切片或遇到错误。它的判断条件很适合令牌、盐值和固定宽度密钥：返回 n == len(buf) 当且仅当 err == nil。部分输入后遇到 EOF 时，错误是 io.ErrUnexpectedEOF；一个字节都没有读到则可能是 io.EOF。

package main

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

func readToken() ([]byte, error) {
    buf := make([]byte, 32)
    // ReadFull 负责补齐短读；固定长度不满足时直接返回错误。
    n, err := io.ReadFull(rand.Reader, buf)
    if err != nil {
        // n 只用于记录实际进度，不能把半截 buf 当成完整令牌。
        return nil, fmt.Errorf("读取随机令牌失败（%d/32 字节）：%w", n, err)
    }
    // nil 错误意味着 32 个字节都已填充。
    return buf, nil
}

如果错误需要被上层分类，使用 errors.Is(err, io.ErrUnexpectedEOF) 判断固定块被截断，其他错误则保留原始包装链。不要通过再次调用 Read 来“碰运气”补齐，因为那会把读取策略散落到业务代码，并容易遗漏错误。

从 n 和 err 判断真正的失败边界

读取固定长度时，可以把结果压缩成一张小检查表：

这里的“重试”也要有边界：如果 Reader 来自不可恢复的文件、网络或测试替身，盲目重试没有意义；如果是一次可恢复的系统随机源错误，应由更上层决定退避和告警。随机字节一旦不足，宁可让请求失败，也不要用零值补尾。

什么时候直接用 rand.Read，什么时候保留 Reader

如果只是从默认加密随机源取得一段字节，rand.Read(buf) 是更直接的入口；当前实现内部也会对 Reader 做完整读取，失败时不会静默返回半截结果。若 API 接收的是一个可替换的 io.Reader，或者测试需要主动构造短读，则继续使用 io.ReadFull(r, buf)，把“必须填满”写在调用点。

测试时可注入一个每次只返回少量字节的 Reader，再注入 EOF 或自定义错误，验证业务只接受完整缓冲区。注意不要把测试替身的行为推断成默认系统随机源的性能特征；测试的目的只是证明调用方遵守接口边界。

常见问题

短读是不是说明 crypto/rand 不安全？

不是。短读描述本次 Reader 调用返回了多少数据，安全性来自加密随机源及其实现。固定长度场景用 io.ReadFull 收口即可。

为什么不手写 for 循环读取？

可以手写，但必须正确处理每次的 n、EOF、零字节无错和底层错误。io.ReadFull 已经把固定长度语义集中起来，更不容易漏分支。

读到部分字节后还能继续使用吗？

对令牌、密钥、nonce 这类固定结构不能使用。部分字节只能用于日志中的进度信息，不能作为随机值返回。