chrome 地址栏直接 @gemini

感觉目前深度学习和接水管很像，各种层就像各种型号的水管，各种上下采样就是转接头，大多数人能做的也就是照猫画虎排列组合，再放水看看能不能流通，目标出口的流量低了就顺着梯度往回找找直角锐角弯一弯。

用什么口径、放什么流量、每次校准弯多少完全是拍脑袋，基本等于牛顿三定律还没诞生前的物理时代。

@klamx 备案要实名，没找到国内注册商能实名.me

等等，这个.me 是怎么备案的，国内哪家能实名.me

不仅 15 ，还有备案号

每日经济
1 新能源车应定义为“智能载具”[ 2024 年 08 月 28 日 第 7239 期 ]
2 政策：新规明确市内免税店销售对象为 60 日出境旅客[ 2024 年 08 月 28 日 第 7239 期 ]
3 形势要点：舆论对我国民营企业的影响不容忽视[ 2024 年 08 月 28 日 第 7239 期 ]
4 形势要点：贸易保护是正常的，中国的产业也需要[ 2024 年 08 月 28 日 第 7239 期 ]
5 形势要点：供应量提升下蔬菜价格有所回落[ 2024 年 08 月 28 日 第 7239 期 ]
6 形势要点：深海风电“大跃进”面临成本挑战[ 2024 年 08 月 28 日 第 7239 期 ]
7 形势要点：中国需要更多货机但不一定从波音订购[ 2024 年 08 月 28 日 第 7239 期 ]
8 形势要点：氢能在低空经济中的应用前景初见端倪[ 2024 年 08 月 28 日 第 7239 期 ]
9 形势要点：极端气候增加或让沙漠洪水更常见[ 2024 年 08 月 28 日 第 7239 期 ]
10 形势要点：户外经济需要更多配套建设和资质管理[ 2024 年 08 月 28 日 第 7239 期 ]
11 形势要点：为何“职场倦怠”如此普遍？[ 2024 年 08 月 28 日 第 7239 期 ]
12 市场：光伏硅片或许仍未迎来“反转时刻”[ 2024 年 08 月 28 日 第 7239 期 ]
13 形势要点：印度对中国贸易逆差持续扩大[ 2024 年 08 月 28 日 第 7239 期 ]
14 形势要点：泰国和菲律宾正在“争夺”中国老人[ 2024 年 08 月 28 日 第 7239 期 ]
15 形势要点：船舶更替推动全球造船市场持续火热[ 2024 年 08 月 28 日 第 7239 期 ]
16 形势要点：英伟达合作商液冷技术加速突破值得关注[ 2024 年 08 月 28 日 第 7239 期 ]
17 形势要点：美国书店业的兴衰[ 2024 年 08 月 28 日 第 7239 期 ]
18 流量经济导致中国进入降维社会[ 2024 年 08 月 27 日 第 7238 期 ]
19 形势要点：李强总理强调银发经济要扩容提质[ 2024 年 08 月 27 日 第 7238 期 ]
20 形势要点：我国 7 月份规上工业企业利润增长有所加快[ 2024 年 08 月 27 日 第 7238 期 ]
21 形势要点：沙利文访华重点在中美关系“对表”[ 2024 年 08 月 27 日 第 7238 期 ]
22 形势要点：美国业界降低对华关税的要求有可能实现[ 2024 年 08 月 27 日 第 7238 期 ]
23 形势要点：前 7 个月非税收入逆势上涨引发营商环境担忧[ 2024 年 08 月 27 日 第 7238 期 ]
24 形势要点：从上海断网事件看中国经济、社会的脆弱性[ 2024 年 08 月 27 日 第 7238 期 ]
25 形势要点：外资软件企业在中国的困境[ 2024 年 08 月 27 日 第 7238 期 ]
26 形势要点：外媒称中国镓锗管制引发芯片产量担忧[ 2024 年 08 月 27 日 第 7238 期 ]
27 形势要点：这部分灵活就业人员有多少？这是答案[ 2024 年 08 月 27 日 第 7238 期 ]
28 形势要点：上海迪士尼客流量持续增加反映其不可替代性[ 2024 年 08 月 27 日 第 7238 期 ]
29 形势要点：产品质量堪忧导致我国邮轮游市场恢复缓慢[ 2024 年 08 月 27 日 第 7238 期 ]
30 形势要点：国内暑期游“下沉”趋势日益显著

请提取这个网页的右手边的标题与数字，输出{id, title}[]的 JSON 数组，注意后面的[ 2024 年 08 月 27 日 第 7238 期 ]也不需要

豆包：
[
{"id": "1", "title": "新能源车应定义为“智能载具”"},
{"id": "2", "title": "政策：新规明确市内免税店销售对象为 60 日出境旅客"},
{"id": "3", "title": "形势要点：舆论对我国民营企业的影响不容忽视"},
{"id": "4", "title": "形势要点：贸易保护是正常的，中国的产业也需要"},
{"id": "5", "title": "形势要点：供应量提升下蔬菜价格有所回落"},
{"id": "6", "title": "形势要点：深海风电“大跃进”面临成本挑战"},
{"id": "7", "title": "形势要点：中国需要更多货机但不一定从波音订购"},
{"id": "8", "title": "形势要点：氢能在低空经济中的应用前景初见端倪"},
{"id": "9", "title": "形势要点：极端气候增加或让沙漠洪水更常见"},
{"id": "10", "title": "形势要点：户外经济需要更多配套建设和资质管理"},
{"id": "11", "title": "形势要点：为何“职场倦怠”如此普遍？"},
{"id": "12", "title": "市场：光伏硅片或许仍未迎来“反转时刻”"},
{"id": "13", "title": "形势要点：印度对中国贸易逆差持续扩大"},
{"id": "14", "title": "形势要点：泰国和菲律宾正在“争夺”中国老人"},
{"id": "15", "title": "形势要点：船舶更替推动全球造船市场持续火热"},
{"id": "16", "title": "形势要点：英伟达合作商液冷技术加速突破值得关注"},
{"id": "17", "title": "形势要点：美国书店业的兴衰"},
{"id": "18", "title": "流量经济导致中国进入降维社会"},
{"id": "19", "title": "形势要点：李强总理强调银发经济要扩容提质"},
{"id": "20", "title": "形势要点：我国 7 月份规上工业企业利润增长有所加快"},
{"id": "21", "title": "形势要点：沙利文访华重点在中美关系“对表”"},
{"id": "22", "title": "形势要点：美国业界降低对华关税的要求有可能实现"},
{"id": "23", "title": "形势要点：前 7 个月非税收入逆势上涨引发营商环境担忧"},
{"id": "24", "title": "形势要点：从上海断网事件看中国经济、社会的脆弱性"},
{"id": "25", "title": "形势要点：外资软件企业在中国的困境"},
{"id": "26", "title": "形势要点：外媒称中国镓锗管制引发芯片产量担忧"},
{"id": "27", "title": "形势要点：这部分灵活就业人员有多少？这是答案"},
{"id": "28", "title": "形势要点：上海迪士尼客流量持续增加反映其不可替代性"},
{"id": "29", "title": "形势要点：产品质量堪忧导致我国邮轮游市场恢复缓慢"},
{"id": "30", "title": "形势要点：国内暑期游“下沉”趋势日益显著"}
]

如果双耳听力损失是对称的，建议 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 的开发成本；

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