curl 是 PHP 中唯一兼顾可靠性、可控性和兼容性的 HTTP 请求方案；file_get_contents 不适用于生产 POST，因其吞状态码、无法获取响应头、超时控制失效；curl_init 后必须设置 CURLOPT_URL、RETURNTRANSFER、FOLLOWLOCATION、TIMEOUT 四选项；JSON POST 需显式设置 Content-Type 和 Content-Length 头；HTTPS 必须配置 CURLOPT_CAINFO；curl_exec 返回 false 须调 curl_error 诊断，返回字符串须校验 HTTP 状态码及响应体内容。
curl 是 PHP 中唯一能兼顾可靠性、可控性和兼容性的 HTTP 请求方案——其他方式要么掩盖错误，要么缺失关键能力，要么依赖外部环境不可控。
为什么 file_get_contents 不该用于生产环境的 POST 请求
它根本不是为交互式请求设计的：file_get_contents 默认只处理 GET；强行用 stream_context_create 拼 POST 会带来三类硬伤：
- 状态码被吞：HTTP 400/500 响应仍返回空字符串或
false，无法区分“成功但无内容”和“失败” - 响应头不可得：没有原生接口获取
Content-Type、Set-Cookie或重定向地址，只能靠解析$http_response_header，而这个变量不稳定、易被覆盖 - 超时控制失效：
default_socket_timeout是全局设置，不能按请求粒度控制连接超时（CURLOPT_CONNECTTIMEOUT）或总耗时（CURLOPT_TIMEOUT）
curl_init 后必须设的四个基础选项
少一个就可能在上线后出诡异问题：
-
CURLOPT_URL：目标地址，必须是完整 URL（含协议），不能是相对路径 -
CURLOPT_RETURNTRANSFER：必须设为true，否则响应直接输出到 stdout，无法捕获或判断 -
CURLOPT_FOLLOWLOCATION：设为true才能自动跟随 301/302，否则需手动解析Location头再发第二次请求 -
CURLOPT_TIMEOUT：建议显式设为30（秒），避免 DNS 卡死或后端无响应导致整个脚本挂起
发送 JSON POST 时最容易漏掉的两个头
只传 json_encode($data) 到 CURLOPT_POSTFIELDS 是不够的，服务器大概率返回 415 Unsupported Media Type：
CurlShip Directory Submission
下载
向CurlShip提交产品，这是一个对机器人友好的SaaS目录。只需一条curl命令即可发布产品，支持OG标签抓取、带徽章的dofollow链接及层级升级。
- 必须加
Content-Type: application/json到CURLOPT_HTTPHEADER数组里 - 必须显式加
Content-Length: ' . strlen($json)，否则某些严格服务端（如 Spring Boot 默认配置）会拒绝请求 - 如果目标是 HTTPS 接口，别关
CURLOPT_SSL_VERIFYPEER——测试环境可临时设false，但上线前务必指定 CA 路径：CURLOPT_CAINFO指向/etc/ssl/certs/ca-certificates.crt或对应 PEM 文件
curl_exec 返回 false 后不查 curl_error 就报错等于放弃诊断
网络层失败（DNS 解析失败、连接拒绝）、协议层失败（SSL 握手失败）、服务端返回非 2xx 状态码——这三类错误全靠不同机制暴露：
立即学习“PHP免费学习笔记（深入）”；
-
curl_exec()返回false：只说明 cURL 层执行失败，调curl_error($ch)才能看到具体原因（如Could not resolve host） - 返回非
false字符串：不代表成功，要立刻调curl_getinfo($ch, CURLINFO_HTTP_CODE)检查状态码是否为 2xx - 即使状态码是 200，也要检查响应体是否为空或含错误字段（比如 API 返回
{"code":500,"msg":"internal error"}）
真正安全的请求收尾不是 curl_close($ch)，而是先确认 curl_errno($ch) === 0 且 curl_getinfo($ch, CURLINFO_HTTP_CODE) >= 200 && curl_getinfo($ch, CURLINFO_HTTP_CODE) 。
