送上全球各个版本 Apple Watch 支持的频段： https://www.apple.com/watch/cellular/

日版也没有美国这些频段啊，按照你的标准：

n258 (26 GHz) AT&T 、T-Mobile 在用（美国很重要）
n260 (39 GHz) Verizon 、AT&T 、T-Mobile 在用（美国很重要）
n261 (28 GHz) Verizon 、AT&T 、T-Mobile 在用（美国很重要）

用这些频段覆盖的地区已经超过了 b71 和 n71 。不买美版就支持不了这些频段。

不过有一说一，国行缺的那些频段都不是是很重要。比如你去看在美国/加拿大卖的蜂窝版 Apple Watch 就并不支持 b71 和 b29 ；日本销售的 Apple Watch 也不支持 b11 、b21 。但凡这些频段很重要 Apple Watch 蜂窝版也不会阉割掉这些频段。

@muscippe 美区限制相同 IP 登录，抱歉

那怎么盈利，植入广告么？

先问是不是，再问为什么。Telegram 的月活连 WhatsApp 的三分之一都不到，所以用的人算不上多，甚至还没微信多。而 WhatsApp 就是你说的默认端到端。

至于为啥微信和 Telegram 没有端到端还能做到 WhatsApp 的三分之一的用户量。Telegram 大量频道和评论本身就是公开的，对于谁都能加入的公开频道，甚至加入前就可以看到聊天内容的群（所有公开群都是如此），端到端加密自然也没意义了。微信的话也同理，发的东西默认是公开的，不想公开的内容我也不会通过微信发。

AWS 就行，文档和功能都齐全，市场占有率也高，而且还有中国区，而且中国区和国际区用的同一套 API

设置 - 蜂窝里把 Allow More Data on 5G 打开就行了。如果是无限流量的 5G 套餐建议打开这个

然后中国银联在美国可以被当作 Discover 卡组织的卡正常线上线下付款，所以接受程度还是很大的。

不过通过这种方式刷卡在美国是重罪

可以明确的告诉你，没有 CVV 也可以完成境外交易。很多商家让你填写 CVV 只是风控的一部分，建议把卡号涂掉

@hackenfu 有 Watch 版跟支持 WatchOS Call Kit 是两回事，国外论坛有讨论过，没见有支持 Watch Call Kit 的

你说的这两个软件也不支持 Apple Watch Call Kit 啊。我至今没找到支持了这个的软件

@leconio 开发者走的不是 App Store 付款，是 Apple Store 的付款，所以余额用不了

@JingXiao 主要是这样你就无法验证是否真的是原厂屏幕了。你细想一下就会发现我那种方式是唯一验证是 1. 原厂屏幕 2. 官方销售 3. 会在官方留下维修记录且下次官方维修不会出问题 的方式

当你使用前端加密，并同时修改后端加密，以尽可能避免这些攻击时，你会发现你最终实现的东西是跟 Passkey 一样的。Passkey 不但不会泄漏原始密码，同时每次登陆所传输的东西还是不一样的

@userKamtao 用处微乎其微

1. 如果泄漏行为本身发生在前端（如恶意浏览器插件），那无论如何 hash 还是会泄漏原密码（读密码输入框/键盘事件），从而所有网站登录被攻破（无论是否前端加密）；
2. 原密码在其他未前端加密平台（是大多数网站）的后端或者传输层被泄漏，也一样可以计算出 hash 后的密文在你的平台上登录；
3. hash 后的密码在你的平台上的后端/传输层泄露，那所有用一样前端的前端加密算法的平台也一样可以登录了

下面考虑情况 3 ，能否每个网站做到不同的 hash ，从而实现每个网站的 hash 算法都不一样。这个可以做到（在 hash 前 append/prepend 一个平台 dependent 字符串就行）。但因为有 1-2 的存在所以 3 的意义有限。此外它带来的麻烦也不少，比如需要修改多个前端（不同客户端和网站）

而且我也提供了解决方案，直接用 Passkey 。用 Passkey 才是王道，而且绝大多数新版的 OS 都支持了

常规的解决方案就是前端不额外加密，密码直接 HTTPS 传，加盐 hash 后存数据库。我敢说绝大多数大厂的登录都是这样的。而且只要是 https 了，那就绝对不是“明文传输”了。如果 OP 觉得 devtools 里是明文有危险，那我可以告诉你，如果黑客都已经能读到这一层数据了，那直接监听键盘，或者直接读密码输入框都是可以做到的。

确实是脱裤子放屁，某种程度上来说你 md5 后反而更不安全了，甭管你是否加盐，也甭管换啥更安全的 hash ，原本密码的不均匀的分布规律在 md5 后也一样不均匀，并且 md5 后的密码长度反而成为了固定值（ 128bits ），墒反而可能会降低，黑客可以确切的知道要 brute force 的密码格式；常用密码攻击也一样无法避免，原本用常用密码攻击，现在是用 hash 后的常用密码攻击

而且就像之前人所说的，如果黑客原本能拿到密码，那黑客现在也能拿到 hash ，而这个 hash 也一样是永久有效的，等同于密码

至于服务器 log ，如果 POST Body 都明文 log 下来了，那 hash 后的密码不也一样 log 下来了，而且很多同样敏感的 POST Body 也一样会 log 下来。这种属于 XY Problem ，应该去解决本质问题，而不是去其他地方脱裤子放屁

99%的情况下，没有学习过密码学的人自创的加密方法都是不安全的或者是没意义的。建议用现成的工具，比如 https 。确实明文传密码有不安全之处，此时的解决方案是去用 TOTP 、Passkey 这种成熟的加密解决方案（后者也涉及到“前端”加密），而不是去研究自创的前端加密这种脱裤子放屁的事