Eloquent模型中数值或日期范围校验需通过mutator（如setFooAttribute）在写入时强制裁剪或抛异常，而非accessor；validate()等无法替代模型层控制，因绕过HTTP层时会失效，模型须具备自守性。
如何在Eloquent模型中定义数值或日期的属性范围校验
直接在模型里加 getFooRangeAttribute 或用访问器（accessor）做范围限制，是常见误解——Eloquent 没有原生的「属性范围」机制。所谓“Attribute Ranges”，实际是开发者对 accessor + mutator + 自定义验证逻辑的组合封装，不是框架内置功能。
真正可行的做法是：在写入时用 setFooAttribute 做值裁剪或抛异常，在读取时用 getFooAttribute 做安全兜底，再配合 rules() 或 validate() 在业务层统一约束。
- 数值范围（如价格必须 0–9999.99）：在
setPriceAttribute中强制截断或 throw new InvalidArgumentException - 日期范围（如不能早于今天、不能晚于 5 年后）：在
setDeadlineAttribute中用Carbon::parse()标准化后比对 - 避免只在 accessor 里处理：读取时修正不解决脏数据写入问题，必须从 mutator 入手
为什么 validate() 和 Form Request 验证不能替代模型层范围控制
Form Request 的 rules() 只在请求进入时生效，一旦绕过 HTTP 层（比如队列任务、Tinker、API 调试、种子数据填充），范围逻辑就失效。模型本身应具备“自守性”——哪怕被直接 new 或 fill，也能守住底线。
-
$model->price = -100; $model->save();—— 如果没写setPriceAttribute，-100 就会存进数据库 -
DB::table('products')->insert(['price' => -500]);—— 绕过 Eloquent，任何 accessor/mutator 都不触发 - 所以模型层控制是“最后一道防线”，不是可选项
日期范围限制的典型陷阱：时区和 Carbon 实例类型
用 setPublishedAtAttribute 处理日期范围时，最容易踩的坑是传入字符串未解析、或传入已格式化的 Carbon 实例却未 clone，导致意外共享引用。
立即学习“PHP免费学习笔记（深入）”；
- 错误写法：
$this->attributes['published_at'] = $value; // 字符串或 null 直接塞入 - 正确写法：
$date = Carbon::parse($value)->startOfDay(); if ($date->lt(now())) { throw new \InvalidArgumentException('不能早于当前时间'); } $this->attributes['published_at'] = $date; - 注意
now()默认用应用时区，而数据库字段可能是 UTC；若字段是datetime且 DB 存 UTC，建议统一用Carbon::now('UTC')对齐
性能与可维护性提醒：别把复杂规则塞进 mutator
如果范围依赖外部状态（比如“不能晚于用户订阅到期日”），就不要硬塞进 setXxxAttribute。mutator 应该是纯函数式、无副作用、无查询的。
- 适合放进去的：数值上下限、日期偏移量（如
+30 days）、格式标准化（trim(),mb_strtoupper()） - 不适合放进去的：查数据库、调 API、读缓存、涉及关联模型判断
- 这类逻辑应放在 Service 类或 Policy 中，模型只负责基础数据合规
范围控制的边界感比实现方式更重要：什么时候该拦、拦不住怎么办、谁来兜底——这些才是上线前真正要对齐的点。
