@LandCruiser 所以还是要回到 90 年代？你要不从工业革命开始说起吧，这样差距更大，好神奇，对 1 万亿 市场一点都感兴趣的企业

@LandCruiser 你这个颇有一旦国内厂家能做的，就不是高端技术的意思，很合理，毕竟长期日吹嘛，理解

插混、增程在中国都要 800 万辆，按均价算这是一个快 1 万亿级别的“低端技术”市场了，日企是一点都看不上啊
到底是做不到呢，还是不想做

@zpvip 某种意义上你说的没有错，比如你说要开个 15 年的车
但是如同自吸气发动+手动挡一样，20 年都不坏，还维护简单，但是几乎没人开了
大电池意味着电气化的支持，比如驻车监控等

@jayhuang0044 哟，byd 血汗工厂论的哥们你来了，顺便给你指引一下：

http://nuerburgring.de/ifo/nuerburgring/records?locale=en&srsltid=AfmBOoo0mcE6xOw8lmG8iSkSGvaJUEJ3u5simz9uObDw9XsTyxoalKJP

Super sports cars
Lap time Vehicle Driver Date
6:59.157 YANGWANG U9 Xtreme Moritz Kranz 22.08.2025 > video

YANGWANG U9 Xtreme 官方数据出来了，赶紧去喷纽北

视频： https://www.youtube.com/watch?v=pcPraRlmi8s

@zpvip 活在 90 年代的人，丰田的混动都快卖不出去了

也许有些冒犯，感觉你这才是很多没车的人的臆想：
真需求：
通勤：算是，但是也包含在你的低频场景里面
面子：在广东，我小区车库下一堆 bba ，没人多看一眼；说点自大的话，50w 以下的车，在我眼里都是家用车，什么 bba 的，还不如某个新势力小众车让我有点兴趣
喜欢车：也没几个真喜欢车的

你说的低频场景：
周末短途游玩：自己开车，想去哪去，中途随时改路线，荒山野岭也大胆走
下雨天：广东雨季一个月能下 20 的雨，想一下，拖家带口全身湿漉漉/大烈日的等车，并且是每天幼儿园接送
节假日回老家：回老家不是去一个地方，是去 N 个地方，并且计划不确定
产检、娃去医院：这更不用说了，在自家的车，产妇、小孩心理都不一样的

车，tmd 就是情绪价值，就很像大哥直播间送礼物，带来的身心愉悦
条件允许就买，控制在你年收入 1/3 ，开到废了就算收回成本了

在 v2 不买房都成了政治正确，完全忽略了当前租房的困境
大部分在一线城市，有过 3/5 段租房经历的朋友，都能找出 1/2 段很不爽的租房经历
这些事情，要是叠加上拖家带口，简直让人情绪爆炸

@ms20148 这是一个通知义务，可以有，也可以没有，法律没有约束力的

@ms20148 Apple 只是目前看没有删除，但是不会有协议承诺不会删除，这两者从法律上，差异性很大的

就是说 Apple 有一天，那怕删除了，也是合法的

为什么你老有一种错觉，这些公司有义务长期保留你的数据呢
我们还都是干程序员的，这些都是要成本的啊

比如说 iCloud 对于备份的协议：

如果您关闭设备上的 iCloud 云备份功能，或设备超过 180 天（约 6 个月）未连接到 iCloud 进行备份，Apple 保留删除该备份的权利。

我也有数据在小米云上，现在数据确实没有了，很可惜
你这官司不可能赢的，大公司法务上，都是有利于自己

但是，本来你也不可能要求一个商业公司，长期保存你的数据
除非类似 iCloud 付费的形式，那种情况肯定支持你维权

以前的网易博客、百度 hi 空间等等，都是说没就没，数据过期不候

知乎有一段时间崩的特别厉害，最后慢慢从 Python -> Go

@ZARRO 预发布环境就是要接近线上到这一步，和发布就一步之差了，甚至我们之前预发布，其实也是线上的一部分
所以，预发布反而就是需要完全的线上环境，否则就失去意义了

反而这折射出你们预发布滥用了
好的预发布，就是线上环境，通过路由等手段进行发布前真实流量校验，才达到降低风险的目的

我以前设计过一套方案，在线上环境下，慢慢灰度指定的服务，可以控制到百分比，甚至可以慢慢灰度一天

@LANB0 线上有视频，你自己去看吧，免费的

@LANB0 因为有视频啊，那条路看起来不是高速，但是感觉开了有 80-100 ，+酒后驾车，估计磕底盘了

@BRKA 被黑成翔的 byd ，无论保有量还是销售量，都真遥遥领先，还有几百万滴滴司机高强度驾驶，目前都比较少看到那种剧烈燃爆的情况（自燃肯定有）

@newtype0092 对，你说的合理，我的意思就是每个 user_id 有个 group_id ，不需要强行一样
hack 手段虽然取巧，长期看不适合，需要维护潜在规则（虽然难度不大，group id 从预定最大 user_id 起始开始就好了）

尽量避免 or
在 group_id 可控的情况下（假设数量不大），为每个用户设定默认 group_id （和 user_id 一样即可）
举个例子：

设定 user_id 范围 [0-2**40] 也就是用户最大数量：1099511627776
剩下的 64 - 40 = 24 ，group_id 范围 [2**40-2**64]

40/24 自己定义，前 40 bit 给 user_id ，后 24 bit 给 group_id
这样
WHERE user_id = ? OR group_id IN (用户所属群组以及所有下级群组的 ID 列表)
转化为：
WHERE group_id IN (用户所属群组以及所有下级群组的 ID 列表，user_id)

user_id 同时也是每个用户默认的 group_id