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 并不是一种严谨的格式语言，浏览器会进行大量的“纠错”。例如，divphello/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; }避坑指南：不要只删标签，要删内容：scriptalert(1)/script 如果只删了 script 和 /script，中间的 alert(1) 就会变成文本显示出来，虽然不执行，但影响用户体验。所以正则要匹配整个块。 大小写敏感：HTML 标签和属性名不区分大小写，但 JavaScript: 可能写成 javascript: 或 JaVaScRiPt:。正则中必须使用 gi 标志，或者在代码中进行 toLowerCase() 处理。 编码绕过：黑客可能使用 HTML 实体编码，如 scrscriptipt. 简单的正则可能无法识别。这就是为什么 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 内容的？是直接用正则，还是引入了专门的净化库？如果在面试中被问到“如何设计一个安全的富文本后端”，你会怎么回答？欢迎在评论区分享你的实战经验和踩坑记录。