1 新iPad登录telegram遇到的巨坑

最近，考虑到已经没有了移动办公的需求，我把家里闲置的m1 macbook pro和ipad mini 6在转转上卖了：

然后加了点钱，换了有国补的蜂窝版 M3 iPad Air。相比官网 6099 的价格，体感上确实划算不少：

设备到手后，系统设置、应用安装基本都很顺利，使用体验也不错。唯一让我折腾了大半天的，反而是一个看起来最“理所当然”的步骤：登录 Telegram——使用手机号登录时，要么一直转圈，要么偶尔跳出“添加邮箱接收验证码”，再接着直接进入一个写着 SMS Fee 的界面：

上图大意是：由于国内运营商对 Telegram 发送验证码短信收取高额费用，而 Telegram 又强制要求通过短信验证手机号，所以需要用户购买一周的 Premium 订阅，用来覆盖这部分短信成本。换句话说就是：想在新设备上登录账号，得先掏钱买会员，才能收到验证码。

登录还要先付费，这个体验多少有点离谱。反正我是接受不了这种逻辑的，但新设备又确实需要登录 Telegram，那不付钱，到底有没有别的办法？

答案是有的：Telegram 其实已经支持了一种基于 Passkey(通行密钥) 的登录方式，可以完全绕过短信验证码流程。

2 什么是 Passkey，以及它为什么能解决 Telegram 的登录问题

2.1 Passkey 的本质：把“我知道一个秘密”，换成“我持有一把钥匙”

在进入具体操作之前，有必要先简单说明一下：Passkey 到底是什么，它和我们熟悉的“密码 + 短信验证码”有什么本质区别，否则，很多人在第一次看到“使用 Passkey 登录”时，心里估计多少会有点犯嘀咕～～。

传统账号体系的核心逻辑是：只要你能证明“我知道某个秘密”（密码 / 验证码），系统就认为你是账号的拥有者。

问题在于，这种“秘密”非常脆弱：密码可以被撞库、被钓鱼；短信验证码依赖运营商通道，成本高、不稳定，甚至在某些地区根本不可用；一旦验证码被劫持，系统无法区分“你本人”和“中间人”。

Passkey 的逻辑则完全不同，它更接近现实世界里的“钥匙”模型：你不是通过输入一个可以被复制的“秘密”来证明身份，而是通过本地设备中保存的一把私钥来完成认证。

在用户体验层面，表现为：不需要直接输入密码；不需要接收短信；只需要在本地通过 Face ID / Touch ID / 系统解锁确认一次即可。

从系统视角看，本质是：服务端只保存你的公钥；私钥永远留在你的设备或密码库中，不会被网站拿走；钓鱼网站即便“长得一模一样”，也无法诱骗你交出私钥。

所以，Passkey 解决的并不仅仅是“少输一个验证码”，而是：直接绕过了传统账号体系中最脆弱、也最依赖外部基础设施的一环（本例中就是telegram必须的短信验证码）。

这也是为什么，在 Telegram 新设备登录被 SMS Fee 卡住的场景下，Passkey 会变成一条真正可用的替代路径。

2.2 为什么 Passkey 能跨设备使用？——关键在于“谁在帮你保管那把钥匙”

很多人对 Passkey 的第一个疑问是：既然私钥存在设备里，那我换设备怎么办？是不是每换一台设备，就要重新绑定一次？理论上，如果私钥只存在某一台设备的本地安全芯片中，确实会有这个问题。而现实中，Passkey 能够做到“跨设备无感同步”，关键在于：私钥并不是由网站托管，而是由你的系统账号或密码库托管。

在苹果生态里，这套机制具体表现为：Passkey 由系统级“密码与钥匙串”管理；私钥会通过 iCloud 进行端到端加密同步；同一个 Apple ID 登录的设备，可以共享这些 Passkey。这意味着：当你在 iPhone 或 Mac 上为 Telegram 创建了 Passkey，换到新的 iPad 登录时，系统会自动从 iCloud 同步这把“钥匙”，你只需要在新设备上通过 Face ID / Touch ID 确认一次，就能完成Telegram的登录。

