3行代码看懂katharsis源码，面试必问的HTML解析坑

很多后端或前端全栈工程师在写 Node.js 项目时，遇到需要处理用户提交的 HTML 内容，第一反应往往是正则。结果发现，正则根本处理不了嵌套标签，或者在面试中被问起“如何安全地解析 HTML”，只能支支吾吾。这就是典型的“学会语法却不知怎么搭项目”的困境。其实，处理 HTML 解析在技术面试中属于面试必问的高频考点，尤其是涉及 XSS 防护、模板引擎渲染底层时。今天咱们不整虚的，直接拆解一个轻量级但极其经典的库——katharsis。它不是 jQuery，也不是 cheerio，而是一个专注于“净化”HTML 的轻量级解析器。通过读它的源码，你能明白为什么浏览器解析 HTML 这么复杂，以及如何在 Node.js 环境里做一个安全的 HTML 过滤器。

入口定位：为什么选 Katharsis 而不是 Cheerio？

在 Node.js 生态里，处理 HTML 的库多如牛毛。Cheerio 是基于 jQuery 语法的选择器库，功能强大但体积较大；JSDOM 则是在 Node 里模拟完整的浏览器 DOM 环境，性能开销巨大。而 katharsis 的设计初衷非常明确：它不构建完整的 DOM 树，它只关心“安全性”。

Katharsis 的核心定位是 HTML Sanitizer（净化器）。它基于 parse5（一个符合 WHATWG 标准的 HTML 解析器）或者简化的状态机来实现。对于中小施工企业的信息化项目，或者任何涉及用户 UGC（用户生成内容）的场景，你不需要知道这个 <div> 的样式是什么，你只需要知道这个 <script> 标签能不能放行。

Katharsis 的入口文件通常非常简洁。我们来看它的核心初始化逻辑。很多开发者习惯直接 require('katharsis')，但不知道它内部其实加载了一套预定义的“白名单”。

// 假设这是 katharsis 的核心初始化片段（基于其源码结构简化）
const parse5 = require('parse5');
const whitelist = require('./whitelist'); // 内置的默认安全标签和属性白名单// 核心解析与净化函数
function parse(html) {// 1. 使用 parse5 将 HTML 字符串解析为文档片段// 注意：这里不是创建 DOM 对象，而是生成 AST（抽象语法树）const documentFragment = parse5.parseFragment(html);// 2. 递归遍历 AST 节点const nodes = serialize(documentFragment.nodes);// 3. 根据白名单过滤节点，移除危险标签const sanitizedHtml = filterNodes(nodes);return sanitizedHtml;
}// 导出模块
module.exports = {parse: parse,// 允许用户自定义白名单setWhitelist: function(customList) {// 合并自定义白名单与默认白名单// ...}
};

这段代码揭示了 Katharsis 的第一层设计思想：AST（抽象语法树）驱动。它不操作 DOM 节点，而是操作解析后的树状结构。这种设计比正则匹配可靠得多，因为它能正确识别标签的开始和结束，不会因为字符串里包含 </div> 这样的文本而误判。

核心片段：AST 遍历与白名单过滤

Katharsis 最核心的逻辑在于如何遍历这棵树，并决定哪些节点该保留，哪些该删除。这里涉及到两个关键概念：标签白名单（Tags）和属性白名单（Attributes）。

我们来看一段处理节点的核心源码逻辑。这是 Katharsis 中 filter 或 sanitize 函数的简化版，展示了它是如何“逐行”清洗数据的。

