Go crypto/rand.Read 返回短数据时业务代码如何处理

如果代码直接调用 crypto/rand.Read(buf)，业务层不应该把它当成普通 io.Reader 去猜“这次是不是短读”。Go 文档对这个函数的契约很明确：它会填满目标切片，返回的 n 应该等于 len(buf)；真正需要防的是错误处理、错误地改用底层 Reader，以及把半截随机数据交给 token 或密钥逻辑。

固定长度随机材料优先调用 crypto/rand.Read 并检查错误；只有直接面对普通 io.Reader 时，才用 io.ReadFull 把短读转换成明确的错误分支。

crypto/rand.Read 为什么不该按普通 Reader 判断短读

crypto/rand.Read 的返回值保留了 (n, err) 形状，但这不代表业务代码要像处理文件或网络流那样循环拼接。官方文档说明它始终填满 b；当前标准库实现对可替换的 Reader 也通过 io.ReadFull 获取完整数据，发生错误时终止当前进程，而不是返回一段可继续使用的密钥材料。

固定长度 token 应该把判断放在哪一层

把长度要求封装在业务函数里，调用方只得到“完整 token 或错误”。下面的示例故意保留 n 检查：按 crypto/rand.Read 的正常契约它不会触发，但它能让封装边界在未来被替换、测试或误接其他实现时尽早失败。

package token

import (
	"crypto/rand"
	"fmt"
)

func NewToken(size int) ([]byte, error) {
	// 固定长度由业务边界决定，避免调用方拿半截数据继续编码。
	if size 

生产日志只记录 size、错误类型和请求关联 ID，不打印 buf、十六进制 token 或密钥。若这个函数返回错误，调用方应停止签名、会话或邀请码流程，而不是用默认值补齐。

业务代码真正要防的是半截密钥

真正容易出现短读的是普通 io.Reader。它可以先给出一部分字节且不报错，下一次再继续；如果业务只调用一次 Read 就编码，结果长度可能看似合法，安全熵却已经不足。面对明确的固定长度要求，直接使用 io.ReadFull：

package token

import (
	"fmt"
	"io"
)

func readFixed(r io.Reader, size int) ([]byte, error) {
	// io.ReadFull 会持续读取，直到填满 buf 或返回错误。
	if size 

这两个函数不要混成一个“万能随机读取器”：crypto/rand.Read 表达的是安全随机源与完整填充契约，io.ReadFull 表达的是对任意 Reader 的长度约束。分清层次，排障时才知道问题来自业务长度、Reader 实现还是系统随机源。

测试怎样覆盖短读而不污染安全边界

测试 readFixed 时可以注入一个每次只返回少量字节的 Reader，观察它最终能否填满；再注入提前返回 io.EOF 的 Reader，确认业务得到错误。不要为了制造短读去修改全局 crypto/rand.Reader，也不要把测试用的固定字节误当成安全随机数。

上线排查建议按三项记录：目标长度是否固定、调用的是 crypto/rand.Read 还是普通 Read、失败时是否仍然继续签名或发放凭据。只要发现一次半截数据进入 token 编码，先让该流程失败并轮换受影响凭据，再追查 Reader 的替换和错误传播。

相关问题

crypto/rand.Read 成功后还要循环读取吗？

不需要。成功返回表示目标切片已经填满；重复读取只会生成另一段随机数据。

为什么不能用时间戳补齐短数据？

时间戳不是密码学随机源，补齐后长度虽然满足格式，却没有恢复缺失的熵。

业务层要不要保留 n 检查？

可以保留作为防御性断言和契约记录，但不要把短读当成可继续使用的成功结果。