AWS Golang Lambda handler未调用且任务超时问题咨询

问题根因 #

这个现象和你的handler签名无关，核心原因是lambda.Start启动后无法和Lambda本地的Runtime API建立通信，一直卡在事件拉取的循环里，根本没有执行到调用HandleRequest的逻辑。你能看到main函数里的日志，说明二进制已经被正常加载启动，问题出在SDK初始化后的网络连接环节，最常见的诱因有两个：

• CGO动态链接的glibc版本不兼容
  Go1.x运行时基于老旧的Amazon Linux 1，内置glibc版本仅为2.17。如果你在新版本Linux发行版（比如Ubuntu 22.04+、Fedora 36+）上编译时没有关闭CGO，生成的二进制会动态链接本地高版本glibc。main函数里的fmt.Print逻辑简单，没有触发版本不兼容的符号，所以能正常输出；但lambda.Start内部依赖net/http发起本地HTTP请求，这部分逻辑调用到高版本glibc专属接口时会直接静默卡住，既不panic也不返回错误，直到触发Lambda超时阈值。
• 代理配置导致本地API访问失败
  Go标准库net/http默认会读取代理环境变量，如果你的Lambda配置了HTTP_PROXY/HTTPS_PROXY全局代理，但没有把本地环回地址加入排除列表，SDK会尝试通过远端代理访问127.0.0.1上的Runtime API，自然永远无法连通，只能不断重试直到超时。

解决步骤 #

1. 编译时强制关闭CGO，生成纯静态二进制，根据你的Lambda架构选择对应命令：
   • x86_64架构Lambda：

   CGO_ENABLED=0 GOOS=linux GOARCH=amd64 go build -o bootstrap main.go
   

   • arm64架构Lambda：

   CGO_ENABLED=0 GOOS=linux GOARCH=arm64 go build -o bootstrap main.go
   

2. 给二进制添加可执行权限：

   chmod +x bootstrap
   

3. 打包zip时直接将bootstrap文件放在压缩包根目录，不要嵌套任何子文件夹。
4. 部署时优先把运行时从已废弃的Go1.x切换为provided.al2（Amazon Linux 2自定义运行时），该运行时对高版本Go兼容性更好，无需额外配置handler值，运行时会自动执行根目录下的bootstrap文件。如果坚持使用Go1.x运行时，把控制台的handler配置值改为bootstrap即可。
5. 检查Lambda环境变量，如果存在HTTP_PROXY/HTTPS_PROXY配置，新增NO_PROXY环境变量，值设为127.0.0.1,localhost，跳过本地Runtime API的代理转发。

补充：Lambda环境下打印日志优先使用标准库log包，它会主动刷新输出缓冲区，避免fmt包因为行缓冲机制导致日志丢失。

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