eloquent attribute patterns 是开发者约定的访问器、修改器与正则校验组合用法，并非 laravel 内置功能；应优先使用 form request 验证、cast 类封装格式化逻辑，避免在 mutator 中抛异常破坏验证流程。
什么是Eloquent Attribute Patterns？它不是 Laravel 内置功能
“Eloquent Attribute Patterns”并不是 Laravel 官方术语，也没有 AttributePatterns 类或配置项。你在文档或社区里看到这个词，大概率是指：**用访问器（accessor）+ 修改器（mutator） + 正则校验逻辑，对 Eloquent 模型字段做格式化与约束的惯用写法**。它本质是开发者自己组织的一套模式，不是框架特性。
所以别搜 AttributePatterns——Laravel 不认识它；要搜的是 accessor、mutator、cast、validate 这些真实存在的机制。
怎么在模型里用正则校验属性输入？别在 mutator 里 throw
常见错误是：在 setEmailAttribute 里直接用 preg_match 校验，不通过就 throw new ValidationException。这会导致模型保存失败且无法被 Form Request 或 $request->validate() 统一捕获，破坏验证流程。
正确做法是把正则校验放在验证层（如 Form Request），属性修改器只负责格式化：
- 在
StoreUserRequest的rules()方法里写'email' => 'required|regex:/^[a-z0-9._%+-]+@[a-z0-9.-]+\.[a-z]{2,}$/i' - 在模型中定义
setEmailAttribute只做 trim / strtolower 等安全处理，不 throw - 如果必须在模型内校验（比如批量导入场景），改用
static::creating或static::updating事件钩子，手动调用Validator::make并处理$validator->fails()
如何让 email 属性自动标准化又保持可读性？用 accessor + mutator 配合 $casts
比如希望数据库存小写邮箱，但读出来仍是原始输入格式（或统一格式），同时支持 JSON 序列化时也干净：
- 在模型里定义
setEmailAttribute($value)：赋值前$this->attributes['email'] = strtolower(trim($value)) - 定义
getEmailAttribute($value)：返回$value（即已处理后的值），不需要再 trim/lowercase - 加上
protected $casts = ['email' => 'string']，避免被当成 object 或 null - 若该字段需参与搜索（如
where('email', ...)），确保数据库索引建在原始列上，而不是靠 accessor 转换后查
注意：不要在 accessor 里做耗时操作（如 DB 查询、HTTP 请求），它会在每次获取属性时触发。
为什么用 $casts + cast class 比手写 mutator 更可靠？
对于更复杂的格式（如电话号、身份证、JSON 结构化字段），建议优先用 Laravel 的类型转换机制：
- 自定义 cast 类（实现
CastsAttributes接口），把正则解析、标准化、异常防护都封装进去 - 例如
PhoneNumberCast在set时用preg_replace('/\D/', '', $value)提纯数字，在get时按模板格式化输出 - 注册到模型：
protected $casts = ['phone' => PhoneNumberCast::class] - 好处是：自动应用于 create/update、mass assignment、JSON API 输出、队列序列化，且不污染模型方法命名空间
手写 mutator 容易漏掉某些入口（比如 updateQuietly 或 fill() 批量赋值），而 cast 是 Laravel 底层统一拦截的。
真正难的不是写正则，而是决定校验时机——入库前？API 入参时？还是展示时？选错位置，轻则验证失效，重则数据不一致。正则本身只是工具，模式的价值在于它嵌在哪一层、谁来触发、失败后怎么退。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
