Go crypto/rand 读取随机数为什么要处理短读：Reader 语义、错误传播与测试替身

给验证码、令牌或会话标识准备固定长度随机字节时，最容易被忽略的不是随机源，而是读取接口的边界：io.Reader 允许一次只返回一部分数据。直接调用 Read 后就继续编码，可能把短字节切片当成完整结果；更稳妥的做法是让读取逻辑明确表达“必须填满”，并在错误时保留可诊断的信息。

固定长度随机字节，真正的约束是什么

假设业务需要 32 字节随机材料，最后编码为十六进制字符串。这里有两个独立要求：随机源要可靠，读取结果也必须恰好是 32 字节。前一个要求由 crypto/rand.Reader 这类安全随机源承担，后一个要求由调用方的读取方式承担。

很多代码只写了下面这一行，然后检查了返回的错误：

n, err := rand.Read(buf)
if err != nil {
    return "", err
}
return hex.EncodeToString(buf[:n]), nil

这段代码把“没有错误”和“已经填满”混成了一个条件。对一般 Reader 来说，n 可能小于 len(buf)；即使当前随机源通常一次填满，也不应该把实现习惯当成接口承诺。

Reader 的返回值为什么不能只看 error

io.Reader 的契约允许一次读取少于请求长度的字节。调用方应该先消费本次返回的 n，再决定是否继续。n > 0 与 err != nil 也可以同时出现，最后一批数据不能因为带有错误就被丢掉。

这正是接口设计里“数据进度”和“终止原因”分开的地方。若业务只需要流式处理，短读可能完全正常；若业务需要固定长度令牌，短读只是中间状态，提前结束或底层错误才是失败结论。

先明确三种结果

• 填满缓冲区：得到可继续编码的完整随机材料。
• 只读到一部分但没有终止：继续读取，不能提前返回。
• 填不满且出现终止或底层错误：返回错误，不能把部分结果交给下游。

io.ReadFull 适合固定长度场景

io.ReadFull 把“读取直到填满”封装成了明确的调用意图。它返回实际读取字节数和错误，缓冲区未填满时不会把部分数据伪装成完整结果。

func secureToken(size int) (string, error) {
    if size 

这里的错误信息保留了进度，但没有泄露随机内容。调用方只需要处理两个稳定结果：拿到完整字符串，或者收到带原因的失败。

生产实现与测试替身怎么分层

生产代码不需要替换 rand.Reader；测试则应该把 Reader 作为参数注入，让短读场景可以被稳定复现。这样测试检查的是读取协议，而不是赌某次系统调用是否恰好分段。

func readToken(r io.Reader, size int) ([]byte, error) {
    if size 

测试替身可以每次只返回两个字节，也可以在读到某个位置后返回自定义错误。测试重点不是替身本身像不像随机源，而是验证调用方是否继续读取、是否保留进度、是否拒绝不完整结果。

一组小测试覆盖三个失败边界

测试数据可以使用固定字节，避免把断言写成“随机值不为空”这种弱检查。第一组替身分段返回，预期仍能拼出完整字节；第二组只返回部分数据后结束，预期得到 io.ErrUnexpectedEOF；第三组返回自定义错误，预期错误链中仍能找到它。

type chunkReader struct {
    data []byte
    step int
}

func (r *chunkReader) Read(p []byte) (int, error) {
    if len(r.data) == 0 {
        return 0, io.EOF
    }
    n := r.step
    if n > len(p) {
        n = len(p)
    }
    if n > len(r.data) {
        n = len(r.data)
    }
    copy(p, r.data[:n])
    r.data = r.data[n:]
    return n, nil
}

如果实现误用了单次 Read，分段替身会立刻暴露返回长度不足的问题；如果使用 io.ReadFull，这个测试同时验证了完整读取和错误收敛。

落地时别把长度和编码混为一谈

32 个随机字节编码成十六进制后会变成 64 个字符，编码长度不是随机材料长度。若协议需要固定字符串长度，应先从协议反推字节数，再写入单元测试。Base64、十六进制和 URL 安全编码的长度规则不同，不能只改一个常量。

另外，读取失败时不要返回部分令牌，也不要为了“让流程继续”填充零字节。认证、找回链接和签名材料都应该快速失败，并由上层决定重试、告警或返回通用错误。

相关问题

crypto/rand.Reader 会不会每次都一次填满？

不能把一次填满当成调用方可以依赖的通用 Reader 语义。固定长度场景仍应通过完整读取语义表达约束。

io.ReadFull 失败后还能使用缓冲区吗？

不应该把未填满的缓冲区当成令牌或密钥材料。可以记录读取进度用于诊断，但返回值应由错误控制。

为什么测试不直接调用 crypto/rand.Reader？

真实随机源适合做连通性检查，分段、提前结束和自定义错误则需要可控 Reader 才能稳定覆盖。

最后的检查清单

• 固定长度读取是否使用了完整读取语义，而不是只看一次 Read 的错误。
• 错误是否保留底层原因和读取进度，同时没有带出随机内容。
• 测试是否覆盖分段返回、提前结束和自定义错误。
• 字节长度、编码长度和下游协议长度是否分别断言。