thinkphp 的 input() 函数默认无安全过滤，/s、/d 仅为类型转换；var_filters 全局配置失效多、不支持嵌套字段；filter 参数仅限单字段且不作用于数组；验证器 filter 不修改原始数据；安全过滤必须按使用场景（sql/html/富文本）分别处理。
ThinkPHP 的 input() 函数默认不做任何安全过滤，所谓“/s”“/d”只是类型转换修饰符，不是 XSS 或 SQL 注入防护手段。 你看到的 input('name/s') 只是确保返回字符串类型，input('id/d') 只是强制转整型——它不会帮你 htmlspecialchars()，也不会自动 filter_var(..., FILTER_SANITIZE_NUMBER_INT)。依赖这个就上线，等于把表单入口裸奔在公网。
全局配置 VAR_FILTERS 看似省事，实则危险且失效常见
有人在 config/app.php 里加：'VAR_FILTERS' => 'htmlspecialchars,trim'，以为所有 GET/POST 参数从此“自动安全”。但问题很多：
- 它只作用于顶层键（如
name、email），对嵌套字段（如user[profile][bio]或input('user.bio')）完全无效 - 一旦开启，所有参数无差别过
htmlspecialchars()，JSON 字段里的双引号被转成"，API 返回直接解析失败 - TP6.0+ 中该配置已被弱化，部分版本甚至不触发多维数组遍历，
$_POST['data']['list'][0]['title']会原样透出 - 无法区分上下文：同一个
title字段，入库时不该转义，输出到 HTML 时才需要——全局过滤做不到按需处理
input() 的第三个参数 filter 是字段级补丁，不是安全兜底
input('post.content', '', 'htmlspecialchars') 这种写法确实能临时刮掉一层 HTML 标签，但它有硬伤：
- 只对当前调用生效，漏写一个字段就少防一处；比如写了
input('title')却忘了加htmlspecialchars，XSS 就从这里进 - 不能链式处理，
input('name', '', 'trim|htmlspecialchars')在 TP6 中不支持管道符组合，必须手动嵌套：htmlspecialchars(trim(input('name'))) - 对数组值无效：
input('tags/a')返回数组，filter参数会被忽略，input('tags/a', [], 'htmlspecialchars')不报错但也不起作用 - 性能上，高频接口对非展示字段（如
status、sort）也执行htmlspecialchars，纯属浪费 CPU
验证器里写 filter 规则 ≠ 数据被清洗，只是验证时临时用
很多人在验证规则里写：'content' => 'require|filter:htmlspecialchars'，然后调用 $this->validate($data, MyValidate::class)，结果 $data['content'] 还是原始值。原因很实在：
-
$this->validate()是静态调用，跳过了验证器实例的filter流程，等同于只校验、不走 filter 逻辑 - 必须显式 new 实例并调用
check()：(new MyValidate())->check($data)，此时 filter 才会在验证副本中生效 - 即使生效，
filter也只修改验证器内部副本，$data原数组不变，你仍需手动赋值或取$validator->getData() - filter 不作用于未在验证规则中声明的字段——比如规则只写了
title和content，那input('desc')就完全不受控
真正关键的一点是：**过滤动作必须和使用场景强绑定**。拼 SQL 就用 input('id/d') + 预处理，输出 HTML 就用 htmlspecialchars(input('name'))，存富文本就用 HTMLPurifier ——没有银弹，也没有“一次配置，全局免疫”。别让 input() 承担它不该背的安全责任。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
