PHP 8.4 中 openssl_encrypt/decrypt 失败主因是参数不合法：IV/key 长度不匹配算法要求、method 名称不规范、加解密参数不一致或 OpenSSL 3.x 严格校验导致；需统一密钥派生逻辑并确认扩展正确加载。
PHP 8.4 中 openssl_encrypt 或 openssl_decrypt 失败，大概率不是函数本身有 bug，而是密钥、IV、算法或填充方式没对齐——尤其 OpenSSL 库版本升级后默认行为更严格，老代码容易踩坑。
openssl_encrypt/decrypt 报错“Failed to encrypt data”或返回 false
这是最常见现象，根本原因通常是参数不合法或底层 OpenSSL 拒绝执行。PHP 8.4 默认使用 OpenSSL 3.x（如系统已升级），而 OpenSSL 3 强制要求：
-
iv长度必须严格匹配所选加密算法的块大小（如 AES-128-CBC 要求 IV 长度为 16 字节） -
key长度必须符合算法要求（如 AES-128 需 16 字节，AES-256 需 32 字节），不能靠自动截断或补零“凑数” - 传入的
method名称必须是 OpenSSL 支持的正式名称（如'aes-128-cbc'，不是'AES128CBC'或'AES-128/CBC'） - 如果启用了 FIPS 模式（某些政企环境），部分算法（如 MD5 衍生密钥）会被直接拒绝
验证方法：用
var_dump(openssl_get_cipher_methods());看当前支持的 method 列表，确认拼写完全一致。
解密结果乱码或“data not valid”，但加密没报错
说明加密成功了，但解密时参数不一致。重点检查三处：
立即学习“PHP免费学习笔记（深入）”；
- 加密和解密用的
method必须完全相同（包括大小写和连字符） - 解密时传的
$iv必须和加密时生成/使用的$iv完全一致（不能重新random_bytes(16)） - 密钥处理逻辑要统一：如果加密前用
hash('sha256', $password, true)得到 32 字节 key，解密时也得走同样路径；不能一边用md5一边用sha256
特别注意 PHP 8.4 对 openssl_encrypt 的 $options 参数更敏感：若传了 OPENSSL_ZERO_PADDING，就必须确保明文长度是块大小整数倍，否则失败且无提示。
php.ini 中 openssl 扩展启用但函数不存在或报“Call to undefined function”
这不是配置问题，是扩展没真正加载成功。运行
php -m | grep openssl（CLI）或 （Web）确认
openssl 在列表里。如果不在：
- 检查
php.ini是否真启用了：extension=openssl（Windows 是extension=php_openssl.dll），且该行未被分号注释 - 确认 PHP 使用的是你修改的那个
php.ini：php --ini
查路径，别改错了文件 - OpenSSL 3.x 要求系统级库兼容，CentOS/RHEL 8+ 或 Ubuntu 22.04+ 一般没问题；但 Alpine Linux 需装
openssl3包而非旧版openssl
如果扩展已加载但函数仍不可用，可能是 Suhosin 或其他安全模块禁用了这些函数（少见但存在），查 disable_functions 配置项。
从 PHP 7.x 升级到 8.4 后加密结果不兼容
核心变化在密钥派生和默认选项。OpenSSL 3.x 废弃了部分 EVP 接口，导致 openssl_encrypt 内部行为微调。例如：
- 旧版允许用短密钥（如 10 字节）自动填充，新版直接拒绝
-
OPENSSL_RAW_DATA和OPENSSL_ZERO_PADDING组合在 8.4 中更易触发静默失败 - 如果之前依赖
mcrypt迁移过来的代码，务必重做密钥/IV 生成逻辑，不要复用旧的 base64 编码规则
临时兼容方案：加一层校验，比如加密前用
if (strlen($key) !== 32) { $key = substr(hash('sha256', $key, true), 0, 32); } 强制标准化；但长期应统一密钥管理流程，避免硬编码算法细节。
最易被忽略的一点：PHP 8.4 的 OpenSSL 扩展在 CLI 和 Web SAPI 下可能链接不同版本的 libssl（尤其 MAMP、XAMPP 或自编译环境），导致行为不一致。调试时务必确认两个环境用的是同一套 OpenSSL 动态库。
