多打打 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 相关的重度组件。

@dogfeet 哦，后面有说到只是纯快照读的前提的话

大家都在说什么啊？是我搞错了吗？ rr 应该妥妥的有幻读的问题啊。

@zzhaolei 谢谢，说的正是这个讨论里的问题

账号：jackma
支持！

@bthulu 看起来就是写不依赖读，或者说写需要的读状态可以是旧数据（只需完整，无需最新）。那么单纯的将 Device 变为不可变就行。ConcurrentDictionary 单纯的读写本身是原子的，查了一下，不可变的线程安全 C# 与 Java 是一致的。

如果更新的时候不看原来的数据，且 [多个监控线程每隔 100 毫秒读取一次所有设备状态, 并根据设备状态执行一次或多次耗时较长的异步操作] 这个过程中数据变化了也没关系的话，可以考虑直接将 Device 变为不可变（所有字段都 readonly)。

C# 不是特别熟了，devices 本身读写是线程安全的，里面的 device 只要每次更新的时候是替换一个新的不可变对象，这在 java 中是线程安全的。

几十个字段的拷贝，应该也还好。

求推荐一些 flutter 开发的较重型的 app 体验下。

接触过的几个链上项目都是这么做的，生态，可控度都不错，主要是用户切换成本低，和 tg 共享生态也即意味着和其他链项目共享用户生态。

区块链惯用方案不应该是：telegram 客户端改，群组聊天全部走 tg ，定制客户端增加钱包，社群，资源等相关页面即可啊。

Kotlin + Spring Boot

前面有人说 PHP 一个接口光写十分钟吧

自己平时做的 CRUD 接口，一个系列增删改查一般总共十分钟不到吧。
Flyway 定义数据库表结构
定义参数结构，通过注解做参数校验（一堆 PHP 不做这个事，有但是不多）
定义个
写 Controler ，写 Service ，MyBatis Plus 一把梭。
对了，带上 Spring Doc 注解，完事后，直接生成文档页面，还可以文档页面直接测试接口。

中间会有些手误啥的错误，强大的类型，包括 MP 都是泛型关联数据库字段，大部分错误编译期就能看的非常清楚。
参考老代码也是一目了然，类型是最权威的注释，也是最权威的代码脉络总纲。

带上测试，15-30 分钟差不多全部搞完吧。

PHP 搞数据库，绝大部分字符串拼接一把梭，搞出问题来了在哪里 Debug 个半天，看着让人想笑，一堆说自己快的人搞出有注入风险的代码。

有些搞法所谓的快，是不是真的比人快先不说，出来的东西，我是懒得维护的，后期找起来就是天书。

对了，后面部分接口想做改造，加个缓存，加个读写分离啥的，你们猜要多久，要改动多少？

Kotlin 语法既强大，又简洁，还简单。建议去试试。

一般按分成合作的渠道方，会要求产品方接入指定的支付通道，也就是所有的流水是先进入到渠道方户，然后按期按比例结算给产品方。这样的话，充值数据双方都是很清晰的。
至于切支付这种骚操作，各家反正都有防。App Store Google Play 这种就是审核+下架+封账号教做人。至于国内的小米华为这种啥的，和前面 2 种有本质区别，这种渠道都是严格的指定量，上这种渠道很不划算，即使有自然量也是产品方的品牌效应。我的理解就是，上这种渠道一般都是因为渠道会保证提供一定的量。如果被发现后期切支付，渠道方只需终止合作不再提供量就行了。
重点产品合作方一般都会定期复查一下的。
个人认为，有流量合作的，不要切支付，坏口碑，以后难找合作。
Google Play App Store 这种，切支付必然夹带马甲包，操作成本也很高，省下来的 28% 左右的利润能否支撑这个操作成本需要自己衡量。
以上有一个例外，就是国内付费游戏，又无版号，这种如果非要违法上，只能切了。