fuzzsh

@fuzzsh 13800138000 例子是简单描述，生活中是先匹配第一位，确定是手机还是固话还是特服，在转发到对应的机构/通讯公司

想必 OP 看过历史战争的美剧，有拍摄过接线生的工作场景（其他剧可能也有出现，但本人见识浅薄）
电话近代化才出现程控式的交换，而且调度规则也很简单，沿用至今，只匹配前缀，例如 13800138000 ，匹配到 138 转发去中国移动总公司网关，总公司将 0013 转到当地分公司的网关，分公司网关的数据库才是记录最终用户的信息。
OP 提到新号码才实施，问题是旧号码怎么拨通？用户量上来后再迭代也要兼容老用户的，而且这个电话号码还是 primary key ，类比开发的时候，迭代会将 primary key 改来改去？除非是重建互不兼容的标准，IPv4/IPv6 就是例子


加了 checksum 还是有打错电话的，是不是还要加多 1 位去校验前 1 位 checksum （滑稽

https://nextjs.org/docs/app/building-your-application/caching
你看下缓存机制就懂了

不动代码也可以在 nginx 去掉这个 cache-control ，不让 client-side 缓存

正常了。锅内的 UI 都很激进，用魔法打魔法，不是白名单统统砍死。还给你其它的 WiFi 的 DNS 加东西，强行追加其它公共 DNS 的地址
用过 OV ，开了无障碍每隔一段时间都给你关掉，在手动去打开又会关，为了体验转买水货三星，不贪便宜了

https://nextjs.org/docs/app/api-reference/config/next-config-js/headers#cache-control

为什么不觉得是 Nextjs 问题🐕

前端不是 SSR 结构直接 build 出来 html 多省事，多跑个服务徒增卸锅难度

手快发布了

以往 CentOS [8-] 是重新打包 RHEL [8-]去除商业代码，改成 stream [8+] 后就反过来了，开发进入 stream [8+] 在进入 RHE[8+]

@julyclyde stream 和 fedora 一样，都是 RHEL 的 upstream 了，在 fedora 开发完就进入 stream ，stream 没问题就进入 RHEL