PHP模拟POST请求需手动AES加密参数再传输，使用openssl_encrypt()配合随机IV和安全密钥，接收端严格一致解密；禁用Base64/哈希等伪加密，HTTPS防窥探，AES防篡改，建议叠加HMAC签名。
PHP 模拟 POST 请求时如何安全传递加密参数
直接拼接明文参数发 POST 是危险的，尤其涉及登录、支付、敏感数据操作。PHP 本身不内置“加密 POST”机制，关键在于：你得在发送前对 $data 手动加密，在接收端用对应密钥和算法解密——不是靠 cURL 或 HTTP 协议本身，而是靠你控制的加解密逻辑。
cURL 发送前对 POST 数据整体 AES 加密（推荐）
比 Base64 或简单 XOR 更可靠，适合中高安全要求场景。用 OpenSSL 扩展（PHP 7.1+ 默认启用）做 AES-128-CBC 或 AES-256-GCM：
- 加密必须带随机 IV（
$iv），且 IV 需随密文一起传（可拼在密文前或作为单独字段），不能写死 - 密钥（
$key）必须足够长（如 32 字节对应 AES-256），且服务端客户端严格一致 - 不要用
mcrypt（已废弃），避免手动实现 PKCS#7 填充，优先用openssl_encrypt() - 示例片段：
$data = ['user_id' => 123, 'action' => 'pay', 'amount' => 99.9];
$json = json_encode($data);
$iv = random_bytes(16);
$key = hash('sha256', 'your-secret-salt', true); // 真实环境请用安全密钥管理
$encrypted = openssl_encrypt($json, 'AES-256-CBC', $key, OPENSSL_RAW_DATA, $iv);
$payload = base64_encode($iv . $encrypted); // IV + 密文一起 base64 编码
$ch = curl_init('https://api.example.com/endpoint');
curl_setopt($ch, CURLOPT_POSTFIELDS, http_build_query(['enc_data' => $payload]));
接收端解密失败的常见原因
90% 的“解不开”问题出在细节不一致，不是算法本身：
-
openssl_decrypt()的$options参数漏传OPENSSL_RAW_DATA，导致解密返回 false - IV 长度不对（AES-CBC 要 16 字节，GCM 要 12），或从 base64 解码后没截取正确长度
- 密钥生成方式两端不一致（比如一端用
md5()，另一端用hash('sha256')） - JSON 编码后含中文，但接收端没设
JSON_UNESCAPED_UNICODE，导致解密后 JSON 格式错误 - POST 数据被框架自动过滤（如 ThinkPHP 的
input()对特殊字符转义），应在解密前用file_get_contents('php://input')原始读取
别踩这些轻量级加密的坑
有人图快用 base64_encode() 或 urlencode() 当“加密”，这等于没加；也有人用 md5() 或 sha1() 哈希参数——哈希不可逆，收不到原始值。真正需要加密传输时，记住：
立即学习“PHP免费学习笔记（深入）”；
- 对称加密（AES）是主流选择，非对称（RSA）只适合加密小数据（如会话密钥）
- 不要自己写加解密函数，不要用
eval()或create_function()动态执行密文 - 如果只是防抓包窥探，HTTPS 已解决大部分问题；加密是为防中间人篡改或服务端未校验来源
- 加密不能替代签名——建议额外加 HMAC（如
hash_hmac('sha256', $payload, $secret)）验证完整性
加解密逻辑一旦上线，密钥轮换、算法升级、兼容旧数据解密都会变复杂，一开始就把 IV 生成、密钥存储、错误提示日志这些细节想清楚。
