安全传递参数的关键是发送前对所有用户输入进行过滤和验证，而非仅关注传输方式；需按接口要求选择合适Content-Type，禁用addslashes等SQL专用函数。
PHP cURL POST 请求中如何安全传递参数
直接拼接字符串到 URL 或用 http_build_query() 丢进 curl_setopt($ch, CURLOPT_POSTFIELDS, ...) 是常见做法，但不等于安全。关键不是“怎么发”，而是“发什么”——参数必须在发送前完成过滤和验证。
- 所有用户输入（包括
$_POST、$_GET、JSON body 解析结果）都必须视为不可信，不能跳过校验直接塞进 cURL 请求体 - 若目标接口要求
Content-Type: application/x-www-form-urlencoded，用http_build_query()是合适的；但该函数不做任何过滤，仅做编码，别把它当 sanitizer - 若目标接口接受 JSON，应先用
filter_var()或正则校验字段，再json_encode()，并显式设置curl_setopt($ch, CURLOPT_HTTPHEADER, ['Content-Type: application/json']) - 敏感字段（如
token、user_id）建议在构造请求前就从原始输入中 unset，避免误传
filter_var 过滤 POST 参数的典型组合用法
filter_var() 不是万能的，但它比手动 trim() + intval() + htmlspecialchars() 更可控、可配置。重点在于选对 FILTER_* 常量，并理解它们的边界行为。
- 数字类字段：用
filter_var($input, FILTER_VALIDATE_INT, ['options' => ['min_range' => 1, 'max_range' => 9999]])，比(int)强制转换更安全（后者会把"123abc"变成123） - 邮箱字段：用
filter_var($email, FILTER_VALIDATE_EMAIL)，但注意它不验证域名是否存在，仅校验格式 - URL 字段：用
filter_var($url, FILTER_VALIDATE_URL, FILTER_FLAG_PATH_REQUIRED)，加上FILTER_FLAG_PATH_REQUIRED可排除空路径的假 URL（如http://example.com） - 字符串清理：用
filter_var($str, FILTER_SANITIZE_STRING)已被弃用（PHP 8.1+），应改用FILTER_SANITIZE_SPECIAL_CHARS+ 手动trim()+ 白名单正则（如/^[a-zA-Z0-9_\-\s]{1,50}$/）
cURL POST 中容易忽略的 Content-Type 和编码陷阱
参数内容没被篡改，但服务端收不到或解析失败，大概率是 Content-Type 声明与实际 payload 不匹配，或字符编码不一致。
- 如果用
http_build_query()发送表单数据，必须配curl_setopt($ch, CURLOPT_HTTPHEADER, ['Content-Type: application/x-www-form-urlencoded; charset=UTF-8'])，否则某些服务端（如 Java Spring）可能默认按 ISO-8859-1 解码中文 - 如果用
json_encode()发送，除了设Content-Type: application/json，还要确保json_encode()的第三个参数包含JSON_UNESCAPED_UNICODE | JSON_UNESCAPED_SLASHES，避免中文被转义成\u4f60影响可读性和调试 - 不要依赖
curl_setopt($ch, CURLOPT_ENCODING, 'UTF-8')—— 这个选项控制的是响应压缩解码，和请求体编码无关 - 调试时可用
curl_setopt($ch, CURLOPT_HEADER, true)+curl_setopt($ch, CURLOPT_RETURNTRANSFER, true)捕获完整响应头，确认服务端是否返回了Content-Type: application/json; charset=utf-8这类线索
为什么 addslashes() 或 mysql_real_escape_string() 绝对不能用于 POST 参数过滤
这是历史遗留误区。这些函数专为 SQL 字符串拼接设计，目的是防止注入到数据库查询中，跟 HTTP 请求参数安全毫无关系。拿它们处理 cURL POST 数据，轻则导致接口报错，重则引入双转义漏洞。
立即学习“PHP免费学习笔记（深入）”；
-
addslashes()会给'、"、\、\0加反斜杠，但目标接口可能根本不需要这些字符转义，反而让 JSON 解析失败或字段值异常（如把don't变成don\'t） -
mysql_real_escape_string()已废弃且依赖 MySQL 连接上下文，用在 HTTP 请求构造里属于类型错配，PHP 8+ 直接报致命错误 - 真正要防的是服务端接收逻辑里的漏洞（如未过滤的
eval()、命令拼接、模板注入），而不是在客户端“提前加料”。POST 参数过滤的目标是「符合接口契约」，不是「模拟服务端防护」
in_array($status, [0, 1], true) 校验，而不是只 check is_numeric()。 
