本文介绍如何在 Laravel 中于验证前自动为表单字段（如 em_code）拼接固定前缀（如 bZm.），确保前端输入的纯数字能被后端统一转换为带前缀的完整值，从而让 unique 等验证规则与数据库实际存储格式保持一致，避免因格式不匹配导致的验证失效或 MySQL 唯一约束冲突。
本文介绍如何在 laravel 中于验证前自动为表单字段（如 `em_code`）拼接固定前缀（如 `bzm.`），确保前端输入的纯数字能被后端统一转换为带前缀的完整值，从而让 `unique` 等验证规则与数据库实际存储格式保持一致，避免因格式不匹配导致的验证失效或 mysql 唯一约束冲突。
在 Laravel 中，若希望前端仅输入数字（如 1111），但数据库中实际存储并校验的是带前缀的完整字符串（如 bZm.1111），不能依赖控制器中手动拼接——因为验证逻辑（如 unique:users,em_code）会在数据合并到请求对象之后、进入控制器之前执行。若拼接发生在控制器内，验证器看到的仍是原始数字 1111，无法匹配数据库中 bZm.1111 的记录，导致唯一性校验失效，最终触发数据库层面的 Duplicate entry 错误。
✅ 正确做法是：在验证流程早期、验证规则执行前，就将原始输入“标准化”为最终存储格式。Laravel 提供了优雅的钩子 —— prepareForValidation() 方法，专为此类场景设计。
✅ 推荐方案：使用 Form Request 预处理输入
首先，生成一个自定义表单请求类（推荐用于复杂验证）：
php artisan make:request StoreUserRequest
然后，在 app/Http/Requests/StoreUserRequest.php 中重写 prepareForValidation() 方法：
<?php
namespace App\Http\Requests;
use Illuminate\Foundation\Http\FormRequest;
class StoreUserRequest extends FormRequest
{
protected function prepareForValidation()
{
// 仅当 em_code 存在且非空时进行拼接
if ($this->filled('em_code')) {
$this->merge([
'em_code' => 'bZm.' . $this->string('em_code')->trim(),
]);
}
}
public function rules()
{
return [
'em_code' => [
'required',
'string',
'max:20',
'unique:users,em_code', // ✅ 此时验证的是 'bZm.1111'，与 DB 字段值完全一致
],
// 其他字段...
];
}
}? 注意：
$this->string('em_code')是 Laravel 9+ 提供的安全字符串封装，可防止非字符串类型（如数组）引发错误；trim()确保去除首尾空格。
接着，在控制器中直接使用该请求类：
public function store(StoreUserRequest $request)
{
// $request->em_code 已是 'bZm.1111' 格式，可直接入库
User::create($request->validated());
return redirect()->back()->with('success', '用户创建成功！');
}⚠️ 注意事项与最佳实践
- 不要在 Blade 中通过 JS 拼接并隐藏提交：前端拼接不可靠（易被绕过、影响 UX、破坏语义），且无法保证服务端验证一致性。
-
避免在 Controller 中
merge()或replace()请求数据：此时验证已执行完毕，拼接无效；且违反单一职责原则。 -
数据库字段类型需匹配：确保
em_code字段为VARCHAR（如VARCHAR(20)），而非INT或BIGINT，否则无法存储前缀字符串。 - 兼容旧版 Laravel（：若未使用
string()辅助方法，可改用(string) $this->em_code并手动trim()。 -
批量更新/其他场景：同理，所有涉及该字段的验证（如
UpdateUserRequest）均需复用prepareForValidation()逻辑，保障一致性。
通过 prepareForValidation()，你实现了「输入即规范」——用户只需输入数字，系统自动补全前缀，并在验证、存储、查询全流程中保持格式统一。这是 Laravel 官方推荐、安全可靠、高度可维护的解决方案。
