@xd199153 这个是不行的，只能限定 T 的上界是 a|b
比如 type a = {a: 1}; type b = { b: 1 }
如果 <T extends a|b>
那 { a: 1, b: 1, c: 1 } 是一个合法的 T

我遇到一个问题，ant design mobile 需要用一个 ref，但是 react useref 和 forwardref 的类型怎么都写不对，给的提示信息又是天书，最后实在是烦躁加了个 //ts-ignore，跑起来完全没问题。。如果是完全追求类型安全就很抓狂了
还有就是泛型函数好像没办法限制 T 是两个类型中的一个，多次尝试后写了两个完全一样但是类型不同的函数。。

用的主题还没适配，我先等等
搞不懂为什么升版本会导致主题不兼容

我 leader 是空格
shift 只用左手边的
surround 操作的括号和花括号用 b 和 B 代替
几乎不用寄存器。。
键盘是静电容
整体感觉还行，不会有特别累的

@toaruScar 是去索尼线下维修店和售后小程序里的店送修的吗

理论上是标明 unmodifiable list 比较好
但自从函数式思想传播开后，其实现在也很少会对 list 做增删改，都是用 stream 生成新的 list
所以就偷懒写 list 了
当然更好的方法是换一种对类型推导支持更加完善的语言，比如 kotlin

@hushao 去年 5 月买的，已经过保了

@Microi 飞利浦我也坏过两个，都是进水坏的，后来再也没买过了

老用户不如狗系列。。

主要是 go 写并发程序的心智负担小，且 go 编译后为机器码
听说 loom 的目标也是类似这种，再加上 graalvm 的 aot 编译，以后应该会差不太多
不过离正式支持 loom 的 lts 版本 jdk 估计还得等个几年。。

可能拥塞控制和可靠性的实现太长了背不下来吧

@huyujievip 平时 crud 几乎没写过 for，都是 stream，除了一些要提前 return 的地方
刚开始的话多写就习惯了

stream api 用的比较习惯的话应该还行吧
kotlin 标准库里各种工具函数和 5 个作用域方法真的挺爽的

@A388 vue 不清楚，react 就是很多大项目啊，比如网页端 office，figma 啥的
装了 react dev tool 之后我才发现国外真是随便一个网站都是 react 。。

go 写业务会用到 goroutine 吗
如果不用的话实在想不到用 go 有什么优势

有些人是不是没有基本的交流或者表达能力啊？
很难想象这是现代智人的行为
另外有点好奇这种交流模式会出现在中国以外的情侣间吗？