高安全性场景必须用SecureRandom.nextBytes而非Random.nextBytes，因前者依赖不可控熵源（如/dev/random、RdRand），后者基于可预测的LCG算法和System.nanoTime()种子，易被逆向推导。
高安全性业务场景下，不能只看“随机”二字，关键要看随机数是否可预测、是否依赖可控种子、熵源是否来自可信系统事件。Random.nextBytes 和 SecureRandom 的核心差异，就藏在这三点里。
Random.nextBytes 本质是确定性序列
Random 使用线性同余算法（LCG），种子默认为 System.nanoTime()。只要攻击者知道大致时间窗口，就能穷举可能的 seed；一旦 seed 确定，整个 nextBytes 输出序列完全可复现。比如：
- 两个 new Random(123) 实例，调用 nextBytes(new byte[8]) 得到的字节数组必然一模一样
- Web 应用用 Random 生成 session ID，攻击者截获几个 ID 后，结合服务器启动时间，大概率能推算出后续 ID
SecureRandom.nextBytes 依赖不可控熵源
SecureRandom 不靠时间戳，而是主动采集操作系统级随机事件：/dev/random 或 /dev/urandom（Linux）、RdRand 指令（Intel CPU）、中断时序、内存页分配抖动等。这些输入无法被远程观测或重现，因此：
- 即使两个 SecureRandom() 实例同时创建，nextBytes 输出也几乎必然不同
- 它不承诺“相同 seed → 相同输出”，反而刻意避免这种可重复性——这是安全设计的刚需
- Java 8+ 默认使用 NativePRNGBlocking 或 NativePRNG，底层直连内核熵池，无需手动补种
选型不是性能取舍，而是威胁模型匹配
不是“SecureRandom 更慢所以慎用”，而是“你的业务是否经得起被逆向推导”。以下场景必须用 SecureRandom.nextBytes：
- 生成 JWT 加密密钥、AES 对称密钥、RSA 密钥对的私钥材料
- 产生密码重置令牌、邮箱验证链接中的一次性随机串
- 为哈希加盐（salt）——若 salt 可预测，彩虹表攻击成本骤降
- TLS 握手中的客户端随机数（client_random）或初始化向量（IV）
别踩这些常见坑
实际开发中容易忽略的细节：
- 不要传自定义 seed 给 SecureRandom 构造函数——除非你有硬件真随机源，否则自己给的 seed 往往比系统默认熵更弱
- 避免 getInstance("SHA1PRNG", "SUN")——该算法已被主流合规标准弃用（如国密要求、PCI DSS），2023 年起禁止用于安全随机数生成
- ThreadLocalRandom 不解决安全问题——它只是为多线程优化 Random，仍属伪随机，不可用于密钥或令牌
- UUID.randomUUID() 是安全的——其内部基于 SecureRandom，但仅限 v4 版本；v1/v2 依赖时间戳+MAC 地址，不可用于敏感场景
