在 formrequest 中应于 prepareforvalidation() 方法内对字符串字段调用 trim()，避免误处理非字符串值；切勿使用已移除的 sanitize()，也不应在 rules() 或控制器中分散清洗，以确保验证一致性与数据纯净。
直接在 FormRequest 里做 trim() 是最轻量、最可控的清洗入口，但必须避开 sanitize() 方法（它早在 Laravel 5.5 就被移除了），改用 prepareForValidation() 或 trait 注入。
FormRequest 中如何安全地 trim 所有字符串输入
Laravel 的 FormRequest 不提供默认清洗钩子，但 prepareForValidation() 是唯一被框架保证在验证前调用、且能修改原始输入的地方。它接收一个数组，你可以原地处理所有字符串字段。
- 只对字符串类型字段调用
trim()，避免误处理数组、文件或 null 值 - 不要在
rules()或messages()里做清洗 —— 那时输入已不可变 - 若规则中用了
required|string|email，trim()后再验证才能让"user@example.com "通过
protected function prepareForValidation()
{
$this->merge(
collect($this->all())
->map(function ($value) {
return is_string($value) ? trim($value) : $value;
})
->all()
);
}
为什么不用 $request->input() + 手动 trim？
单独在控制器里对每个 $request->input('email') 调用 trim() 看似简单，但会重复、遗漏、且破坏验证一致性。
- 一旦漏掉某个字段（比如新增的
phone），后续exists:users,phone规则就可能查不到带空格的数据 - 验证规则和清洗逻辑分散，后期改规则时容易忘记同步清洗逻辑
- 如果用了
$request->validated()，它返回的是已过滤后的数据 —— 但前提是清洗已在prepareForValidation()完成，否则返回的仍是脏数据
批量导入时的清洗要前置到 toArray() 阶段
Excel/CSV 导入场景下，清洗不能等到 FormRequest，因为请求体根本不是标准 HTTP 表单，而是二进制文件。清洗必须发生在解析为 PHP 数组之后、送入 Validator 之前。
- 使用
maatwebsite/excel时，在自定义Import类里重写toArray()，对每行每个单元格做trim()和mb_convert_case($value, MB_CASE_LOWER) - 别在
model()方法里清洗 —— 那时模型已开始构造，脏数据可能污染属性或触发 mutator 误判 - 大文件导入务必配合队列，且复用同一个
Validator实例，避免每次 new 消耗内存
HTML 内容净化不能靠 mutator，必须走事件
对富文本字段（如 content）做 XSS 过滤，绝不能只依赖 setContentAttribute()。Eloquent 的 mutator 在 fill()、update()、create() 等批量操作中不会触发。
- 必须用
creating和updating模型事件，在数据落库前统一净化 - 优先用 Laravel 9.26+ 自带的
Str::clean()，它比strip_tags()更安全，能处理onerror、javascript:协议等 - 若需白名单控制（比如只允许
<p></p>、<strong></strong>），用league/html-sanitizer并显式配置 sanitizer 实例
真正难的不是“怎么写清洗逻辑”，而是确保它在所有写入路径上都不被绕过 —— 包括 API 直接调用 Model::create()、队列任务里的 update()、甚至 Tinker 里的手动赋值。事件监听和集中式清洗方法比零散的 trim() 更值得花时间设计。
