filter在验证器中未生效是因为其仅作用于验证器内部副本，需显式实例化并调用check()，清洗后数据须通过getdata()获取；全局过滤应在中间件中选择性处理字符串参数；模型层推荐使用访问器精准净化；输出时须按上下文选用htmlspecialchars、json_encode或urlencode。
验证器里写 filter 却没生效？检查调用方式和数据流向
很多人在验证规则里写了 'title' => 'require|filter:trim,htmlspecialchars'，但打印 $data 发现还是原始值——这不是 bug，是 ThinkPHP 的设计逻辑：filter 只在 (new MyValidate())->check($data) 执行时，对验证器内部副本做清洗，$data 本身完全不变。
- 必须显式实例化验证器并调用
check()，不能用静态方法Validate::check($data, ...)，后者跳过 filter 流程 - 清洗后的数据要从验证器取：
$safeData = $validate->getData()，而不是继续用原始$data - 嵌套字段如
user.name不支持input('user.name', '', 'htmlspecialchars')，得在中间件或模型层处理 - 高频接口慎用全量
htmlspecialchars，只对可能输出到 HTML 的字段（如content、intro）启用
中间件统一预处理 GET/POST 参数，但避开非展示字段
在控制器之前就清洗原始输入，比每个接口手动处理更可靠。但直接对所有参数调用 htmlspecialchars() 会破坏数字、JSON、文件上传等类型数据，必须有选择地过滤。
- 创建中间件
app/middleware/GlobalInputFilter.php，在handle()中遍历$request->param() - 只对字符串值执行
trim()和htmlspecialchars()，其他类型（int、array、null）跳过 - 用
$request->withParam($cleaned)注入清洗后数据，后续input()或param()拿到的就是干净值 - 不要改
$_GET/$_POST—— ThinkPHP 的param()是封装快照，直接改超全局变量无效
模型层精准净化，别依赖 $filter 属性
TP6 中模型的 $filter 属性基本失效：它只在 data()->validate()->save() 链式调用且显式启用时才触发，save(['field'=>'val']) 直接绕过。真正可控的方式是字段级访问器。
- 定义
setUsernameAttr($value)方法，在里面做trim()、去零宽字符、全角转半角等 - TP6.1+ 支持批量注册：
$this->filter(['title', 'desc'], 'trim')，框架自动绑定到对应setXxxAttr -
Db::table()->insert()、JSON 字段、关联数据都不走模型过滤，这些场景得靠数据库中间件兜底 - 富文本字段（如编辑器内容）禁用
htmlspecialchars，必须用HTMLPurifier白名单过滤
输出上下文决定清洗方式，同一数据不同处理
清洗不是“刮一层就完事”，而是按最终使用位置决定策略。把 htmlspecialchars() 塞进数据库或 JSON 接口，会导致双编码、前端显示异常等问题。
- 输出到 HTML：用
htmlspecialchars($content, ENT_QUOTES | ENT_HTML5, 'UTF-8')，三参数缺一不可 - 赋值给 JavaScript 变量：必须用
json_encode($desc, JSON_UNESCAPED_UNICODE | JSON_HEX_TAG | JSON_HEX_AMP) - 拼进 URL 参数：用
urlencode()，不是htmlspecialchars() - 插入数据库前：不清洗，靠预处理语句隔离；入库后读出再按输出场景分别处理
json_encode，XSS 就可能绕过所有前置过滤。php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
