.NET5开发的ServiceBusTrigger函数部署Azure后无法触发配置咨询

1. ServiceBus连接字符串配置名 #

直接填写ServicebusConnectionString即可。
Azure Functions门户中「应用设置」的键直接对应local.settings.json中Values节点下的键名，不需要加任何Values相关的前缀。其余带Values前缀、下划线分隔的候选都是环境变量转义或旧版本适配场景的选项，正常Windows/Linux部署下直接和本地Values下的键名保持一致即可，Linux环境下仅大小写不敏感，不会强制要求转下划线。

2. 嵌套配置对应的门户配置名 #

优先使用clients.mapId，如果部署在Linux环境不生效，替换为clients__mapId（双下划线分隔层级）即可。
.NET配置系统天生支持用.或者双下划线__作为嵌套层级的分隔符，大小写不敏感，所以全大写的CLIENTS_MAP_ID也可以被识别，但建议和代码中绑定的属性名保持大小写一致，降低维护成本。
注意：如果你的嵌套配置是写在local.settings.json的根节点而非Values节点下，本地运行时需要手动调整配置加载逻辑才能读取，Azure Functions默认只会自动加载Values和ConnectionStrings节点下的配置项。

3. .NET5函数部署到.NET6运行时的兼容性问题 #

不会引发兼容问题。
.NET本身具备向后兼容能力，且.NET5对应的是Azure Functions的独立进程模型，运行时是和函数App独立的，只要你项目中指定的.NET目标框架、函数worker配置没有错误，即可正常运行在.NET6的运行时栈上。但需要注意.NET5已经停止官方支持，建议后续逐步升级到.NET6或LTS版本的.NET运行时，避免安全风险。

补充疑问解答 #

local.settings.json是本地开发专用的配置文件，它的结构设计中Values节点是专门用来存放应用级配置的容器，本地运行时Azure Functions Core Tools会自动把Values节点下的所有键值对直接提取为环境变量，和生产环境中门户配置的应用设置直接作为环境变量注入的逻辑完全对齐。
相当于本地的Values节点只是一个分类容器，不会被作为配置键的前缀，因此生产环境不需要加Values前缀，两边的最终配置键逻辑是一致的，并没有出现修改键名的情况。

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