至少 299

楼上说的"接口不保留状态"基本就能概括了
无状态基本是微服务的必备条件，因为负责均衡的关系，
一个业务的多个请求，是分布在不同节点上完成的，
如果有状态的话，只能在同一节点上完成

88 已经很高了，被子对会湿，要开抽湿

被裁员拿 N+1 不都是每个员工的心愿吗。。

@CEBBCAT 上面忘了 at 。。。不好意思

另外真随机是完全无规律的随机，所以只适合用作密码学相关以及设置伪随机的种子，在业务场景下，希望获得 均匀分布、正态分布 等特性的随机数需要对应的伪随机配合，所以 业务场景 真随机种子 + 伪随机算法 就是最优解没有之一

我说的是 真随机 的获取非常慢，因为涉及到操作系统要主动将熵值填入熵池，这个是很缓慢的。

golang 的 crypt/rand 在某些系统下并不是纯正的真随机（纯真随机应该类似于 /dev/random 一样会在熵池被掏空时阻塞），golang 在不同的操作系统下的实现
// On Linux, FreeBSD, Dragonfly and Solaris, Reader uses getrandom(2) if
// available, /dev/urandom otherwise.
// On OpenBSD and macOS, Reader uses getentropy(2).
// On other Unix-like systems, Reader reads from /dev/urandom.
// On Windows systems, Reader uses the RtlGenRandom API.

1. getrandom(flags==0), 相当于 /dev/random ，https://github.com/torvalds/linux/blob/d9fc1511728c15df49ff18e49a494d00f78b7cd4/drivers/char/random.c#L1343-L1350 ，默认会阻塞等待熵值
2. getentropy ，https://support.apple.com/zh-cn/guide/security/seca0c73a75b/web ， 使用 Fortuna 算法，安全度很高的伪随机并使用熵源初始化，无阻塞
3. RtlGenRandom ，https://learn.microsoft.com/en-us/windows/win32/api/ntsecapi/nf-ntsecapi-rtlgenrandom ， 文档上就说是伪随机
4. /dev/urandom ，不会阻塞，会在熵值耗尽使用 crng_fast_key_erasure 获得伪随机结果（ chacha 加密结果的一部分） https://github.com/torvalds/linux/blob/d9fc1511728c15df49ff18e49a494d00f78b7cd4/drivers/char/random.c#L336-L341

这是对的。SecureRandom 应该是使用系统熵的真随机。使用这个作为伪随机的种子能够做到更好的效果。
因为在分布式 /多实例场景下，使用时间作为种子也很容易得到初冲突。

c++11 后也是这样的，参考 https://learn.microsoft.com/zh-tw/cpp/standard-library/random?view=msvc-170 最后一个实例
go 也有使用 crypto/rand 设置 math/rand 种子的用法

主要原因是真随机的获取非常慢。不适合在业务场景下使用。这种方式能够兼得随机性与速度的最好效果（甚至可以在多线程场景下分线程创建以避免锁开支）

黑客就喜欢你这样的开发

难道第一映像不是 比特派 5k 怎么弄到的吗

格式化完别动，然后用 diskgenius 恢复

我记错了是，1200 一个人

YTIwMTYwNjMz 这个是我之前找过的

淘宝好像 2000 一个人吧

建议干死这个产品
或者增加必备资料的导入 /导出