Azure Function v4本地运行正常 部署后无qn参数报500错误

本地与云端运行表现差异并非Function运行时版本不一致导致，本质是代码存在未覆盖的边界逻辑bug，两边测试场景构造的默认请求内容不同，触发了不同代码分支：

• 本地发起GET请求调试时，请求体完全为空，ReadToEndAsync()读取到的内容是空值，JsonConvert.DeserializeObject处理空输入返回null。此时data?.name通过null条件运算符直接返回null，不会触发属性访问逻辑，代码正常走qn为空的响应分支，返回200结果。
• Azure门户「Code + Test」功能发起无参数GET请求时，会默认给请求附带值为空字符串""的JSON格式请求体，而非完全空的请求体。此时JsonConvert.DeserializeObject对该输入的反序列化结果是string类型的空实例，不是null。用dynamic类型变量访问.name属性时，相当于尝试从string类型对象上读取不存在的name属性，直接抛出运行时绑定异常，返回500错误，与日志记录的报错信息完全匹配。

核心是补全JSON反序列化的边界校验逻辑，禁止无判断直接访问dynamic类型反序列化结果的属性，可参考如下修改：

public static class HealthStatus
{
    [FunctionName("HealthStatus")]
    public static async Task<IActionResult> Run(
        [HttpTrigger(AuthorizationLevel.Function, "get", "post", Route = "health/status")] HttpRequest req,
        ILogger log)
    {
        log.LogInformation("C# HTTP trigger function processed a request.");

        string qn = req.Query["qn"];
        string requestBody = await new StreamReader(req.Body).ReadToEndAsync();
        object data = null;
        
        // 空请求体、非JSON格式请求体直接跳过反序列化逻辑，避免抛错
        if (!string.IsNullOrWhiteSpace(requestBody))
        {
            try
            {
                data = JsonConvert.DeserializeObject(requestBody);
            }
            catch
            {
                data = null;
            }
        }
        
        // 仅当反序列化结果为JSON对象结构时，才读取name字段
        if (data is Newtonsoft.Json.Linq.JObject jObj)
        {
            qn = qn ?? jObj.Value<string>("name");
        }

        string responseMessage = string.IsNullOrEmpty(qn)
            ? "qn : All. Status OK"
            : $"qn : {qn}. Status OK";

        return new OkObjectResult(responseMessage);
    }
}

长期维护建议：

• 尽量避免使用dynamic接收JSON反序列化结果，优先使用强类型模型或JObject做显式类型判断，从根源上避免动态绑定带来的运行时异常
• 健康检查类接口建议保持逻辑最小化，无特殊需求可以直接移除请求体解析逻辑，减少不必要的报错点

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