@ZZITE #3 感觉降噪和上一代 pro 差不多，但是佩戴舒适感比 pro 好太多，也更不容易掉。音质对比上一代 airpods 也有提升，目前体验很不错。

快递刚到驿站 中午回家取了体验一下

不考虑下 tailwind 的 addUtilities 吗，自己注册一些常用的样式组合
addUtilities({
.flex-h-center {
'display': 'flex',
'flex-direction': 'row',
'align-items': 'center'
}
})

@zlg881215 #13 有没有推荐的景点或者美食，国庆有打算去贵阳玩一玩~

目前做的 3D 编辑器项目。有线下会议需要到现场是经常需要到公司开会？那人不在深圳可能就不太合适了吧。

最近伤好了，发现小拇指中间第二关节无法独立弯曲（就是无名指、中指、食指都伸直情况下）。

我试了下第二关节也无法独立弯曲。。第一关节弯曲都容易带着无名指一起弯。。

@june4 #3 嗯嗯，这里 Elements[T]如你所说，通过 T extends 'div' | 'a' 是可以推断出具体类型结构的，但在 Omit 后返回了一个新类型，这个新类型是抽象的，就是我说的泛型参数，这里是无法推断出 id 一定存在于新类型的类型结构里的。

我觉得应该在保持第一种写法的情况下，在 getProps 传参这里使用断言处理，即 getProps(props, ["id"] as (keyof Omit<Elements[T], 'x'>)[])；

和 Omit 无关，两种情况的区别在于第一种 Omit<Elements[T], 'x'>的结果是泛型参数，这里 TS 是不会做出“ ‘id’一定存在于这个泛型中”的这种推断的，它无法确定具体的类型结构。这里的报错具体来说其实是“ “id' is not assignable to type 'Exclude<keyof Elements[T], "x">'”。但我们知道"id"是有效的 key😂，所以在传入“id”的时候对它做个类型断言。

至于第二种写法，Omit<Elements['div' | 'a']是一个具体的联合类型，ts 是可以确定整个类型结构的，也可以推断出"id"是一个符合联合类型结果的有效 key

你是前端的话，Three.js 、Babylon.js 二选一基本是绕不开。建模那是需要有专门的建模师用 Blender 来做，复杂的模型是做好了直接放进来的，你的部分是搭建呈现最终的场景

去小红书搜索，厦门的攻略太多了

没懂，看了下文档不是本身就支持你的需求吗
https://element-plus.org/zh-CN/component/select.html#%E8%87%AA%E5%AE%9A%E4%B9%89%E4%B8%8B%E6%8B%89%E8%8F%9C%E5%8D%95%E7%9A%84%E5%BA%95%E9%83%A8

textarea {
display: block;
}

感觉设计的蛮不错的

```
const ROOM_TYPE_KEYS = ["OR", "PACU"] as const;

type RoomTypeMap = {
[key in (typeof ROOM_TYPE_KEYS)[number]]: {
label: string;
value: number;
color?: string;
};
};

export const ROOM_TYPE_MAP: RoomTypeMap = {
OR: {
label: "手术间",
value: 1,
},
PACU: {
label: "复苏室",
value: 2,
},
};
```

我一般会这么写

工作中带薪学习我相信每个程序员或多或少都有过的，遇到新东西现学现用很正常，但 OP 的案例显然不属于这一类，如果“github docker 这些都需要学习的这种”那我觉得是工作能力不达标的。你可以说下了班不想和工作扯上关系，工作上看成果，你只要能完成任务谁会在意你在哪学习呢。但如果没有成果，上班就是学习来的，那我觉得确实太学生心态了
至于行业，用人市场什么的跟这些都没关系。当然 OP 不差钱，其实也不用想太多，等着被开就行了，公司/招聘人也要为面试失误买单

@EvanQu #15 扫地机哪一款 太难选了