最安全的高亮做法是用textContent提取纯文本，再用document.createElement('mark')包裹匹配片段并replaceChild替换；过滤时应统一转小写比较，多词搜索需拆分后逐个命中，超200条数据要加防抖。
HTML里怎么让搜索关键词高亮显示
直接用 innerHTML 替换再插入，是最常用也最容易出问题的做法。浏览器不会自动转义 HTML 字符，如果搜索词含 、<code>" 或用户输入了恶意字符串，innerHTML 会执行脚本或破坏结构。
安全做法是先用 textContent 提取纯文本，再构造带 <mark></mark> 的新 DOM 节点，而不是拼接字符串后塞进 innerHTML。
- 优先用
document.createElement('mark')包裹匹配片段，再用Node.replaceChild()替换原文本节点 - 正则匹配时加
g和i标志，但注意RegExp构造函数里特殊字符要双反斜杠转义，比如new RegExp('\b' + keyword + '\b', 'gi') - 避免对整个
body或大段 HTML 直接操作，只处理目标容器（如class="work-item"内的标题和描述）
filter() 配合 includes() 做前端作品列表过滤够不够用
够用，但仅限简单场景：关键词完全匹配、不区分大小写、不需要模糊或分词。一旦需求变成“搜‘react’也命中‘React Native’”，或者要支持空格分隔多关键词，includes() 就力不从心了。
常见错误是把用户输入直接传给 filter(item => item.title.includes(input))，结果搜 “ui” 漏掉 “UI Design”，搜 “node” 匹配到 “frontend” 里的子串。
立即学习“前端免费学习笔记（深入）”；
- 统一转小写比较：
item.title.toLowerCase().includes(input.toLowerCase()) - 多词搜索时用
input.split(/s+/).filter(Boolean)拆分，每个词都得命中才算通过 - 如果作品数据量超 200 条，建议加防抖（
setTimeout+clearTimeout），否则每敲一个字都触发重绘
为什么 mark 标签高亮后样式错位或换行异常
因为 <mark></mark> 是内联元素，但被它包裹的文本如果原本在 <div> 或 <code><p></p> 里是块级上下文，强行插入内联标签可能破坏盒模型，尤其当原内容有 white-space: pre-line 或 display: flex 时。
更隐蔽的问题是：高亮后 DOM 节点数量变多，若你用 querySelectorAll('.work-item') 后再循环操作，可能重复处理已被替换过的节点。
- 给
<mark></mark>加 CSS：mark { background: #ffeb3b; padding: 0 2px; border-radius: 2px; }，避免默认背景撑开行高 - 高亮前先清空旧
<mark></mark>：el.querySelectorAll('mark').forEach(m => m.replaceWith(m.textContent)) - 不要在高亮过程中修改父容器的
innerHTML，改用replaceChild或insertBefore
搜索过滤要不要用 indexOf() 替代正则
要看是否需要通配或边界控制。indexOf() 快、安全、无正则注入风险，但无法做“单词开头匹配”或“忽略标点”。比如搜 “js”，indexOf() 会命中 “javascript”，而 /js/i 不会。
性能上，1000 条以内数据差异可忽略；但若开启实时搜索且词库大，indexOf() 的朴素遍历比编译后的正则慢一点——不过这点延迟远不如 DOM 重绘耗时。
- 纯子串查找、不关心位置：用
str.indexOf(keyword) !== -1 - 要排除子串干扰（如“vue”不匹配“vuex”）：必须用正则，且记得
keyword.replace(/[.*+?^${}()|[]\]/g, '\$&')转义特殊字符 - 移动端 Safari 对某些正则标志支持不稳定，
/(? 这种 lookbehind 在 iOS 15.4 以下会报错，退化为 <code>/vue/i
真正难的是平衡：既要高亮准确，又不能让 DOM 变得支离破碎；既要过滤灵敏，又得避开 XSS 和 layout thrashing。这些细节不在文档首页，但在每次搜索卡顿或高亮错乱时，它们全都会跳出来。
