看完 OP 的帖子，马上点了更新。数据都在……
应该是 OP 说的删 default 导致的。

不太想折腾包管理工具，一直是自己下安装包。

不用过户，大部分保险跟着车走。一部分保险是保车主的，续保的时候改成保驾驶员的险种就行了。
续保的问题，等你车子保险到期之后，让你父亲联系保险公司续保就行了，续保价格不会变动的。

至于其他回复提到的事故责任的问题，就全看你自己了。如果自用的家庭车不用考虑 #9 提到的运营车案例。

@Desdemor #23 ，感觉应该会和之前的 ECG 一样，在国内认证通过之后才会推送启用吧。

@xunandotme #20 ，心脏健康和 ECG 不是从 S6 开始就有了么😂，最新的是睡眠监测的呼吸暂停。

@Anshay #15 ，软件的使用体验不同。如果单纯只关注功能，手环就能满足几乎所有除社交外的所有功能，续航还比手表长。
如果关注使用体验的话手表就会强很多，各种的“生态接力”实现是手环没法办到的。
也就是需求只是运动记录 + 身体监测，手环就能全覆盖你的需求，如果想更进一步就可以选择手表。
有点类似于现阶段辅助编程中 Copilot 和 Cursor 的区别。

1. 运动就是硅胶表带，日常穿搭和睡眠还是针织表带舒服（补充：有一些人对硅胶表单过敏）
2. 如果你有外出跑步的需求，买蜂窝出门装备会轻很多。我现在出门户外跑就一个表+Airpods ，收发微信和支付（被扫）都没问题。如果没有我提到的这个需求，那就不用买蜂窝。
3. 充电问题，基本上一个小时充的电就足够日常使用了。每天运动完洗澡前摘掉，一直到入睡前再戴回来，这个时间段充的电足够（基本上 80%的电量一天使用下来没问题的）。

我就是普通的 S6 首发到用到现在了，使用量是每天佩戴时间 21 小时+，运动时间 128 分钟（向下箭头）。关闭了全天候显示这样能省很多电量。之前可以两天一充，现在电池健康不到 75%得每天一冲。
每天就是晚上运动完充到入睡前，其他时间段不充电的。偶尔有几天晚上跑 10 公里会断电，如果准备长时间跑步，最好是前一天晚上充到 100%。

如果对电量有焦虑的可以考虑 Ultra ，但是 Ultra 跑步的时候会会明显感觉手腕会有负重的感觉，所以如果不是特别电量焦虑的，不需要入 Ultra ，普通版就足够了。

如果做不到固定的开发工作流，确保每一个 MR 都会 review 通过后才会被合并。
那么 OP 你关注于“技术”部分的规范，确实会补充中领导的长远看法一样。

---
关于团队开发规范一般都是开发团队中互相理解认可，最终达成一致的规范。而不是一两个人拍脑袋确定下来的。
至于项目 A 使用，不代表项目 B 也适用。其实和团队 A 认可，不代表团队 B 也会认可一样的。

比如你的举例就很“技术”，并不是一个对于开发流程的规范，更像是 Lint 相关的规范（也就是 Coding Style ），那么确实并不一定适用所有项目。
---

比如你可能会觉得<问题 1>很不爽，但是可能项目开始时期 `script:setup` 并没有实现，所以当时只是使用了 `setup` 并没有使用 `script:setup`。
那么按照你<问题 4>的认定，你多半也不会认可在一个项目中同时出现选项式和组合式两种写法。那么比较合适的情况就是延续旧有的“开发规则”，继续使用 `setup` 开发而不是 `script:setup`，而不是全部重构成 `srcipt:setup`。

