使用AWS Toolkit构建SAM应用时出现Go依赖错误问题咨询

根目录执行sam build批量构建时，SAM会为每个Lambda函数创建独立的临时构建沙箱，仅将函数CodeUri配置指向的目录内容拷贝到沙箱内执行构建，不会主动向上遍历目录加载项目根目录的公共模块配置、go.sum校验文件。
在端点自身目录单独执行sam build能成功，是因为本地直接构建时Go模块机制会自动向上递归查找父目录的go.mod，可正常读取根目录公共service模块的aws-sdk-go依赖声明；但批量构建时沙箱隔离了路径访问，既拿不到根目录的go.sum，也无法正常解析公共模块的传递依赖校验信息，就会抛出缺失go.sum条目的错误。

三选一即可，优先选前两种长期稳定的方案：

• 方案1：给每个端点的go.mod补全传递依赖
  切到每个端点的目录下执行go mod tidy，命令会自动识别当前端点引用的所有直接、传递依赖，把aws-sdk-go这类公共模块引入的依赖的校验和写入端点自身的go.sum文件。所有端点都执行完该命令后，回到根目录重新执行sam build即可正常构建。
• 方案2：调整template.yaml的函数构建配置
  把每个函数的CodeUri设置为项目根目录，同时指定Handler为对应端点main文件的相对路径，让构建沙箱能直接拿到根目录所有公共代码、全局go.mod/go.sum文件。配置参考：

  Resources:
    EndpointAFunction:
      Type: AWS::Serverless::Function
      Properties:
        CodeUri: ./
        Handler: api/matches/endpoint-a/main.go
        Runtime: provided.al2 # 替换为实际使用的Go运行时版本
        # 其余事件、权限等原有配置保持不变
  

• 方案3：构建前预加载全局依赖
  根目录执行sam build前，先在根目录运行go mod download all提前拉取所有模块到本地Go模块缓存，部分环境下可以绕过沙箱内的依赖校验问题，但该方案兼容性差，换CI/CD环境或者新设备拉代码后很容易复现问题，不推荐长期使用。

避坑提示：如果端点go.mod里用了replace指令指向本地根目录的公共service模块，要确保replace的路径在构建上下文里是可访问的，不然就算解决了go.sum问题，后续也会报找不到本地模块的错误。

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