$casts和setfooattribute()无法阻止运行时修改，因其不介入属性写入逻辑；唯一全局拦截点是__set()，需结合存在性判断与初始化状态实现字段级只读，再配合请求层验证构成完整防护链。
为什么 $casts 和 setFooAttribute() 无法阻止运行时修改
因为 Eloquent 的属性赋值流程中，$casts 只影响序列化/反序列化，setFooAttribute() 是赋值钩子而非访问控制；它们都不介入模型实例的属性写入逻辑本身。直接执行 $model->foo = 'new' 或 $model->fill(['foo' => 'new']) 会绕过 setter，最终写入 $model->attributes 数组 —— 这是可变性的根本来源。
真正能拦截写入的只有两个位置：属性设置前的魔术方法（__set()），或模型事件（如 updating）。但后者只能抛异常、不能静默拒绝，且不覆盖批量赋值场景。
-
__set()是唯一能在所有赋值路径（点号、fill()、update()）生效的拦截点 - 必须配合
isDirty()或白名单判断，否则会破坏正常字段更新 - 不能只依赖
isset($this->attributes[$key])，因为新增字段也可能被误锁
用 __set() 实现字段级运行时锁定
在模型中重写 __set()，对指定字段（如 locked_at、status）在已存在值时拒绝新赋值：
public function __set($key, $value)
{
// 定义运行时只读字段（可放配置或数据库查出）
$immutableFields = ['locked_at', 'created_by'];
if (in_array($key, $immutableFields) && $this->exists && $this->getAttribute($key) !== null) {
throw new \LogicException("Cannot modify immutable field: {$key}");
}
parent::__set($key, $value);
}
注意：$this->exists 排除新建模型场景；!== null 允许显式设为 null（若业务允许）；若需更严格（连 null 都不允许），改用 array_key_exists($key, $this->attributes)。
- 该方案对
$model->fill([...])和$model->update([...])同样生效 - 不干扰
saveQuietly()或forceFill()—— 它们绕过__set()，这是设计使然，不是缺陷 - 若需封锁
forceFill()，必须重写该方法并加同样逻辑
如何让部分字段“只读但可初始化”
有些字段如 uuid、reference_id 要求创建时可设、之后不可改。这时不能只看 $this->exists，得区分“首次赋值”和“后续修改”：
protected $initializedImmutableFields = [];
public function __set($key, $value)
{
$immutableOnUpdate = ['uuid', 'reference_id'];
if (in_array($key, $immutableOnUpdate)) {
if ($this->exists && isset($this->initializedImmutableFields[$key])) {
throw new \LogicException("Field {$key} is immutable after creation");
}
$this->initializedImmutableFields[$key] = true;
}
parent::__set($key, $value);
}
这个模式把“是否已初始化”状态存在模型实例内存里，比查数据库或文件快，也避免了 getAttribute() 在未加载字段时返回 null 导致误判的问题。
- 务必用
protected属性，防止外部篡改$initializedImmutableFields - 不要在
__construct()中预设，因为模型可能从数据库 hydrate 而来，此时字段已存在但未走__set() - 如果字段默认值由数据库生成（如
DEFAULT UUID()），需在boot()中监听creating事件补全初始标记
别忽略 toArray() 和 API 响应中的“假只读”陷阱
即使字段在模型层锁死，前端仍可能通过 API 提交该字段并被静默忽略 —— 用户得不到任何反馈，以为改成功了。这不是模型问题，而是接口契约缺失。
解决方式不是放开字段，而是在控制器或请求验证层显式过滤：
// 在 Request 或 Controller 中 $data = $request->except(['locked_at', 'created_by']); $model->update($data);
或者用 validated() 配合规则限制：
public function rules()
{
return [
'locked_at' => 'prohibited',
'status' => 'required_if:can_edit_status,false',
];
}
-
prohibited规则会在验证失败时明确报错，比模型层抛LogicException更符合 API 设计习惯 - 模型层锁定 + 请求层校验，才是完整的字段防护链；只做一边容易漏掉批量更新或队列任务里的修改路径
- 尤其注意队列任务中使用的模型实例，它可能复用旧数据，
__set()拦截依然有效，但日志和监控要跟上
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
