Go crypto/rand检查随机读取返回的错误的处理方案

生成令牌、验证码或密钥时，Go 的 crypto/rand.Read 返回值不要直接丢弃。更稳妥的处理是：先判断 err，再确认 n 等于目标长度，最后才把字节交给编码或业务层。当前标准库文档说明，默认的 rand.Read 会填满切片并且通常不会返回错误；这不等于业务封装可以把错误边界删掉，尤其是测试替换随机源、底层平台异常或未来更换读取方式时。

先分清 crypto/rand.Read 的返回值契约

crypto/rand.Read 的签名是 func Read(b []byte) (n int, err error)。在默认 rand.Reader 下，官方文档描述它会调用 io.ReadFull 填满目标切片；如果底层读取真的返回错误，默认实现会让程序不可恢复地终止。因此，生产代码通常不会靠“读到一半再继续”来修复问题，而是把错误尽快交给上层。

这里有两个容易混淆的判断：n == len(buf) 只说明写入数量符合预期，不能代替 err == nil；相反，err == nil 也不应让一个自定义 Reader 的异常短读被默默接受。随机数据没有完整长度时，继续编码成 token 会把一个不完整结果伪装成成功。

封装一次随机读取，成功后再返回数据

把判断集中在小函数里，调用方就不用在每个生成令牌的地方重复写一套不完整的分支。下面的示例保留错误上下文，并把长度检查放在编码之前。

package token

import (
	"crypto/rand"
	"fmt"
)

func randomBytes(size int) ([]byte, error) {
	// 负数或过大的申请应在业务层另行限制，这里只处理读取契约。
	if size 

调用方只在成功分支中使用结果，例如把字节交给十六进制编码器；错误分支可以返回服务错误或进入有限重试，但不要把原始随机字节写入日志。对 crypto/rand.Read 来说，长度检查更多是防御性边界，而不是预期的常规分支。

用可替换 Reader 验证错误路径

因为默认随机源很难稳定地产生错误，测试时可以把读取动作抽成接受 io.Reader 的函数，再用一个短读或故障 Reader 注入边界。io.ReadFull 会持续读取直到填满缓冲区，无法填满时返回错误，这正适合验证“失败就停止”的行为。

package token

import (
	"fmt"
	"io"
)

func readBytes(r io.Reader, size int) ([]byte, error) {
	// 统一使用 ReadFull，避免普通 Read 的短读被误当成成功。
	if size 

单元测试可以传入只返回一部分字节后报错的 Reader，断言函数返回非空错误和空结果；成功测试则传入固定字节 Reader，检查长度而不是把随机值写进断言。这样既覆盖了失败分支，也不会让测试依赖操作系统随机源。

重试与日志只处理故障，不暴露随机内容

随机源错误通常不是业务输入错误，不能用无限重试掩盖。若部署环境有明确的瞬时故障边界，可以在最外层做次数很少的重试，并在每次失败之间记录错误类型、请求追踪标识和尝试次数；不要记录 token、密钥、完整缓冲区或把错误原文直接返回给外部用户。无法确认可恢复时，直接失败比生成低质量随机值更安全。

常见问题

crypto/rand.Read 的 err 可以直接忽略吗？

默认实现按文档通常不会返回错误，但公共封装仍建议保留错误分支，避免替换读取方式或测试注入后静默吞错。

为什么还要检查 n？

长度检查表达了业务需要的完整性；它不能替代错误判断，也不应被当成普通短读的重试许可。

测试时应该断言随机值固定吗？

不应断言真实随机值。注入固定 Reader 后断言长度、错误和调用结果，把随机性与读取错误处理分别测试。