中国电信澳门通过iPhone自助转eSIM的千万不要去公众号换发eSIM。
原因是直接走sim to eSIM和快速转移的用户首次从实体卡转成eSIM的时候被分配了一个不知名邮箱，后续换发eSIM都会发到那个邮箱里。
建议换发eSIM前先尝试一下邮箱登录看看邮箱到底是不是自己的以免换发完才发现收不到eSIM二维码邮件。
via: https://forum.naixi.net/thread-15613-1-1.html
原因是直接走sim to eSIM和快速转移的用户首次从实体卡转成eSIM的时候被分配了一个不知名邮箱，后续换发eSIM都会发到那个邮箱里。
建议换发eSIM前先尝试一下邮箱登录看看邮箱到底是不是自己的以免换发完才发现收不到eSIM二维码邮件。
via: https://forum.naixi.net/thread-15613-1-1.html
❤17✍1
我眼中的 codex 重置
先说一个暴论：codex 重置从来都不算是福利和补偿，更像是一种低成本的营销策略。
codex 经常性发放的「额度重置」，不管是全体订阅的硬重置，还是用户自行应用的手动重置，都是额度回满后重新等 7 天，原定刷新日推倒重新计算。乍看额度回满了，其实代价是刷新时间也被重置了。
codex 不定期给用户重置额度，看着是好事，不过刷新时间也会跟着重新算。比如原本 9 月 7 日恢复，9 月 4 日官方给重置了，下一次就变成 9 月 11 日。7 号不会再刷一次。
已经把额度用光的人确实赚到了，没怎么用的人就有点尴尬：可能只补回来一点额度，本来再等 3 天就能刷新，现在又得等 7 天。
以为是额外送一次周限，实际上是提前结束这周，直接开下一周。
补满的时候挺开心，回头一看日期，怎么还往后挪了😂
准确说，甚至所有用量低于平均值的用户「遭受」重置都是亏的，乃至于很多人的用量计划全被打乱。
以至于我们看到一个现象：
有确定日期的重置
所有博主、各个论坛都会开始警报「猛蹬」——意思是抓紧时间在重置前把额度用完。
以为自己赚了，其实那些额度对大部分人来说压根没起到什么作用，不过就是为了猛蹬而猛蹬，白白燃烧 token 而已。
对于突然发放的、没有确定日期的重置
选择在原本自然刷新前就把额度用光的人获利。
乖乖按计划使用的人没有获利（额度回了一点，但是刷新时间也延后了）。
而选择在周限后半段再使用的人，额度没有回多少，周限却实打实从 7 天重新开始计算。
对于手动重置卡
如果是按计划使用，那么就会在接近自然重置的时候才把额度用光，这时候使用重置卡还是等自然重置？
那么显而易见，肯定是越快蹬完越好啊，这样离自然刷新还远着，用了重置卡损失的时间也越少。
但是这样就养成了不良的使用习惯，在没有重置的时候，就要干等着自然重置，或是购买更高用量的订阅。
所以对于庄家来说，给全部人重置，其实根本没有太大的成本，尤其是连续的重置、接近自然周限的重置——本来就马上要重置了，却看上去是发福利一样。
相比之下，其他 AI 的重置大部分都是不改变自然重置周期的情况下直接把额度回满，我个人认为，那才叫真正的 reset。
先说一个暴论：codex 重置从来都不算是福利和补偿，更像是一种低成本的营销策略。
codex 经常性发放的「额度重置」，不管是全体订阅的硬重置，还是用户自行应用的手动重置，都是额度回满后重新等 7 天，原定刷新日推倒重新计算。乍看额度回满了，其实代价是刷新时间也被重置了。
codex 不定期给用户重置额度，看着是好事，不过刷新时间也会跟着重新算。比如原本 9 月 7 日恢复，9 月 4 日官方给重置了，下一次就变成 9 月 11 日。7 号不会再刷一次。
已经把额度用光的人确实赚到了，没怎么用的人就有点尴尬：可能只补回来一点额度，本来再等 3 天就能刷新，现在又得等 7 天。
以为是额外送一次周限，实际上是提前结束这周，直接开下一周。
补满的时候挺开心，回头一看日期，怎么还往后挪了😂
准确说，甚至所有用量低于平均值的用户「遭受」重置都是亏的，乃至于很多人的用量计划全被打乱。
以至于我们看到一个现象：
有确定日期的重置
所有博主、各个论坛都会开始警报「猛蹬」——意思是抓紧时间在重置前把额度用完。
以为自己赚了，其实那些额度对大部分人来说压根没起到什么作用，不过就是为了猛蹬而猛蹬，白白燃烧 token 而已。
对于突然发放的、没有确定日期的重置
选择在原本自然刷新前就把额度用光的人获利。
乖乖按计划使用的人没有获利（额度回了一点，但是刷新时间也延后了）。
而选择在周限后半段再使用的人，额度没有回多少，周限却实打实从 7 天重新开始计算。
对于手动重置卡
如果是按计划使用，那么就会在接近自然重置的时候才把额度用光，这时候使用重置卡还是等自然重置？
那么显而易见，肯定是越快蹬完越好啊，这样离自然刷新还远着，用了重置卡损失的时间也越少。
但是这样就养成了不良的使用习惯，在没有重置的时候，就要干等着自然重置，或是购买更高用量的订阅。
所以对于庄家来说，给全部人重置，其实根本没有太大的成本，尤其是连续的重置、接近自然周限的重置——本来就马上要重置了，却看上去是发福利一样。
相比之下，其他 AI 的重置大部分都是不改变自然重置周期的情况下直接把额度回满，我个人认为，那才叫真正的 reset。
👏20🤔7❤2✍2
HyperOS 还是太抽象了。
最近发现 ChatGPT 点「使用 Google 登录」一直转圈，账号列表死活不出来，用邮箱登录也是一样，压根进不去登录流程。
抓日志才发现，Google 已经返回候选凭据，卡死的是小米自己的凭据选择器 MiuiCredentialManager 4.0.4.1：
系统给它发了一个约 557 KiB 的启动事务，直接报
整个过程：
5 个谷歌账号就把小米自己搓的 Credential Manager 干死了，退出几个谷歌账号后问题（临时）解决。
这玩意是小米自己搞的，把所有 passkey 事件都拦截了。
passkey 设成 1Password 也绕不开，它和这个系统选择弹窗是两回事，用过的都知道，就算是第三方 passkey，也是走的系统弹窗。
后台弹窗启动失败，前台连句报错都没有，就让你一直等。 不抓日志，还以为是自己的网络或者账号有问题😅。
目前只确认本机复现，不代表所有人都中招。如果 GPT 登录直接连谷歌账号都显示不出来并且手机上登录了超过5个Google账号，大概率是小米自己的 Credential Manager 的锅，解决方法就是退出Google账号至5个以下。
最近发现 ChatGPT 点「使用 Google 登录」一直转圈，账号列表死活不出来，用邮箱登录也是一样，压根进不去登录流程。
抓日志才发现，Google 已经返回候选凭据，卡死的是小米自己的凭据选择器 MiuiCredentialManager 4.0.4.1：
com.android.credentialmanager/.CredentialSelectorActivity系统给它发了一个约 557 KiB 的启动事务，直接报
Binder buffer full 和 TransactionTooLargeException。拉起新进程重试，还是失败，最后就卡死了。整个过程：
ChatGPT 登录页
→ CredentialManager 预取 Google ID Token
→ GMS 返回账号候选和头像
→ 小米凭证选择器启动事务过大
→ CredentialSelectorActivity 启动失败
→ ChatGPT 等不到 CredentialManager 回调
→ Google、非 Google 页面都表现为转圈
5 个谷歌账号就把小米自己搓的 Credential Manager 干死了，退出几个谷歌账号后问题（临时）解决。
这玩意是小米自己搞的，把所有 passkey 事件都拦截了。
passkey 设成 1Password 也绕不开，它和这个系统选择弹窗是两回事，用过的都知道，就算是第三方 passkey，也是走的系统弹窗。
后台弹窗启动失败，前台连句报错都没有，就让你一直等。 不抓日志，还以为是自己的网络或者账号有问题😅。
目前只确认本机复现，不代表所有人都中招。如果 GPT 登录直接连谷歌账号都显示不出来并且手机上登录了超过5个Google账号，大概率是小米自己的 Credential Manager 的锅，解决方法就是退出Google账号至5个以下。
🤣20❤1👏1🤔1😨1