核心用法
Azure Bicep Deploy 是微软 Azure 原生支持的基础设施即代码（IaC）工具链，专注于通过声明式 Bicep 或 JSON ARM 模板管理云资源。核心能力覆盖四大场景：
1. 模板部署：支持 az deployment group create 命令将 Bicep (.bicep) 或 ARM (.json) 模板部署到指定资源组，配合参数文件实现灵活配置。
2. 预部署验证：what-if 模式可在实际执行前预览资源变更，避免意外修改；az bicep build 提供纯语法校验。
3. 多环境管理：通过 params/ 目录下的环境专属参数文件（dev/staging/prod）实现一套模板多环境复用，是 GitOps 工作流的标准实践。
4. 容器工作负载：内建 Azure Container Apps 支持，涵盖 Ingress、自动扩缩容、版本管理等企业级容器部署需求。
显著优点
- 官方原生：Bicep 为微软第一方 DSL，与 Azure ARM API 实时同步，无功能滞后
- 渐进迁移：现有 ARM 模板可无损转换为 Bicep，双向兼容降低采纳门槛
- IDE 友好：VS Code 插件提供 IntelliSense、语法高亮、错误即时反馈
- 成本可控：what-if 预览避免误操作导致的资源浪费，特别适合生产环境
潜在局限
- Azure 锁定：语法与语义深度绑定 Azure 资源模型，多云/混合云场景需额外适配
- 学习曲线：虽比原生 ARM JSON 简洁，但需理解 Azure 资源拓扑与依赖关系
- 状态管理：无内置状态文件（对比 Terraform），依赖 ARM 的幂等性语义，复杂场景需自行设计部署策略
- 社区生态：模块仓库规模不及 Terraform Registry，第三方模块复用度有限
适合人群
- Azure 重度用户与云架构师
- 已采用 GitHub Actions/Azure DevOps 的 DevOps 团队
- 需管理多环境（dev/staging/prod）一致性的工程组织
- 容器化工作负载（ACA/AKS）运维人员
常规风险
- 权限蔓延：部署服务主体（SPN/MI）需
Contributor或更细粒度 RBAC，配置不当易致权限过大 - 敏感泄露：参数文件可能含连接字符串、密钥，需配合 Azure Key Vault 或 GitHub/Azure DevOps Secrets 管理
- 并发冲突：多流水线同时部署同一资源组可能触发 ARM 级乐观锁失败
- 模板漂移：手动门户修改未被模板覆盖，导致配置漂移（drift）