secrets不能用random替代，因为random生成伪随机数可预测，而secrets调用操作系统加密安全源，不可预测、不可重现，用于密码、API密钥等场景是强制要求。
secrets 为什么不能用 random 替代
random 模块生成的是伪随机数，依赖种子（seed），可预测；secrets 则直接读取操作系统提供的加密安全随机源（如 /dev/urandom 或 CryptGenRandom），不可预测、不可重现。
一旦用于生成密码、API密钥、重置令牌等，用 random 就等于把门锁换成纸糊的。
- 生产环境里所有需要「防猜测」的随机值，必须用
secrets，哪怕只是临时 token -
random.choice()和secrets.choice()行为相似，但前者不安全，后者才合规 - 即使加了
random.seed(int(time.time()))，也完全不提升安全性——这只是让结果“看起来更乱”，实际仍可爆破
生成密码或 token 的正确写法
别拼接字符串、别用 string.ascii_letters + string.digits 配合 random.choices()。要让每个字符都来自加密安全源，并控制字符集范围。
- 用
secrets.token_urlsafe(n)：返回 URL 安全 Base64 编码字符串，长度约n字节编码后结果（比如n=32→ 实际返回约 43 字符） - 用
secrets.token_hex(n)：返回n字节的十六进制字符串（长度固定为2*n） - 若需自定义字符集（如排除易混淆字符
0O1lI），必须用secrets.choice()循环选，不能用random.choices()
import secrets
import string
<p>allowed = string.ascii<em>letters + string.digits.replace('0', '').replace('O', '').replace('1', '').replace('l', '').replace('I', '')
token = ''.join(secrets.choice(allowed) for </em> in range(24))</p>secrets.choice() 和 secrets.randbelow() 的边界问题
secrets.choice() 安全，但只适用于序列；secrets.randbelow(n) 返回 [0, n) 内整数，比 random.randint(0, n-1) 更可靠——尤其当 n 不是 2 的幂时，randbelow 能避免偏斜分布。
-
secrets.randbelow(100)是获取 0–99 安全整数的唯一推荐方式 - 不要用
secrets.randbits(k) % n，会产生模偏差（bias），尤其n远小于2^k时 -
secrets.choice(my_list)要求my_list非空，否则抛IndexError；生产代码中记得检查长度
Flask/Django 中 session key 或 CSRF token 的生成误区
框架默认可能用 os.urandom，但显式调用 secrets 更可控、语义更清晰。很多人在自定义 auth 流程里手写 token 生成逻辑，却沿用旧习惯。
- Flask 的
app.secret_key应设为secrets.token_urlsafe(32)生成的字符串，而非硬编码或os.urandom(24).hex()（后者虽也安全，但不如secrets语义明确） - Django 的
get_random_string()默认不安全；应改用secrets.token_urlsafe()并确保长度 ≥ 50 - 注意：
secrets模块在 Python 3.6+ 才有，若项目还跑在 3.5 及更早版本，得降级用os.urandom+ Base64 手动封装，且务必避开random
真正难的不是调用哪个函数，而是判断「这个值有没有被外部猜测或重放的风险」——只要答案是“有”，secrets 就不是可选项，是必选项。
立即学习“Python免费学习笔记（深入）”；
