调用Azure Communication Services Email API时遭遇EOF错误求助

可能的原因及排查步骤 #

1. 连接层异常（TLS/网络） #

EOF错误大多源于HTTP连接被提前关闭，优先排查以下点：

• 确认API端点正确性：ACS Email API的端点格式必须为 https://<resource-name>.communication.azure.com/emails:send?api-version=2023-03-31，检查域名拼写、API版本号是否匹配。
• 禁用HTTP/2测试：部分服务器对HTTP/2兼容性存在问题，在Go中可通过修改Transport强制使用HTTP/1.1：

transport := &http.Transport{
    TLSNextProto: make(map[string]func(authority string, c *tls.Conn) http.RoundTripper),
}
client := &http.Client{Transport: transport}

• 网络环境排查：用curl发起相同请求测试，排除代理、防火墙拦截导致的连接中断：

curl -X POST "https://<resource-name>.communication.azure.com/emails:send?api-version=2023-03-31" \
  -H "Authorization: HMAC-SHA256 SignedHeaders=x-ms-date;x-ms-content-sha256;host;content-type&Signature=<your-signature>" \
  -H "x-ms-date: <RFC1123-date>" \
  -H "x-ms-content-sha256: <body-sha256-base64>" \
  -H "Content-Type: application/json" \
  -d '{"senderAddress":"<verified-sender>","recipients":{"to":[{"address":"<recipient>"}]},"content":{"subject":"Test","plainText":"Hello World"}}'

2. 请求签名验证失败 #

签名错误可能导致服务器直接关闭连接（无明确错误返回），需逐一核对：

• x-ms-date格式与时效性：必须是RFC1123格式（如 Tue, 01 Aug 2023 12:00:00 GMT），且与生成签名时的时间完全一致，时间差不能超过15分钟。
• x-ms-content-sha256计算准确性：确保是请求体原始字节的SHA256哈希（Base64编码），不要对JSON做额外格式化（如删除空格、换行），保持与发送的请求体完全一致。
• Authorization头格式：严格遵循 HMAC-SHA256 SignedHeaders=x-ms-date;x-ms-content-sha256;host;content-type&Signature=<signature-value> 格式，注意SignedHeaders的顺序必须与签名时一致，且必须包含host字段。

3. 请求体内容不符合API规范 #

即使JSON语法正确，以下问题也可能触发服务器异常：

• 发件人验证状态：确认发件人地址是ACS中已验证的域或邮箱，未验证的发件人会被服务器拒绝，部分场景下会直接断开连接。
• 收件人地址合法性：检查收件人地址格式是否正确，无拼写错误（如缺少@、域名无效）。
• 简化请求体测试：暂时移除HTML内容、附件等非必填项，仅保留发件人、单个收件人、纯文本主题和内容，排除复杂内容导致的问题。

4. Go HTTP客户端配置问题 #

客户端配置不当可能导致连接中断：

• 增加超时时间：避免请求未完成就被客户端中断：

client := &http.Client{
    Timeout: 30 * time.Second,
}

• 正确关闭响应体：无论请求成功与否，都要调用resp.Body.Close()，避免连接泄漏影响后续请求：

resp, err := client.Do(req)
if err != nil {
    // 错误处理
    return
}
defer resp.Body.Close()
// 读取响应内容

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