没有“一招鲜”的html输入过滤方案，需据输出上下文、数据流向和富文本需求选择：htmlspecialchars()仅适用于纯文本输出且须指定ent_quotes与'utf-8'；strip_tags()不校验属性危险性，慎用于前端；filter_sanitize_string已弃用；htmlpurifier是富文本唯一可靠方案，但性能开销大。
直接说结论：没有“一招鲜”的HTML输入过滤方案，选哪种方法取决于你输出时要不要保留HTML结构、数据流向哪、以及是否允许富文本。
htmlspecialchars() 适合纯文本输出场景
这是最常用也最容易误用的函数。它只转义 &、、<code>>、"、' 这几个字符，不碰其他标签内容，也不解析嵌套或属性。
- 必须显式传
ENT_QUOTES和'UTF-8'，否则单引号可能绕过、编码不一致会触发双解码漏洞 - 只适用于你明确知道输出位置是纯文本上下文（比如
<p></p>内容、title属性、textarea值） - 如果输出到
href或onclick等属性里，htmlspecialchars()不够用，得配合上下文专用转义 - 别在 JSON 输出里用它——
json_encode($str, JSON_UNESCAPED_UNICODE)才是正确姿势
strip_tags() 要小心保留标签的陷阱
它靠正则粗暴删掉所有 <...></...>，但完全不管标签内部有没有 onerror、javascript: 这类危险属性。
html-to-pptx-converter
下载
使用 PptxGenJS 和 Python 解析，将结构化的 HTML/CSS 幻灯片内容转换为原生、可编辑的 PowerPoint（.pptx）演示文稿。
- 允许白名单时，
strip_tags($input, '<p><br><strong>')</strong></p>
看似安全，但若用户输入<p onclick="alert(1)"></p>，这个onclick会被原样留下 - 它不校验标签是否闭合，也不处理注释、CDATA、自闭合标签里的异常内容
- 性能虽好，但仅推荐用于后台日志清洗、导出纯文本等非前端渲染场景
filter_var() 的 FILTER_SANITIZE_STRING 已被弃用
PHP 8.1 起 FILTER_SANITIZE_STRING 就没了，文档里还留着只是兼容残留。现在用它等于埋雷。
- 替代方案是
FILTER_SANITIZE_SPECIAL_CHARS，但它行为和htmlspecialchars()高度重叠，且默认不指定编码，容易漏掉' -
FILTER_SANITIZE_FULL_SPECIAL_CHARS更接近htmlspecialchars($str, ENT_QUOTES | ENT_HTML5, 'UTF-8')，但依然不处理属性上下文 - 真正需要过滤+验证混合逻辑时，应拆成
filter_var($input, FILTER_VALIDATE_URL)+ 手动白名单校验，而不是依赖单一 filter
HTMLPurifier 是唯一能真正处理富文本的方案
如果你的编辑器支持加粗、链接、图片，又不能信用户自己写的 HTML，那就绕不开它。
- 安装后要配置
HTML.Allowed，比如'a[href|title],strong,em,p,br'，否则默认几乎全禁 - 它会解析 DOM、剥离非法属性、修复未闭合标签、转义 JS 事件，比任何正则都可靠
- 代价是性能开销大，别在高频接口里实时调用；建议存入数据库前净化一次，而非每次读取都 purify
- 注意它不处理 CSS 内联样式，如需支持
style，得额外开启CSS.AllowedProperties并严格限制值范围
最容易被忽略的一点：过滤动作必须紧贴输出上下文。同一段用户输入，输出到 HTML body、data- 属性、URL query、JS 字符串字面量，要用完全不同的转义逻辑——没所谓“全局过滤一次就万事大吉”。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