从用户视角看，体验是：不需要额外安装任何工具；不需要导入导出；设备间的“账号继承”几乎是无感的。这也是我在这次换设备过程中，能够顺利使用 Passkey 登录 Telegram 的关键原因：真正承载身份连续性的，不再是手机号，而是你的 Apple ID + 系统级密码库。

2.3 非苹果用户怎么办？密码库正在成为“跨平台的身份中枢”

如果不在苹果生态内，其实逻辑也是类似的，只是承载“钥匙”的主体从 iCloud 变成了第三方密码库，例如像 Bitwarden 这类已经支持 Passkey 的密码管理器(Bitwarden的具体搭建步骤可以参考我之前的文章：使用docker基于bitwarden搭建自己的密码管理系统)，本质上扮演的是：“跨设备、跨平台的私钥托管与同步中枢”。只要：Passkey 保存在你的密码库中，且不同设备登录的是同一个密码库账号，那么在新设备上登录 Telegram 时，同样可以完成 Passkey 的调用与验证，而不需要走短信验证码流程。

换句话说：Passkey 并不是绑定在某一台设备上，而是绑定在你所信任的“身份中枢”上。在苹果生态里，这个中枢是系统的密码/钥匙串模块，它通过 iCloud 在多台设备间同步；在跨平台场景里，则可以通过第三方密码库来实现类似的功能。

其实我之前在苹果生态中也是使用的自建的 Bitwarden 方案。不过在升级到 iOS 26 和 iPadOS 26 之后，我发现 iPhone 和 iPad 上的 Bitwarden 使用过程中出现了一些异常（Mac 上暂时没有问题）。因此，至少在当前这个系统版本阶段，我更倾向于只在非苹果生态中推荐 Bitwarden 方案，而在苹果生态内则优先使用系统自带的密码与钥匙串方案会更稳妥一些。

2.4 小结：Passkey 不是“花样登录方式”，而是新的身份承载方式

如果把这件事再抽象一层来看，其实可以发现，传统登录体系和 Passkey 体系之间，本质上是两种完全不同的身份承载方式。传统登录体系的身份锚点建立在手机号和密码之上，强依赖电信网络的可达性以及用户对“秘密信息”的记忆能力；而 Passkey 体系则将身份锚点转移到了设备的信任根与系统级密钥管理之上，登录过程本质上变成了一次“设备对账号所有权的证明”，而不再是“人类向系统重复输入凭证”。

在 Telegram 这个具体场景中，Passkey 的意义并不在于它“技术上更先进”，而在于它在现实环境中提供了一条不依赖运营商的可行路径。当短信通道因为成本、政策或网络环境等原因变得不可用时，基于 Passkey 的登录方式，恰好绕开了这一整套电信体系依赖，使账号登录不再被国际短信这一单点能力所卡死。

理解了这一点，后面具体的操作步骤其实就很好接受了：你并不是在使用某种“黑科技”来绕过限制，而是在使用 Telegram 已经提供的一种更现代、也更符合当前网络环境的登录方式。

3 在 Telegram 中启用并使用 Passkey 登录(以苹果生态为例)

在确认使用 Passkey 作为登录方式之前，首先需要确保当前你已经有苹果终端设备已经登录到了 Telegram 的设备中，账号状态是正常可用的。换句话说，Passkey 并不是“在无法登录时的救命稻草”，而是需要你先在已有设备上完成一次绑定，之后才能在新设备上作为替代登录方式使用。因此，这一步操作建议在你仍然可以正常使用 Telegram 的 iPhone 或 Mac 上完成。

