Serverless中SSM引用嵌套env变量报错求助

先排查环境变量加载是否正常 #

先确认${env:ENV}是否能被正确读取，避免是环境变量本身没加载导致的嵌套失败：

• 在serverless.yml里临时加一个测试环境变量：

  provider:
    environment:
      TEST_ENV: ${env:ENV, "NOT_VALID"}
  

• 运行serverless print命令，查看输出里TEST_ENV的实际值。如果显示的是NOT_VALID，说明当前终端没正确设置ENV环境变量（比如没执行export ENV=xxx），或者Serverless进程无法读取到该变量。

调整嵌套变量的写法 #

新版本Serverless对变量解析的优先级或语法可能有调整，试试以下两种写法：

1. 提取变量到custom块后再引用，避免直接嵌套：

   custom:
     currentEnv: ${env:ENV, "NOT_VALID"}
   provider:
     environment:
       SQS_URL: ${ssm:/foo/${self:custom.currentEnv}/sqsUrl}
   

2. 去掉默认值的引号（部分版本对字符串默认值的解析有变化）：

   ${ssm:/foo/${env:ENV, NOT_VALID}/sqsUrl}
   

验证SSM参数的存在性与权限 #

• 确认对应环境的SSM参数确实存在：比如当ENV=prod时，SSM中必须有/foo/prod/sqsUrl这个参数。
• 用AWS CLI手动测试权限：

  aws ssm get-parameter --name /foo/[你的ENV实际值]/sqsUrl
  

如果CLI返回参数不存在或权限错误，先解决这个问题（创建参数或给部署角色添加ssm:GetParameter权限）。

临时回退变量解析模式（应急方案） #

如果以上方法都不行，可以尝试切换到旧版的变量解析模式，兼容之前的写法：
在serverless.yml根节点添加：

variablesResolutionMode: 20210326

注意：这只是临时方案，建议后续逐步适配新版本的变量解析规则。

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