在多个 dotnet new 模板之间做选择时…

当用户需要在相似的 dotnet new 模板（如 webapi vs webapp、blazor vs blazorwasm）之间做选择时，通过逐一检查各模板参数与特性支持，生成并排对比表并给出决定性推荐。

适用场景

解决思路

1. 对每个待比较的模板依次运行 `dotnet new <template> --help`，收集其参数（名称、类型、默认值、可选值）与支持的框架；必须顺序执行，因为模板引擎使用全局互斥锁，并发运行可能因 mutex/persistence 错误而返回空输出；若某次调用失败，重试一次后继续，并仍基于已有参数知识产出对比。
2. 若某模板未安装，查找其提供程序并报告缺失的前置条件；仅当用户要求修改环境或批准安装时才安装。
3. 构建并排对比表，覆盖：参数（名称、类型、默认值、可选值）、特性支持（auth、AOT、Docker、controllers、interactivity）、可用框架（如 net8.0、net9.0、net10.0）、分类（模板声明的类别，如 Web、API、Blazor）。
4. 每个用户关心的决策维度占一行，单元格中引用实际观察到的选项名；不要用通用框架知识填充关于模板生成内容或暴露选项的行。
5. 当用户询问生成的依赖项但不允许创建项目时，检查已安装模板包源码中的 `.csproj` 文件；`--help` 和 `--dry-run` 不会暴露包引用；不要为检查而创建临时项目，也不要猜测当前包 ID 或测试平台默认值。
6. 对不可用或未暴露的选项标注为 `Not exposed`，不要猜测或从其他模板借用标志。
7. 以决定性的 `Recommendation:` 行结尾，格式为：**Recommendation: `<template>`** — 一句话将选择与用户所述场景关联。（若 `<condition>` 则选另一个。）随后链接到 `template-instantiation` 创建项目。
8. 常见模板对的决策捷径（仅用于推荐，不作为当前参数支持的证据；填表前仍须用 `--help` 检查）：`webapi` vs `webapp` — JSON/REST 后端选 `webapi`，服务端渲染 HTML/Razor Pages 选 `webapp`；`blazor` vs `blazorwasm` — 需要离线/无服务器时选 `blazorwasm`，需要灵活的服务端+客户端交互时选 `blazor`（Web App）；`worker` vs `console` — 长时间运行/队列/后台处理选 `worker`；`mvc` vs `webapp` — 以页面为中心的应用选 `webapp`（Razor Pages），大规模控制器/视图分离选 `mvc`。
9. 以下约束覆盖上述捷径：当用户明确预期大型应用或共享控制器逻辑时，即使首批页面以 CRUD 为主也选 `mvc`；当富交互表单是核心但首个响应必须返回可用 HTML 时，选带 Server 交互性的 `blazor` 而非 `webapp`，并说明初始渲染由服务端生成、交互组件使用 Blazor 表单/组件模型而非 Razor Pages 的 `PageModel`；需要离线支持时选 `blazorwasm`，并说明 PWA/service-worker 要求、首次加载后缓存的行为以及执行时无需实时服务器；需要持久队列处理器时选 `worker`，并将决策与 Generic Host 生命周期、依赖注入、配置、日志、优雅关闭以及真实持久队列（而非内存循环）关联。
10. 验证清单：每个请求的模板都通过 `dotnet new <template> --help` 检查过；对比覆盖参数、特性支持、框架和分类；与用户场景相关的差异被明确指出；提供了推荐（或明确的权衡）；不支持的选项被标注而非猜测；最终推荐是单行决定性的 `Recommendation:`。
11. 避免常见陷阱：不要凭记忆比较未安装的模板，应安装并检查每个模板以反映真实参数与选项；不要假设特性对等，参数名和特性支持因模板而异，须逐一用 `--help` 确认；只比较解决重叠问题的模板，当它们面向不同场景时予以说明。

适用边界 · 注意事项

• 用户想要创建项目时——应路由到 `template-instantiation`
• 用户想要编写或验证自定义模板时——应路由到 `template-authoring` 或 `template-validation`
• 用户只需查找或检查单个模板时——应路由到 `template-discovery`