Laravel修改器需严格匹配驼峰命名、显式赋值attributes且须配对访问器；常见错误包括方法名错误、漏赋值、误用于DB查询及缺失访问器。
修改器只在模型属性被赋值时触发，不是“设个开关就自动生效”的功能；写错方法名、漏掉 $this->attributes 赋值、或指望它在 create() 里自动跑——这三类错误占了实际调试的 80% 以上。
set{Attribute}Attribute 方法名必须严格匹配驼峰规则
数据库字段是 user_name，对应修改器必须叫 setUserNameAttribute，不能是 set_user_name_attribute、setusernameattribute 或 setUserNameAttr。Laravel 完全靠方法名字符串匹配来识别，大小写、下划线、拼写缺一不可。
常见陷阱：
- 数据库字段为
profile_data→ 方法名是setProfileDataAttribute，不是setProfiledataAttribute - 你想对外暴露一个虚拟属性
fullName（数据库里并不存在），就得写setFullNameAttribute，然后在方法里手动存到$this->attributes['first_name']和$this->attributes['last_name'] - 方法必须是
public，且只接受一个参数（即传入的原始值）
修改器内部必须显式写入 $this->attributes
修改器不会帮你把处理后的值塞进数据库字段——你得自己动手。Laravel 只负责调用你的方法，其余一概不管。
正确写法：
public function setEmailAttribute($value)
{
$this->attributes['email'] = strtolower(trim($value));
}
错误写法（完全无效）：
public function setEmailAttribute($value)
{
return strtolower(trim($value)); // Laravel 忽略返回值
}
关键点：
- 字段名必须和数据库列名一致（如
email），不能写成user_email除非数据库字段真是那个名字 - 如果属性名和字段名不一致（比如数据库存
salary_cents，外部叫salary），就必须在方法里明确指定键：$this->attributes['salary_cents'] = $value * 100 - 别在修改器里做耗时操作（如远程 API 调用、文件读写），它运行在每次赋值时，容易拖慢请求
批量操作（fill()、create()、update()）是否触发？
会触发，但前提是数组键名能精确匹配你定义的修改器所对应的属性名。
例如：
-
User::create(['user_name' => 'ABC'])→ 触发setUserNameAttribute（因为模型有user_name字段，且你写了该修改器） -
$user->fill(['email' => 'FOO@BAR.COM'])→ 触发setEmailAttribute -
User::create(['username' => 'ABC'])→ 不触发，因为没定义setUsernameAttribute，且模型默认也不识别username为合法字段
注意：DB::table('users')->insert() 或 update() 完全绕过修改器，Eloquent 层根本没参与。
只定义修改器，不配访问器，数据会“看起来不对”
这是最隐蔽也最难排查的问题：你存进去是小写邮箱，但读出来还是大写——因为你只写了 setEmailAttribute，没写 getEmailAttribute。
访问器和修改器完全解耦，互不影响。Eloquent 读取时直接从 $this->attributes 拿原始值，不做任何转换。
所以如果你希望读写都统一格式：
- 写修改器：确保存入前转小写
- 必须同步写访问器：
public function getEmailAttribute($value) { return strtolower($value); } - 或者更合理的方式：用
$casts = ['email' => 'string']配合访问器，避免重复逻辑
日期、JSON、加密等强业务逻辑，优先走 $casts 或独立服务封装，别堆在修改器里——那里只适合轻量、确定、无副作用的格式转换。
