@fc191230 大佬咋解决的。。我也被困在其中无法解脱。
感觉确实是软件 bug 啊。。

登录成功只有个 more 用户。。用户选择里面也不能选我的账户，删除 more 也没反应。。

@leonshaw
1. 周期在内部的，可以考虑 move 出来，很少有不能 move 的吧。。
2. 方向反了。。是异步线程 resume 协程，不会影响线程管理，实际上整个执行流程和你写回调地狱是一致的。。

感觉这套逻辑比较抽象，有点难解释，但是能够最大限度保证无依赖无损接入协程

上面文案有误 '在一个线程中开始启动协程' -> '在当前线程中开始启动协程'，才会造成上面的误解

@ysc3839 并没有引入额外线程。。那个 test 里面有 async 做实验的。线程是靠原有的异步框架管理的

大佬 加我 a2toYWlrZQ==

@CrazyCoolL 这是什么输入法。我装了 gboard 没找到 17 键

@bao3 我也用自带双拼，但是感觉误触很多，经常重打浪费了很多时间。如果有替代的能够纠错的输入法就好了

有科普教程么。

你说的“分流”应该就是 extern inline 关键字组合的意义。。
相关参考 https://blog.csdn.net/force_eagle/article/details/11106571

我觉得 c++ 面试，系统网络的问题比较多 https://feisky.gitbooks.io/sdn/content/

至少 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