Bicep重部署消费计划Azure函数应用时超出部署槽数上限报错

• 第一是配额超限：你使用的Y1为Azure Functions经典消费计划SKU，该SKU硬限制每个函数应用最多只能创建1个额外部署槽（算上生产槽总计2个槽位），你配置了2个部署槽本身不符合配额要求。首次部署能成功是因为你使用的2021-03-01版Web资源API存在校验缺陷：逐个创建槽位时配额计数存在延迟，未实时统计已创建的槽位，属于漏判，不代表配置合法。
• 第二是配置触发校验逻辑bug：你在部署槽资源的properties中显式配置了serverFarmId字段。首次创建槽位（站点子资源）时，ARM会直接让槽继承父站点的宿主计划，不会触发计划变更校验；但后续增量重部署时，即使你传入的serverFarmId和当前值完全一致，ARM也会识别为你有修改槽位宿主计划的意图，进入跨计划迁移校验流程——该流程针对消费计划有强制校验：只要检测到计划关联操作，就会判定不允许存在部署槽，直接抛出你看到的报错，和实际槽数量无关。

• 第一步先处理配额问题：如果确实需要保留2个及以上部署槽，将函数应用的宿主计划SKU从Y1消费计划升级为弹性高级计划（EP1/EP2/EP3）或专用应用服务计划（S1及以上），这类SKU支持最多20个部署槽；如果不需要多个槽，删除多余的部署槽，将额外部署槽数量控制在1个以内，符合Y1 SKU的配额限制。注意如果已经通过首次部署创建了超量槽位，需要先手动删除多余槽位再执行后续部署。
• 第二步修正Bicep配置：删除所有部署槽资源properties块中的serverFarmId字段，部署槽作为函数站点的子资源，会自动继承父站点的宿主计划配置，无需显式指定，从根源避免触发计划变更校验逻辑。
• 第三步升级API版本：将Microsoft.Web/serverfarms、Microsoft.Web/sites、Microsoft.Web/sites/slots三个资源的API版本从老旧的2021-03-01升级到稳定版2023-12-01，新版API修复了消费计划下槽位校验延迟、重复计数、同值serverFarmId误判为计划变更的已知问题。

修正后的部署槽核心配置参考：

// 升级API版本、移除serverFarmId后的部署槽配置
resource appServiceSlot 'Microsoft.Web/sites/slots@2023-12-01' = {
  name: slotName
  location: location
  parent: appServicFuncApp
  identity: {
    type: 'SystemAssigned'
  }
  properties: {
    enabled: true
    httpsOnly: true
    // 移除serverFarmId配置，自动继承父站点关联的应用服务计划
  }
}

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