最稳妥方案是用 filter_var() 配合 FILTER_SANITIZE_FULL_SPECIAL_CHARS（等价 htmlspecialchars），而非已废弃的 FILTER_SANITIZE_STRING；它专为表单净化设计，自动剔除 null 字节、控制字符及非法 UTF-8，但仅转义不删除，需按上下文补充 PDO 绑定或 json_encode 等处理。
PHP表单提交时用 filter_var() 过滤字符串最稳妥
直接用 filter_var() 配合 FILTER_SANITIZE_STRING（PHP 8.1 已废弃）或更现代的替代方案，比手写正则或 strip_tags() + htmlspecialchars() 组合更可靠。它专为表单净化设计，内置语义规则，比如自动剔除 null 字节、控制字符、不合法 UTF-8 序列。
但注意：PHP 8.1+ 已彻底移除 FILTER_SANITIZE_STRING，必须改用 FILTER_SANITIZE_SPECIAL_CHARS（仅转义，不删除）、FILTER_SANITIZE_FULL_SPECIAL_CHARS（等价于 htmlspecialchars($str, ENT_COMPAT | ENT_HTML5)），或组合 FILTER_SANITIZE_ENCODED + 后续解码处理。
- 推荐做法：对用户输入先用
filter_var($input, FILTER_SANITIZE_FULL_SPECIAL_CHARS)转义 HTML 特殊字符，再根据上下文决定是否进一步处理（如存数据库前用 PDO 参数绑定，输出到 JS 前用json_encode()） - 别依赖
filter_var($input, FILTER_SANITIZE_STRING)—— 它在 PHP 7.4 已弃用，8.0+ 直接报ValueError - 若需删除而非转义（例如用户名只允许字母数字下划线），改用
filter_var($input, FILTER_SANITIZE_SPECIAL_CHARS)+preg_replace('/[^a-zA-Z0-9_]/', '', $str)，但务必把preg_replace放在 filter 之后，避免正则被未过滤的恶意字符干扰
为什么 htmlspecialchars() 不算“过滤”，只是“转义”
htmlspecialchars() 本质是输出安全函数，不是输入净化函数。它把 变成 <code><，" 变成 "，但原始字符串里的 SQL 注入 payload（如 ' OR 1=1 --）或 XSS 载荷（如 <img src="https://img.php.cn/" alt="PHP表单如何过滤特殊字符输入_过滤字符PHP表单函数法【净化】">）依然完整保留在变量中——只是显示时被浏览器当作文本渲染了。
- 误用场景：把
htmlspecialchars($_POST['name'])存进数据库，等于把一堆写进去，读出来显示就是字面量 <code><，不是用户本意 - 正确分工：
filter_var()或自定义规则做输入净化（删/限制字符），htmlspecialchars()仅在 输出到 HTML 上下文 时调用 - 例外：如果表单字段明确要求“允许有限 HTML”（如富文本简介），就不要用
htmlspecialchars()，而应使用HTMLPurifier等专用库白名单过滤
处理中文、emoji 和宽字符时容易漏掉的陷阱
默认的 FILTER_SANITIZE_FULL_SPECIAL_CHARS 对 UTF-8 支持良好，但遇到 emoji（4 字节 UTF-8）、零宽空格（\u200b）、BOM 头、或者 GBK 编码混入时，可能失效或产生乱码。
立即学习“PHP免费学习笔记（深入）”；
- 强制声明编码：在
filter_var()前加mb_convert_encoding($input, 'UTF-8', 'UTF-8')，可清理非法字节序列 - 检测并剔除控制字符：用
preg_replace('/[\x00-\x08\x0B\x0C\x0E-\x1F\x7F]/', '', $input)清理 ASCII 控制符（含 tab、换行外的不可见字符） - emoji 保留与否看业务：若不允许，可用
preg_replace('/[\x{1F600}-\x{1F6FF}\x{1F900}-\x{1F9FF}\x{1F300}-\x{1F5FF}]/u', '', $input)；若允许，确保 MySQL 表和连接都设为utf8mb4，否则存不进数据库
别忘了表单验证和数据库层的协同
前端 JavaScript 校验和后端 PHP 净化不是二选一，而是分层防御。一个被 filter_var() 清洗过的字符串，仍可能违反业务规则（如邮箱格式、手机号长度、密码强度）。
- 输入净化（
filter_var）解决“字符安全”，表单验证（filter_var($email, FILTER_VALIDATE_EMAIL)）解决“格式合规”，业务逻辑（如“用户名不能为 admin”）解决“语义合法” - 数据库写入必须用参数化查询（PDO 或 MySQLi 的
prepare()），哪怕输入已净化——因为净化无法覆盖所有边界情况（如 MySQL 的宽字节注入在特定配置下仍可能触发） - 特别注意
$_FILES：文件名同样要过filter_var()（FILTER_SANITIZE_FILENAME不是内置常量，得自己用正则），且服务端必须重命名文件、校验 MIME 类型、限制上传目录权限
filter_var() 返回 string，但如果你期望整数却没 cast，后续用 == 比较或传给函数时可能出隐式转换问题。比如 filter_var('123abc', FILTER_SANITIZE_NUMBER_INT) 返回 '123'（字符串），不是 123（整型）。 
