php 2026年首选对称加密方案是openssl_encrypt/decrypt配合aes-256-gcm，或更安全的sodium secretbox；密钥必须严格管理，iv需每次随机且长度固定，错误处理须检查返回值。
PHP 代码本身不加密，但数据可以且必须加密；混淆或编译（如 Zend Guard）是保护源码的手段，和 openssl_encrypt 这类运行时加解密不是一回事——别混用场景。
openssl_encrypt / openssl_decrypt 是2026年首选对称加解密方案
PHP 8.1+ 已彻底移除 mcrypt，openssl 是唯一被官方维护、支持现代算法的扩展。AES-256-GCM 模式在 2026 年已成为新项目默认推荐，它同时提供机密性与完整性校验，避免手动拼接 IV + HMAC 的出错风险。
-
openssl_encrypt($data, 'aes-256-gcm', $key, 0, $iv, $tag, '', 16)：第 7 参数为附加认证数据（AAD），第 8 参数是标签长度（通常 16 字节） - IV 必须每次随机生成，且长度固定为 12 字节（GCM 推荐值），不能复用；
openssl_random_pseudo_bytes(12)是安全选择 - 解密时必须传入相同的
$tag和 AAD，否则openssl_decrypt直接返回false，不抛异常 - 错误处理要检查返回值：
if ($decrypted === false) { error_log(openssl_error_string()); }
不要用 AES-256-CBC 手动管理填充和 HMAC
CBC 模式本身不防篡改，2026 年仍见大量项目把 openssl_encrypt + hash_hmac 拼在一起用，结果因 IV 重用、填充 oracle 或 HMAC 验证顺序错误导致被绕过。
- IV 存储方式常见错误：
base64_encode($iv . $ciphertext)—— 正确做法是分开字段或用结构化格式（如 JSON），避免解包歧义 - HMAC 必须先验证再解密，且密钥不能和加密密钥相同；否则攻击者可利用密文重放构造有效签名
- PHP 8.3 新增
OPENSSL_AEAD_TAG_LENGTH常量，但 GCM 的 tag 长度仍需显式传参，别依赖常量自动推断 - ECB 模式在任何生产环境都禁用——它完全暴露数据模式，连「密码」字段都可能被猜出
Sodium 是更简但更安全的替代选项
如果你用的是 PHP 7.2+（2026 年基本全是），sodium_crypto_secretbox 和 sodium_crypto_secretbox_open 是比 OpenSSL 更难写错的 API：它强制 nonce 随机、内置验证、无填充概念。
- 密钥长度必须是
SODIUM_CRYPTO_SECRETBOX_KEYBYTES（32 字节），少一字节都会报错，杜绝弱密钥 - nonce 长度固定为
SODIUM_CRYPTO_SECRETBOX_NONCEBYTES（24 字节），不可自定义 - 加密输出直接是
$nonce . $ciphertext，解密前无需分离——但你要确保传输/存储时保留完整二进制长度 - 注意：Sodium 不支持密钥派生（如 PBKDF2），若用户密码做密钥，必须先用
sodium_crypto_pwhash转成密钥
硬编码密钥和环境变量泄露是最大落地坑
2026 年真实攻防演练中，超 60% 的加密失效案例，根源不是算法选错，而是密钥管理失控。
- 密钥绝不能出现在代码里，哪怕注释里写
// KEY=abc123都会被静态扫描工具抓出 -
$_ENV['APP_ENCRYPTION_KEY']是常见做法，但确认 Web 服务器（如 Nginx）未将.env文件设为可下载，且 PHP-FPM 未开启env[APP_ENCRYPTION_KEY]的全局暴露 - 密钥轮换时，旧密文需兼容解密，但新加密必须用新密钥——别忘了在数据库中标记密钥版本号（如加字段
encryption_version） - CI/CD 流水线中，密钥应通过 secret manager 注入，而非写入构建镜像；Dockerfile 里出现
ENV KEY=...是高危项
真正难的从来不是调哪个函数，而是 IV 怎么存、密钥怎么换、错误怎么报、旧数据怎么迁——这些细节没对齐，再新的算法也白搭。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
