php无数据库字段级透明加密，所谓“透明”实为应用层封装；openssl_decrypt()失败静默返回false，需用openssl_error_string()定位error:06065等错误；iv必须随机生成且与密文同存；mysql字段须用varbinary存二进制密文，eloquent查询需手动加密条件。
别指望“透明加密”真能自动干活——PHP 里没有数据库字段级的透明加密机制，所谓“透明”只是模型层或应用层封装了加解密逻辑，数据进库前已加密，出库后才解密，中间全是明文传输和处理。
openssl_encrypt() 解密失败只返回 false，怎么快速定位问题
PHP 的 OpenSSL 扩展不抛异常，openssl_decrypt() 失败就静默返回 false。开发期必须加校验：
- 解密后立刻检查：
if ($decrypted === false) { error_log('OpenSSL error: ' . openssl_error_string()); } - 常见底层错误：
error:06065（IV 长度不对）、error:0606F（密钥长度或格式错）、error:06072（填充损坏） -
base64_decode()默认静默失败，改用base64_decode($encoded, true)，第三个参数设true可让非法 Base64 直接返回false，避免垃圾数据传给openssl_decrypt()
IV 必须每次随机生成，且不能只存密文不存 IV
复用或硬编码 $iv 是最常见翻车点——同一明文产出相同密文，丧失语义安全，还可能被重放或统计分析。
- 生成方式必须匹配算法：
$iv = openssl_random_pseudo_bytes(openssl_cipher_iv_length('AES-256-CBC'));（不是random_bytes(16)就完事） - 存储推荐两种：
– 拼接后 Base64：base64_encode($iv . $ciphertext_raw)，解密时再拆分
– 分开存字段：user_phone_enc存密文（VARBINARY），user_phone_iv存 IV（CHAR(22)，因base64_encode(16)固定 22 字符） - 绝对不要写死
$iv = '1234567890123456'—— 这会让整个加密形同虚设
MySQL 字段类型必须用 VARBINARY，别用 VARCHAR 存 Base64
加密后的密文是二进制数据，不是文本。用 VARCHAR 存，MySQL 会在字符集转换中悄悄破坏它。
- 正确做法：
ALTER TABLE users MODIFY user_id_card VARBINARY(255);（AES-256-CBC下，100 字符明文加密后约 136 字节，留余量） - 如果坚持存 Base64 字符串：
– 字段用VARCHAR(344)（136 × 2.5 ≈ 340，四舍五入）
– PDO 连接必须显式禁用模拟预处理：PDO::ATTR_EMULATE_PREPARES => false
– DSN 中加;charset=binary，否则 UTF-8 连接仍可能触发隐式转换 - 反例：
TEXT或VARCHAR配utf8mb4_unicode_ci—— 插入时看似成功，读出来却是乱码
为什么 EloquentEncryption 查不到数据
EloquentEncryption 是模型层透明加解密，查询时 SQL 构造器拿到的是明文条件，但数据库里存的是密文，WHERE password = '123' 实际查的是密文 vs 明文，永远不匹配。
- 需要等值匹配的字段（如身份证号），必须手动加密后作为查询条件：
whereRaw("password = ?", [$encrypted]) - 模糊搜索无法支持，因为 AES 是确定性加密，且无索引友好结构
- 确认是否生效：直接查数据库原始值，
SELECT password FROM users WHERE id = 1，看到乱码或U2FsdGVkX1+风格字符串才算加密成功 - 检查
$encryptable字段名拼写、trait 是否引入、config:clear是否执行过 —— 配置未加载会导致静默退化为不加密
最易被忽略的一点：密钥和 IV 的生命周期管理比加解密逻辑本身更关键。密钥硬编码、IV 复用、Base64 存储时没配 charset=binary，这三件事只要做错一件，前面所有代码都等于白写。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
