Azure Function（PowerShell）接收双重编码JSON体的异常原因咨询

我运行着一个基于PowerShell的Azure Function，包含编排器功能，此前一直通过JSON请求体调用该函数。今日测试时，函数报错称请求体缺少必要参数，排查后发现需要执行两次JSON转换才能解决问题。

修复前代码 #

$request = $Context.Input | ConvertFrom-json -AsHashtable

Write-Information "ServicePrincipal: $($request.ServicePrincipalName)"

执行后输出：ServicePrincipal:

修复后代码 #

$request = $Context.Input | ConvertFrom-json -AsHashtable
if ($($request.gettype().name) -eq 'String') {
    $request = $request | ConvertFrom-json -AsHashtable
    Write-Host $($request.gettype().name)
}
Write-Information "ServicePrincipal: $($request.ServicePrincipalName)"

执行后输出：HashTable 及 ServicePrincipal: myname@myorg.com

疑问：为何请求体内容的行为突然发生变化？

• Azure Functions运行时版本更新：若最近Azure Functions的PowerShell运行时（如Az Functions Runtime 4.x小版本更新）有变更，可能修改了$Context.Input的序列化逻辑。此前运行时可能自动将JSON请求体反序列化为对象/哈希表，现在仅传递原始JSON字符串，导致第一次ConvertFrom-Json后仍得到字符串，需二次转换。
• 请求内容的编码或格式变化：测试时的请求可能在传输中被额外序列化了一次（比如客户端误将JSON对象再次执行JSON.stringify），到达函数时的请求体是JSON字符串的JSON表示（外层为字符串包裹的JSON），第一次转换后得到原始JSON字符串，需二次转换才能解析为哈希表。
• 触发器或编排器配置变更：若近期修改了Function的触发器类型、绑定配置，或是编排器的输入输出序列化设置，可能影响$Context.Input的格式。比如Durable Functions编排器的上下文序列化策略调整，导致输入内容被双重序列化。
• PowerShell模块版本变化：ConvertFrom-Json的行为可能随PowerShell版本或相关模块更新而改变，不同版本对输入类型的处理逻辑存在差异，导致第一次转换未能正确解析嵌套的JSON结构。

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