最常用也最容易出错的是用curl_setopt设置Authorization头；必须显式通过CURLOPT_HTTPHEADER传Bearer等约定格式的Token，避免空格、编码问题，并匹配Content-Type与POST数据格式。
curl_setopt 设置 Authorization 头最常用也最容易出错
PHP 用 curl 模拟带 Token 的 POST 请求，核心就是把 Token 正确塞进请求头的 Authorization 字段。不是拼在 URL 里，也不是当 POST body 传——90% 的失败都卡在这步。
常见错误现象：401 Unauthorized、403 Forbidden，但服务端日志显示“missing token”或“invalid format”。这时候大概率是头没设对，或者格式不匹配（比如该用 Bearer xxx 却只传了 xxx）。
实操建议：
- Token 类型必须和服务端约定一致：多数是
Bearer，少数用Token、API-Key或自定义前缀，看接口文档 - 用
curl_setopt($ch, CURLOPT_HTTPHEADER, [...])显式设置，不要依赖自动合并 - 确保 Token 字符串本身不含多余空格或换行，建议用
trim()处理 - 如果 Token 是从文件或数据库读取的，注意编码是否为 UTF-8，避免不可见字符干扰
POST 数据体格式要和 Content-Type 匹配
Token 只是身份凭证，真正要发的数据（比如 user_id=123&action=save 或 JSON）还得按服务端要求组织。错配 Content-Type 会导致后端解析失败，哪怕 Token 正确也返回 400 Bad Request。
立即学习“PHP免费学习笔记（深入）”；
实操建议：
- 发表单数据（
application/x-www-form-urlencoded）：用http_build_query()构造 body，别手动拼字符串 - 发 JSON（
application/json）：用json_encode()，并确保Content-Type头同步设置 - 不设
Content-Type头时，cURL 默认用application/x-www-form-urlencoded，但很多 API 强制校验，必须显式声明 - 用
curl_setopt($ch, CURLOPT_POSTFIELDS, $data)传 body，不要混用POSTFIELDS和HTTPHEADER里的Content-Length（cURL 会自动算）
忽略 SSL 验证在开发环境可行，上线必须关掉
本地调测试接口经常遇到 cURL error 60: SSL certificate problem，临时加 CURLOPT_SSL_VERIFYPEER => false 能跑通，但这等于放弃 HTTPS 安全校验。
实操建议：
- 开发阶段可加
CURLOPT_SSL_VERIFYPEER => false和CURLOPT_SSL_VERIFYHOST => false快速验证逻辑 - 上线前必须删掉这两行，改用
CURLOPT_CAINFO指向可信 CA 证书路径（如/etc/ssl/certs/ca-certificates.crt） - 若服务端用自签名证书，应让运维提供对应根证书，而非全局禁用验证
- 部分旧版 PHP（如 5.6）默认不带 CA 包，需手动配置或升级 OpenSSL
调试时用 curl_getinfo 和 curl_error 看真实发出的请求
光看 PHP 代码很难判断 Token 到底有没有发出去、header 格式对不对、body 是不是被截断。得靠 cURL 自带的诊断能力。
实操建议：
- 请求后立即调用
curl_getinfo($ch)，重点关注http_code、content_type、redirect_url - 失败时必查
curl_error($ch)，它比 HTTP 状态码更早暴露底层问题（如 DNS 失败、连接超时） - 加
CURLOPT_HEADER => true可在响应里看到完整返回头，确认服务端是否返回了X-RateLimit-Remaining这类调试字段 - 实在不确定，用
curl -v命令行复现相同请求，对比 header 和 body 是否一致
Token 本身不加密，传输过程全靠 HTTPS 保护；任何把 Token 写死在代码里、打在日志中、或通过 GET 参数传递的行为，都会导致泄露。真正的难点从来不在“怎么发”，而在于“怎么管”。