进入 Telegram 的设置页面后，在”设置 → 隐私 → 通行密钥”(英文界面路径是”Settings → Privacy and Storage → Passkeys”)，可以看到 Telegram 提供的多种登录与验证方式，其中就包括 Passkey(通行密钥)相关选项：

点击启用 Passkey 后，系统会弹出由 iOS 或 macOS 提供的系统级验证窗口，提示你使用 Face ID、Touch ID 或设备解锁方式，然后需要你手动创建并保存一把通行密钥：

完成这一步之后，Telegram 账号实际上已经与当前 Apple ID 下的系统密码库建立了绑定关系。此时，你可以在 Telegram 的安全设置中看到 Passkey 已经处于启用状态。这一步非常关键，它意味着：后续只要是同一个 Apple ID 登录的设备，都有能力调用这把 Passkey 作为登录凭证。

接下来就是在新设备(以我的iPad Air 7为例)上的登录过程了。在新设备上安装并打开 Telegram 客户端后，正常情况下你会看到熟悉的手机号登录界面。在这个界面中，除了传统的手机号 + 验证码登录路径之外，Telegram 通常会提供一个“使用通行密钥登录”选项入口。此时不要再走短信验证码流程，而是直接选择 Passkey 登录方式：

当你选择使用 Passkey 登录后，系统会再次弹出由 iOS 提供的身份验证窗口，提示你使用 Face ID 或 Touch ID 进行确认。这里并不会要求你输入 Telegram 密码，也不会触发任何短信验证流程，整个认证过程完全发生在设备本地与 iCloud 密码库之间。只要当前设备登录的是与你原设备相同的 Apple ID，系统就能从 iCloud 同步到对应的 Passkey，并完成一次对 Telegram 服务器的身份证明：

验证通过后，Telegram 会直接完成账号登录，整个过程不涉及手机号验证码，也不会再出现 “SMS Fee” 相关的提示。对用户来说，体验上更接近于“解锁设备即可登录账号”，而不是传统意义上的“输入凭证”。如果一切顺利，你应该会在几秒内直接进入熟悉的聊天界面。

再次需要强调，这套流程的前提是：你的 Passkey 已经在其他能正常登录telegram的设备上创建并同步到了 iCloud。如果你在原设备上从未启用过 Passkey，那么新设备上是不会凭空出现“使用 Passkey 登录”的选项的。这也是为什么强烈建议在账号仍可正常登录的情况下，提前完成一次 Passkey 的绑定。某种程度上，这相当于给自己的账号提前准备了一条“不依赖短信的备用登录通道”。

从实际体验来看，这种基于系统密码库和 iCloud 同步的 Passkey 登录方式，在苹果生态内的流畅度远高于传统的短信验证码方案。它不仅绕开了国际短信成本高、稳定性差的问题，也避免了因收不到验证码而被迫中断登录流程的尴尬场景。更重要的是，一旦你适应了这种登录方式，后续在更换设备、重装系统时，账号迁移的心智负担会明显降低——登录不再是一件需要“等外部系统配合”的事情，而更多变成了一次本地设备权限的确认。

到这里，Telegram 基于 Passkey 的登录方式在苹果生态下的完整流程基本就跑通了。后续如果你还有 Mac、iPhone、iPad 等多设备环境，这套机制几乎可以无感复用，不再需要为“收不到验证码”这种问题反复折腾。

补充说明｜关于 Passkey 登录过程中“验证成功但无反应”的现象

在实际使用 Passkey 登录 Telegram 的过程中，有读者反馈在 iPad 上完成指纹验证后，界面并没有任何明显变化，看起来就像是“什么都没发生”。回想起来，我自己当时在实际操作中也遇到过类似的情况，只不过发生在高铁上(当时一会用iPad自己蜂窝的联通网，一会通过热点使用iphone的电信网，同时小火箭一会开，一会关～)，网络环境本身就比较混乱，所以当时并没有特别在意这个现象。

