选错模板应重开项目并选Isolated模式（.NET 6+），检查.csproj含net6.0和Exe输出类型；HTTP触发器需用HttpRequestData手动读查询参数（区分大小写）和请求体（注意Stream位置）；本地调试失败多因Core Tools版本过低，需升级至4.47.1+；部署须用Zip Deploy且确认函数启用。
用 Visual Studio 创建 Azure Function 项目时选错模板怎么办
新建项目时选 Azure Functions 模板，但必须确认 .NET 版本和触发器类型匹配实际需求。VS 2022 默认推荐 .NET 6+ Isolated Worker，而传统 In-Process 模式只支持到 .NET 5（已停用）。如果误选 In-Process 模板再迁移到 .NET 6+，会遇到 Microsoft.NET.Sdk.Functions 包不兼容、FunctionName 特性失效等问题。
实操建议：
- 新项目一律选
Azure Functions模板 → 运行时选Isolated (NET 6+) - 触发器类型按需选，比如快速验证用
HTTP trigger，别一上来就选 Timer 或 Blob - 项目生成后检查
.csproj文件是否含net6.0 Exe
HTTP Trigger 函数里怎么获取查询参数和请求体
Isolated 模式下不能用旧版的 HttpRequestMessage 或 HttpActionContext，必须用 HttpRequestData 和 HttpResponseData。它不自动解析查询字符串或 JSON Body，全靠手动读取。
常见错误：直接对 req.Body 调用 ReadAsStringAsync() 却没先 Seek(0, SeekOrigin.Begin)，导致二次读取为空；或用 req.Query 取值时忽略大小写（它区分大小写）。
实操建议：
- 取查询参数：
req.Query["name"]（注意 key 大小写），或遍历req.Query.Keys - 读 JSON 请求体：
using var reader = new StreamReader(req.Body); var json = await reader.ReadToEndAsync(); - 返回 JSON 响应：用
req.CreateResponse(HttpStatusCode.OK)，再设response.Headers.Add("Content-Type", "application/json")，最后await response.WriteStringAsync(jsonString)
本地调试时提示 “Unable to connect to the host” 怎么办
这通常不是代码问题，而是 Azure Functions Core Tools 版本与项目目标框架不匹配。比如项目是 net6.0，但本地装的是 v4.x Core Tools（只支持 net5 及以下），就会启动失败，日志里出现 Worker process started and initialized 后立刻断连。
实操建议：
- 在终端运行
func --version，确认输出为4.47.1或更高（v4.40+ 才正式支持 isolated .NET 6+） - 若版本太低，卸载旧版：
npm uninstall -g azure-functions-core-tools，再用npm install -g azure-functions-core-tools@4 --unsafe-perm true - VS 内置的 func CLI 可能滞后，建议关闭 “Use VS installed version”，改用全局安装的 CLI（项目属性 → Debug → General → uncheck “Use dotnet watch” and enable “Launch browser” manually）
部署到 Azure 时函数没出现在 Portal 列表里
最常被忽略的是发布配置中没选对“部署模式”。Isolated 模式必须用 Zip Deploy，不能选 Run from Package（虽然后者更快，但 isolated 函数目前不支持）。另外，函数名在 Portal 中显示为 Function App 名/函数名，但实际 URL 是 https:// —— 如果部署后访问 404，大概率是 URL 拼错了路径或函数没启用。
实操建议：
- VS 发布时，“Target” 选
Azure Function App (Windows)，发布方法选Zipped Deploy - 发布后进 Portal → Function App → Functions，确认状态是
Enabled（不是灰色禁用） - 查看日志流：
Monitor → Log Stream，启动时若报Could not load file or assembly 'Microsoft.Azure.Functions.Worker'，说明 nuget 包版本与 runtime 不一致（如用了 1.10.0 但 Azure 上 runtime 是 ~4）
Isolated 模式下函数入口逻辑、依赖注入、配置加载都和传统模式完全不同，很多“看着像能跑”的代码其实漏了 IFunctionsHostBuilder 配置或 ConfigureFunctionsWorkerDefaults 调用——这些地方不报编译错，但一运行就静默失败。
