Rust 链接报 TAPI unknown architecture，核对 Xcode 27 SDK 与链接器
Rust 链接解析 MacOSX27.0.sdk 的 TAPI 文件失败时，核对显式 rust-lld 与旧 Apple linker，选择匹配工具或已安装的兼容 SDK。
Rust 项目更新 Apple 开发工具后，连依赖的 build script 都无法链接，最早的错误是：
could not load TAPI file .../MacOSX27.0.sdk/usr/lib/libSystem.tbd
unknown architecture
arm64e.x1-macos
后面可能跟着 _memcpy 等大量符号未定义。先看 TAPI 解析失败，不要从每一个缺失符号逐个找库：SDK 的系统库桩文件没有读成功，后续错误可能只是连带结果。
这条故障涉及 Xcode 27.0 SDK 与无法识别新架构名称的旧链接器。Rust 1.98.1 的显式 rust-lld 有明确表现，旧 Apple linker 配上新 SDK 也有类似失败；因此不能只按 macOS 的系统版本判断。
找到编译器实际调用了什么
记录 cargo build --verbose 的完整链接命令、rustc --version --verbose、SDK 路径及 linker 来源。检查项目 .cargo/config.toml、用户级配置与构建环境是否显式设置了 linker。
例如下面的用户级配置会让同一目标绕过默认选择：
[target.aarch64-apple-darwin]
linker = "rust-lld"
如果确实没有使用它的必要，可以只撤回这一项自定义设置，让项目回到与已安装 Apple 工具匹配的默认链接路径，再从原构建入口验证。先保存配置差异，别删除整份配置；里面可能还有私有源、目标选项和其他工程需要的内容。
若默认路径仍选到了旧开发工具，单纯移除 rust-lld 也不够。需要让 SDK 与支持它的 linker 来自兼容的工具链组合。SDKROOT 指向新 SDK、DEVELOPER_DIR 或 PATH 却选旧工具，是值得检查的一组混用。
临时选用已安装的兼容 SDK
暂时无法统一开发工具时，可以在单次构建中选择仍兼容的旧 SDK。下面假设该目录实际存在，并且满足工程的 API 与目标要求：
SDKROOT="/Library/Developer/CommandLineTools/SDKs/MacOSX26.5.sdk" cargo build
这是示例路径，不是要求下载某个来源不明的 SDK。先核对已安装目录，保留原 profile、target 和其他构建参数；只跑 cargo check 未必覆盖最终二进制的完整链接过程。
选择旧 SDK 会影响可用 API 和构建环境，应在项目或 CI 中明确记录。不要为排一次故障全局切换所有工程，也不要把新 SDK 的 .tbd 文件手工改掉或从另一套工具中拼接系统库。
解析通过后，还要回到完整构建
LLVM 上游已有相关架构解析工作，但源码合入不能直接代表当前安装的 rust-lld 已经带上；后续更新 Rust 时仍需核对工具链和原链接命令。Apple 工具更新的反馈也不能等同于所有机器都可用同一个版本。
恢复标准是 SDK 库桩能被实际链接器解析、原项目完整构建与必要运行检查通过，且 CI 使用相同的明确配置。若错误变成 Library not loaded: @rpath/libLLVM.dylib，那属于链接器自身的动态库加载，处理的不是当前 SDK TAPI 文件。