如果从原理上拆解这条登录链路，其实 Passkey 登录至少同时依赖两条网络路径都处于可用状态：一条是设备的系统密码库(在苹果生态中通过 iCloud 同步)能够正常访问，用于读取和校验本地保存的 Passkey；另一条是 Telegram 的登录服务本身能够正常连通，用于完成最终的账号认证。这两条链路只要有任意一条在当前网络环境下不可达，登录流程就可能表现为“验证通过了，但客户端没有明确反馈”。

在国内网络环境下，这种情况更容易被放大：一方面，国区 iCloud 实际部署在云上贵州，如果开启了全局代理但没有做国内外流量分流，可能会影响系统密码库与 iCloud 之间的正常通信；另一方面，Telegram 的服务本身又需要通过代理才能访问。如果这两条路径的网络策略互相“打架”，就很容易出现看似玄学的登录失败或无响应现象。

因此，如果你在使用 Passkey 登录时遇到类似问题，一个相对稳妥的做法是：尽量固定网络环境，避免在蜂窝、热点、直连和代理之间频繁切换；同时确保 iCloud 与 Telegram 的访问路径都处于一个“对双方都友好”的网络状态(比如科学策略做了国内外流量分流)。很多时候，并不是 Passkey 本身失效，而是登录链路中的某一环节在当前网络条件下无法正常完成。

4 后话

这次在新设备上登录 Telegram 被短信验证卡住，表面上看只是一个很具体、甚至有点“鸡毛蒜皮”的使用问题，但折腾完整个过程之后，反而让我更直观地意识到：我们已经非常习惯把“手机号 + 短信验证码”当作理所当然的登录方式，却很少去思考，这套体系本身其实高度依赖于电信网络的可达性、成本结构以及各地区运营商的策略。一旦这些前提条件发生变化，原本看起来理所当然的流程，就会在某个具体场景下突然失效。

从这个角度看，Telegram 要求为短信验证付费，本身并不是一个技术问题，而是底层通信体系与互联网产品之间目标不一致所带来的现实摩擦。对用户来说，这种摩擦往往以一种非常不友好的形式出现——你明明只是想登录自己的账号，却被迫为一条验证码短信买单。这种体验很难让人产生认同感，也会促使人主动去寻找替代方案。

Passkey 在这里扮演的角色，其实并不是“更先进的炫技功能”，而是一条绕开电信体系依赖的现实路径。当登录这件事从“我能否收到一条短信”转变为“我的设备是否能够完成一次本地身份确认”之后，整个流程的可控性明显提高了。至少对我个人来说，这次切换到基于 Passkey 的登录方式之后，在苹果生态内更换设备的心智负担明显降低了不少，登录不再是一件需要“看运营商脸色”的事情。

当然，这并不意味着 Passkey 现在已经是一个完美无缺的解决方案。一方面，它仍然依赖于操作系统级的生态支持，不同平台之间的体验存在差异；另一方面，对很多普通用户来说，“密钥”“密码库”“同步”这些概念仍然有一定认知门槛。因此，在现阶段，把 Passkey 当作一种可选的备用登录通道，而不是唯一手段，可能是更稳妥的做法。

如果有一个比较现实的建议，那就是：在账号仍然可正常登录的情况下，提前为一些重要服务绑定好 Passkey，相当于给自己的账号准备一条不依赖短信的“后备通道”。也许大多数时候你用不到它，但一旦哪天真的遇到类似这次的场景，它会让整个问题变得简单很多。

这次经历本身不是什么“大事件”，但它很清楚地暴露出一个正在发生的变化：我们习以为常的登录方式，并不是不可替代的。随着设备能力和系统级安全机制的成熟，身份认证正在从“对外部通信体系的依赖”，慢慢转向“对本地设备信任根的依赖”。等哪天你发现越来越多服务都开始提供 Passkey 登录时，大概也就不难理解，这种变化并不是某一家厂商的选择，而是整个生态在向一个更现实、也更可控的方向迁移。