修改器仅在模型属性赋值时触发，需手动写入 $this->attributes，不干预SQL、查询条件或批量操作；优先用 $casts 或模型事件替代，注意与访问器双向一致。
set{Attribute}Attribute 方法必须手动赋值到 $this->attributes
修改器不是“自动拦截并改写 SQL”，它只在模型属性被 PHP 层设置时触发，且不会自动更新底层属性。如果你漏掉 $this->attributes['field_name'] = $value 这一行，数据根本不会存进数据库——字段保持原值或 NULL。
常见错误现象：$user->email = 'ADMIN@EXAMPLE.COM'; $user->save(); 后查数据库仍是旧邮箱，甚至报错“Column 'email' cannot be null”。
- 方法名必须严格匹配：数据库字段
user_name→ 修改器名是setUserNameAttribute（驼峰，首字母大写） - 参数名无所谓，但必须接收传入值，比如
setEmailAttribute($raw)中的$raw就是原始输入 - 不能 return 任何东西；Laravel 完全忽略返回值，只看你有没有写进
$this->attributes - 对批量操作如
User::where(...)->update([...])或DB::table()->update()完全无效——这些绕过模型，不走修改器
修改器只在模型赋值时生效，不参与查询条件构建
很多人误以为写了 setCreatedAtAttribute 就能统一处理时间格式，结果发现 User::where('created_at', '>', '2025-01-01')->get() 返回异常，或时间被当成字符串比较。这是因为修改器只影响写入前的值转换，不影响 where 条件里的字段名或类型。
典型陷阱：你把 setPublishedAtAttribute 设成自动转 Carbon 并格式化为 Y-m-d H:i:s，但查询时仍要用数据库原生格式写条件，不能依赖修改器“帮你转”。
- 修改器不改变字段在数据库中的实际类型或存储格式（比如你存的是字符串，它不会帮你转成 DATETIME）
- 查询条件中用的仍是原始字段名和原始值逻辑，修改器对其无感知
- 若需统一时间处理，建议配合
$casts数组（如'published_at' => 'datetime'），而非仅靠修改器
密码哈希、邮箱小写等标准场景，优先用 $casts 或模型事件代替修改器
像密码加密、JSON 字段解析、布尔值标准化这类通用转换，Laravel 提供了更稳定、更易维护的替代方案：$casts 和模型事件比手写 set{Attribute}Attribute 更少出错、更易测试。
例如，邮箱转小写用修改器看似简单，但一旦模型通过 fill()、create()、批量赋值或 API 请求带数组进来，容易遗漏边界；而 $casts = ['email' => 'lowercase']（需自定义 cast 类）或直接在 setEmailAttribute 里调用 Str::lower() 都可行，但后者要承担重复逻辑风险。
-
$casts支持内置类型（array,json,datetime）和自定义 cast 类，适合结构化转换 - 密码哈希强烈建议用
creating模型事件或在save()前显式调用Hash::make()，避免修改器里混入业务逻辑 - 如果修改器里做了 DB 查询、HTTP 调用或复杂计算，会严重拖慢
save()性能，且无法批量处理
修改器与访问器配对使用时，注意双向一致性
比如你用 setPriceInCentsAttribute 把前端传来的“元”乘以 100 存为分，那对应就得写 getPriceInCentsAttribute 或 getPriceAttribute 把分转回元展示——否则调用 $product->price 会得到原始分值，前端显示成“9999”而不是“99.99”。
最容易被忽略的是：访问器返回的是“读取值”，修改器处理的是“写入值”，二者操作的字段可能不同（如存 price_cents，读 price），命名和逻辑必须严格对齐。
- 不要在访问器里改
$this->attributes，否则可能引发无限递归（如getPriceAttribute里又去设$this->price = ...） - 若字段名和属性名不一致（如数据库是
user_name，你想暴露为name），用$fillable+ 修改器 + 访问器组合，但务必在文档里标清映射关系 - 测试时重点覆盖：赋值 → save → reload → 读取，三步都走通才算真正闭环
