如果双耳听力损失是对称的，建议 airpods pro ，便宜好用不尴尬。

b 站有如何将 airpods pro 设置为助听器的教程。

IPv6 由前缀和后缀组成。

设备获得 IPv6 地址有三种方式：
1. 在设备上手动设置
2. 路由器周期广播包含前缀的路由通告，设备收到通告后，自己搞个后缀拼上（ SLAAC ）
3. 设备主动请求路由器要一个地址（ DHCPv6 ）

显然，根据设备不同的获取 IPv6 地址的方式，路由器的控制能力各不相同：
1. 路由器不能控制设备地址的全部：既不能控制前缀，也不能控制后缀
2. 路由器能控制设备地址的一部分：只能控制前缀，不能控制后缀
3. 路由器能控制设备地址的全部：既能控制前缀，也能控制后缀

Windows 系统默认同时启用了 SLAAC 和 DHCPv6 ，在存在路由器 RA 通告和 DHCPv6 服务器的环境中，能拿到两个 IPv6 地址。
但也有 Android 系统只支持 SLAAC ，无视 DHCPv6 ，对于这种设备，指定 DHCPv6 没用。

这个价位进小米之家随便挑个好看的，感觉都应该不会卡

闲鱼：主食爱吃囊

寄了只进过水的耳机过去，老板检查后说没问题，一分钱没要给我发回来了，给我搞不好意思了。

qr pn da zi vf de bi yu yn ky ma?

token 要跨链，一定是在源链上锁定或销毁 token ，再在另一条链上发行或铸造原 token 的替身。

比如 1 个原生比特币要跨到以太坊链， 我就可以在原先那条链上把币转入一个没人知道私钥的地址，比如全零地址。
然后在以太坊链上凭空制造一个叫做 WBTC 的 token ，并备注上刚才那笔交易的哈希。
这样，任何人都可以自行查看两条链，验证这对交易存在、有效、且数量相等。

很明显，在整个过程中，没有任何东西从一条链上转换到了另一条链上，比特币原生链上的 BTC 和以太坊链上的 WBTC 从技术视角看是完全不同的。

只是我们使用的时候把它们当成一样的：因为在同一时间，这个比特币只能要么以 BTC 的形式在原生比特币链上流通，要么以 WBTC 的形式在以太坊链上流通。

在这整个“转换”过程中，最关键的不是技术，而是共识。
WBTC 之所以能当 BTC 用，是因为我们相信这两种 token 都只是比特币这个概念的不同表现形式。

Copilot 擅长将非结构数据转换为结构数据。

直接注释接口文档里的描述，稍微起个头就能快速定义 TypeScript 类型和枚举。

没必要，微服务的架构本质来自组织架构。

纠结就买 iPhone ，因为安卓不好用时一定会后悔没买 iPhone ，iPhone 不好用时会自适应。

粘出来格式不好看，原文来自： https://zexi.notion.site/b9f941b097054bb1a28de1de61535adf

我看之前楼层都在情绪输出，我来说说我的思考吧。



两个前提：
1. 老板只在意业务功能是否实现，没人在意前后端之间的接口质量；
2. 督促后端交付高质量接口的沟通成本远大于前端写几行 map 的开发成本；

故结论，前端兼容。



问题是，对于前端的某一字段，不同的后端提交、响应不同，甚至值的类型也不同。
导致在写 TypeScript 时，就要定义大量 TS 类型，还很难起名。
但仔细想想我们真的需要这些“一次性”类型吗？



看个例子，假设我们有两个接口：

```JavaScript
// id 查 user
const res = fetch.get('/user', { id: 1 })
console.log(res.body) // { id: 1, name: 'alice' }

// id 改 user 名
const res = fetch.post('/user', { user_id: '1', new_username: '' })
console.log(res.body) // { code: 1 }
```

很难受吧，查和改的字段居然不一致。
那我用户 ID 究竟叫 id 还是 user_id ？类型究竟是 number 还是 string ？

很简单，按前端方便来：

```
type User = {
userId: string,
username: string
}

<div>
<div>用户 ID：{{userId}}</div>
<div>用户名：<input type="text" value="{{username}}" /></div>
</div>
```



？？？



