dogfeet

对于我们这种游戏业务，只允许单客户端登录的，有很重要的意义。

1. rt 的存在，就是为了减少核心认证数据的传输频率（比如账号密码，手机验证码等）
2. rt 会持久化，at 的校验成本更低，往往会存在内存中直接校验。
3. rt 无法用来登录，只能用来刷新 at ，重点是一个账户只有唯一的一个有效 rt ，每次刷新都需要当前正确的 rt ，刷新后 rt 会变，之前的 rt 就失效了。如果所谓的 rt 被抓包拿了，除非只有你一个人用，否则，用户刷新失败触发账号密码或验证码登录，此时刷新的 rt 会覆盖掉抓包拿的 rt 。也就是游戏中的发现自己被挤下来后，自己用最高优先级的账号密码登录，对方就无法再登录了。

重点：
rt 只能使用一次，这是与账户密码最大的不同点。
rt 只能使用一次，这也是与 at 最大的不同点，成本较 at 高。

总结：
正常用户的使用过程中，几乎很少触发账户密码验证码登录，体验更好。
非正常使用过程中，也能一定程度的保证安全。
减少账户密码的传输频率也能降低其被窃取的风险。

多打打 wa3 ，星际，就好按了。

@dogfeet 我一般还是用 glibc ，但是不用 native-tls(openssl)。虽然很多人说 musl 性能较 musl 差，但其实我并不在乎这个，只是没觉得 glibc 问题有那么严重。毕竟这玩意和内核关系紧密，不像 openssl 。
在加上 zigbuild 能很方便的指定 glibc 的版本，没觉得这个有啥麻烦的地方。所以继续 glibc

@bli22ard 是的，想要不依赖 glibc 就用 musl ，想要不依赖 openssl ，就是用 rustls 。
至于要方便的交叉编译，直接使用 cargo zigbuild 就行。

大致就是这么简单。

对了，刚忘说了，我是直接在 windows 上交叉编译 linux 的。安装下 ziglang 和 zigbuild 就行了。
没觉得比 Golang 麻烦在哪里。

我都是：

不使用 native-tls ，专用 rustls
使用 cargo zigbuild ，还可以指定 glibc 版本，挺无脑的，没你说的那么费劲。

不是，这测的有啥问题吗？

要测 100 万异步并发任务内存占用，可不就是构造个 100 万异步任务同时运行的场景吗？
你可以说知道 100 万异步并发任务内存的占用了的指导意义有限，但你不能说用 `sleep` 去构造这个场景有问题吧。

看的头疼，感觉没那么难理解啊。

还有就是，虚拟线程也是 `stackful` 的，咋就不公平了呢？

怎么没人替 java 喊喊冤啊。

个人不太喜欢裸 sql 的方式，因为喜欢改字段名，再就是参数类型 时间字符串数值要不停的记住。裸 sql 对测试代码的覆盖率的要求更高。

vue 的后台管理系统，可以试试 nuxt ui [https://dashboard-template.nuxt.dev/]，pro 版本中很多 Dashboard 相关的重度组件。