靠谱的cURL封装必须显式控制超时（CURLOPT_TIMEOUT、CURLOPT_CONNECTTIMEOUT）、SSL验证（CURLOPT_SSL_VERIFYPEER/VERIFYHOST）、错误检查（curl_errno后置）、统一返回结构（success/data/error/http_code），并支持可插拔鉴权、幂等重试与脱敏日志。
用 cURL 封装请求类，别绕开超时和错误处理
直接裸调 curl_init() 写接口请求，十次有八次在生产环境出问题——不是卡死就是返回空，根本不知道是网络断了、服务没响应，还是对方关了 SSL 验证。靠谱的第一步，是把超时、错误码、SSL 行为全显式控制住。
-
CURLOPT_TIMEOUT必设，建议 10～30 秒之间，别用默认值（可能无限等） -
CURLOPT_CONNECTTIMEOUT单独设（比如 5 秒），避免 DNS 解析慢拖垮整个请求 -
CURLOPT_SSL_VERIFYPEER和CURLOPT_SSL_VERIFYHOST要按环境开关：测试可关，线上必须开且配好 CA 证书路径 - 每次
curl_exec()后必须检查curl_errno($ch)，不能只看返回值是否为空
统一返回结构，别让调用方自己 json_decode() 猜结果
封装类返回的不应该是原始字符串或布尔值，而应是明确的数组结构，包含 success、data、error、http_code 四个字段。否则下游每次都要手动 json_decode($res, true) + 判空 + 判 code 字段，极易漏判。
- 成功时：
['success' => true, 'data' => [...], 'error' => null, 'http_code' => 200] - HTTP 层失败（如 404/502）：
['success' => false, 'data' => null, 'error' => 'HTTP 404 Not Found', 'http_code' => 404] - cURL 层失败（如超时、DNS 错）：
['success' => false, 'data' => null, 'error' => 'cURL error 28: Operation timed out', 'http_code' => 0]
支持常见认证方式，但别硬编码进方法签名
微信、支付宝、自建 Token 接口的鉴权方式五花八门：Bearer Token、API Key Header、Sign + Timestamp、Basic Auth……如果每个都写一个 postWithToken()、postWithSign() 方法，类会迅速膨胀且难维护。
- 把鉴权逻辑抽成可插拔的「处理器」，例如传入一个闭包：
function($ch) { curl_setopt($ch, CURLOPT_HTTPHEADER, ['Authorization: Bearer xxx']); } - 提供快捷静态方法如
HttpTool::withBearer('xxx')，但底层仍走同一入口，不重复写 cURL 设置逻辑 - 敏感字段如
AccessKeySecret绝对不要出现在方法参数里，应由调用方自行拼进 header 或 sign，封装层只负责透传
别忽略重试和日志，尤其是跨域或第三方接口
调第三方 API 时，偶发 502、连接被拒、TLS 握手失败太常见。不加重试，一次失败就中断业务；不记日志，出问题根本没法定位是对方抖动还是你参数错了。
立即学习“PHP免费学习笔记（深入）”；
- 重试策略建议最多 2 次，间隔递增（如 100ms → 300ms），且仅对幂等请求（GET / HEAD / PUT）开启
- 日志至少记录：URL、method、headers（脱敏敏感头）、耗时、最终
http_code、错误信息；别记完整 body，尤其含用户数据时 - 对微信这类强依赖签名的接口，日志里要额外记下生成的
sign和timestamp，方便和对方对账
真正难的不是把 cURL 参数串起来，而是让每一次失败都有迹可循、每一次重试都可控、每一次调用都不用再翻文档查 header 怎么写。封装的价值，是把「可能出错的点」全部显性化、可配置、可追踪。