// 核心过滤逻辑片段
function filterNode(node, whitelist) {// 1. 判断节点类型：元素节点、文本节点、注释节点等// 在 parse5 的 AST 中，node.type 可能是 'element', 'text', 'comment'if (node.type !== 'element') {// 文本和注释通常被认为是安全的，但需要进一步检查文本内容// 防止文本中包含类似 </script> 的闭合标签导致上下文切换if (node.type === 'text') {return escapeText(node.value);}return '';}// 2. 获取当前标签名（小写）const tagName = node.tagName.toLowerCase();// 3. 检查标签是否在白名单中// 如果不在白名单中，直接丢弃该节点及其所有子节点if (!whitelist.tags.includes(tagName)) {return '';}// 4. 构建新的安全属性列表let safeAttributes = [];for (let i = 0; i < node.attrs.length; i++) {const attr = node.attrs[i];const attrName = attr.name.toLowerCase();// 检查属性名是否在白名单中if (!whitelist.attributes.includes(attrName)) {continue;}// 5. 特殊处理：事件属性（如 onclick）绝对禁止if (attrName.startsWith('on')) {continue;}// 6. 特殊处理：URL 属性（如 href, src）需要检查协议if (['href', 'src', 'background'].includes(attrName)) {if (isDangerousUrl(attr.value)) {continue;}}safeAttributes.push(attr);}// 7. 递归处理子节点let innerHTML = '';for (let i = 0; i < node.childNodes.length; i++) {innerHTML += filterNode(node.childNodes[i], whitelist);}// 8. 重组 HTML 字符串let attrStr = safeAttributes.map(a => `${a.name}="${escapeAttr(a.value)}"`).join(' ');let tag = `<${tagName}`;if (attrStr) {tag += ` ${attrStr}`;}tag += `>`;// 自闭合标签特殊处理（如 <br>, <img>）if (isVoidElement(tagName)) {return tag.replace('>', '/>');}return `${tag}${innerHTML}</${tagName}>`;
}

逐行解析重点：

节点类型判断：node.type !== 'element' 这一步至关重要。很多 XSS 攻击不是通过 <script> 标签，而是通过 <img src=x onerror=alert(1)> 或者 <svg onload=alert(1)> 实现的。Katharsis 必须区分元素节点和文本节点，因为文本节点中的 < 和 > 应该被转义，而不是被解析为标签。
白名单匹配：whitelist.tags.includes(tagName)。这是“白名单机制”的核心。默认情况下，Katharsis 只允许 <a>, <b>, <i>, <p>, <br>, <div> 等基础格式化标签。像 <script>, <iframe>, <object> 等高风险标签直接被丢弃。
属性清洗：注意 attrName.startsWith('on') 的判断。这是为了防止 onclick, onerror, onload 等事件监听器。即使标签在白名单里（比如 <a>），如果它带有 onclick 属性，这个属性也会被剥离。
URL 协议检查：isDangerousUrl 是一个关键函数。它需要检查 href 是否以 javascript:, data:, vbscript: 开头。例如 <a href="javascript:alert(1)"> 必须被拦截。

设计思想：防御性编程与最小权限原则

Katharsis 的设计思想体现了安全领域的最小权限原则（Principle of Least Privilege）。它不试图支持所有 HTML 标签，而是只允许“已知安全”的标签和属性。这种“默认拒绝，白名单放行”的策略，比“黑名单拦截”要安全得多。

为什么？因为黑客总是能想出新的标签或属性组合来绕过黑名单。比如，早期的一些过滤器拦截了 <script>，但黑客可以用 <svg/onload=alert(1)>。如果用黑名单，你需要不断添加新的拦截规则。但用白名单，只要 <svg> 不在白名单里，不管它带什么属性，都会被直接丢弃。

此外，Katharsis 依赖于 parse5 或类似的标准化解析器，这解决了“解析歧义”问题。HTML 并不是一种严谨的格式语言，浏览器会进行大量的“纠错”。例如，<div><p>hello</div> 在 HTML 规范中是不合法的（因为 <p> 不能嵌套在 <div> 中而不闭合），但浏览器会自动处理。如果使用正则表达式解析，可能会把 <p> 错误地识别为 <div> 的子元素，或者完全解析失败。Katharsis 通过复用成熟的解析器，确保了它对各种畸形 HTML 的处理与浏览器行为一致，从而避免了“解析差异攻击”（Mozambique Bug 等）。

对于面试来说，这里有一个面试必问的延伸点：为什么前端框架（如 React, Vue）的 v-html 或 dangerouslySetInnerHTML 依然需要谨慎使用？ 答案就是：它们依赖库的自动转义机制，但一旦你手动注入了未净化的 HTML，就绕过了这层保护。Katharsis 这类工具的作用，就是在数据进入渲染引擎之前，先过一遍“安检”。

手写简化版：如何在项目中实现轻量级净化？

虽然我们可以直接用 Katharsis，但理解其原理后，你可以手写一个更轻量的版本，用于对性能要求极高或对依赖敏感的场景。以下是一个基于 Node.js 内置 DOMParser（需 polyfill）或简单状态机的简化实现思路。

