不安全，filter_var()仅适合基础类型校验，不能清洗非法字符；应优先用htmlspecialchars()（显式指定ent_quotes和utf-8），富文本须用htmlpurifier等成熟库，数据库只存原始数据、输出时按上下文转义。
php用filter_var()过滤字符串安全吗？
不安全，它只适合校验基础类型（如邮箱、URL），对“非法字符”这种模糊需求完全不适用。它的设计目标是数据验证，不是内容清洗，比如filter_var("xss<script>", FILTER_SANITIZE_STRING)</script>在 PHP 8.1+ 已被移除，且旧版本也只做极简替换，不防 XSS、不处理 Unicode 边界、不统一编码。
- 别用
FILTER_SANITIZE_STRING：已废弃，且行为不可控（如对无反应） - 校验型过滤器（如
FILTER_VALIDATE_EMAIL）返回布尔值，不能当清洗函数用 - 若硬要用，仅限 ASCII 范围内的简单去标签场景，且必须搭配
htmlspecialchars()二次处理
真正该用的函数是htmlspecialchars()还是htmlentities()？
95% 场景下选 htmlspecialchars()，它只转义 HTML 元字符（, <code>>, &, ", '），保留所有非 HTML 语义的字符（比如中文、emoji、数学符号），而 htmlentities() 会把所有非 ASCII 字符也转成实体，导致可读性崩坏、搜索失效、数据库存储膨胀。
- 必须显式传
ENT_QUOTES和UTF-8编码：htmlspecialchars($str, ENT_QUOTES | ENT_HTML5, 'UTF-8') - 如果输出到 HTML 属性里（如
value="..."），确保属性值用双引号包裹，否则单引号内容无法被ENT_QUOTES覆盖 -
htmlentities()只在需强制兼容古董浏览器（IE6）、或明确要求所有非 ASCII 字符不可见时才考虑
用户输入含富文本怎么办？不能全转义又不能全放行
这是最常踩坑的点：用 strip_tags() 简单删标签，结果留下 onerror=alert(1) 这类内联 js；或者用正则匹配 <script></script>，却漏掉 <script></script>、<img src="x" onerror="..." alt="PHP怎么过滤特殊字符 php字符串非法字符过滤【进阶】" > 等变体。
- 不要自己写白名单过滤逻辑——HTML 解析器比你想象中复杂得多
- 生产环境必须用成熟库：
HTMLPurifier（重量但精准）、league/html-to-markdown+ 白名单 Markdown 渲染（适合评论区）、或前端用DOMPurify做二次过滤 - 若坚持轻量方案，至少用
strip_tags($str, ['br', 'p', 'strong', 'em'])显式声明允许标签，并对输出前再过一遍htmlspecialchars()（针对未闭合标签或属性截断漏洞）
数据库存入前要不要过滤？还是只在输出时处理？
只在输出时处理。过滤/转义是上下文相关的动作，同一段字符串在 HTML 页面、json API、sql 查询、日志文件中的安全要求完全不同。提前“消毒”会污染原始数据，导致搜索失败、导出乱码、API 字段语义丢失。
立即学习“PHP免费学习笔记（深入）”；
- 存入数据库前，只做必要编码统一（如
mb_convert_encoding($str, 'UTF-8', 'auto')）和长度截断 - SQL 注入防护靠预处理语句（
pdo::prepare()/mysqli->prepare()），不是靠过滤字符串 - 唯一例外：存入前需校验格式（如手机号、邮编），那用
filter_var()或正则做只读判断，不修改原值
最易被忽略的是多层上下文嵌套——比如把用户输入拼进 JavaScript 字符串再塞进 HTML：<script>var msg = "<?php echo $user_input; ?>"</script>。这时 htmlspecialchars() 不够，得用 json_encode($user_input, JSON_UNESCAPED_UNICODE)，否则引号和反斜杠会破坏 JS 语法。这种细节，不跑真实数据根本试不出来。