Go crypto/rand生成指定范围内的安全整数的参数边界

需要生成抽签序号、一次性验证码片段或安全令牌中的数字时，范围边界比“随机”两个字更容易出错。Go 的 crypto/rand.Int 已经提供了安全的均匀取值，但它的上界是不包含的：结果属于 [0,max)，而 max 会触发 panic，随机源读取失败则通过 error 返回。

官方地址：https://pkg.go.dev/crypto/rand

Go crypto/rand 的安全整数边界先看 max

crypto/rand.Int 的签名是 Int(rand io.Reader, max *big.Int) (*big.Int, error)。第一个参数通常使用并发安全的 rand.Reader，第二个参数表示“结果上界的下一个值”。因此 max=10 得到的是 0 到 9，而不是 0 到 10。

这个设计和切片下标、math/rand.Intn 的半开区间一致，便于组合。但它也意味着调用方必须先确认业务是半开区间还是闭区间。不要把 max 直接写成一个可能为零的配置值，也不要用字符串转整数失败后的零值继续调用。

对于安全场景，使用 math/rand 产生的值再做哈希并不能补回不可预测性；随机源的选择应在生成入口就正确。

用宽度表达任意范围，避免把上界算错

从零开始的范围最简单，闭区间则要先增加一个单位。下面的例子同时处理了空范围，并把 big.Int 保留到边界计算完成，适合范围可能超过机器 int 的场景。

package main

import (
	"crypto/rand"
	"errors"
	"fmt"
	"math/big"
)

// secureClosedInt 返回 [min, max] 内的安全随机整数。
// 先计算 width，再平移结果，避免把 max 误当成 crypto/rand.Int 的可取值。
func secureClosedInt(min, max int64) (*big.Int, error) {
	if min > max {
		return nil, errors.New("随机区间为空") // 反向区间直接交给调用方修正。
	}
	lo := big.NewInt(min)
	width := new(big.Int).Sub(big.NewInt(max), lo)
	width.Add(width, big.NewInt(1)) // 闭区间需要把右端点计入宽度。

	n, err := rand.Int(rand.Reader, width)
	if err != nil {
		return nil, fmt.Errorf("读取安全随机源失败: %w", err) // 保留底层错误便于上层记录。
	}
	return n.Add(n, lo), nil // n 原本在 [0,width)，平移后落在 [min,max]。
}

func main() {
	n, err := secureClosedInt(100, 999)
	if err != nil {
		fmt.Println(err)
		return
	}
	fmt.Println(n)
}

如果业务实际需要的是 [min,max)，宽度应写成 max-min，不再加一。使用 int64 计算宽度时还要留意极端的最小值与最大值相减可能溢出；范围很大时，直接使用 big.Int 做减法更稳妥。

crypto/rand.Int 和 math/rand.Intn 怎么选

两个 API 都表达半开区间，却解决不同问题。crypto/rand.Int 使用密码学安全随机源，接收 *big.Int 上界，适合会影响认证、抽签公平性、重置码或不可预测编号的场景。math/rand.Intn 接收普通整数，适合测试数据、动画抖动、洗牌演示等不需要对抗预测的场景。

尤其不要写成“取一个随机字节再对范围取模”。当字节空间不能被范围整除时，较小的余数会获得更多机会。标准库的 crypto/rand.Int 已经负责均匀取值的边界处理，应用代码只需给出正确的正数上界。

上线前检查四个参数边界

第一，确认 max 是宽度而不是业务上界；闭区间的右端点要在宽度计算时加一。第二，确认 min > max 时返回业务错误，而不是把负数交给 rand.Int。第三，保留 error，不要因为“随机读取通常成功”就忽略它。第四，测试时可以传入自定义 io.Reader 控制读取错误，但生产调用仍使用 rand.Reader。

// 检查一个半开区间的配置是否合法。
func validateRange(min, max int64) error {
	if min >= max {
		return fmt.Errorf("需要满足 min 

把这四项检查写在边界层，业务函数内部就只接收已经明确的范围。这样既能避免 panic，也能让“上界不包含”和“安全随机源失败”在日志中呈现为两个不同的问题。

常见问题

crypto/rand.Int 能直接生成 1 到 100 吗？

可以，把宽度设为 100，取到的结果在 [0,100)，再加 1 即可得到 [1,100]；不要把 100 直接当成包含式上界。

max 传 0 为什么不是返回 error？

这是 API 的参数契约：max 小于等于 0 会 panic。调用前应在业务边界校验配置，不能依赖 recover 代替参数检查。

普通验证码也能用 math/rand.Intn 吗？

如果验证码会承担认证或找回身份的作用，就应使用 crypto/rand；只有演示、测试或不具备安全意义的随机展示才适合 math/rand。