因为 JavaScript 里常用驼峰命名，userId 通常也只是展示，不会涉及什么数值运算，绑定 input 之类也比较方便…

噢，哈哈，你肯定早就知道这些，我知道你是在疑惑，接口怎么办？

别急。



我们知道，TypeScript 类型系统很好很强，除非 any 泛滥。
要想抑制 any 渗入 TS ，就要观察 any 从哪产生：

什么函数返回 any ？

- JSON.parse()
- fetch()
- ...

喔，外部数据流入 TS 时，就是 any ，有才有德的我知道，此时我应该立刻手动为标记类型：

```JavaScript
// 接口响应类型
type GetUser = { id: number, name: string }

// 前端易用类型
type User = { userId: string, username: string }

function fetchUser(userId: string) {
// 外部数据
const res = fetch.get('/user', { id: Number(userId) })
console.log(res.body) // { id: 1, name: 'alice' }

// 标记类型 any -> GetUser
const data: GetUser = res.body

// 转为前端易用的格式
const user: User = {
userId: String(data.id ?? ''),
username: data.name
}
return user
}
```

很好很完美，我们成功封装了一个接口请求函数，它能通过 string 的 userId ，查到 User 数据，以前端想要的格式。

但多看一眼，我们真的有必要定义 GetUser 吗？

简化下可以吗：

```JavaScript
type User = { userId: string, username: string }

function fetchUser(userId: string): User {
const res = fetch.get('/user', { id: Number(userId) })
return {
userId: String(res.body.id ?? ''),
username: res.body.name
}
}
```

噢，虽然 res.body 是 any ，虽然按照 TypeScript 最佳实践我应该马上声明它的类型，但事实上，完全可以将这个明晰 any 的过程延迟到数据转换一并进行。

这样一切就变得简单多了，只要我守好数据流入和流出的关口，那无论多离谱的后端，我都不需撕逼，分钟对接：

```JavaScript
function updateUser(userId: string, username: string): boolean {
const res = fetch.post('/user', {
user_id: Number(userId),
new_username: username
})
return res.code === 1
}
```


于是作为前端：
在开发阶段，我以最舒适的姿势定义 State 的数据结构、绑定 UI 组件。
在联调阶段，我直接对着浏览器抓包的响应体，实现关口函数内的转换。
完全摆脱各接口字段定义不一致、实际响应和接口文档不符、string 和 number 类型没对上之类来回沟通筋疲力尽的鸡零狗碎。



再温故一遍：
1. 老板只在意业务功能是否实现，没人在意前后端之间的接口质量；
2. 督促后端交付高质量接口的沟通成本远大于前端写几行 map 的开发成本；

在公司开发流程中，开各种评审会议、写各种留痕文档、读历史屎山、和测试来回拉锯的工时最多，编码的占比非常之小。

哦不好意思没注意，原来是在对比计算机运行的效率，不是人算出结果的效率

Excel-数据分析-回归

https://www.youtube.com/watch?v=EUR7RE18VDY

@yfugibr 自动扩容是在 append 时原容量不够才发生的，new 时候给定大小，然后直接用下标设置就不会触发扩容。

想太远了，这才大三上，考虑考研考公就业那都是明天春天后的事。

---

**“我也意识到了，但我不知道该怎么改变。”**

先从每天运动开始。

人在成年后，只有健身是一分努力一分收获。

健身的反馈周期也比较合适，叠上新手福利期，最多一两周就能看到配速变快了、心率变低了、肌肉变强了，这些都是结结实实的正反馈。

**你必须首先做成一件事，才能获得自己有能力做成事的信心。**

躺在宿舍床上畏畏缩缩瞻前顾后？

起来。
训练。

你只是基因驾驶的蛋白质机甲。

基因主人为你这套智能机甲设计了两个任务：

1. 摄入能量，维持自己稳定运行；
2. 在自己损坏之前，制造出新的机甲。

@BBCCBB 确实，你一说我才发现，第一句话实际是在预先合理化自己之后的行为。
b 站有个“戒社”，经常读一些赌狗私信，OP 文章的第一句话，和那些私信第一句好像。

想起来之前看过的一句话：

大多数时候我们以为自己在思考，其实都是在对自身的行为和欲望进行合理化，这正是人类被称作“自我解释的动物”的原因。