模型字段脱敏配置必须在initialize()中完成，因__construct()时框架未初始化表名和数据库连接，导致脱敏失败；需通过withmask()在视图层控制脱敏时机，避免侵入数据层。
模型字段脱敏配置必须在 initialize() 里做，不能放 __construct()
ThinkPHP 的模型生命周期中，__construct() 执行时框架尚未完成属性初始化（比如 $this->table、$this->schema 都还没加载），此时读数据库策略会失败或返回空。而 initialize() 是模型首次被实例化后、查询前的最后可控钩子，字段元信息和连接已就绪。
常见错误现象：Call to a member function query() on null 或脱敏字段始终不生效，实际是 $this->db 还没绑定。
- 只在
initialize()中调用$this->loadMaskConfig()类方法加载策略 - 避免在
getAttr()或setAttr()中实时查库——高并发下会拖垮数据库 - 如果策略本身需要动态更新，用
Cache::get('mask_config_'.$this->name)缓存 5–10 分钟，而不是每次重查
getAttr() 里判断脱敏级别要先校验字段是否在策略中
不是所有字段都需要脱敏，也不是所有请求都该触发脱敏。直接对字段硬编码 if ($name === 'id_card') 会导致策略变更后代码散落难维护；但若只依赖配置又容易因字段名拼写错误或大小写不一致漏脱敏。
使用场景：用户中心展示页需脱敏手机号，但后台导出 Excel 时需明文——靠 Request::param('export') 控制开关，而非改模型。
- 从缓存读出的策略结构应为
['mobile' => ['level' => 2, 'on' => true]]，不是扁平数组 - 判断前先
isset($this->maskConfig[$name]) && $this->maskConfig[$name]['on']，防止未配置字段报 Notice - 级别 1（如手机号中间 4 位）、级别 2（如身份证前 6 后 2）、级别 3（全 *）用
str_replace()+substr()组合，别用正则——性能差且易误匹配
数据库读取脱敏策略时，表名和字段名必须严格小写 + 下划线
ThinkPHP 默认开启 strict 模式时，字段名大小写敏感；而 MySQL 在 Windows 上默认不区分大小写，Linux 上区分。如果你在本地开发用 user_name，上线后数据库字段是 UserName，策略就查不到。
错误现象：maskConfig 数组为空，但日志显示 SQL 已执行——其实是 WHERE field = 'Phone' 匹配不到 phone 字段。
- 统一约定策略表字段为
table_name、field_name、mask_level、enabled，全小写下划线 - 查策略时用
$this->name（模型名，如user）而非$this->table（可能带前缀，如tp_user） - 字段名统一用
strtolower($name)再查，哪怕模型里定义了protected $schema = ['Phone' => 'phone']
脱敏逻辑不能侵入 toArray() 和 JSON 输出流程
很多人把脱敏写在 hidden 或 visible 里，或者重写 toArray() 做字符串替换，结果导致 API 返回的 data 被脱敏，但 count、total 等统计字段也被当字符串处理出错；更糟的是，导出 CSV 时也触发脱敏，生成一堆 138****1234。
核心原则：脱敏是视图层行为，不是数据层行为。模型只提供“可脱敏能力”，不决定“何时脱敏”。
- 在控制器里调用
$user->withMask(['mobile', 'id_card'])->toArray()，而不是让模型自己判断 -
withMask()方法内部用array_walk_recursive()处理多维数组，但跳过数字键和非字符串值 - JSON 输出前用
Json::encode($data, JSON_UNESCAPED_UNICODE)，确保脱敏后的字符串不被二次转义
最常被忽略的一点：关联模型（如 User::with('profile')）里的子模型不会自动继承父模型的脱敏配置，必须显式调用子模型的 withMask()，否则 profile.mobile 就是明文。这不是 bug，是设计使然——每个模型的脱敏策略彼此隔离。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
