应使用 openssl_encrypt()（如 aes-256-cbc）加密参数，严格对齐密钥、iv 长度及加解密流程，禁用 base64_encode() 作加密，post 采用 application/json 格式传输密文。
PHP 用 cURL 发送 POST 请求时如何安全传参
直接拼接明文参数发 POST 是最常见也最危险的做法——尤其当参数含用户 ID、token 或敏感操作指令时。PHP 本身不自动加密，必须手动在发送前对 $params 做处理，接收方再对应解密。关键不是“用不用加密”，而是“加密是否和解密完全对齐”，否则 500 或空响应就是常态。
- 别用
base64_encode()当加密：它只是编码，无密钥、不可逆混淆，抓包即破 - 优先选
openssl_encrypt()（AES-128-CBC 或 AES-256-GCM），PHP 7.1+ 原生支持，兼容性好 - 密钥（
$key）和 IV（$iv）必须和服务端严格一致，硬编码要加注释说明来源，别写死在脚本里 - POST body 推荐用
application/json格式传密文，比application/x-www-form-urlencoded更易控制结构
加密后 POST 到接口的完整调用链
典型流程是：组装原始数组 → JSON 编码 → AES 加密 → base64 编码 → 放入 POST body。服务端收到后反向操作。漏掉任意一环（比如忘记 JSON 编码或 IV 长度不对），就会解密失败。
示例片段：
$data = ['user_id' => 123, 'action' => 'withdraw', 'amount' => 99.9];
$json = json_encode($data);
$method = 'AES-256-CBC';
$key = '32-byte-secret-key-must-be-exact'; // 32 字节
$iv = '16-byte-iv-must-match'; // 16 字节
$encrypted = openssl_encrypt($json, $method, $key, OPENSSL_RAW_DATA, $iv);
$payload = base64_encode($encrypted);
$ch = curl_init('https://api.example.com/v1/submit');
curl_setopt($ch, CURLOPT_POST, true);
curl_setopt($ch, CURLOPT_POSTFIELDS, json_encode(['cipher' => $payload]));
curl_setopt($ch, CURLOPT_HTTPHEADER, ['Content-Type: application/json']);
curl_setopt($ch, CURLOPT_RETURNTRANSFER, true);
$response = curl_exec($ch);
curl_close($ch);
服务端解密失败的三个高频原因
90% 的“能加密不能解”问题出在两端不一致。不是算法错，是细节没对齐。
立即学习“PHP免费学习笔记（深入）”；
-
$iv长度不符：AES-256-CBC 要求 IV 必须为 16 字节，用substr($iv, 0, 16)截取比硬写字符串更稳妥 - JSON 编码/解码嵌套层级错：比如前端传的是
{ "cipher": "xxx" }，服务端却直接对整个 body 做openssl_decrypt()，实际该先json_decode()取出$cipher字段 - 字符编码隐性污染：原始数据含中文时，
json_encode()默认不转义 Unicode，若服务端用不同 locale 解析 JSON，可能解密后 JSON 无效 —— 加上JSON_UNESCAPED_UNICODE参数更稳
要不要在 URL 或 Header 里传密钥或 IV？
不要。密钥永远不传输，IV 可以随每次请求变化（但必须和服务端协商好生成规则），最简方案是把 IV 和密文一起 base64 合并传输，例如：base64_encode($iv . $encrypted)，服务端先解 base64，再拆出前 16 字节作 IV。
如果 IV 固定，就彻底失去语义随机性，重放攻击风险上升；如果密钥出现在 URL 或 Header 里，等于把锁芯焊在门把手上。
