1. 随机数的第一课别急着import random早些年带新人写爬虫最常被问的问题不是“怎么解析JSON”而是“师傅为什么我每次运行生成的数据都一模一样”。后来转做量化策略发现很多同事对随机数的理解停留在“random.randint能出个数就行”。每次听到这种话我都想拉着他坐下来聊聊底层那点事——随机数这玩意儿看起来稀松平常用错了能把整个项目坑到哭。先说个场景你要给用户生成一个6位短信验证码。初版代码可能就三行import random code random.randint(100000, 999999)本地测一测没问题。上线之后跑了一阵子突然有用户反馈“验证码不对”。查日志发现短时间生成的一批验证码居然有大量重复。这时候你才开始意识到random模块的随机数其实根本没你想的那么随机。这篇文章想做的就是把Python生成随机数这条线彻底讲透——从random模块的日常用法到伪随机数的底层原理再到并发环境、安全场景、量化回测里那些隐蔽的坑。全文没有“教条式总结”全是实际调试和落地过程中的经验记录。无论你是刚入门Python的爬虫新手还是已经在做数据分析、量化策略的进阶玩家这轮梳理应该都能帮你省下不少排查问题的时间。2. random模块日常随机任务的基石2.1 最常用的那批函数用起来有讲究random模块的函数其实可以按用途分成几类基础随机、序列随机、分布采样、系统随机状态管理。先看最核心的几个。基础的随机浮点数用random.random()返回[0.0, 1.0)之间的浮点数这是整个模块地基里的地基。random.uniform(a, b)是在[a, b]区间取浮点随机数底层就是a (b-a) * random()。整数随机有random.randint(a, b)注意它是闭区间也就是可能取到b。而random.randrange(start, stop, step)遵循range的规则是左闭右开step不为1时可以用来取偶数、取间隔样本。我见过不少新手把randint和randrange搞混然后半夜发消息问“为什么我limit10却随机出了10”。别笑这个bug坑过很多人。序列相关的一组中random.choice(seq)从非空序列里等概率取一个元素random.choices(population, weightsNone, k1)是带权重的取样支持重复取同一个元素k指定取多少个random.sample(population, k)则是无放回取样取出来的元素不可能重复。知道每个函数干什么用还不够关键要知道它们背后的“等概率”到底是什么概率。拿random()来说它返回的浮点数来源于52位随机整数的映射所以实际能表达出来的不同浮点数量级是2^52。这意味着理论上两个相邻浮点数之间存在一个不可再分的“最小间隔”。如果你在[0, 1)区间上做极细粒度采样精度天花板就在这里用random()生成的数不可能覆盖所有浮点值。举个例子模拟掷骰子6000次理论上每个面出现的次数应当在1000左右波动。用random.randint(1, 6)来做蒙特卡洛模拟是够用的因为骰子的取值为离散的6个点精度需求远低于2^52的分辨率。但如果你用随机数去模拟连续分布的积分近似每个采样点刚好落在“网格”上收敛口径就可能出现系统性偏差。2.2 权重、种子和可复现的实验环境random.choices的权重参数很实用。比如运营要做抽奖一等奖概率1%、二等奖9%、三等奖30%、谢谢参与60%直接写成import random items [一等奖, 二等奖, 三等奖, 谢谢参与] weights [1, 9, 30, 60] result random.choices(items, weightsweights, k1)[0]这里weights是相对权重不要求和为100底层会把权重归一化后做累积分布采样。如果某个权重比另一个大1000倍并不意味着“1000次里必出一次大的”这仍然是概率事件只影响长期的分布收敛。最容易被误解的其实是random.seed()。seed(42)把随机数生成器播种到固定状态之后每次调用随机函数都会按相同顺序产出同样的数列。这在写文档示例、算法复现、单元测试时是神器——因为测试可以用固定随机序列来断言结果。但很多人把seed一用就上瘾跑任何脚本都随手加一个random.seed(0)。这在生产环境反而是隐患。之前帮朋友排查过一个A/B测试分组的代码QA同学为了防止“测试随机性”固定了seed结果线上分组每次重启服务后用户分到的实验组完全一样。对于需要真实随机分配的线上场景seed的滥用等于把随机性废掉了。后面第3章我会专门讲随机种子的坑。3. 伪随机数的真相Mersenne Twister与安全边界3.1 random模块的底部到底是怎么运作的说起random模块的底层绕不开Mersenne Twister算法。这是一个伪随机数生成器PRNGMT19937是它的经典实现名字里的“19937”源于它使用的梅森素数2^19937 - 1。它的工作原理大致可以概括为三个阶段。初始化时用一个32位种子seed作为输入通过一系列位运算填满一个长度为624的整数状态数组。生成随机数时每轮从状态数组里取出几个数做位运算组合再经过一个“扭转”过程twist更新状态最终输出看似杂乱无章的32位整数。random.random()取的就是这个输出除以2^32的浮点结果。这段听起来像计算机体系结构的描述为什么值得关心因为它决定了两个重要事实。第一它是确定性的。给定种子它会完整复现同一序列。这在科学计算里是“特性”而非“缺陷”因为实验可复现是论文和回测的基本要求。第二它是可预测的。只要拿到足够多的连续输出值理论上就可以反推出当前的内部状态进而预测后续的随机数。任意基于random模块生成的安全令牌、会话ID、抽奖密钥在懂行的人面前形同虚设。所以安全相关的场景random直接出局要用到第4章的secrets模块。3.2 伪随机数够用的场景与绝不该用的场景伪随机数并非废物它只是“看起来随机但内在有序”。适用场景包括蒙特卡洛模拟、数值抽样、洗牌逻辑、游戏随机掉落、简单的用户分组、数据增强里的随机裁剪。这些场景对“不可预测性”没有强要求但对“可复现性”有强要求所以伪随机数甚至是更好的选择。不适用场景涵盖密码、Token、验证码、密钥生成、重置口令链接、防重放机制里的Nonce、区块链私钥助记词的生成。还有在线抽奖的最终开奖逻辑——如果攻击者能拿到若干次开奖结果通过学习输出数列反推种子与状态就能精准预测下一次大奖给谁。这类数据必须用加密安全的随机源见第4章。再补充一个容易被忽视的边界分布式系统的trace ID生成。如果多个进程同时启动且种子相同就可能出现重复的ID序列。单纯使用random做全局唯一ID是危险的标准做法是UUID、Snowflake算法或直接上secrets.token_hex。4. 多线程与并发环境下的随机数管理4.1 全局随机状态隐藏的线程安全问题random模块默认维护一个全局的Random实例。这个实例内部状态由多个整数组成每次生成随机数都要读取并修改这些状态。多线程场景下如果多个线程同时调用random.random()底层CPython会因为GIL的存在而给每个调用加上互斥保护吗并没有那么理想。random()在CPython里理论上不会出现数据竞争导致崩溃因为GIL保证单条字节码的原子性但它并不保证随机状态的更新是“事务性”的。当线程调度发生在状态读取与更新之间时生成的随机数序列依然可能出现重复或质量下降尤其在密集调用场景。更典型的坑是性能问题。全局锁和共享状态会让多个线程争抢同一块内存更新权导致”多线程用random反而变慢“。你以为是并发了实际上大家都在排队抢同一把锁。4.2 正确的做法每个线程单独一个Random实例解决思路很朴素——别让线程共享随机状态。为每个线程创建独立的random.Random()实例。import random import threading thread_local threading.local() def get_rng(): if not hasattr(thread_local, rng): # 注意这里不要手动seed为同一个值 thread_local.rng random.Random() return thread_local.rng每个线程的Random实例都有自己的状态流。需要注意两点一是不要让多个Random实例使用相同的种子初始化否则它们会产出完全相同的序列二是在fork出来的子进程里如果继承父进程的random状态多个子进程也会产出相同的序列。解决子进程问题要么在子进程启动后重新播种要么直接用secrets这类系统级随机源。Python 3.11以后随机数生成器换了新算法从MT改为PCG64这是numpy早就在用的算法性能更好但对线程安全的使用方式要求不变——独立实例始终是最稳的。4.3 并发场景下随机ID冲突的排查实录之前做一个异步抓取任务每个请求会生成一个本地request_id代码很简单import random request_id random.randint(100000, 999999)结果在日志里搜索request_id时发现同一毫秒内出现多个重复ID。用threading.Thread起8个worker每个worker都会生成ID而它们共享同一个全局random状态。虽然每次调用都有GIL保护但同一时刻的高并发调用让状态更新和值读取之间产生了重叠最终出现重复。修复方案不是加锁因为加锁会让性能变差。直接改成每个线程维护自己的Random实例问题立刻消失。如果对ID的全局唯一性要求更高就直接上uuid.uuid4().hex或secrets.token_hex(8)。这类经验写成结论就一句话并发场景下随机源要按线程/进程隔离。5. 安全随机数secrets模块的正确打开方式5.1 为什么安全随机数必须用系统熵源random的伪随机序列由种子决定而种子的信息熵有限。假设seed的取值范围是0到2^32那么随机数生成器的状态空间至多只有2^32种。攻击者枚举到正确seed后整条序列便能完全复现。安全随机数必须依赖操作系统内核的“熵池”。Linux上的/dev/urandom、macOS和Windows上的系统级加密API会被os.urandom()封装。Python的secrets模块就是建立在这之上的高层封装。拿验证码来举例。短信验证码是典型的强安全需求场景攻击者可能会批量请求验证码然后尝试暴力枚举。如果验证码是random.randint(100000, 999999)生成的攻击者拿到几次输出之后有可能反推状态把所有验证码候选值范围缩小到很小再配合穷举就能造成安全风险。换成secrets.randbelow(900000) 100000每生成一个值都会从操作系统熵池取随机数据攻击者无法通过已有输出来预测后续值。5.2 secrets常用方法token、choice与整数采样secrets的标准用法可以直接照抄import secrets # 随机整数等价于 randint 语义[a, b) 区间的安全版本 safe_code secrets.randbelow(900000) 100000 # 从序列中做安全的选择 winner secrets.choice([user_a, user_b, user_c]) # 生成十六进制token token_hex secrets.token_hex(16) # 生成URL安全base64编码token token_url secrets.token_urlsafe(32) # 生成字节串适合做salt或初始化向量 token_bytes secrets.token_bytes(32)token_hex(16)的输出长度是16字节的十六进制表示也就是32个十六进制字符。token_urlsafe(32)则生成约43字符的URL安全字符串可用于重置密码链接里的token。做API密钥时我会用token_urlsafe(32)因为它在URL里无需额外转义。还有一个很少被人提到的点secrets.choice在抽样数量很多时性能比random.choice差很多。它每次调用都需要从内核熵池取数。熵池本身不慢但如果循环10万次生成随机样本性能差距就体现出来了。批量非安全场景用random安全场景才用secrets这是性能与安全的权衡。5.3 验证码生成中容易被忽略的隐蔽细节验证码类的需求除了选对随机源还要注意存储与校验策略。假设你用secrets.randbelow(1000000)生成6位验证码把验证码明文存到数据库里。数据库一旦泄露攻击者就直接拿到了所有用户的验证码。标准做法是存哈希如sha256加盐校验时把用户输入也做同样的哈希再比对。另外验证码有效期一般设为5分钟。过期以后随机数本身没有意义但旧验证码的哈希还在数据库里就该清理。如果不清理用户的验证码请求频率限制又没做好攻击者可以对同一手机号反复触发新验证码把数据库撑爆。多说一句有些团队图省事直接生成“验证码后回传明文给前端”。这是安全红线永远不要这么做。验证码只应该通过短信通道发送给目标号码业务后端只能保存哈希值和过期时间。6. numpy.random数据科学场景的大杀器6.1 numpy的随机数生成器和random模块的差异做数据分析、机器学习、量化回测numpy.random几乎必用。它的底层实现与random模块不同——numpy有一套自己的随机数生成器体系包括PCG64、Philox、SFC64等多种算法。默认的PCG64相比MT19937统计质量更好、速度更快、状态空间更大。numpy.random中的核心用法更强调“批量”与“分布”。一次性生成一万个正态分布随机数numpy的做法是import numpy as np samples np.random.normal(loc0.0, scale1.0, size10000)底层是一次性分配数组内存并批量填充速度远超在Python里写for循环逐次调random.gauss。我实测过生成100万个标准正态随机数numpy耗时大约是纯Python循环的几十分之一。这个性能差距在蒙特卡洛任务里非常关键。6.2 新APIGenerator与RandomState怎么选numpy在1.17版本引入了新的随机数API推荐用法是这样rng np.random.default_rng(seed42) uniforms rng.random(100) normals rng.normal(0, 1, 100) integers rng.integers(1, 7, size1000)旧写法np.random.seed()配合np.random.rand()还常见于老教程但官方已经标记为legacy。新API的Generator对象提供的方法更丰富比如rng.choice、rng.shuffle、rng.permutation也支持更稳定的分布采样。建议直接用default_rng理由是它给的随机数序列独立性强、可复现性可控、未来兼容性更好。使用default_rng时有个小习惯把它作为参数传入函数而不是在函数内部每次都重新创建。def simulate_price_paths(rng, n_paths1000): return rng.normal(0, 1, n_paths) rng np.random.default_rng(2024) paths simulate_price_paths(rng)这样做的目的是让随机数流可以沿着调用链传递回测时可以整体复现、分模块也能精确定位。如果你在函数内部反复default_rng(2024)那每次调用会从同一种子重置整条序列会被重复使用导致回测结果虚高。这个问题在量化社区里非常普遍很多人跑了半天发现“策略无敌”最后检查发现是随机数被循环重置了。6.3 量化回测里随机种子的正确姿势做量化策略回测时买入卖出时点、参数寻优、样本切分经常会用到随机数。如果每次回测都重新生成随机数结果不稳定你无法判断策略好坏是随机波动还是真实有效。所以必须固定种子。比如rng np.random.default_rng(9527)但固定种子也有坑。如果你的策略里用随机数来做“随机选取N只股票”则固定种子会让每次回测选到的股票完全一致这其实等同于做单一历史回测无法估计策略在多种市场状态下的分布。更好的做法是固定种子做“基础回测”然后跑多个不同种子的敏感度实验看结果均值与方差。这样既能复现又能评估稳定性。实操中我习惯把种子放在配置中心或环境变量中不要硬编码在策略代码里。跑参数寻优的时候用一组种子列表循环运行把每次的结果都存下来最后汇总出策略在多种随机状态下的收益区间。这个习惯帮我淘汰了很多“运气型策略”。6.4 日志中随机数的坑为什么socket收到的奇数字节后面“补”了随机数搜热词的时候发现有人问“为什么socket接收到奇数字节后面会补一个随机数”。这个现象我在做网络通信协议解析时也遇到过原理其实和随机数无关是协议设计里的“填充”问题。很多二进制协议要求数据长度是偶数或对齐到固定字节数。如果发送端发来奇数字节接收端为了解释报文会按协议规范在数据末尾补一个“随机”或“任意”字节保证对齐。这个填充值是不是“真随机”并不重要TCP/UDP本身不会帮你补真正补的是上层协议库或者你自己写的解包代码。如果你抓包看到末尾多了个看似无意义的值不要慌先去看协议文档里有没有对齐要求。这类坑的排查思路是把抓包数据和发送端数据做逐字节比对确认多出来的字节位置再查协议头里有没有长度字段看长度字段是否指向奇数最后看接收缓冲区是不是按固定步长读取。大多数时候问题出在解包/封包代码里没有严格遵循协议的对齐规则而不是系统随机数层面的问题。7. 从入门到进阶的随机数实战清单7.1 基础函数对照表与适用场景速查整理一张速查表方便日常写代码时按图索骥。需求模块与函数是否安全备注随机浮点数[0,1)random.random()否通用模拟、抽样区间内随机整数random.randint(a, b)否闭区间适合离散事件模拟带权重抽样random.choices(seq, weights, k)否支持有放回无放回抽样random.sample(seq, k)否适合洗牌、分组打乱列表顺序random.shuffle(seq)否原地操作注意是None返回安全随机整数secrets.randbelow(n)是验证码、Token安全tokensecrets.token_hex/token_urlsafe是API密钥、会话ID批量正态分布numpy.random.default_rng().normal否科学计算蒙特卡洛固种子复现实验random.seed()/default_rng(seed)否测试、回测、论文复现这里补一个random.shuffle的坑它是原地操作返回值是None。新手写成lst random.shuffle(lst)得到的是None而不是打乱后的列表。批量数据需要保留原始顺序时先用copy.deepcopy或[:]复制一份再打乱。7.2 两种必须掌握的“固定随机”组合技第一种是“单元测试固定随机”。适合做算法自测import random random.seed(123) test_data [random.randint(1, 100) for _ in range(1000)] # 对该固定数据做后续断言保证测试结果稳定第二种是“多实验复现随机”。适合做策略回测和机器学习实验import numpy as np def run_experiment(seed): rng np.random.default_rng(seed) # 模拟或训练逻辑 return result for s in [42, 2024, 9527]: result run_experiment(s) print(s, result)这种方式至少能回答两个问题代码里有没有bug级随机污染策略是否在多个随机状态下稳定如果三个种子的结果方差极大说明策略对随机因素高度敏感上线前要格外谨慎。7.3 换个视角Python生态里其他常见的随机数用法除了标准库和numpyPandas里也有DataFrame.sample()底层调用的还是random或numpy的随机源可以指定random_state参数。Scikit-learn里几乎每一个带随机性的模型都有random_state参数例如train_test_split、RandomForestClassifier。这些库的random_state本质都是固定底层随机种子保证每次运行结果一致。Faker库生成模拟数据时也有随机种子概念Faker(zh_CN)配合seed_instance(0)可以生成固定但看起来随机的中文姓名、地址、公司名这在伪造测试数据时很实用。很多时候你并不需要亲手写随机数算法但你需要理解“随机性从哪里来、在哪里被固定”这样才能把复现性和安全性的主动权握在自己手里。8. 实操经验几个让我“熬夜排查”过的随机数问题8.1 在for循环里反复seed序列等于被重复使用有一次帮同事排查数据增强效果图像识别模型的训练集随机采样里他在每个batch生成前都执行了random.seed(42)。结果多个epoch之间每个batch的数据几乎一模一样模型严重过拟合到固定样本上。排查时看到代码里“为求稳妥”加的seed我整个人都沉默了。正确的做法是在训练开始时固定一次种子之后让随机源自然推进。如果每个batch都要独立的随机性就不要在循环内重新种。当时同事的潜台词是“我每次都种下一样的数应该最稳”但随机数的正确理解恰好相反——种子固定的是序列起点不是每步的输出值。8.2 验证码模块上线首日重复率异常一个抢购系统的验证码上线第一天的重复率高达15%。开发环境没问题生产环境才暴露。后来的定位过程很有意思应用部署了多个实例每个实例启动时都会执行random.seed()而seed来源是容器启动时间精确到秒。同一个秒钟内启动的实例越多种子相同的概率越高结果就是这波实例生成的前几个验证码完全一样。修复方案是去掉显式seed让Python在启动时从系统熵源自动获取种子同时把验证码生成迁移到secrets.randbelow。如果某些框架强制要求seed就用os.urandom的字节做种子而不是时间戳。8.3 蒙特卡洛模拟的结果离理论值“偏得离谱”在做期权定价的蒙特卡洛模拟时发现标准误差缩减得很慢比理论收敛速度慢了一个数量级。检查后发现问题出在低质量随机数上——random.random()生成的随机数序列在二维投影中呈现网格状分布而不是均匀“铺满”平面。这是MT19937在低维投影下的潜在缺陷之一。后来改用Sobol序列低差异序列做抽样问题明显改善。实践中如果模拟问题涉及高维积分建议优先考虑准随机数生成器例如scipy.stats.qmc.Sobol。这类工具虽然不那么常见但在量化定价、风险因子模拟里是标配。8.4 日志追踪里的随机数陷阱最后分享一个有点偏门但真实遇到的坑。某次排查线上请求链路发现日志里每隔一段就出现一个随机字节的乱码。起初以为加密逻辑出了错后来发现是把某字段长度从奇数值强行对齐成偶数的协议层代码在末尾补了随机的填充字节而这些填充字节又被业务日志原样打印出来了。不是说随机数本身有问题而是它出现在预期之外的字段里会让日志分析、监控报警产生大量噪音。解决方法是明确协议中对齐位的“哑值”约定例如固定填充0x00或0xFF而不是随便取一个随机字节。随机数该用于对抗和采样不该用于无意义的字节填充。这一点纯属经验累积。9. 随机数之外还有一件事值得养成习惯写完这么多还是想以一个老开发的口吻多叮嘱一句随机数模块的选择本质上是对“随机性来源”的选择。日常模拟、数据抽样、回测复现用random或numpy.random就对了密码、令牌、验证码、抗枚举场景一定要切到secrets多线程、多进程环境各线程各进程要管理好独立的随机流固定的随机种子只出现在测试和可复现实验中不要随手乱加。如果你现在正被某个随机数问题折磨得头疼可以先用一个最简单的测试验证怀疑写一小段循环打印50次随机结果看看序列是否出现规律性重复。再想想运行环境里有没有人为的seed注入。排查的方向对了问题大概率会在半小时内水落石出。最后再分享一个很小但很实用的技巧写代码前先想清楚“这个随机数能不能被预测”如果答案是“能也无所谓”说明你选错了场景模型如果答案是“绝对不能”那它就是安全随机数该上岗的位置。把每个随机数的用途都想透你写代码的确定性自然就高出一大截。