怎样在ThinkPHP中实现数据库字段加密存储【安全】

ThinkPHP没有自动加密字段，必须通过模型setAttr/getAttr手动拦截读写实现可控加解密；Db::table()->update()等原生操作绕过模型层，不触发加密逻辑，且需严格处理空值、密钥长度、字段类型（如utf8mb4_bin）、IV管理及查询设计。

ThinkPHP 没有“自动加密字段”这回事，所谓自动，全是靠你在模型里手动写 setAttr 和 getAttr 拦截读写——这是唯一可控、不绕过、不漏场景的方式。

为什么不能用 Db::table()->update() 加密字段

因为 Db::table() 绕过模型层，setAttr 根本不触发。你写 Db::name('user')->update(['phone' => '138...'])，数据就以明文直写进库，加密逻辑完全失效。

• 只有通过模型实例赋值再 save()，或 create()，才会走修改器
• where()->update()、批量 insert()、关联写入（如 $user->profile()->save()）默认也不触发，除非 profile 模型自己也定义了对应修改器
• CLI 命令（如导入脚本）若没实例化模型，同样跳过加密——别指望中间件或事件能兜底

setAttr 里怎么避免重复加密和解密失败静默丢数据

常见翻车点：空值、已加密串、解密失败返回 false 却没处理，结果查出来是空字符串，还以为字段丢了。

• setPhoneAttr 开头必须判空：if (empty($value)) return '';，否则 null 会被转成字符串 "Array" 再加密，解不开
• 不要对 base64 编码过的密文二次加密——可在入参前加判断：if (base64_decode($value, true) !== false && strlen($value) % 4 === 0)，但更稳妥是业务层约定只传明文
• getPhoneAttr 解密失败必须显式返回 '' 或抛异常：return openssl_decrypt($value, 'AES-256-CBC', $key, 0, $iv) ?: '';，别留空 return
• 密钥长度必须严格：AES-256 要 32 字节，用 hash('sha256', $raw_key)；AES-128 要 16 字节，用 md5($raw_key)；硬写短口令会静默失败

数据库字段类型和排序规则怎么设才不截断

加密后是 base64 字符串，含 +、/、=，还可能带不可见字节。utf8mb4_general_ci 会把末尾 = 当填充忽略，导致解密失败。

立即学习“PHP免费学习笔记（深入）”；

• 字段类型必须是 TEXT 或 VARCHAR(512)（AES-256-CBC + base64 后长度 ≈ 原始字节数 × 1.33 + 16）
• 排序规则强制设为 utf8mb4_bin，防止大小写混淆、等号截断、emoji 错乱
• 千万别用 CHAR 或 VARCHAR(255) 存 AES 密文——超长直接被 MySQL 截断，解密永远失败

加密字段根本没法 where 查询，怎么办

不是 ThinkPHP 的限制，是加密本身的数学约束：相同明文每次加密结果不同（IV 随机），密文无序、不可索引、无法模糊匹配。

• 绝对不要写 where('phone', $input)——$input 是明文，库里存的是密文，永远不匹配
• 真要查手机号，建一个明文索引字段 phone_prefix（存前3位），加数据库索引，查时用 where('phone_prefix', '138')
• 需要精确匹配（如登录验手机号），先用相同密钥+IV 加密输入值，再 where('phone_encrypted', $encrypted_input) —— 注意 IV 必须固定（如 substr(hash('sha256', $key), 0, 16)），否则查不到
• 别用 MySQL 的 AES_ENCRYPT()：密钥在 SQL 层暴露，ORM 条件构建失效，跨环境迁移全崩

最易被忽略的点：密钥不能写死在模型里，也不能放 .env 明文存；IV 不能全局复用，但也不能每次随机——查不了和不安全，得自己权衡取舍。加密本身很简单，难的是密钥怎么注入、IV 怎么管理、查询怎么设计，这些地方漏一环，上线后就是生产事故。