PHP openssl_decrypt解密失败主因是密钥/IV未转二进制、填充方式不匹配、Base64未解码、密文含头部元数据或长度非块整数倍；需校验cipher参数、密钥IV长度、分块处理大文件并用sodium替代。
PHP 读取加密文件时，openssl_decrypt 解密失败的常见原因
解密失败绝大多数不是算法写错了，而是密钥、IV、填充方式或编码格式没对齐。PHP 的 openssl_decrypt 对输入极其敏感，一个字节的偏差（比如 Base64 多了个换行）就会返回 false 而不报错。
- 确认加密时用的 cipher（如
AES-128-CBC）和 PHP 解密时完全一致，大小写、短横都不能错 - 密钥和 IV 必须是二进制原始字节，不是字符串明文——常见错误是直接传
"mykey123"而没用hex2bin()或mb_convert_encoding()转换 - 如果加密端是 Java/Python/Node.js，注意它们默认可能用 PKCS#5 填充，而 PHP
OPENSSL_ZERO_PADDING和OPENSSL_PKCS1_PADDING不通用，优先用OPENSSL_DEFAULT_PADDING - Base64 解码后再解密：先
base64_decode($encoded_data)，再喂给openssl_decrypt，跳过这步必失败
PHP 解密文件内容时，fread 读出的数据要先剥离头部或元信息
很多“加密文件”其实不是纯密文，而是自定义格式：比如前 16 字节存 IV、后 4 字节存原始长度、中间才是密文。直接 fread($fp, filesize($file)) 全读进来就解不了。
- 用
fopen($file, 'rb')打开，确保二进制模式，否则 Windows 下会乱码 - 用
fseek($fp, 0, SEEK_END)+ftell()精确计算有效密文起始偏移，别硬猜 - 如果加密时用了 salt 或 header（如
"ENCR\0\0\0\1"），必须按协议跳过——漏掉哪怕 1 字节，AES-CBC 就全乱 - 密文长度必须是 block size（如 AES 是 16 字节）的整数倍，否则
openssl_decrypt返回空，检查strlen($ciphertext) % 16 === 0
PHP 中 openssl_decrypt 返回空或 false，怎么快速定位问题
它不抛异常，只静默失败，调试靠打印中间态。重点看三样：原始密文是否完整、密钥 IV 是否长度合规、cipher 参数是否被误拼写。
- 打印
strlen($ciphertext)和strlen($key)：AES-128 要 16 字节密钥，AES-256 要 32 字节；IV 必须严格等于 block size（通常 16） - 用
var_dump(bin2hex($ciphertext))看前几个字节是不是预期的密文特征（非可读 ASCII），避免误把加密头当密文 - 临时改用
openssl_error_string()查 OpenSSL 底层错误，比如error:06065064:digital envelope routines:EVP_DecryptFinal_ex:bad decrypt就说明 IV 或密钥错 - 别在生产环境用
eval()或反射去“动态解密”，PHP 没有通用解密函数，算法必须和加密端一一对应
PHP 解密大文件时内存爆掉，不能一次性 file_get_contents
file_get_contents 把整个加密文件读进内存，100MB 文件就占 100MB RAM，还无法流式解密。必须分块处理，但 AES-CBC 不能随便切——只有 ECB 模式支持独立块解密，而 ECB 不安全，几乎没人用。
立即学习“PHP免费学习笔记（深入）”；
- 真正可行的是用
openssl_encrypt/openssl_decrypt的流式封装：自己实现 CBC 模式的“上一块密文 = 下一块 IV”，需要手动维护状态 - 更稳妥的做法是改用
libsodium（PHP 7.2+），用sodium_crypto_secretstream_*系列函数，原生支持流式加解密，且自动处理 nonce 和认证 - 如果必须用 OpenSSL 且文件超大，先用
fseek定位到密文起始，用fread($fp, $chunk_size)分批读，但每批需携带前一块的最后 16 字节作为 IV，逻辑容易出错 - 别试图用
gzdeflate压缩密文再解密——压缩会改变数据分布，破坏加密语义，多数加密库拒绝处理压缩后的密文
