Go 问答：crypto/rand.Read 返回错误时还能使用已填充字节吗：随机源失败与切片状态

看到 crypto/rand.Read 的返回值是 (n int, err error)，很多人会自然地写出“即使出错，也先用前 n 个字节”。这个判断对普通 io.Reader 不能直接套到 rand.Read 上：当前 Go 的公开契约是填满整个切片，遇到随机源错误会让进程不可恢复地终止，而不是把半截随机值交给调用方。

不要把 rand.Read 当成“可能返回部分密钥的普通读取函数”。生成密钥、Nonce 或令牌时，只有完整填充并成功返回，整段切片才有资格进入后续逻辑；如果要测试失败路径，应把测试边界放在底层读取器或包装函数上。

先分清 rand.Read 和普通 Reader 的返回语义

io.Reader.Read 允许一次只返回一部分数据，也允许同时返回一个错误；因此，调用方通常要依据 n 和 err 决定是否继续。crypto/rand.Read 对外暴露了相同的返回值形状，但语义更强：文档明确说它会填满 b，并且不会返回错误。

在 Go 源码里，rand.Read 对底层 Reader 调用 io.ReadFull。默认随机源成功时，函数直接返回完整长度；若底层出现错误，错误不会作为一个“可消费的部分结果”交给调用方。

为什么 n 不能让半截密钥“变得可用”

假设业务需要 32 字节密钥，缓冲区初始值是零。底层读取器只写入前 11 字节后报错，剩余 21 字节可能仍是旧内容、零值，或者是上一次复用缓冲区留下的内容。此时 n == 11 只说明写入进度，不说明这 32 字节具备随机性。

这也是“先截取 b[:n] 再继续”的危险之处：密钥长度改变了；而“继续使用完整 b”更糟，因为未覆盖部分没有随机源保证。对安全材料，失败是整块失败，不是可以按字节打折的成功。

package main

import (
	"crypto/rand"
	"fmt"
)

func newKey() ([]byte, error) {
	key := make([]byte, 32)
	n, err := rand.Read(key)
	if err != nil || n != len(key) {
		return nil, fmt.Errorf("random key was not fully filled: n=%d err=%v", n, err)
	}
	return key, nil
}

这个检查保留了调用方的意图：只有完整长度才进入后续流程。按当前公开契约，默认 rand.Read 不会走到 err != nil 分支，但检查 n 仍能防止未来换成别的实现或包装器后悄悄改变约束。

需要可恢复错误时，把边界下移到受控读取器

如果程序必须把随机源故障转换成 HTTP 500、任务失败或重试信号，不要依赖 rand.Read 返回底层错误。可以在业务边界注入一个 io.Reader，用 io.ReadFull 读取到临时缓冲区，成功后再提交给调用方；发生错误就丢弃临时缓冲区。

func fillRandom(r io.Reader, size int) ([]byte, error) {
	buf := make([]byte, size)
	n, err := io.ReadFull(r, buf)
	if err != nil {
		return nil, fmt.Errorf("random source stopped after %d bytes: %w", n, err)
	}
	return buf, nil
}

这里的提交点很重要：返回前没有把 buf 的切片暴露出去，所以调用方不会拿到部分填充结果。生产环境仍应使用操作系统提供的安全随机源；注入自定义读取器主要用于测试错误分支和验证上层回滚。

测试失败路径时，别把进程终止误判成普通 error

当前 Go 源码对 rand.Read 的底层错误采用不可恢复终止路径，因此测试“返回了多少字节”并不能覆盖这个行为。更合适的单元测试是测试上面的 fillRandom：让一个测试读取器先写入少量字节再返回错误，断言返回值为 nil，并核对错误中包含实际读取数量。

另外，Go 版本会影响 crypto/rand 的内部随机源选择。文章中的结论只针对公开 API 契约；不要把内部实现细节写进业务判断，也不要为了制造失败而在生产环境替换全局随机源。

相关问题：几个容易混淆的边界

n 等于 len(b) 就一定代表业务安全了吗？

它只说明缓冲区被完整填充。密钥用途、长度、生命周期和是否泄露仍由业务负责，不能把长度检查当成完整安全审计。

遇到错误能不能重试 rand.Read？

默认实现的错误路径不是普通返回错误。可恢复重试应放在注入的 io.Reader 或业务包装层，并设置次数、超时和失败告警，不能对已经部分填充的密钥原地重试后继续使用。

为什么示例还保留 err 检查？

因为返回值签名如此，而且包装、替换实现或未来版本可能带来不同边界。保留检查能让代码意图清楚；真正关键的是只接受完整缓冲区。

结论：随机源失败时整块作废

crypto/rand.Read 的核心承诺不是“尽量填一些字节”，而是“成功时填满整个切片”。看到 n 和 err 时，先判断自己调用的是哪个层级：普通读取器可以处理短读，随机材料则必须采用完整填充、成功提交的边界。需要模拟错误，就在可注入的 io.Reader 包装函数上测试，并把部分结果彻底丢弃。