Laravel 的表单请求（Form Request）在处理包含 HTML 实体 < 的输入时，会错误地将 < 后续字符（非空白符）之后的内容截断，导致数据丢失；根本原因并非 Laravel 自动转义，而是底层 filter_var() 在 FILTER_SANITIZE_STRING（已废弃）或某些 PHP 扩展/配置下对 < 的误解析。

laravel 表单请求中 `

这个问题不是 Laravel 主动转义 <，而是一个典型的「伪转义截断」现象——实际是 PHP 的 filter_input() 或某些安全扩展（如 suhosin，虽已过时但部分环境仍残留）在处理 < 时，将其误识别为未闭合的 HTML 标签起始（如 <bar>），进而触发了不安全内容过滤逻辑，导致后续字符串被静默截断。</bar>

✅ 正确诊断方式：

// 在 FormRequest 的 authorize() 或 rules() 中临时调试
dd($_POST['comments']); // 原始 POST 数据完整
dd($this->input('comments')); // 可能已被截断 → 说明问题出在 Laravel 输入解析层

? 根本解决方案（推荐）：

1. 禁用自动输入过滤（Laravel 9+ 默认已移除，但旧版本需检查）
   Laravel 5.5–8.x 中，App\Http\Kernel 的 $middleware 数组可能包含 TrimStrings::class 或自定义过滤中间件。检查是否启用了类似 filter_var($value, FILTER_SANITIZE_STRING) 的逻辑（该函数自 PHP 8.1 起已彻底废弃，且行为不可靠）。切勿使用 htmlspecialchars("foo < bar") 作为解决方案——这属于错误归因：htmlspecialchars() 作用于 &、、<code>> 等字符，但 < 是已编码实体，双重编码会导致 ，完全偏离原始意图。

2. 在 FormRequest 中绕过默认解析，直接读取原始输入

   

   laravel-specialist

   精通 Laravel 10+，遵循现代 PHP 实践的 Laravel 专家。擅长优雅语法、Eloquent ORM、队列系统及企业级特性...

   下载

   // app/Http/Requests/StoreCommentRequest.php
   protected function prepareForValidation()
   {
       // 强制以原始字符串获取 comments 字段，避免中间件/过滤器干扰
       $input = $this->all();
       if (isset($input['comments'])) {
           // 使用 $_POST 直接获取（确保未被修改）
           $input['comments'] = $_POST['comments'] ?? $input['comments'];
       }
       $this->replace($input);
   }

3. 升级并清理 PHP 环境（长期建议）

   • 确认 PHP 版本 ≥ 8.0，禁用所有废弃的 suhosin 或 mod_security 规则；
   • 检查 php.ini 中是否存在 filter.default = unsafe_raw（应设为 unsafe_raw 或显式移除）；
   • 避免全局启用 FILTER_SANITIZE_STRING（已废弃，无替代方案，应改用白名单过滤）。

⚠️ 注意事项：

• 不要对用户输入做“预 htmlspecialchars”，这破坏了数据原始性，应在输出渲染时（Blade 中 {{ $content }} 已自动转义）或富文本场景下使用 !! $content + CSP 白名单控制；
• 若需存储 HTML 内容，请明确使用 htmlentities() 或 strip_tags() 配合白名单（如 Purify 包），而非依赖模糊的自动过滤；
• 此问题在 Laravel 9+ 中极少复现，因其已移除对 FILTER_SANITIZE_* 的隐式调用，升级框架是最稳妥的修复路径。

总结：这不是 Laravel 的“特性”，而是历史兼容性与不当服务器配置叠加产生的副作用。优先通过 prepareForValidation() 获取原始输入，并推动环境标准化，才能一劳永逸解决问题。