GitHub Copilot 驱动的 Azure Functions C# 隔离工作模型开发指南awesome-copilot【免费下载链接】awesome-copilotCommunity-contributed instructions, agents, skills, and configurations to help you make the most of GitHub Copilot.项目地址: https://gitcode.com/GitHub_Trending/aw/awesome-copilot本文是 awesome-copilot 仓库中 azure-functions-csharp.instructions.md 指令文档的深度解读与工程化展开。它面向所有使用 GitHub Copilot 在 C# 中构建 Azure Functions 的开发者核心围绕**隔离工作模型isolated worker model**展开从项目搭建、触发器与绑定、依赖注入、错误处理与重试到可观测性、性能调优、安全加固与测试实践并附带一套可直接用于 Copilot 代码评审的审查清单。读完本文你将掌握一套可复制、可落地、面向生产环境的 Azure Functions C# 工程规范并能在 Copilot 辅助下写出与之匹配的高质量代码。为什么新项目必须使用隔离工作模型Azure Functions 在 .NET 生态中存在两种运行模型进程内模型in-process函数与 Functions 宿主运行在同一进程依赖FunctionsStartup、IWebJobsStartup等机制与宿主共享生命周期长期存在版本耦合问题。隔离工作模型isolated worker函数代码运行在独立进程中与 Functions 宿主解耦支持 .NET 6 及更高版本可以独立使用HostBuilder/FunctionsApplication.CreateBuilder进行宿主配置与依赖注入。azure-functions-csharp.instructions.md 的通用指令部分明确要求所有面向 .NET 6 及以上的新 Azure Functions 项目一律使用隔离工作模型这是整个指令体系的基石。隔离模型带来的直接收益包括更少的宿主与 SDK 版本冲突、对 ASP.NET Core 中间件如UseMiddleware的原生支持、以及更符合现代 .NET 开发习惯的 DI 容器。宿主初始化与函数声明在Program.cs中使用FunctionsApplication.CreateBuilder(args)或HostBuilder完成宿主设置与依赖注入注册。使用[Function(FunctionName)]特性声明函数并采用强类型的触发器和绑定特性。每个函数只做一件事函数方法体保持薄业务逻辑一律下沉到通过 DI 注册的服务类中绝不在函数体内直接堆业务代码。日志通过构造函数注入的ILoggerT获取而非函数参数传入的ILogger保证结构化日志的一致性。所有 I/O 操作使用async/await禁止使用.Result或.Wait()阻塞在支持的场景下优先声明CancellationToken参数以支持优雅关闭。项目结构与工程化配置NuGet 依赖与组织方式依赖Microsoft.Azure.Functions.Worker与Microsoft.Azure.Functions.Worker.Extensions.*系列包。在Program.cs中通过builder.Services.Add*扩展方法注册服务保持 DI 容器干净。按领域关注点而非触发器类型组织函数类把相关函数放进同一类而不是把同一类触发器堆在一起。本地开发配置放在local.settings.json部署环境使用 Azure App Configuration 或 Application Settings。配置与密钥管理绝不硬编码连接字符串或密钥一律从IConfiguration或环境变量读取。部署环境中的机密通过 App Settings 里的 Key Vault 引用Microsoft.KeyVault(SecretUri...)注入。认证优先使用Managed IdentityDefaultAzureCredential尽量避免使用带密钥的连接字符串。host.json需要按触发器类型分别调优maxConcurrentCalls、batchSize、重试策略都在宿主级别配置。仓库中姊妹篇 azure-durable-functions-csharp.instructions.md 还给出了本地配置的补充约束本地开发必须包含AzureWebJobsStorage可用UseDevelopmentStoragetrue或 Azurite 连接串、FUNCTIONS_WORKER_RUNTIME设为dotnet-isolated且local.settings.json不得提交到源码库用local.settings.json.example占位。这也印证了隔离工作模型项目以dotnet-isolated为运行时标识的事实——azure-static-web-apps 技能中记录的 SWA API 支持运行时清单同样包含dotnet-isolated:8.0。触发器选型与最佳实践不同触发器有截然不同的调优重点指令文档逐类给出了指导触发器核心要点HttpTrigger生产端点使用AuthorizationLevel.Function或更高Anonymous仅限有明确理由的公开 API。使用 ASP.NET Core 集成时可用UseMiddleware与IActionResult返回类型TimerTrigger使用 NCRONTAB 表达式如0 */5 * * * *生产环境避免RunOnStartup true会在每次冷启动时立即执行Queue / ServiceBus在host.json与 Azure Portal 配置MaxConcurrentCalls、死信策略、MaxDeliveryCount需要细粒度消息控制时直接处理ServiceBusReceivedMessagecomplete / abandon / dead-letterBlobTrigger优先基于 Event Grid 的 blob 触发器Microsoft.Azure.Functions.Worker.Extensions.EventGrid相比轮询式延迟更低、存储事务成本更少EventHubTrigger批量处理时设置cardinality many参数类型使用EventData[]或string[]始终依赖EventHubTriggerAttribute内置的检查点机制CosmosDBTrigger使用变更源change feed触发器做事件驱动处理设置LeaseContainerName并将租约容器与数据容器分离管理输入输出绑定声明式优于命令式绑定能覆盖的场景优先用输入绑定声明式读取数据而不是在函数体内直接用 SDK。多输出绑定定义自定义返回类型属性上标注对应绑定特性如[QueueOutput]、[BlobOutput]、[HttpResult]。Blob读写用[BlobInput]/[BlobOutput]大 blob 优先Stream而非byte[]避免内存压力。Cosmos DB点读与简单查询用[CosmosDBInput]复杂查询通过 DI 注入CosmosClient配合 Managed Identity。Service Bus单消息发送用[ServiceBusOutput]批量或高级发送场景通过 DI 注入ServiceBusSender。一致性原则对同一资源避免混用 DI 注入的 SDK 客户端与绑定 I/O一个资源选一种模式保持风格一致。依赖注入与配置源码级要点指令文档给出的 DI 与配置规范可以直接对应到Program.cs的实现外部客户端BlobServiceClient、ServiceBusClient、CosmosClient以单例注册使用services.AddAzureClients()来自Azure.Extensions.AspNetCore.Configuration.Secrets包配合DefaultAzureCredential。强类型配置段使用IOptionsT或IOptionsMonitorT。禁止在函数中使用static状态所有共享状态经 DI 注册的服务流转。HttpClient一律通过IHttpClientFactory注册管理连接池并避免 socket 耗尽。错误处理与重试策略重试要分两层设计宿主级重试在host.json的retry配置fixedDelay或exponentialBackoff策略实现触发器级重试。代码级弹性瞬态故障处理使用Microsoft.Extensions.Http.Resilience或 Polly v8ResiliencePipeline组合重试、熔断、超时策略。其余硬性规则捕获具体异常并以结构化上下文correlation ID、输入标识记录日志随后再抛出或投递到死信队列。所有重试都失败后的消息进入死信队列函数处理器内绝不静默吞掉异常。HTTP 触发器对预期内的错误条件返回恰当的IActionResult类型BadRequestObjectResult、NotFoundObjectResult而不是抛异常。可观测性与日志结构化日志_logger.LogInformation(Processing message {MessageId}, messageId)。在Program.cs中通过builder.Services.AddApplicationInsightsTelemetryWorkerService()与builder.Logging.AddApplicationInsights()接入 Application Insights。自定义事件、指标、依赖追踪用TelemetryClient。在host.json的logging段设置合适的日志级别控制生产环境的遥测成本。分布式追踪上下文传播使用System.Diagnostics的Activity/ActivitySource。任何日志语句都不得包含敏感数据PII、密钥、连接字符串。性能与可伸缩性调优最小化函数启动时间昂贵初始化放到懒加载单例中而不是函数构造函数里。托管计划选择事件驱动、不可预测负载用Consumption低延迟、高吞吐或需要 VNet 集成用Premium / Dedicated。CPU 密集工作卸载到后台Task或 Durable Functions避免阻塞函数宿主线程。尽量批量一次调用处理IEnumerableEventData或ServiceBusReceivedMessage[]而非一条条处理。按托管计划与预期吞吐调优FUNCTIONS_WORKER_PROCESS_COUNT与maxConcurrentCalls。设置WEBSITE_RUN_FROM_PACKAGE1直接从部署包运行以加快冷启动。安全加固清单HTTP 触发输入先校验再处理使用 FluentValidation 或 Data Annotations。内部 API 间调用使用AuthorizationLevel.Function函数密钥存放在 Key Vault。对外公开的 HTTP 函数前面挂Azure API ManagementAPIM统一处理认证、限流与路由。敏感函数用 App Service 网络能力IP 限制、Private Endpoints限制入站访问。绝不记录包含 PII 或密钥的请求体。测试策略服务类独立于函数宿主做单元测试标准 xUnit/NUnit mock 依赖。集成测试使用Azurite本地 Azure Storage 模拟器TestServer或 Azure Functions Core Tools。使用Microsoft.Azure.Functions.Worker.Testing辅助构造 mockFunctionContext。测试重点放在被提取到服务中的业务逻辑避免测试触发器管道本身。代码评审指导让 Copilot 帮你把好关指令文档最后一部分是一套现成的审查规则可直接粘贴进你的评审提示词中若项目使用旧式进程内模型FunctionsStartup、IWebJobsStartup建议迁移到隔离工作模型并依据dotnet-isolated-process-guide给出迁移路径。发现代码或配置中的硬编码连接字符串/存储账户密钥 → 标记建议替换为DefaultAzureCredential Key Vault 引用。生产应用中出现TimerTrigger的RunOnStartup true→ 标记为风险建议改用部署槽或功能开关。出现async void→ 立即标记改用async Task。函数内手工实现Thread.Sleep/Task.Delay重试 → 建议替换为宿主级重试策略或 Polly 弹性管道。这些规则与 azure-durable-functions-csharp.instructions.md 中编排器内禁止DateTime.UtcNow/Guid.NewGuid()/直接 HTTP 调用一律下沉到 Activity的审查精神一脉相承共同构成完整的 .NET Azure Functions 工程护栏。如何把这份指南接入 GitHub Copilotawesome-copilot 仓库把这类规则封装为Custom Instructions。按 docs/README.instructions.md 的说明你可以将azure-functions-csharp.instructions.md下载后复制到工作区.github/copilot-instructions.md让规则全局生效或将任务级指令放入.github/instructions/目录例如.github/instructions/azure-functions.instructions.md按需作用于具体任务。指令文件通过 YAML front matter 声明applyTo: **/*.cs, **/host.json, **/local.settings.json, **/*.csproj即 Copilot 在编辑 C# 源文件、host.json、local.settings.json与*.csproj时会自动应用这些规则——这正是由文件模式驱动、自动生效的指令机制。小结本文以 awesome-copilot 的 azure-functions-csharp.instructions.md 为骨架完整继承并展开了隔离工作模型下的工程规范宿主与 DI 搭建、六类触发器的选型与调优、输入输出绑定、错误处理与双层重试、可观测性、性能与安全、测试方法以及可直接复用的代码评审清单。配合 azure-durable-functions-csharp.instructions.md 处理有状态编排场景你可以在 GitHub Copilot 的辅助下稳定地产出生产级的 Azure Functions C# 代码并让 AI 代码评审与人工规范保持一致。【免费下载链接】awesome-copilotCommunity-contributed instructions, agents, skills, and configurations to help you make the most of GitHub Copilot.项目地址: https://gitcode.com/GitHub_Trending/aw/awesome-copilot创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 GitHub Copilot 驱动的 Azure Functions C 隔离工作模型开发指南（awesome-copilot）
GitHub Copilot 驱动的 Azure Functions C# 隔离工作模型开发指南awesome-copilot【免费下载链接】awesome-copilotCommunity-contributed instructions, agents, skills, and configurations to help you make the most of GitHub Copilot.项目地址: https://gitcode.com/GitHub_Trending/aw/awesome-copilot本文是 awesome-copilot 仓库中 azure-functions-csharp.instructions.md 指令文档的深度解读与工程化展开。它面向所有使用 GitHub Copilot 在 C# 中构建 Azure Functions 的开发者核心围绕**隔离工作模型isolated worker model**展开从项目搭建、触发器与绑定、依赖注入、错误处理与重试到可观测性、性能调优、安全加固与测试实践并附带一套可直接用于 Copilot 代码评审的审查清单。读完本文你将掌握一套可复制、可落地、面向生产环境的 Azure Functions C# 工程规范并能在 Copilot 辅助下写出与之匹配的高质量代码。为什么新项目必须使用隔离工作模型Azure Functions 在 .NET 生态中存在两种运行模型进程内模型in-process函数与 Functions 宿主运行在同一进程依赖FunctionsStartup、IWebJobsStartup等机制与宿主共享生命周期长期存在版本耦合问题。隔离工作模型isolated worker函数代码运行在独立进程中与 Functions 宿主解耦支持 .NET 6 及更高版本可以独立使用HostBuilder/FunctionsApplication.CreateBuilder进行宿主配置与依赖注入。azure-functions-csharp.instructions.md 的通用指令部分明确要求所有面向 .NET 6 及以上的新 Azure Functions 项目一律使用隔离工作模型这是整个指令体系的基石。隔离模型带来的直接收益包括更少的宿主与 SDK 版本冲突、对 ASP.NET Core 中间件如UseMiddleware的原生支持、以及更符合现代 .NET 开发习惯的 DI 容器。宿主初始化与函数声明在Program.cs中使用FunctionsApplication.CreateBuilder(args)或HostBuilder完成宿主设置与依赖注入注册。使用[Function(FunctionName)]特性声明函数并采用强类型的触发器和绑定特性。每个函数只做一件事函数方法体保持薄业务逻辑一律下沉到通过 DI 注册的服务类中绝不在函数体内直接堆业务代码。日志通过构造函数注入的ILoggerT获取而非函数参数传入的ILogger保证结构化日志的一致性。所有 I/O 操作使用async/await禁止使用.Result或.Wait()阻塞在支持的场景下优先声明CancellationToken参数以支持优雅关闭。项目结构与工程化配置NuGet 依赖与组织方式依赖Microsoft.Azure.Functions.Worker与Microsoft.Azure.Functions.Worker.Extensions.*系列包。在Program.cs中通过builder.Services.Add*扩展方法注册服务保持 DI 容器干净。按领域关注点而非触发器类型组织函数类把相关函数放进同一类而不是把同一类触发器堆在一起。本地开发配置放在local.settings.json部署环境使用 Azure App Configuration 或 Application Settings。配置与密钥管理绝不硬编码连接字符串或密钥一律从IConfiguration或环境变量读取。部署环境中的机密通过 App Settings 里的 Key Vault 引用Microsoft.KeyVault(SecretUri...)注入。认证优先使用Managed IdentityDefaultAzureCredential尽量避免使用带密钥的连接字符串。host.json需要按触发器类型分别调优maxConcurrentCalls、batchSize、重试策略都在宿主级别配置。仓库中姊妹篇 azure-durable-functions-csharp.instructions.md 还给出了本地配置的补充约束本地开发必须包含AzureWebJobsStorage可用UseDevelopmentStoragetrue或 Azurite 连接串、FUNCTIONS_WORKER_RUNTIME设为dotnet-isolated且local.settings.json不得提交到源码库用local.settings.json.example占位。这也印证了隔离工作模型项目以dotnet-isolated为运行时标识的事实——azure-static-web-apps 技能中记录的 SWA API 支持运行时清单同样包含dotnet-isolated:8.0。触发器选型与最佳实践不同触发器有截然不同的调优重点指令文档逐类给出了指导触发器核心要点HttpTrigger生产端点使用AuthorizationLevel.Function或更高Anonymous仅限有明确理由的公开 API。使用 ASP.NET Core 集成时可用UseMiddleware与IActionResult返回类型TimerTrigger使用 NCRONTAB 表达式如0 */5 * * * *生产环境避免RunOnStartup true会在每次冷启动时立即执行Queue / ServiceBus在host.json与 Azure Portal 配置MaxConcurrentCalls、死信策略、MaxDeliveryCount需要细粒度消息控制时直接处理ServiceBusReceivedMessagecomplete / abandon / dead-letterBlobTrigger优先基于 Event Grid 的 blob 触发器Microsoft.Azure.Functions.Worker.Extensions.EventGrid相比轮询式延迟更低、存储事务成本更少EventHubTrigger批量处理时设置cardinality many参数类型使用EventData[]或string[]始终依赖EventHubTriggerAttribute内置的检查点机制CosmosDBTrigger使用变更源change feed触发器做事件驱动处理设置LeaseContainerName并将租约容器与数据容器分离管理输入输出绑定声明式优于命令式绑定能覆盖的场景优先用输入绑定声明式读取数据而不是在函数体内直接用 SDK。多输出绑定定义自定义返回类型属性上标注对应绑定特性如[QueueOutput]、[BlobOutput]、[HttpResult]。Blob读写用[BlobInput]/[BlobOutput]大 blob 优先Stream而非byte[]避免内存压力。Cosmos DB点读与简单查询用[CosmosDBInput]复杂查询通过 DI 注入CosmosClient配合 Managed Identity。Service Bus单消息发送用[ServiceBusOutput]批量或高级发送场景通过 DI 注入ServiceBusSender。一致性原则对同一资源避免混用 DI 注入的 SDK 客户端与绑定 I/O一个资源选一种模式保持风格一致。依赖注入与配置源码级要点指令文档给出的 DI 与配置规范可以直接对应到Program.cs的实现外部客户端BlobServiceClient、ServiceBusClient、CosmosClient以单例注册使用services.AddAzureClients()来自Azure.Extensions.AspNetCore.Configuration.Secrets包配合DefaultAzureCredential。强类型配置段使用IOptionsT或IOptionsMonitorT。禁止在函数中使用static状态所有共享状态经 DI 注册的服务流转。HttpClient一律通过IHttpClientFactory注册管理连接池并避免 socket 耗尽。错误处理与重试策略重试要分两层设计宿主级重试在host.json的retry配置fixedDelay或exponentialBackoff策略实现触发器级重试。代码级弹性瞬态故障处理使用Microsoft.Extensions.Http.Resilience或 Polly v8ResiliencePipeline组合重试、熔断、超时策略。其余硬性规则捕获具体异常并以结构化上下文correlation ID、输入标识记录日志随后再抛出或投递到死信队列。所有重试都失败后的消息进入死信队列函数处理器内绝不静默吞掉异常。HTTP 触发器对预期内的错误条件返回恰当的IActionResult类型BadRequestObjectResult、NotFoundObjectResult而不是抛异常。可观测性与日志结构化日志_logger.LogInformation(Processing message {MessageId}, messageId)。在Program.cs中通过builder.Services.AddApplicationInsightsTelemetryWorkerService()与builder.Logging.AddApplicationInsights()接入 Application Insights。自定义事件、指标、依赖追踪用TelemetryClient。在host.json的logging段设置合适的日志级别控制生产环境的遥测成本。分布式追踪上下文传播使用System.Diagnostics的Activity/ActivitySource。任何日志语句都不得包含敏感数据PII、密钥、连接字符串。性能与可伸缩性调优最小化函数启动时间昂贵初始化放到懒加载单例中而不是函数构造函数里。托管计划选择事件驱动、不可预测负载用Consumption低延迟、高吞吐或需要 VNet 集成用Premium / Dedicated。CPU 密集工作卸载到后台Task或 Durable Functions避免阻塞函数宿主线程。尽量批量一次调用处理IEnumerableEventData或ServiceBusReceivedMessage[]而非一条条处理。按托管计划与预期吞吐调优FUNCTIONS_WORKER_PROCESS_COUNT与maxConcurrentCalls。设置WEBSITE_RUN_FROM_PACKAGE1直接从部署包运行以加快冷启动。安全加固清单HTTP 触发输入先校验再处理使用 FluentValidation 或 Data Annotations。内部 API 间调用使用AuthorizationLevel.Function函数密钥存放在 Key Vault。对外公开的 HTTP 函数前面挂Azure API ManagementAPIM统一处理认证、限流与路由。敏感函数用 App Service 网络能力IP 限制、Private Endpoints限制入站访问。绝不记录包含 PII 或密钥的请求体。测试策略服务类独立于函数宿主做单元测试标准 xUnit/NUnit mock 依赖。集成测试使用Azurite本地 Azure Storage 模拟器TestServer或 Azure Functions Core Tools。使用Microsoft.Azure.Functions.Worker.Testing辅助构造 mockFunctionContext。测试重点放在被提取到服务中的业务逻辑避免测试触发器管道本身。代码评审指导让 Copilot 帮你把好关指令文档最后一部分是一套现成的审查规则可直接粘贴进你的评审提示词中若项目使用旧式进程内模型FunctionsStartup、IWebJobsStartup建议迁移到隔离工作模型并依据dotnet-isolated-process-guide给出迁移路径。发现代码或配置中的硬编码连接字符串/存储账户密钥 → 标记建议替换为DefaultAzureCredential Key Vault 引用。生产应用中出现TimerTrigger的RunOnStartup true→ 标记为风险建议改用部署槽或功能开关。出现async void→ 立即标记改用async Task。函数内手工实现Thread.Sleep/Task.Delay重试 → 建议替换为宿主级重试策略或 Polly 弹性管道。这些规则与 azure-durable-functions-csharp.instructions.md 中编排器内禁止DateTime.UtcNow/Guid.NewGuid()/直接 HTTP 调用一律下沉到 Activity的审查精神一脉相承共同构成完整的 .NET Azure Functions 工程护栏。如何把这份指南接入 GitHub Copilotawesome-copilot 仓库把这类规则封装为Custom Instructions。按 docs/README.instructions.md 的说明你可以将azure-functions-csharp.instructions.md下载后复制到工作区.github/copilot-instructions.md让规则全局生效或将任务级指令放入.github/instructions/目录例如.github/instructions/azure-functions.instructions.md按需作用于具体任务。指令文件通过 YAML front matter 声明applyTo: **/*.cs, **/host.json, **/local.settings.json, **/*.csproj即 Copilot 在编辑 C# 源文件、host.json、local.settings.json与*.csproj时会自动应用这些规则——这正是由文件模式驱动、自动生效的指令机制。小结本文以 awesome-copilot 的 azure-functions-csharp.instructions.md 为骨架完整继承并展开了隔离工作模型下的工程规范宿主与 DI 搭建、六类触发器的选型与调优、输入输出绑定、错误处理与双层重试、可观测性、性能与安全、测试方法以及可直接复用的代码评审清单。配合 azure-durable-functions-csharp.instructions.md 处理有状态编排场景你可以在 GitHub Copilot 的辅助下稳定地产出生产级的 Azure Functions C# 代码并让 AI 代码评审与人工规范保持一致。【免费下载链接】awesome-copilotCommunity-contributed instructions, agents, skills, and configurations to help you make the most of GitHub Copilot.项目地址: https://gitcode.com/GitHub_Trending/aw/awesome-copilot创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考