多数情况下耗时过长是因为网络链路波动或触发了频率限制，建议优先排查客户端到腾讯服务器的网络质量，并将同步发送改为异步处理。

快速定位网络耗时

无需额外文件，直接使用 curl 的 -w 参数输出各阶段耗时，确认瓶颈是在 DNS、TCP 握手还是服务端处理。

curl -w "\ntime_namelookup: %{time_namelookup}\ntime_connect: %{time_connect}\ntime_starttransfer: %{time_starttransfer}\ntime_total: %{time_total}\n" -o /dev/null -s "https://qyapi.weixin.qq.com/cgi-bin/webhook/send?key=YOUR_KEY" -X POST -H "Content-Type: application/json" -d '{"msgtype":"text","text":{"content":"test"}}'

如果 time_connect 耗时较长，说明网络链路存在波动；如果 time_starttransfer 到 time_total 间隔大，可能是服务端处理慢或触发限流。

核心代码优化方案

避免在主线程同步等待，建议使用 HTTP 连接池复用 TCP 连接，并配合异步线程或消息队列。以下以 Python requests 库为例，展示如何配置连接池与重试机制。

import requests
from requests.adapters import HTTPAdapter
from urllib3.util.retry import Retry

# 创建 Session 复用连接
session = requests.Session()

# 配置重试策略：遇到 500/502/503/504 或连接错误时重试
retry_strategy = Retry(
    total=3,
    status_forcelist=[500, 502, 503, 504],
    backoff_factor=1
)

# 配置连接池：pool_connections 为连接池大小，pool_maxsize 为最大连接数
adapter = HTTPAdapter(
    pool_connections=10,
    pool_maxsize=10,
    max_retries=retry_strategy,
    pool_block=False
)

session.mount("https://", adapter)

def send_msg(content):
    try:
        # 设置合理超时，避免无限等待
        resp = session.post(
            url="https://qyapi.weixin.qq.com/cgi-bin/webhook/send?key=YOUR_KEY",
            json={"msgtype": "text", "text": {"content": content}},
            timeout=3
        )
        resp.raise_for_status()
    except Exception as e:
        # 记录日志或存入失败队列后续补偿
        print(f"Send failed: {e}")

关键配置参数参考

• 超时时间（timeout）：建议设置为 3-5 秒。过短容易误报超时，过长会阻塞线程。高可靠性场景需配合重试机制。
• 连接池大小（pool_maxsize）：根据并发量调整，一般服务设置为 10-50 之间，避免频繁创建 TCP 连接。
• 重试次数（max_retries）：建议 3 次左右，避免雪崩效应，同时防止消息丢失。

验证与监控

在代码中埋点记录每次 HTTP 请求的 start_time 和 end_time。优化后，对比日志中的平均耗时和最大耗时。同时关注业务侧是否还有因超时导致的报错。

如果使用异步方案，验证重点在于主业务流程的响应速度是否提升，以及消息最终是否都能成功送达（检查重试日志）。

常见坑与风险

• 同步阻塞主线程：在 Web 请求处理过程中直接调用机器人接口，一旦接口超时，会导致用户页面卡死。
• 忽略 SSL 握手耗时：短连接频繁建立会导致大量时间浪费在握手阶段，务必启用 HTTP Keep-Alive 或连接池。
• 异步发送丢失消息：改为异步后若未捕获异常或重试，网络波动会导致消息静默丢失，务必记录失败日志或存入死信队列。
• 消息体过大：虽然文本消息限制较宽，但过长的内容会增加传输和处理时间，尽量精简通知内容。