至于<问题 2>和<问题 3> 是出于一个中间地带，首先代码量少并不一定就是“好代码”，举个很极端的例子 `const result = condition1 ? condition2 ? 'A' : 'B' : condition3 ? 'C' : 'D';`
虽然示例和 OP 你表达的并不一样，我这样举例有一点抬杠的意味，但想表达的是 代码结构清晰，可以让所有人都可以快速理解的代码，才是真的“好代码”。
不知道你举例的 `useRequest` 是 [VueUse]( https://vueuse.org/core/useFetch/) 这种比较大众的工具类库提供的，还是自己内部实现的工具类库。

API 都声明在一个 `index.js` 文件中，我也觉得会是一个问题，但是可能开发团队已经习惯了直接使用 `import { xx } from '@api' 中引入对应的接口了。
可以贡献一个模块化拆分后 API 维护的 MR ，并且提供和原本一样的聚合后的 `@api/index.js`出口（`export * from './modulesA'`）。
这个 MR 就可以当成首次 review 的一个样例。

---

但是 OP 你得和你的领导确定好，你们想要制定的规范是什么，是开发流程的规范，还是编码风格的规范。
开发流程的规范当形成习惯之后是可以随团队一直延续、传承下去的，但是编码风格的规范会随着不同项目的主导人而不同的。

后面还会有二番战的 😆

@crocoBaby #50 ，我现在手里头的 15pro 周末出游会有电量焦虑。可能和 5G 有关？如果外出目的地有 wifi 的话，电量下的会比较慢。户外下电真的很快。

看了发布会，真的提不起兴趣……所以现在准备马上换的应该都是 13 以前的换个新吧。
对 AI 感兴趣的就算现在买了也用不了，而且今年想用还不能买国行版……不想刷 beta 版的，等到 AI 真的推送的时间节点 pro 和 promax 还不是随便买。

每天运动结束就快 22 点，洗完澡洗完衣服起码 22:30 ，稍微收拾一下或者刷刷视频和文章就第二天了。
有些时候累可能就会洗完澡晾了衣服 11 点多就直接睡了，但大部分时间都是 1 点左右的样子。

早上因为太远了，开车通勤都要将近一个小时，所以早八人出门必定要在 7:00 之前，那么起床时间就是 6:00 ~ 6:30 。
每天睡眠时间平均下来大概 5 小时，周末如果没事的话会睡超过 10 个小时。

----
长期熬夜确实会影响记忆力，特别是短期记忆。这个听说是无法挽回的。

因为使用引号 会有歧义，不清楚是"引用对话内容"，还是 "特殊含义词"。
很明显书名号并不会引发这样的歧义，比如说《赢麻了》这样的情况，可以很直觉的让人感觉到这是在强调、讽刺或者引用某一些人的对话，特别是在特定时空下的弹幕中。

另外就是 #8 说的，书名号这样的符号在弹幕中会更显眼，最后这种习惯逐渐转移到其他类型平台上。
至于为什么不用 「」或者『』，我觉得单纯就是输入不方便……甚至有一些人完全不知道如何打出来（相信在回帖中 OP 已经感觉到了）

和是不是小米没多大关系，客厅空调是美的，我每天回家自动打开，也没办法把全客厅打到 25 度。
具体是设置启动半小时内 17 度+强风，半小时后固定 23 度+80%风量，客厅边角基本上也还是 26/27 度的样子（全程循环扇配合搅动空气）。

卧室书房之类的房间就算是 1 匹的，没有循环扇配合都能很快降到设置的温度附近。

https://codesandbox.io/features
可以多人协同编辑代码，并且可以看到其他人的光标。

“无法充电。这是一个特定国家或地区的充电器。它与此 Apple Watch 不兼容。”
单纯从字面理解，应该是特供版的充电器不能给其他地区的 AW 充电。

S6 用到现在了，好像苹果的产品我一直没有体验到过快充……之前换了 15pro 也一直都是磁吸充电，快充头买了到现在就用了不到 10 次。
平时就是洗澡之前(大概 22:00 ~ 22:30 之间）放上去充，充到睡前（ 23:30 ~ 00:00 的样子）就拿下来戴上睡觉，完全注意过是不是充满了，基本上也能维持一天的用量。

运动完剩余电量大概剩下 25%左右？日常用几乎没跳出来过低电量提醒。现在还有 59%的电量（关闭了全天候显示）。
每天运动时间最少 100 分钟，watch 的运动趋势是 130 分钟/天（向下箭头），应该算是日常用的比较多了的吧。

用的贝尔金的三合一充电座(标的是 15w)，应该是和这个没关系吧？
原本的磁吸充电器我丢车里了，之前没有关全天候显示整个白天电量是足够的，偶尔晚上出去夜跑超过 60 分钟会出现跑着跑着没电的情况，所以之前通勤的时候会摘下来充电。

我们这边会在茶水间放一个全自动咖啡机，自己往里面加豆子就好。如果介意口味的话，就得自己下楼去咖啡吧买了。

如果不是不锈钢杯的铁味的话，就是咖啡变质了。咖啡液萃完如果不冷藏的话馊起来很快的……一般是建议 2 个小时内喝完来着？

@ggimonmyway #47 ，但是我说的就不是补偿的问题哇。单纯就是退货的问题，出库的时候会把订单号和你的设备号做绑定的。
并不是现在针对现在的优惠场景，而是一直都有这个策略。就是怕调包去退货，比如现在是说同一家店的两个订单那还好。
万一你在 JD 、PDD 都买了一份，然后把 PDD 的退给 JD 了呢。毕竟大家都知道 PDD 保真不保新，不做验证的话不就把风险转移给 JD 商家了么。