PHP加密结果不一致的主因是$iv未固定或非二进制、$options误用默认值、字符编码不统一、填充模式不匹配；需确保IV为合规长度二进制、显式设OPENSSL_RAW_DATA、统一UTF-8编码、两端PKCS#7填充一致。
PHP加密结果不一致？先盯死 openssl_encrypt 的 $iv 和 $options
PHP里用 openssl_encrypt 加密结果每次都不一样，大概率不是算法问题，而是 $iv（初始化向量）没固定或没传对，或者 $options 参数误用了默认值。ECB模式虽不用IV，但极度不安全，实际项目基本不用；CBC、GCM等主流模式必须显式提供长度合规的 $iv，且加解密两端必须完全一致。
常见错误现象：openssl_encrypt 返回空字符串、false，或解密时提示 error:06065064:digital envelope routines:EVP_DecryptFinal_ex:bad decrypt。
-
$iv必须是二进制字节（非 hex 字符串），长度取决于算法（如 AES-128-CBC 要 16 字节） - 别用
md5($string)或sha1($string)直接当 IV——它们返回的是 32/40 位 hex 字符串，不是原始字节 -
$options推荐显式设为OPENSSL_RAW_DATA，避免 base64 编码干扰比对；若需 base64，统一在加密后手动调用base64_encode() - 如果用
OPENSSL_ZERO_PADDING，必须确保明文长度是块大小整数倍，否则填充逻辑失效，结果不可逆
字符编码不统一：mb_convert_encoding 比 iconv 更稳
中文、emoji 或特殊符号加密前若存在编码歧义（比如 UTF-8 字符被当成 ISO-8859-1 处理），会导致字节流不同，加密结果必然不同。PHP 默认不校验输入编码，strlen() 和 mb_strlen() 返回值可能差好几倍。
实操建议：
立即学习“PHP免费学习笔记（深入）”；
- 统一在加密前强制转为 UTF-8：
mb_convert_encoding($data, 'UTF-8', 'UTF-8, GBK, BIG5, ASCII')，第二个参数是目标编码，第三个是源编码候选列表 - 避免用
iconv('GBK', 'UTF-8//IGNORE', $data)——//IGNORE会静默丢字节，导致数据损坏 - 用
mb_detect_encoding($data, ['UTF-8', 'GBK', 'BIG5'], true)辅助判断原始编码（注意第三个参数true表示 strict 检测） - 加密后可用
bin2hex($encrypted)输出十六进制字符串，方便跨语言/平台比对原始字节
AES 填充模式差异：别依赖 PHP 默认 PKCS#7，显式处理更可靠
PHP 的 openssl_encrypt 在未指定填充时，默认使用 OpenSSL 底层的 PKCS#7（对称加密中常称 PKCS#5，实际等价），但某些旧系统或 Java 实现可能用 ZeroPadding 或 NoPadding，导致加解密不互通。
关键点：
- PKCS#7 填充要求：若原文长度已是块大小整数倍（如 AES 块长 16 字节），仍要补满一整块（即加 16 字节
\x10）；ZeroPadding 则只在不足时补\x00，且解密时从末尾截断所有\x00—— 这会导致原文末尾真有\x00时被误删 - PHP 不支持直接禁用填充（NoPadding），必须手动实现：加密前用
str_pad($data, ceil(strlen($data) / 16) * 16, "\x00", STR_PAD_RIGHT)，解密后用rtrim($decrypted, "\x00")—— 但要注意这不兼容标准协议 - 最稳妥做法：两端都用 PKCS#7，并用开源库（如
defuse/php-encryption）替代裸openssl_*函数，它自动处理填充、IV 生成与验证
跨语言比对失败？用 openssl 命令行当“可信参考”
当 PHP 加密结果和 Python/Java 不一致，不要立刻怀疑代码逻辑，先用系统级 openssl 命令验证“理论正确值”。它绕过所有语言封装，直击 OpenSSL 库行为。
例如 AES-128-CBC 加密：
echo -n "hello世界" | openssl enc -aes-128-cbc -K 0123456789abcdef0123456789abcdef -iv 0123456789abcdef0123456789abcdef -nopad -a
注意：
-
-K和-iv接的是十六进制密钥/IV（32 位 hex 表示 16 字节 key），PHP 中需用hex2bin()转换 -
-nopad表示不自动填充，此时输入必须是块对齐的；若要测试 PKCS#7，去掉该参数即可 - 输出的 base64 结果可与 PHP 的
base64_encode(openssl_encrypt(...))直接对比 - 若命令行结果和 PHP 一致，说明问题出在另一端（比如 JS 的 CryptoJS 默认用 Latin1 编码字符串，而非 UTF-8）
真正麻烦的从来不是“怎么加密”，而是“两端是否用同一套字节解释规则”。IV 是否二进制、编码是否 UTF-8、填充是否严格 PKCS#7、密钥是否 hex2bin 过——四个点里错一个，结果就对不上。
