ExplodingDragon

RN 的可用性和隔壁的 kotlin compose-multiplatform 一个级别的，没法用，ai 可帮你简单解决不了各种诡异的 ffi 跨平台调用

云原生确实是非常值得了解深入的一方面，不是说有哪些项目，而是指相关的细节和考量，例如为什么在此处用 xx 而不是 xx ， 很多都是实际生产环境的经验总结

用 {1} 写出来的程序 用 {2} 审计出来了 {3} 多个 bug

其中 {1} / {2} 可替换为任何模型，{3} 可替换为任意正整数

> 玩家向管理员申诉，管理员就能封禁那个恶意节点

那如果管理员有坏人或者玩小团体有偏向呢

现在 pro 5x 额度掉的比之前快多了

> “ 6 个相信你的人” , “初期一个 pro 账号廉价账号加廉价账号甚至日抛,” “余量还能往外卖” , “掺水血赚一波”

这就是不要相信任何中转站的很小部分原因

A ➗ 都已经这样子了就不要给他当狗了 ...

中转站没有安全的，没给你响应内容替换为病毒脚本算良心的

顺便贴一下使用 chatgpt pro 的结果 , 无法跳步或 SIMD 就没继续看了 （：

这段原始代码不能直接用“常数快速幂”或“矩阵快速幂”跳过 1e14 轮。关键原因是：x ^= x >> 32 不是高低 32 位交换，而是把高 32 位异或进低 32 位；它虽然可逆，但和普通整数乘法的进位混在一起后，整体既不是模 2^64 乘法，也不是 GF(2) 线性变换。

设 B = 2^32 ，C = 0xD1342543DE82EF95 = aB + b ，x = hB + l 。一轮乘法后：

```
L = b*l mod B
H = b*h + a*l + floor(b*l / B) mod B
```

随后：

```
T(h, l) = (H, L xor H)
```

问题就在这里：H 里有整数乘法进位 floor(b*l / B)，而低位又用了 xor 。这会把“模加/乘”的结构和“GF(2) 异或线性”的结构打碎。

一个很小的反例就能排除快速幂假设：

T(1) = 0xd13425430fb6cad6
T(2) = 0xa2684a871f6d95ad

如果它等价于某个常数乘法 T(x)=Kx mod 2^64 ，那么应有：

```
2*T(1) mod 2^64 = 0xa2684a861f6d95ac
```

但实际 T(2) 多了 0x100000001 。这就是进位和异或混合造成的偏差。

同样，它也不是 GF(2) 线性的：

```
T(1 xor 2) != T(1) xor T(2)
```

所以这类写法都不成立：


```
// 错：只能用于纯乘法状态转移
x *= pow_mod(C, n, 2^64);

// 错：只能用于真正的 GF(2) 线性 xorshift
matrix_pow(M, n) * x;
```

这个常数本身确实是常见的 64 位 LCG/LXM 乘子； OpenJDK 相关实现也把 0xd1342543de82ef95 用作 LCG 乘子并说明其谱测试分数。也就是说，如果状态转移只是 LCG 乘法/加法，它能快进；但你这里把 mix 结果反馈回状态了，结构就变了。