根本原因是IV长度与算法要求不匹配，需用openssl_cipher_iv_length()获取准确长度，用random_bytes()生成，并确保存储传输时按二进制处理，ECB模式应传null而非空字符串。
openssl_encrypt 报错“IV length error”怎么修
根本原因是传给 openssl_encrypt 的 $iv 长度和所选加密算法+模式要求的 IV 长度不一致。比如 AES-128-CBC 要求 IV 必须是 16 字节，但你传了 12 字节或 32 字节的字符串，就会直接报错。
常见错误现象：Warning: openssl_encrypt(): IV passed is only 12 bytes long, cipher expects an IV of precisely 16 bytes, padding with \0 或更严格的 PHP 8.1+ 直接抛出 ValueError。
- 先用
openssl_cipher_iv_length($cipher)查准所需长度，别靠记忆——AES-128-CBC、AES-256-CBC都要 16；AES-128-GCM推荐 12（但接受 8–16）；chacha20要 12 - 生成 IV 别用
md5()或substr(str_shuffle())——它们不保证字节长度且不可靠；改用random_bytes($len) - 存储或传输 IV 时，它必须和密文一起保存（通常前置拼接），且解密时原样传回——不能 base64_decode 后再截取，也不能误当字符串 strlen 处理（要用
mb_strlen($iv, '8bit')或直接strlen）
为什么 openssl_decrypt 解密失败却没报 IV 错误
IV 长度不对时，openssl_decrypt 可能静默失败（返回 false），而不是抛异常。这不是 bug，是 OpenSSL 底层行为：长度不足会补零，过长则截断，导致解密后明文乱码或验证失败（尤其 GCM 模式下 auth_tag 校验不过）。
- 务必检查
openssl_decrypt返回值是否为false，而不是只看是否为空字符串 - GCM 模式下，必须同时传入正确的
$tag和$iv，且$iv长度偏差会导致 tag 校验失败，返回 false —— 此时错误不是“IV length”，而是“decryption failed” - 调试时可用
var_dump(bin2hex($iv), strlen($iv))确认实际字节数，避免被编码/转义干扰
ECB 模式不用 IV？那为啥还传参报错
ECB 模式逻辑上不需要 IV，但 PHP 的 openssl_encrypt 仍要求传一个参数。如果传了非 null 的值，它会检查长度；若传 null，内部会忽略，但部分版本（如 PHP 7.4）对 null 的处理不稳定。
立即学习“PHP免费学习笔记（深入）”；
- 明确不用 IV 的场景（如兼容旧系统），直接传
null，不要传空字符串''（会被当成 0 字节 IV，触发长度检查） - 但强烈不建议用 ECB——它不安全，相同明文块永远产出相同密文块；生产环境请换 CBC/GCM
- 如果必须用 ECB 且遇到报错，确认调用时第 4 个参数（IV）确实是
null，而非''或0
从 base64 存储中还原 IV 时容易漏掉的点
很多人把 IV 和密文一起 base64_encode 存库，解密时 base64_decode 后直接拆分，却忘了 base64_decode 返回的是原始二进制字节流——它的长度就是真实字节数，不是字符数。
- 假设你约定 IV 占前 16 字节：
$data = base64_decode($encoded); $iv = substr($data, 0, 16); $ciphertext = substr($data, 16); - 别用
mb_substr($data, 0, 16, '8bit')代替substr——虽然结果一样，但多一层编码指定反而易错 - 如果 base64 字符串末尾有换行或空格（比如从 textarea 提交），
base64_decode会失败或返回 false，务必先trim()
strlen 和 Python 的 len(bytes) 行为一致，但和 JS 的 TextEncoder 输出容易混淆。 
