Requests库中requests.exceptions.Timeout仅捕获高层超时，而底层系统级超时（如DNS解析、SSL握手、TCP重传卡死）会以TimeoutError嵌套在ConnectionError中抛出，导致常规except无法捕获——必须分层判断__cause__并统一兜底。

requests库中`requests.exceptions.timeout`仅捕获高层超时，而底层系统级超时（如dns解析、ssl握手、tcp重传卡死）会以`timeouterror`嵌套在`connectionerror`中抛出，导致常规except无法捕获——必须分层判断`__cause__`并统一兜底。

在Python网络编程中，“超时未被捕获”是生产环境高频故障源，其根本原因在于：requests的timeout参数仅作用于其应用层逻辑（连接建立 + 响应读取），但无法干预操作系统socket层面的阻塞行为。当发生DNS解析超时、TLS握手僵死、防火墙SYN丢包重传失败等底层问题时，requests会将原始socket.timeout或TimeoutError包裹进requests.exceptions.ConnectionError中，而非直接抛出requests.exceptions.Timeout。

因此，你看到的两种日志现象本质不同：

• ✅ Request to ... timed out after 10 seconds → 触发了requests.exceptions.Timeout（高层超时，已正确捕获）；
• ❌ Request failed: ('Connection aborted.', TimeoutError('timed out')) → 底层TimeoutError被包装为ConnectionError的__cause__，落入了通用RequestException分支，未被识别为超时。

正确的分层异常处理策略

应构建三层防御机制：显式超时设置 → 精确类型捕获 → 原因穿透校验。以下是推荐的健壮实现：

macOS UI 自动化技能包 —— 用 Python 控制你的 Mac

让 macOS 自动化像说话一样简单 —— 用代码控制你的 Mac，无需学习 AppleScript 系统要求 macOS 14+ (Sonoma) Python 3.9+ 需要开启：辅助功能 + 屏幕录制权限

下载

import requests
from requests.exceptions import (
    Timeout,
    ConnectionError,
    HTTPError,
    RequestException
)
import logging

def robust_api_call(api_url, payload, timeout=(3, 10)):
    """
    带全路径超时识别与重试能力的安全API调用
    timeout: tuple (connect_timeout, read_timeout)，推荐(3, 10)
    """
    try:
        response = requests.post(
            api_url,
            json=payload,
            timeout=timeout,
            headers={"Content-Type": "application/json"}
        )
        response.raise_for_status()  # 触发HTTPError（4xx/5xx）

        # 安全解析JSON
        try:
            result = response.json()
            structured_output = result.get("message", {}).get("content")
            if not isinstance(structured_output, str):
                raise ValueError("Expected string content in message.content")
            parsed = json.loads(structured_output)
            return json.dumps(parsed, indent=2)
        except (ValueError, KeyError, json.JSONDecodeError) as e:
            logging.warning(f"Invalid response structure: {e} | Raw: {response.text[:200]}")
            return f"Parse error: {e}"

    # 第一层：requests明确超时（连接/读取阶段）
    except Timeout as e:
        logging.error(f"[HIGH-LEVEL TIMEOUT] {api_url} failed after {timeout}: {e}")
        raise TimeoutError(f"High-level timeout on {api_url}: {e}") from e

    # 第二层：ConnectionError —— 必须检查其根本原因是否为TimeoutError
    except ConnectionError as e:
        cause = getattr(e, "__cause__", None)
        if isinstance(cause, (TimeoutError, socket.timeout)):
            logging.error(f"[LOW-LEVEL TIMEOUT] OS-level timeout on {api_url}: {cause}")
            raise TimeoutError(f"Low-level timeout (DNS/TLS/SYN): {cause}") from e
        else:
            logging.error(f"[NETWORK FAILURE] Connection failed for {api_url}: {e}")
            raise ConnectionError(f"Network unreachable: {e}") from e

    # 第三层：其他HTTP/请求异常（含HTTPError已由raise_for_status触发）
    except HTTPError as e:
        logging.warning(f"[HTTP ERROR] {e.response.status_code} from {api_url}")
        return f"HTTP {e.response.status_code}: {e.response.reason}"
    except RequestException as e:
        logging.error(f"[REQUEST ERROR] Unhandled request exception: {e}")
        raise RuntimeError(f"Unexpected request failure: {e}") from e

关键注意事项

• ✅ 永远使用元组形式 timeout=(connect, read)：避免单值timeout=10导致读取阶段无约束；
• ✅ 禁用 timeout=None 或省略timeout：这等于主动放弃超时控制，生产环境零容忍；
• ✅ 不要依赖 except Exception: 兜底：会掩盖超时信号，丧失故障定位能力；
• ⚠️ Windows / 企业内网更易触发底层超时：因DNS缓存策略、代理拦截、SSL中间设备等原因，建议在关键服务中叠加线程级强制中断（见下文增强方案）；
• ? 补充重试逻辑（可选但强烈推荐）：结合urllib3.Retry实现指数退避重试，仅对幂等请求（GET/HEAD/OPTIONS）启用：

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

session = requests.Session()
retry_strategy = Retry(
    total=3,
    backoff_factor=1,
    status_forcelist=[429, 500, 502, 503, 504],
    allowed_methods=["HEAD", "GET", "OPTIONS", "POST"]  # POST默认不重试，按需开启
)
adapter = HTTPAdapter(max_retries=retry_strategy)
session.mount("http://", adapter)
session.mount("https://", adapter)
# 后续用 session.post(...) 替代 requests.post(...)

终极保障：线程级超时（应对顽固阻塞）

若业务对响应确定性要求极高（如实时风控、金融报价），建议将请求封装进独立线程，并用threading.Thread.join(timeout)实施硬性截断：

立即学习“Python免费学习笔记（深入）”；

import threading
from queue import Queue

def thread_safe_request(url, payload, timeout_total=15):
    result_q = Queue()

    def _worker():
        try:
            resp = requests.post(url, json=payload, timeout=(3, 10))
            result_q.put(("success", resp))
        except Exception as e:
            result_q.put(("error", e))

    t = threading.Thread(target=_worker)
    t.start()
    t.join(timeout_total)  # 强制15秒后终止线程（注意：Python线程不可杀，但join返回即表示超时）

    if t.is_alive():
        logging.error(f"Thread forced timeout after {timeout_total}s for {url}")
        raise TimeoutError(f"Thread-level timeout on {url}")

    status, data = result_q.get()
    if status == "error":
        raise data
    return data

总结：超时不是单一异常，而是分层现象。真正健壮的HTTP客户端必须同时覆盖 requests.Timeout（应用层）、ConnectionError.__cause__（系统层）、以及外层线程/协程级超时（运行时层）。唯有如此，才能在复杂网络环境中实现“可预期、可监控、可恢复”的稳定通信。