这里我们提供一个基于“字符串替换 + 简单正则”的极简净化器，仅用于演示思路，不建议直接用于生产环境，因为它的覆盖范围有限。

// 极简 HTML 净化器（仅用于理解原理，生产环境请用成熟库）
function simpleSanitize(html) {// 1. 移除所有 <script> 标签及其内容html = html.replace(/<script\b[^<]*(?:(?!<\/script>)<[^<]*)*<\/script>/gi, '');// 2. 移除所有 <style> 标签及其内容html = html.replace(/<style\b[^<]*(?:(?!<\/style>)<[^<]*)*<\/style>/gi, '');// 3. 移除所有 on* 事件属性html = html.replace(/\bon\w+\s*=\s*("[^"]*"|'[^']*'|[^\s>]+)/gi, '');// 4. 移除 javascript: 协议html = html.replace(/href\s*=\s*("javascript:.*?"|'javascript:.*?'|javascript:.*?)/gi, 'href="#"');// 5. 转义文本中的特殊字符（简化版，实际需更严谨）// 注意：这一步很难用正则完美实现，因为要区分标签内的属性和标签外的文本// 这里仅展示思路，实际项目中请避免手写return html;
}

避坑指南：

不要只删标签，要删内容：<script>alert(1)</script> 如果只删了 <script> 和 </script>，中间的 alert(1) 就会变成文本显示出来，虽然不执行，但影响用户体验。所以正则要匹配整个块。
大小写敏感：HTML 标签和属性名不区分大小写，但 JavaScript: 可能写成 javascript: 或 JaVaScRiPt:。正则中必须使用 gi 标志，或者在代码中进行 toLowerCase() 处理。
编码绕过：黑客可能使用 HTML 实体编码，如 <scr<script>ipt>. 简单的正则可能无法识别。这就是为什么 Katharsis 依赖 parse5 的原因——解析器会先解码实体，再构建 AST，从而暴露出隐藏的标签。

应用场景：从面试到生产环境的落地

在实际的项目中，Katharsis 或类似的 HTML 净化库通常应用在以下几个场景：

富文本编辑器输出：用户在前端编辑器中输入内容，提交到后端。后端在存储前，必须使用 Katharsis 对 HTML 进行净化，只保留格式化标签（如加粗、斜体、链接），移除所有脚本和样式。
评论系统：用户提交的评论可能包含 HTML。如果不净化，恶意用户可以插入 <img src=x onerror=alert(document.cookie)> 窃取 Cookie。
邮件模板渲染：如果你需要向用户发送包含用户自定义内容的邮件，必须净化 HTML，防止邮件客户端执行恶意脚本。

面试高频考点总结：

Q: 如何防止 XSS 攻击？
- A: 1. 输入验证（白名单）；2. 输出编码（HTML Entity Encoding）；3. 使用 CSP（内容安全策略）；4. 使用 HTML 净化库（如 Katharsis, DOMPurify）。
Q: Katharsis 和 DOMPurify 的区别？
- A: DOMPurify 是浏览器端库，依赖 DOM API；Katharsis 是 Node.js 端库，依赖 AST。DOMPurify 性能更好，因为直接操作 DOM；Katharsis 更轻量，适合服务端流式处理。
Q: 为什么不用正则解析 HTML？
- A: HTML 不是正则语言（Regular Language），它包含嵌套结构。正则无法正确处理嵌套标签、畸形标签和实体编码。解析器（Parser）是唯一的可靠方案。

在中小施工企业的信息化项目中，很多业务系统（如进度汇报、现场照片描述）都涉及富文本输入。如果后端没有做 HTML 净化，整个系统都可能成为 XSS 攻击的跳板。这不仅是一个技术问题，更是一个合规问题。根据MDN Web Docs 关于“Sanitizing untrusted content”的指南，任何来自不可信来源的 HTML 内容，在渲染前都必须经过净化。这不是可选的最佳实践，而是安全底线。

你公司项目里是怎么处理用户输入的 HTML 内容的？是直接用正则，还是引入了专门的净化库？如果在面试中被问到“如何设计一个安全的富文本后端”，你会怎么回答？欢迎在评论区分享你的实战经验和踩坑记录。