发送大附件邮件时API未等待响应的问题求助（附代码）

1. 上层ASP.NET请求超时限制 #

你的代码运行在HttpContextBase上下文（如ASP.NET MVC/WebForms）中，ASP.NET默认请求超时为110秒，即便你给HttpClient设置了20分钟超时，一旦ASP.NET自身的请求超时触发，整个线程会被强制终止，导致HttpClient的请求被中断，直接进入异常分支。

修复方案： #

在Web.config中修改ASP.NET请求超时配置：

<system.web>
  <!-- 设置为20分钟（1200秒），同时适配异步请求 -->
  <httpRuntime executionTimeout="1200" asyncTimeout="1200" />
</system.web>

2. PostAsJsonAsync大对象序列化瓶颈 #

PostAsJsonAsync会将包含25MB附件的Email对象一次性序列化到内存后再发送，这不仅会占用大量内存，还可能触发TCP传输层面的超时，或被中间代理/服务器截断。相比直接调用API，代码里的序列化方式会放大传输风险。

修复方案： #

改用流式分块发送，避免一次性加载整个对象到内存：

public static async Task<string> SendEmail1(HttpContextBase contextBase, Email email)
{
    string status = string.Empty;
    try
    {
        string Token = await GetVendorToken(contextBase, vendorCredentialDetails);
        string baseAddress = EHRAppSettingsDictionary.GetKeyValue("abc");
        
        // 改用MultipartFormDataContent分块发送（需确保API支持表单上传）
        using var client = new HttpClient(new HttpClientHandler { AutomaticDecompression = DecompressionMethods.GZip });
        client.DefaultRequestHeaders.Accept.Clear();
        client.DefaultRequestHeaders.AcceptEncoding.Add(new StringWithQualityHeaderValue(SharedConstants.StringWithQualityHeaderValue));
        client.DefaultRequestHeaders.Accept.Add(new MediaTypeWithQualityHeaderValue(SharedConstants.MediaTypeWithQualityHeaderValue));
        client.DefaultRequestHeaders.Add("Authorization", Token);
        client.BaseAddress = new Uri(baseAddress);
        client.Timeout = TimeSpan.FromMinutes(20);

        var content = new MultipartFormDataContent();
        // 添加邮件基础信息（根据Email类属性调整）
        content.Add(new StringContent(email.To), "To");
        content.Add(new StringContent(email.Subject), "Subject");
        // 流式加载附件，避免内存过载
        using var attachmentStream = new MemoryStream(email.AttachmentBytes);
        content.Add(new StreamContent(attachmentStream), "Attachment", email.AttachmentFileName);

        HttpResponseMessage response = await client.PostAsync("api/EMAIL/SendEmail", content).ConfigureAwait(false);
        
        if (response.IsSuccessStatusCode)
        {
            status = "Success";
        }
        else
        {
            // 读取API返回的详细错误信息，替代笼统提示
            var errorDetail = await response.Content.ReadAsStringAsync().ConfigureAwait(false);
            status = $"Error: {errorDetail}";
        }
    }
    catch (TaskCanceledException ex)
    {
        // 明确区分超时和主动取消
        status = ex.CancellationToken.IsCancellationRequested 
            ? "Error: Request canceled" 
            : $"Error: Request timed out - {ex.Message}";
    }
    catch (Exception ex)
    {
        // 包含内部异常信息，便于排查
        var fullError = ex.InnerException != null 
            ? $"{ex.Message} | Inner Error: {ex.InnerException.Message}" 
            : ex.Message;
        status = $"Error: {fullError}";
    }
    return status;
}

如果API仅支持JSON格式，可启用分块传输：

client.DefaultRequestHeaders.TransferEncodingChunked = true;

3. 重复创建HttpClient导致连接池问题 #

每次调用方法都新建HttpClient实例，会导致HTTP连接池耗尽，底层连接被提前回收，进而引发请求中断。

修复方案： #

复用全局HttpClient实例（如静态单例或依赖注入单例）：

// 全局静态HttpClient，仅初始化一次
private static readonly HttpClient _sharedHttpClient = new HttpClient(new HttpClientHandler { AutomaticDecompression = DecompressionMethods.GZip });

static YourClassName()
{
    _sharedHttpClient.DefaultRequestHeaders.AcceptEncoding.Add(new StringWithQualityHeaderValue(SharedConstants.StringWithQualityHeaderValue));
    _sharedHttpClient.DefaultRequestHeaders.Accept.Add(new MediaTypeWithQualityHeaderValue(SharedConstants.MediaTypeWithQualityHeaderValue));
    _sharedHttpClient.Timeout = TimeSpan.FromMinutes(20);
}

在方法中使用时，仅动态修改必要的请求头：

_sharedHttpClient.BaseAddress = new Uri(baseAddress);
// 移除旧Token，添加新Token
_sharedHttpClient.DefaultRequestHeaders.Remove("Authorization");
_sharedHttpClient.DefaultRequestHeaders.Add("Authorization", Token);

4. 异常信息被掩盖 #

原代码仅捕获Exception并返回ex.Message，但HttpClient超时会抛出TaskCanceledException，很多底层错误信息会藏在InnerException中，导致无法定位真实问题。

修复方案： #

如上述代码所示，单独捕获TaskCanceledException并区分超时场景，同时包含内部异常信息，便于精准排查。

验证步骤 #

1. 先修改异常捕获逻辑，获取详细错误信息，确认是超时还是传输错误；
2. 同步调整ASP.NET请求超时配置，确保与HttpClient超时一致；
3. 切换为流式发送大附件，验证是否解决问题；
4. 复用HttpClient实例，优化连接池使用。

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