赋值后读取属性仍是原值，通常因修改器未触发或未写入底层；需确认方法名严格匹配字段驼峰规则（如user_name→setusernameattribute），且修改器内必须手动赋值$this->attributes['xxx'] = $value，否则值不会存入数据库。
赋值后读取属性仍是原值，通常不是修改器“没运行”，而是它根本没被触发，或触发了但没真正写进模型底层。重点不在“改没改”，而在“有没有走到那一步”。
确认修改器方法名和字段名是否严格匹配
数据库字段是 user_name，修改器必须叫 setUserNameAttribute（驼峰、首字母大写），不能是 setUsernameAttribute 或 set_user_nameAttribute。Laravel 不会报错，只会静默跳过。检查模型里方法名拼写、大小写、下划线转驼峰是否准确——比如 profile_data → setProfileDataAttribute，少一个 D 就失效。
检查是否漏写了 $this->attributes['xxx'] = $value
修改器不会自动把处理后的值塞进数据库字段，你必须手动赋值。常见错误写法：
- ❌
return strtolower($value);—— Laravel 完全忽略返回值 - ❌
$this->email = strtolower($value);—— 这会再次触发修改器，可能造成无限循环 - ✅ 正确写法：
$this->attributes['email'] = strtolower(trim($value));
如果这行缺失，属性在数据库里永远是旧值或 NULL，读出来当然还是原样。
排查是否绕过了模型赋值流程
以下操作完全不走修改器，赋值后读取“看似变了”，其实只是内存里的临时值，没进 $attributes：
- 直接操作
$user->attributes['email'] = 'new@ex.com' - 用
DB::table('users')->update()或User::where(...)->update(...) - 批量填充时键名不匹配，比如传入
['user_email' => 'A@B.C']，但模型没定义setUserEmailAttribute
只对 $user->email = 'A@B.C';、$user->fill([...])、User::create([...]) 这类走 Eloquent 属性设置的路径才生效。
验证修改器是否真的被调用
在修改器方法开头加一行日志或断点：
info('setEmailAttribute triggered', ['raw' => $value]);- 或者
throw new Exception('hit mutator');
如果没触发，说明问题出在调用路径；如果触发了但读出来还是旧值，立刻检查上一条——是不是没写进 $this->attributes。
