html搜索框需javascript实现实时搜索，oninput比onkeyup更全面支持各类输入方式；须加防抖避免高频请求；表格过滤应优化dom操作与匹配逻辑；清空时须正确重置display样式。
HTML搜索框本身不触发实时搜索，这是设计使然——input元素默认只提供输入能力，没有内置的“边输边查”逻辑。要实现它，必须靠JavaScript主动监听、过滤、请求或渲染。
为什么oninput比onkeyup更适合实时搜索
oninput在每次输入内容变更时立即触发（包括粘贴、删除、语音输入、剪贴板插入），而onkeyup只响应键盘抬起事件，漏掉非键盘操作。比如用户右键粘贴“react”，onkeyup完全不会捕获；但oninput会。
- 直接写在HTML里：
<input type="search" id="searchInput" oninput="handleSearch()"> - 更推荐JS绑定：
searchInput.addEventListener('input', handleSearch)，便于统一管理与解绑 - 注意：不要用
onchange，它只在失焦后触发，完全不符合“实时”要求 - 移动端软键盘回车也可能触发
input，行为一致，无需额外适配
不加防抖会导致什么问题
每敲一个字符就发一次请求，用户输入“hello”会发起5次HTTP调用，其中前4次响应可能在第5次结果返回后才抵达，造成界面错乱（旧数据覆盖新结果）、服务端压力陡增、前端内存泄漏（未清理的Promise或定时器）。
Article To Html
下载
文章转信息图。将文章/笔记转化为手机可读的 HTML 信息图，自动匹配视觉风格。触发场景：文章转图、笔记转图、信息图、转小红书图、做张图、可视化这篇文章、文生图。
- 简单防抖实现只需三行：
clearTimeout(debounceTimer)→debounceTimer = setTimeout(() => { /* fetch */ }, 300) - 300ms是经验值，太短（100ms）仍可能高频，太长（800ms）会让用户觉得卡顿
- 若搜索依赖用户输入完整词（如拼音首字母缩写），可提升到500ms，但需同步告知用户“正在思考…”状态
- 别忘了在页面卸载前
clearTimeout(debounceTimer)，避免内存泄漏
表格内实时过滤为何总卡顿
对超过200行的表格逐行遍历textContent并调用includes()，DOM重排+字符串匹配会明显拖慢主线程，尤其在低端Android设备上可能掉帧。
- 先用
filter预筛：只检查rows[i].style.display !== 'none'的可见行，跳过已隐藏项 - 避免重复获取DOM：
const cells = rows[i].cells比getElementsByTagName('td')快且语义清晰 - 用
String.prototype.indexOf()替代includes()，前者在V8中优化更好，差异在微秒级但累积显著 - 真到500+行，就得切分任务：用
requestIdleCallback分批处理，或改用虚拟滚动+索引缓存
搜索框清空后没恢复全部数据
常见原因是过滤逻辑只做“匹配显示”，没做“不匹配隐藏”的逆向还原。比如你设了row.style.display = 'none'，但清空输入时没把所有row.style.display重置为''（空字符串才继承CSS默认值）。
- 清空时别用
row.style.display = 'table-row'，硬编码值会覆盖CSS中的display: flex等其他设定 - 统一用
row.style.display = ''，让浏览器按样式表规则重新计算 - 更稳妥做法：给所有数据行加一个类名如
data-row，过滤时只操作data-row的display，清空时document.querySelectorAll('.data-row').forEach(r => r.style.display = '') - 如果用了
visibility: hidden而非display: none，记得对应还原，二者行为完全不同
真正难的不是写通逻辑，而是判断什么时候该停——比如用户输入“a”，后面紧接“b”，中间间隔400ms，是否算两次独立操作？这得结合业务场景定防抖阈值，而不是抄个300ms就完事。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
