通过Bicep配置FunctionApp与AppService的appSettings差异咨询

本质区别 #

• 资源层级与API设计差异
  FunctionApp的appSettings是独立的子资源（Microsoft.Web/sites/config@2023-12-01），需通过parent关联到FunctionApp主体；而AppService的appSettings是嵌套在站点资源siteConfig属性下的数组。这源于Azure对两种资源的REST API设计不同：FunctionApp的配置是单独的资源端点，AppService则将配置整合在站点资源的属性中。

• 数据结构差异
  FunctionApp的appSettings采用键值对对象格式（KEY: value），结构简洁；AppService的则是包含name和value字段的对象数组，这种格式支持扩展更多配置属性（比如slotSetting用于部署槽的差异化配置）。

• 部署行为差异
  单独的config子资源部署时，可仅更新appSettings而不影响FunctionApp主体的其他配置；AppService修改siteConfig内的appSettings时，会和其他siteConfig变更一起触发应用重启。不过要注意，FunctionApp单独更新config资源同样会触发应用重启，只是粒度更聚焦在配置本身。

推荐配置方式 #

• FunctionApp：优先使用独立的config子资源方式。这种设计符合Bicep的资源模块化理念，便于将配置与应用主体分离管理，尤其是当配置项较多、需要关联其他资源（如引用KeyVault机密）时，拆分后代码结构更清晰，也和VS Code反编译工具生成的默认格式一致。

• AppService：两种方式均支持（也可将appSettings拆分为独立的config子资源），但通常推荐嵌套在siteConfig中。因为AppService的siteConfig还包含站点运行的核心配置（如alwaysOn、httpLoggingEnabled等），将appSettings放在一起便于统一管理整个站点的运行配置。如果需要单独更新appSettings而不改动其他站点配置，也可以采用独立config子资源的方式。

示例参考 #

FunctionApp独立config方式（推荐）

resource funcApp 'Microsoft.Web/sites@2023-12-01' = {
  name: funcAppName
  location: location
  kind: 'functionapp'
}

resource funcApp_appSettings 'Microsoft.Web/sites/config@2023-12-01' = {
  parent: funcApp
  name: 'appsettings'
  properties: {
    KEY1: value1
    KEY2: value2
  }
}

AppService嵌套siteConfig方式（推荐）

resource appService 'Microsoft.Web/sites@2023-12-01' = {
  name: appService_name
  location: location
  properties: {
    enabled: true
    serverFarmId: appServicePlan_id
    siteConfig: {
       appSettings: [
          {
            name: KEY1
            value: value1
          }
          {
            name: KEY2
            value: value2
          } 
       ]
    }
  }
}

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