在日常开发中，伪随机函数几乎是必不可少的一个函数。
大部分我们在使用这个函数时，就自然而然拿来用了，很少去思考用的对不对，反正他是随机的，并且也很难去验证（需要各种大量数据统计)。
所以即使概率看起来不太对，也可以安慰自己说，其实是统计的数据量不够。但有时候真的是因为我们误用了随机函数。
在《计算机程序设计艺术》卷2中，详细介绍了线性同余序列的生成算法。
下面就以线性同余算法为例，来分析一下，为什么随机函数还有可能被误用，他原本不就是随机的么？
在游戏开发中，一般都会设计有开宝箱环节，假设每个宝箱每次开出A的概率是30%，开出B的概率是70%，宝箱可以重复开。
我们的代码可能会这么写
int open_box(box *b)
{
int n = rand() % 1000;
return n < 300 ? b->a : b->b;
}是的,这段代码就是开宝箱存在“垫刀”的根本原因。
我们来看一下线性同余(LCG)伪随机算法的定义：
Nj+1 = (A*Nj + B) (mod M)(j, j+1为下标)
其中A,B,M为线性同余序列生成常数。
LCG周期为M，A,B,M的关系限定如下：
- B,M互质
- M的所有质因子都能整除A-1
- 若M是4的倍数，则A-1 也是
- A, B, N0都比M小
- A,B是正整数
通俗点来讲就是，线性同余生成的[0,M)个数在统计学意义上，是等概率出现的。也就是说在足够多次随机以后，他们出现的次数是相同的。
咋一看，感觉上面的代码好像没啥问题。因为[0,M)是等概率出现的，因此rand()%1000之后的值，也是等概率出现的。
但是！我们忽略了一个事实，这段代码意味着。所有人的所有宝箱（甚至还有其他系统）共用了一个伪随机序列。
假设rand()%1000的伪随机序列是这样的：
900，1，300， 500， 299， 785， 556 …
我们来模拟一下多个宝箱交替打开的行为：
开宝箱1，rand()%1000返回的是900， 因此开出来的是B
开宝箱2，rand()%1000返回的是1， 因此开出来的是A
开宝箱1，rand()%1000返回的是300， 因此开出来的是B
开宝箱1，rand()%1000返回的是500, 因此开出来的是B
开宝箱2， rand()%1000返回的是299， 因此开出来的是A
如果宝箱1和宝箱2一直在以类似的顺序交替打开。即使开再多次，你也很难拍着胸脯说，宝箱1和宝箱2开出来的A，B概率分布是符合预期的。
毕竟你亲口告诉玩家，每个宝箱都有30%的概率开出来的是A，但是宝箱1却从来开不出A。
事情之所以会演变成这样。根本原因是，除了有一个伪随机序列之外，还有一个真随机事件，即玩家开宝箱的时机选择。
用软件工程的话来说，宝箱1和宝箱2通过一个全局变量（同一个线性同余序列）耦合在一起了，他们不是正交的。因此，开一个宝箱势必会影响另一个，所以它必然是错的。
还有很多类似的情况，比如一个技能的触发概率。我们本来告诉玩家的是每个技能以某种特定的概率触发，但是我们很可能做成了，以某种概率释放了某个技能。
在我们用随机函数之前，一定要先问问自己，所有使用rand()函数的地方其实是共用了同一个伪随机序列，这样真的没问题么？
2021/11/16补充:
经过这一年多来的观察, 除了"垫刀"的问题之外, 我们还习惯使用如1000, 10000之类的数字来代替100%的概率. 这就会产生一个现象, 就是1000或10000很可能和LCG公式中的M是有公约数的, 这会导致LCG的周期缩短, 其影响远大于"垫刀"产生的不良影响。在我们将接近1000或10000的质数作为100%概率的代表时，随机数的分布有明显改善。