说明：本次草稿依据提交记录，未逐行核对实现。提交未给出回调地址与配置细节；查不到的只讲思路，不编造回调 URL 的具体值。
背景：入口统一，接入方式不同
本项目的登录取向很明确：手机号验证码、Google 与 Apple 走统一注册、登录入口，按 Web 端实施，不要求昵称，不提供邮箱密码表单。这是 README 记载的实证。同时，真实 Provider 需配置腾讯云 SMS、Google Web Client ID 或 Apple Services ID 后才会显示——登录选项的出现是有条件的，取决于服务端是否配好了 Provider。
在此背景下，Apple Sign-in 要同时覆盖两端。一次提交（2026-10-15）做了原生接入、双域名容灾与 iOS 构建升级到版本 2；一次提交（2026-10-16）做了 Web 端接入。本文只讲这一条线。
原生与 Web：系统凭证 vs 回调
原生与 Web 虽都叫 Apple 登录，接入方式完全不同。原生用系统凭证流程：用户在 iOS 系统界面确认，应用拿到系统签发的凭证，与设备、系统账号结合紧密；重点是正确处理系统返回的凭证与用户信息，并与自家账号体系对接。
Web 端则走 Services ID 与回调：浏览器里没有系统凭证，需先跳转到 Apple 授权页，用户登录确认后，再由 Apple 回调回应用指定的地址。概括起来：原生是“系统给凭证”，Web 是“跳转授权再回调”。产品上都是“用 Apple 登录”，工程上却是两条链路，需分别实现、测试与处理异常。
动态多域名回调：为什么需要三个域名
其中一次提交提到 Web 端用动态多域名回调，涉及主域名、加速域名、地区域名三个域名。先讲多域名：产品可能同时有主域名、加速域名、面向不同地区的域名。用户从哪个域名进来，回调就应回到哪个域名，否则会出现“从 A 登录、却被带到 B”的割裂体验；回调地址还需在 Apple 侧配置，写死一个域名，其他域名就走不通。
再讲动态：回调地址不是写死的值，而是按用户当前所在域名动态决定。从主域名进来，回调回主域名；从加速域名进来，回调回加速域名；从地区域名进来，回调回地区域名。这样登录流程才能在多域名部署下都走通。
本文不编造回调 URL 的具体值。提交只提到三个域名的存在，未给出每个回调地址的完整形式。关键思路是回调地址要与入口域名一致，而非全局写死。
双域名容灾：切换思路
其中一次提交提到“双域名容灾”，核心问题是主域名出问题时登录还能不能继续。基本思路是准备两个可用域名，正常走主域名；主域名不可用或登录链路失败时，切换到备用域名继续。
有几个细节要想清楚。第一，何时切换：是域名解析失败、请求超时，还是 Apple 回调失败？不同原因，策略可能不同。第二，切换后状态怎么办：用户已在登录流程中途，切换后会话与回调上下文能否衔接？若切换意味着重走一遍流程，容灾的体验收益会打折。第三，切换要不要让用户感知：理想是透明的，但明确告知有时反而更可信。本文未逐行核对实现，不写具体切换条件；只讲清容灾要解决的问题：单域名故障不应导致登录整体不可用。
Apple 只给一次性信息：邮箱与姓名的坑
Apple Sign-in 有个著名的坑：只在首次授权时提供邮箱与姓名，且用户可选择隐藏真实邮箱，使用 Apple 生成的中转邮箱。之后再次登录，不一定再提供这些信息。
这对账号体系有直接影响。若首次登录没保存好邮箱与姓名，之后就再也拿不到了；若把邮箱当作账号唯一标识，而用户又用了隐藏邮箱，“同一个 Apple 账号”与“同一个应用账号”的对应关系就需要额外小心。
账号合并也与此相关：用户可能先用手机号注册，再用 Apple 登录。系统需判断两个登录方式背后是不是同一个人；判断错了会生成两个账号，数据随之分散。常见思路是以应用内部账号 ID 为准，多种登录方式都绑定到同一账号；首次登录时保存好能拿到的信息，后续以 Apple 的用户标识为准，不再依赖每次返回邮箱与姓名。本文不写该项目的具体合并规则，因提交里没有给出；只讲清坑的存在与设计要求：首次信息要及时保存，账号标识要独立于邮箱。
踩坑
第一，原生与 Web 是两条链路，别用一套逻辑硬套两端。第二，回调地址要与入口域名一致，写死迟早出问题。第三，容灾要有明确的切换条件与状态衔接，只备域名还不够。第四，Apple 的邮箱与姓名只给一次，首次就要保存好；账号标识应独立于邮箱。第五，入口可用性取决于代码与配置，缺配置时入口不显示是预期行为，不是缺陷。
小结：Apple Sign-in 的双端接入，表面是“多一个登录按钮”，实质是两条链路、三个域名与一套容灾思路的组合。原生靠系统凭证，Web 靠 Services ID 与回调；多域名回调让各入口都能登录，双域名容灾让主入口故障时还能登录；一次性邮箱与姓名的坑，则要求账号体系从一开始就把标识与合并想清楚。
