Bicep name属性作用与模块内资源名正确引用方法咨询

1. vas_resource_group.name 的实际指向 #

这个写法拿到的不是模块内部创建的资源组的实际名称，它返回的是你在main.bicep中声明模块时，模块块内填写的name: 'vas_resource_group'值——也就是这个模块对应的底层ARM嵌套部署资源（Microsoft.Resources/deployments类型）的资源名。
你修改后错误消失，仅仅是因为这个硬编码的字符串值在部署启动前就能确定，满足scope属性对值的编译期可计算要求，但这个值和你要的rg-xxx格式的资源组名完全无关，用它做scope部署会直接报目标资源组不存在的错误。

2. Bicep中name属性的统一逻辑 #

Bicep里所有声明块中的name属性逻辑是完全一致的，不存在“有时有效有时无效”的区别：name永远对应当前声明块所代表的Azure资源的实际资源名称。你觉得它在模块场景下“没用”，本质是没搞清楚模块声明块对应的实际Azure资源是什么：

• 当你声明普通资源（比如示例中的Microsoft.Resources/resourceGroups），name自然就是这个资源组在Azure中的实际名称，符合直觉。
• 当你声明module块，这个块在底层对应的Azure资源是部署资源（Microsoft.Resources/deployments），它是用来承载子模块部署操作的元资源，不是模块内部创建的业务资源。这里写的name是这个部署元资源的名称，只会出现在Azure的部署操作记录里，和模块内部创建的任何业务资源的名称没有绑定关系。

另外要注意区分：等号左侧的vas_resource_group是Bicep文件内的本地符号名，仅用于当前文件内的代码引用，不会上传到Azure，和任何name属性都没有关系。

3. 获取模块内资源实际名称的最佳实践 #

首先要明确你遇到BCP120错误的根本原因：scope属性是部署编排阶段就要确定的参数，必须在部署启动前、任何资源创建前就能计算出值，而模块的outputs是模块部署完成后才能返回的运行时值，天然不能用来给scope赋值。
针对你的场景，正确做法按优先级排序：

• 优先方案：抽离公共命名逻辑，不要把命名规则封装在模块内部
  把资源组名称的拼接逻辑提成可在编译期计算的公共变量/函数，在main.bicep中直接计算出最终的资源组名称，再作为参数传入模块，从根源保证命名一致：

  // main.bicep 中先计算最终名称
  var rgName = 'rg-${runningNumber}-${descriptionShort}-${function}-${regionShort}-${environment}'
  
  module vas_resource_group '../common/resource_group.bicep' = {
    name: 'vas_resource_group_deploy' // 这里是部署元资源的名称，不影响业务资源
    params: {
      rgName: rgName // 把预计算的名称作为参数传给模块
      location: defaultLocation
      // 其余参数省略
    }
  }
  
  // 同文件中其他需要用到该资源组scope的模块，直接用提前算好的rgName即可，不需要引用模块属性
  module otherModule 'xxx.bicep' = {
    name: 'other_deploy'
    scope: resourceGroup(rgName)
    // 其余配置省略
  }
  

  对应的资源组模块直接接收传入的名称参数即可：

  // resource_group.bicep
  param rgName string
  param location string
  
  resource resource_group 'Microsoft.Resources/resourceGroups@2021-01-01' = {
    name: rgName
    location: location
  }
  
  output name string = resource_group.name
  

  这种方案完全规避了跨模块引用运行时值的问题，也保证了全链路命名规则一致，是生产环境的标准做法。
• 备选方案：将依赖同scope的资源收拢到对应模块内部
  如果你确实要把命名逻辑封装在资源组模块里，那所有需要部署到这个资源组的资源，都应该直接写在资源组模块内部，作为模块的一部分一起部署，不需要在main文件里跨模块引用scope。

不要用vas_resource_group.name来猜测内部资源名，这个值和模块内业务资源没有任何绑定关系，随时可能因为你修改模块部署名导致故障。

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