迁移到Azure Functions Isolated后IHttpContextAccessor为空如何解决？

核心结论 #

Azure Function .NET 隔离（Out-of-process）模型原生不支持 IHttpContextAccessor，你遇到的 HttpContext 为 null 属于预期行为，并非配置错误。

底层原因 #

• 进程内（In-process）模型的函数直接运行在 Azure Function 宿主进程中，与 ASP.NET Core 共用请求管道，存在原生 HttpContext 实例，因此 IHttpContextAccessor 可正常工作。
• 隔离模型的函数运行在独立的 Worker 进程中，与宿主进程通过 gRPC 协议交互，请求信息会被封装为 HttpRequestData 对象传递到 Worker 进程，整个上下文不存在 ASP.NET Core 原生的 HttpContext 实例，因此即使注册了 IHttpContextAccessor 也无法获取到有效值。

适配方案 #

方案1：适配隔离模型原生设计（推荐） #

直接使用函数入口参数中的 HttpRequestData 即可获取所有请求相关信息，无需依赖 IHttpContextAccessor。
示例中的需求可直接修改为如下实现：

[Function("Function1")]
public HttpResponseData Run([HttpTrigger(AuthorizationLevel.Function, "get", "post")] HttpRequestData req,
    FunctionContext executionContext)
{
    var logger = executionContext.GetLogger("Function1");
    // 直接从HttpRequestData获取请求Scheme
    logger.LogInformation(req.Url.Scheme);
    // 剩余业务逻辑
}

如果你的公共服务层大量依赖请求上下文，可以将所需的请求属性提取封装为自定义上下文对象，在函数入口将其注入到当前请求的服务作用域中，后续公共服务直接读取该自定义对象即可。

方案2：社区兼容方案（不推荐） #

如果旧项目中 IHttpContextAccessor 依赖量极大，短时间内改造完成的成本过高，可使用社区开源的兼容实现模拟 IHttpContextAccessor 能力，但需要自行承担兼容性和后续维护风险。

内容的提问来源于stack exchange，提问作者sschoof