PHP主流架构怎么处理表单验证_规则与自定义【技巧】

在 Laravel 中,表单验证规则应定义在 FormRequest 类的 rules() 方法中,使用字符串规则、闭包或 Rule 对象,并注意 trim、nullable 等细节以正确处理空格、null 等边界值。

表单验证规则怎么定义在 Laravel 的 Request 类里

直接在 FormRequest 类中重写 rules() 方法,是最主流、最清晰的规则组织方式。Laravel 会自动调用它,并在验证失败时返回 422 响应。

常见错误是把规则硬编码在控制器里,导致复用困难、测试难覆盖、错误消息分散。

  • requiredemailmax:255 这类字符串规则可直接写,但注意 max 对字符串是字符数,对数组是元素个数,对文件是字节数
  • 需要动态参数(比如“用户名不能与当前用户相同”)时,用闭包函数:
    return [
        'username' => ['required', function ($attribute, $value, $fail) {
            if ($value === auth()->user()->username) {
                $fail('用户名不能与当前账号相同');
            }
        }]
    ];
  • 规则顺序有影响:Laravel 按数组顺序逐条校验,遇到第一个失败就停;所以把轻量级检查(如 required)放前面,避免执行耗时规则(如 exists:users,email

自定义验证规则为什么推荐用 Rule 对象而不是字符串

字符串规则(如 'price' => 'between:0,9999.99')写起来快,但缺乏上下文、难复用、无法注入依赖,一旦逻辑变复杂就容易失控。

Illuminate\Validation\Rule 对象(配合 Rule::exists()Rule::unique() 等)能显式表达意图,也支持链式配置。

  • Rule::unique('users')->ignore($user->id)'email' => 'unique:users,email,' . $user->id 更安全:后者若 $user->id 为空或为字符串 'null',可能意外跳过忽略逻辑
  • 自定义规则类(php artisan make:rule UppercaseFirstLetter)必须实现 passes()message(),且 passes() 返回 bool,不能抛异常——否则验证流程中断,不走统一错误处理
  • Rule 对象在批量验证(validateWithBag())或表单重填(old())场景下行为更稳定,字符串规则有时会因引号嵌套或空格导致解析歧义

前端提交空字符串 vs null,后端验证怎么不踩坑

Laravel 默认把空字符串 '' 当作有效值(除非加 required),而 JavaScript 表单序列化常把未填字段发成 '' 而非 null,这和开发者直觉不符。

关键点:Laravel 不会自动过滤空字符串,trim 必须显式加在规则里,否则 ' ' 会通过 required

  • 对文本字段,习惯性加上 'name' => 'required|string|trim|min:2'trim 是 Laravel 9+ 内置规则,会自动去首尾空格并转为 null(若结果为空)
  • 不要依赖前端 JS 校验来过滤空格——用户禁用 JS 或用 curl 提交时,后端必须兜底
  • 如果字段允许为空但又需格式校验(如邮箱),用 'email' => 'nullable|email'nullable 允许 null 或空字符串,但不会自动 trim,所以组合写法是 'email' => 'nullable|string|trim|email'

验证失败后如何保留原始输入并高亮错误字段

Laravel 自动把验证失败的请求数据存进 session 的 errorsold 区域,但模板里要主动用 old()$errors 才能生效。

容易忽略的是:默认只保留上一次请求的 old 数据,刷新页面后丢失;且 $errorsMessageBag 实例,不是普通数组。

  • Blade 中取值统一用 {{ old('email') }},别用 $_POST['email']request('email'),后者在重定向后拿不到原始值
  • 判断字段是否有错:用 @error('email')...@enderror,它底层调用 $errors->has('email'),比手动写 @if($errors->has('email')) 更简洁
  • 如果用了 Vue/React 做表单,后端仍需返回标准 JSON 错误结构(422 Unprocessable Entity + {"message":"Validation failed","errors":{"email":["The email must be a valid email address."]}}),前端才能统一处理;此时 old() 无意义,得靠响应体里的 input 字段或手动存入 localStorage
验证规则的边界情况(比如空格、null、0、false、字符串数字)比想象中多,真正稳定的表单处理,80% 功夫花在明确每个字段的“合法空值”定义上,而不是堆砌规则。