根本原因是未设置CURLOPT_RETURNTRANSFER导致返回true而非响应体、POST数据未正确编码或未声明Content-Type，以及JSON前存在BOM/HTTP头/编码不一致等问题。
用 curl_init() 发起 POST 请求时，为什么返回空或乱码？
根本原因通常是没显式设置返回体为字符串、没正确编码参数，或服务端返回了压缩内容但没解压。PHP 的 curl_exec() 默认直接输出，不捕获响应体。
必须加这两行：
-
curl_setopt($ch, CURLOPT_RETURNTRANSFER, true);—— 否则curl_exec()返回true而非响应内容 -
curl_setopt($ch, CURLOPT_POSTFIELDS, $data);—— 注意：若$data是关联数组，cURL 会自动用multipart/form-data；若要application/x-www-form-urlencoded，得先http_build_query($data) - 中文参数未
urlencode或未设Content-Type: application/x-www-form-urlencoded; charset=utf-8，会导致服务端解析失败或乱码
file_get_contents() + stream_context_create() 的 POST 写法要注意什么？
它轻量，但容错差、调试难，且默认不支持重定向、超时控制弱。常见错误是把 POST 数据塞进 GET 查询串里，或漏掉 Content-Length 头。
关键配置项必须显式写全：
'method' => 'POST'-
'header' => "Content-Type: application/x-www-form-urlencoded\r\n"（注意换行符是\r\n，不是\n） -
'content' => http_build_query($data)—— 不能传数组，必须是 URL 编码后的字符串 - 没设
'timeout'时，默认可能卡住 60 秒以上
返回 JSON 却 json_decode() 失败？检查这三处
不是数据本身问题，而是 HTTP 层干扰了 JSON 解析。典型现象是 json_last_error() 返回 JSON_ERROR_SYNTAX，但肉眼看 JSON 完全合法。
- 响应体开头有 BOM 或空白字符（比如
curl日志里混入了 debug 输出）—— 建议用trim($response)再解码 - 服务端返回了带 HTTP 头的完整响应（如用
curl -i测试时），而 PHP 没关CURLOPT_HEADER，导致 JSON 前混入HTTP/1.1 200 OK... - 编码不一致：服务端返回
UTF-8，但响应头声明charset=gbk，json_decode()会拒绝解析 —— 此时应忽略 header，强制用mb_convert_encoding($response, 'UTF-8', 'auto')
模拟登录后保持 session 的关键是 Cookie 处理
单次 POST 成功不等于能继续调用接口，因为 session ID 通常靠 Cookie 传递。PHP 默认不自动管理 Cookie，需手动抓取并复用。
- 首次请求加
curl_setopt($ch, CURLOPT_COOKIEJAR, '/tmp/cookie.txt');存 Cookie - 后续请求加
curl_setopt($ch, CURLOPT_COOKIEFILE, '/tmp/cookie.txt');读 Cookie - 避免用内存路径（如
'cookie.txt'），否则多进程下会冲突；临时文件建议用sys_get_temp_dir()拼接 - 如果目标站用
SameSite=Lax/Strict，且你的请求跨域，Cookie 可能被浏览器策略拦截 —— 这类场景必须走服务端中转，不能纯前端模拟
实际跑通的关键往往不在 POST 本身，而在你有没有把上一次响应里的 Set-Cookie 完整、无损地塞进下一次请求头。少一个 Path= 或漏掉 Secure 标志，都可能导致 session 断开。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
