ThinkPHP中统一过滤用户输入参数需按版本选择方案：TP5.0用default_filter或request_filter_rules；TP5.1兼容default_filter与全局中间件；TP6推荐验证器filter或路由分组中间件。

在ThinkPHP项目中，如果需要对所有用户输入参数进行统一的安全处理，以防范XSS、HTML注入等常见风险，那么框架自带的全局过滤机制就是你的首选工具。不过，具体怎么配，得看你的项目用的是哪个版本。下面这几种配置方式，都是经过验证的可行方案。

一、配置application/config.php中的default_filter

这个方法适用于ThinkPHP 5.0和5.1版本。它的原理很简单：通过修改一个全局的默认过滤函数设置，让框架在通过input()、request()->param()等方法获取数据时，自动完成清洗工作。说白了，就是Request类在调用input()方法时，如果没收到明确的过滤指令，就会自动套用这里配置的规则。

具体操作分四步：

1、打开项目里的application/config.php文件。

2、在配置数组中找到合适的位置，添加或修改'default_filter'这一项。比如，你可以写成：'default_filter' => 'htmlspecialchars,strip_tags,trim'。

立即学习“PHP免费学习笔记（深入）”；

3、确保这个配置项是写在return [ ... ]这个结构里面的，并且键名拼写要绝对准确。

4、保存文件后，别忘了重启一下Web服务（比如Apache或Nginx），让配置生效。

这里有个关键点：TP6.x版本已经废弃了default_filter配置，所以这个方法对ThinkPHP 6及以后的版本不适用。

二、在app/middleware.php中注册全局中间件过滤

如果你想找一个TP5.1和TP6.x都能兼容的方案，那么全局中间件过滤就是答案。它的思路是在请求生命周期的早期介入，拦截原始的GET或POST数据，清洗干净后再塞回Request对象里。这样一来，后续所有通过input()获取的数据就都是“干净”的了。核心要点是，要确保数据清洗发生在框架读取原始超全局变量（如$_GET、$_POST）之前。

实现起来也不复杂：

1、先创建一个中间件类，比如放在app/middleware/GlobalInputFilter.php。

2、在这个中间件的handle()方法里，编写逻辑来遍历清洗$request->get()和$request->post()的数据。对于字符串值，可以用htmlspecialchars()或者filter_var($value, FILTER_SANITIZE_STRING)来处理，记得跳过数组、对象这些非标量类型。

3、清洗完成后，需要把数据合并回去。TP6.1及以上版本可以用$request->mergeParam($cleanedData)；如果是旧版的TP6，可能就需要通过反射来修改$request->param属性了。

4、最后，在app/middleware.php文件里，把这个中间件类名加入到全局中间件数组中，例如：[\app\middleware\GlobalInputFilter::class]。

这里必须敲一下黑板：中间件的handle()方法里，最后一定要记得return $next($request)，否则请求链就断了，页面会白屏。

三、启用request_filter_rules全局规则集（TP5.0专属）

这是ThinkPHP 5.0版本独有的一个功能，它通过一个叫request_filter_rules的扩展配置项，允许你定义字段级别的白名单过滤策略。相比一刀切的default_filter，它更精细，能有效避免因为全局清洗而误伤JSON等结构化数据字段。

配置方法如下：

1、在application/config.php里，添加'request_filter_rules'这个配置项。

2、设定规则。你可以用通配符，比如'*' => ['trim', 'htmlspecialchars']，表示所有字段都执行去除空格和HTML转义。

3、也可以指定具体字段，搞个白名单。例如：'user' => ['htmlspecialchars'], 'content' => ['htmlspecialchars_decode']。

4、最后，确保配置里'request_filter' => true是开启状态，不然规则不会加载。

再次强调：这个配置项只有TP5.0支持，TP5.1及以上版本，包括TP6，都用不了。

四、基于验证器的字段级filter声明（TP6推荐）

到了ThinkPHP 6，官方更推荐的方式是把过滤逻辑和验证规则绑定在一起。这种方式不依赖任何全局配置，特别适合不同接口需要对字段做差异化处理的场景。它的原理是，在验证器调用check()方法时，对匹配的字段执行指定的过滤函数，但请注意，这个操作只影响验证器内部的数据副本。

具体可以这么操作：

1、在你的验证器类（比如app/validate/UserValidate.php）的规则数组里，为字段加上'filter'键。例如：'title|标题' => 'require|filter:htmlspecialchars'。

2、调用验证时，务必使用实例化方式，而不是静态调用：(new UserValidate())->check($data)。

3、如果需要批量过滤多个字段，可以在scene方法中统一配置，像这样：'filter' => ['name' => 'trim', 'email' => 'strtolower']。

4、还有一个容易踩的坑：调用check()之前，必须先通过data($data)方法绑定原始数据，否则过滤规则不会生效。

这一点至关重要：验证器里的filter操作，不会去修改你传入的原始$data数组，它只作用于验证器自己内部的那份数据副本。

五、通过路由中间件按分组启用过滤（精准控制）

有时候，我们并不需要全局洗数据。比如，只想给管理后台（/admin/）或者某个API版本（/api/v1/）加上过滤，而像登录页、静态资源文件这些路径则想排除在外。这时候，路由分组中间件就派上用场了，它能做到精准控制，避免不必要的性能损耗和误伤合法数据。

实现路径如下：

1、在route/middleware.php（或类似的路由定义文件）中，为特定的路由分组定义中间件。例如：Route::group('admin', function () { ... })->middleware('global_filter');。

2、创建对应的中间件文件，比如app/middleware/GlobalFilter.php，里面的过滤逻辑可以参考上面第二项中间件的写法，但要确保它只对匹配当前分组的请求执行。

3、为了更精准，你可以在中间件的handle()方法里加入路径判断。比如：if (strpos($request->url(), '/public/') === 0) return $next($request);，这样/public/路径下的请求就直接放行了。

4、注册这个中间件到路由分组时，要确保它是在路由定义之后、调用->middleware()方法之前完成的。

最后提个醒：部署后一定要检查一下，看看中间件会不会意外拦截到CSS、JS这类静态资源的请求，否则可能导致页面样式错乱或者功能失效。