优点：
- 简化了控制器代码，无需手动过滤输入。
- 如果忘记在其他地方（例如控制器或验证器）控制输入，可以提供额外的保护层。
缺点：
- 需要在模型中维护 $fillable 或 $guarded 属性。
- 如果需要频繁更改允许或禁止批量赋值的字段，可能会变得繁琐。
2. 控制器保护
另一种方法是在控制器中显式指定要更新的字段。
// Controller
public function update(Request $request, User $user)
{
$user->update([
'name' => $request->input('name'),
'email' => $request->input('email'),
]);
}优点：
- 允许使用不同的输入名称和数据库字段名称。
- 可以在将输入放入模型之前对其进行操作（尽管可以使用 mutators 或 repository 模式实现）。
缺点：
- 控制器代码更加冗长。
- 如果其他开发人员忘记在其他控制器中控制输入并使用 $request->input()，则可能存在安全风险。
3. 验证器保护
Laravel 8+ 引入了 safe() 方法，可以只获取经过验证的数据。对于 Laravel 8 之前的版本，可以使用 validated() 方法。
// Laravel 8+ MyModel::update($request->safe()->all()); // Laravel 8 之前 MyModel::update($request->validated());
优点：
- 将验证和数据清理结合在一起。
- 控制器代码更加简洁。
- 确保所有数据都经过验证。
缺点：
- 需要仔细定义验证规则，以确保所有必要的字段都经过验证。
- 对于可选数据，需要注意验证规则的设置。
4. Repository 模式
Repository 模式是一种将数据访问逻辑与业务逻辑分离的设计模式。它可以将数据访问逻辑封装在单独的类中，从而使控制器和模型更加简洁。
优点：
- 控制器和模型更加简洁。
- 查询逻辑可以重用。
- 更容易进行单元测试。
缺点：
- 对于小型项目，可能会增加复杂性。
总结
在 Laravel 中，即使使用了强大的验证机制，批量赋值保护仍然很重要。选择哪种保护方法取决于项目的规模和需求。
- 对于小型项目，可以使用 Eloquent 保护或验证器保护。
- 对于大型项目，可以使用 Repository 模式。
- 控制器保护可以作为一种补充方法，用于处理特殊情况。
无论选择哪种方法，都应该仔细考虑安全风险，并采取适当的措施来保护模型字段。记住，安全是一个持续的过程，需要不断审查和改进。
