敏感信息必须在数据流转各环节主动加密或脱敏：模型需声明$encrypt_fields才能自动加密入库；日志须用Log::record+递归脱敏；展示层用获取器getMobileAttr()；缓存加密禁用Crypt，应使用sodium_crypto_secretbox()并带认证。
敏感信息在 ThinkPHP 项目中不加密、不脱敏，等于把用户凭证直接摊在日志里、数据库里、缓存里——不是“可能被看到”，而是“必然暴露”。关键不在用不用加密函数，而在加解密是否嵌入到数据流转的正确环节。
模型 $encrypt_fields 声明是加密入库的前提
ThinkPHP 不会自动识别哪些字段要加密。没在模型里写 $encrypt_fields，哪怕你手动调了 Crypt::encrypt() 再塞进数据，save() 时照样明文入库。
-
$encrypt_fields必须是 protected 属性，且字段名必须和数据库列名、模型属性名完全一致（区分大小写） - 不支持 JSON 字段内层键加密，比如
extra里的bank_no，只能整体加密或改用手动流程 - 用
Db::table()操作时，$encrypt_fields完全无效——这是线上最常踩的坑 - 加密后字段值变成 Base64 字符串，长度膨胀约 33%，建表时字段类型要预留足够空间（如
VARCHAR(255)）
Log::write() 记录 $request->param() 就等于泄露密码
Log::write($request->param(), 'info') 这行代码在生产环境运行一次，日志文件里立刻出现 "password": "123456"。这不是框架缺陷，是设计上默认信任你已处理好敏感字段。
- 必须用
Log::record()替代，配合递归脱敏函数，例如：Log::record('登录请求: ' . json_encode(maskSensitiveData($request->param()), JSON_UNESCAPED_UNICODE), 'info') - 脱敏函数要用
array_walk_recursive()，关键词匹配需大小写不敏感（password、PWD、Token都得覆盖） - 替换值统一用
***，禁止为空字符串，否则可能被误判为字段缺失或触发空值校验异常 - 自定义日志处理器（继承
think\log\driver\File）是最彻底的方式，但要注意它不处理Log::record()的内容，两者需统一策略
获取器 getMobileAttr() 是展示层脱敏最省心的方式
在模型里写一个 getMobileAttr()，所有 toArray()、json_encode()、模板输出、Excel 导出都会自动生效——但前提是别在控制器里提前处理。
立即学习“PHP免费学习笔记（深入）”；
- 函数体必须判空：
if (empty($value) || !is_string($value)) { return $value; }，否则查不到数据时$value是null，substr_replace()会报 warning - 用
substr_replace($value, '****', 3, 4)比正则快，也更可控；不要用str_replace()，它无法按位置替换 - 导出原始手机号时，TP6.1+ 可用
$user->getAttr('mobile', null, false)跳过获取器；TP6.0 只能用$user->getData('mobile') - 注意：获取器只影响读取，不影响查询。你在
where('mobile', '138****5678')是搜不到的——数据库存的是完整号码
缓存加密不能依赖 think\facade\Crypt
think\facade\Crypt 是为 Cookie 和配置设计的，密钥派生弱、不暴露 nonce 控制权，不适合缓存场景。缓存加密必须自己封装，且必须带认证。
- 首选
sodium_crypto_secretbox()：调用sodium_crypto_secretbox_keygen()生成 32 字节密钥，sodium_randombytes_buf(24)生成 nonce - 密文必须 base64 编码后存储，且 nonce 要和密文一起存（比如拼接或 JSON 包裹），否则无法解密
- 解密失败时函数返回
false，不是抛异常，必须显式判断：if ($decrypted === false) { /* 处理篡改或密钥错误 */ } - 禁用
openssl_encrypt('AES-256-CBC')：CBC 无认证，密文被篡改后仍能解出乱码，且 IV 管理极易出错
最容易被忽略的点是：APP_DEBUG=false 且 Runtime 目录移出 Web 根目录，只是物理防护的第一步；真正危险的是日志内容本身、数据库字段值、缓存数据——这些都得在代码层面做主动过滤或加密，而不是靠部署配置兜底。
