wasm-tools 安装缺 iOS manifest：检查 workload set 和源

安装的是 wasm-tools，失败信息却说找不到 microsoft.net.sdk.ios.manifest-10.0.100 的 27.1.10018。先看日志选择了哪一版 workload set：这类错误可能发生在集合的 manifest 更新阶段，还没进入你想安装的具体工作负载。

2026 年 10 月 19 日，workload set 10.0.402.1 选择了尚未出现在官方源的 iOS manifest 27.1.10018，导致无关的 wasm-tools 安装也失败；同一天该 manifest 补齐后，安装恢复。当前官方源已经提供这个版本，所以今天再次遇到相同报错时，不能继续按“官方仍未发布”处理。

workload set 固定的是一组版本

集合不是单个 wasm-tools 包的版本号。对应的 Microsoft.NET.Workloads.10.0.400 包 10.402.1 中，iOS 条目明确为 27.1.10018/10.0.100，同时还列着 Android、Emscripten、Mono 等 manifest。更新集合时，日志因而可能出现与当前目标平台无关的条目。

先保留实际 SDK、workload-set 版本、第一条缺包错误及有效 NuGet 源。区分“集合声明了一个当时不存在的版本”和“当前构建机使用的镜像尚未同步该版本”；鉴权失败、源不可达、包签名或本机权限错误也要按最早的错误分别处理。

安装回滚又提示某 manifest 没装好，通常是失败后的结果，不代表反复执行 repair 就能取得源里还不存在的版本。也不要因为日志打印了 iOS，就顺手删掉已经使用的其他工作负载。

包已补齐时，先修正实际取包路径

当前 27.1.10018 的官方包与 manifest 已可取得。若企业镜像仍缺它，按原依赖源流程补齐或更新获准镜像，保留既有认证和签名校验；不要把私有源、认证和校验全部关闭后再尝试安装。

核对当前目录是否有 global.json 固定 sdk.workloadVersion，以及以前的 install/update 操作是否已经选择 workload-set 模式。只修改一条命令，而仓库仍固定另一版集合，可能没有改变实际选择。SDK 版本、feature band 与 workload-set 版本也不能当成同一个数字随意替换。

确需暂时固定上一集合时，按同一 SDK 配套处理

在已确认兼容的 SDK 10.0.402 环境、且没有 global.json 的 workloadVersion 覆盖时，可以按既有构建环境流程评估固定到之前可安装的 10.0.402.0：

dotnet workload install wasm-tools --version 10.0.402.0

命令会安装工作负载并改变该 SDK 环境的 workload 状态，需要下载包；它不是只读查询。若仓库已经设置 workloadVersion，应在原配置中审查配套变更，保留 SDK、rollForward 等其他约束，不叠加一个与之竞争的版本参数。

固定旧集合是临时选择，不是修复官方集合包，也不意味着可以长期不更新。后续无版本参数的 workload update 可能切到新集合并解除 install 的固定，应把更新与 CI 镜像维护作为同一流程核对。

验收不仅看安装退出成功，还要确认实际集合版本、目标工作负载列表，并在原项目完成所需的 wasm 构建或发布。保存原构建环境与版本约束，确认镜像和源同步后再评估恢复匹配的新集合，不把安装回滚提示本身当作必须重装整套 SDK 的依据。