Go问答：crypto/rand.Read 返回错误后还能不能使用缓冲区怎样处理失败结果

如果你看到 crypto/rand.Read 的签名里有 (n int, err error)，不要因此把它当成普通的可恢复短读接口。Go 官方文档明确说明：rand.Read 会填满传入切片，正常情况下不会返回错误；它在底层随机源失败时会让进程不可恢复地退出。因此，失败后不存在“继续使用半截缓冲区”的安全处理路径。

官方文档：https://pkg.go.dev/crypto/rand#Read

使用默认 crypto/rand.Read 时，调用方只应在正常返回后使用完整切片；如果业务必须把读取错误返回给上层，就直接面向一个可控的 io.Reader 使用 io.ReadFull，失败时丢弃整个缓冲区。

为什么 crypto/rand.Read 的 error 不能按普通返回值处理

rand.Read 的实现会通过 io.ReadFull 填充随机字节。官方实现对底层错误采取的是不可恢复退出，而不是把错误继续交给调用方。返回值保留了 io.Reader 风格的形状，主要是为了兼容接口习惯，不代表调用方需要围绕“短读后重试”编写分支。

所以最小用法可以直接把随机切片交给 rand.Read。示例中的空白标识符不是忽略安全错误，而是表达该 API 的契约：默认随机源成功时切片必然被填满，底层异常不会回到这里形成可恢复分支。

package main

import (
    "crypto/rand"
    "fmt"
)

func main() {
    key := make([]byte, 32)
    // rand.Read 按契约填满 key；默认随机源异常时不会返回可恢复 error。
    _, _ = rand.Read(key)
    // 随机字节可能包含不可打印字符，这里只把它格式化为十六进制。
    fmt.Printf("%x\n", key)
}

不要把不完整的随机材料继续交给业务层

随机字节一旦用于密钥、一次性令牌、签名输入或不可预测的标识，就必须满足“完整且来自可信随机源”这两个条件。只检查 n > 0、只忽略 err，或者复用上一次调用留下的尾部字节，都会让调用方拿到语义不完整的材料。

这里还要区分两种情况：

• 默认 crypto/rand.Reader：rand.Read 成功就填满，底层失败由运行时终止进程，调用方没有安全的错误恢复点。
• 你自己控制的 io.Reader：不要伪装成 rand.Read 的错误分支，改用 io.ReadFull 明确接收数量和错误。

需要可恢复错误时，直接使用 io.ReadFull

测试随机源、硬件随机源适配器或其他可替换输入如果需要把故障传回上层，可以让读取函数返回一个新切片。只有读满且没有错误时才返回它；任何短读或错误都返回 nil，这样不完整内容不会继续流入密钥或令牌生成逻辑。

package randombytes

import (
    "fmt"
    "io"
)

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

io.ReadFull 会反复读取直到填满切片，或者遇到错误；如果输入提前结束，调用方会得到数量和错误。这里即使未来某个 Reader 同时给出非零数量与错误，也不会把半成品交给调用方。

按场景决定重试，而不是重试半截缓冲区

如果上层决定重试，应重新创建或清空一块新的目标缓冲区，并设置明确的次数、超时和日志上下文。重试策略解决的是“随机源暂时不可用”，不是把不完整随机材料变成完整材料。

常见问题

crypto/rand.Read 返回的 n 是否还需要比较 len(buf)？

从契约上看，成功返回时它会填满切片；业务代码可以把“完整切片”作为前提。若你正在封装可替换的普通 Reader，则应使用上面的 io.ReadFull 并同时检查 n 与 err。

失败后能不能保留已写入的前 n 个字节？

不能把它们当作本次随机材料继续使用。即使底层 Reader 写入了部分字节，调用方也无法仅凭数量证明整块数据满足业务安全条件；应丢弃整块缓冲区并按场景返回错误或终止流程。

小结：crypto/rand.Read 的关键不是“如何接住 error”，而是先认清它的失败契约；要可恢复，就把边界下移到 io.Reader 和 io.ReadFull，并只交付完整结果。