必须缓存dom查询结果，因每次调用getelementbyid或queryselector都会遍历dom树，开销大；应提前获取并存为变量，如const savebtn = document.getelementbyid('save-btn')，避免重复查询。
重复查同一个 DOM 元素，性能就掉得明显——尤其在循环、高频事件或长列表渲染里。缓存不是“可选优化”，而是必须做的基础操作。
为什么不能每次用都调 document.getElementById 或 querySelector
浏览器每次执行这些查询，都要从根节点开始遍历 DOM 树，哪怕目标元素离得很近，也得走一遍匹配逻辑。深度越大的 DOM 树，开销越不可忽视；更关键的是，现代浏览器虽有内部缓存机制（如 ID 查询的哈希索引），但不保证跨调用复用，且 querySelector 这类支持复杂选择器的方法基本每次都是全新解析。
常见错误现象：
- 滚动中反复调用
document.querySelector('.status-bar')导致卡顿 - for 循环里写
document.getElementById('item-' + i)，i 从 0 到 99，触发 100 次查询 - 组件多次 render 时，每次都重新查同一组按钮，没做任何引用保留
最稳妥的缓存方式：变量引用 + 提前获取
这不是“技巧”，而是最直接、最可控、兼容性最好的做法。核心原则：查一次，存变量，后面全用这个变量。
使用场景：
- 页面初始化后就确定要长期使用的元素（如导航栏、侧边栏容器）
- 组件挂载后需绑定事件或读取尺寸的 DOM 节点
- 表单内固定结构的输入框、提交按钮等
实操建议：
- 把缓存语句放在模块顶层或组件
onMounted/useEffect中，避免在函数体内重复执行 - 命名清晰，比如
const saveBtn = document.getElementById('save-btn')，别用el或dom这种模糊名 - 如果元素可能不存在，加空值判断：
if (!saveBtn) return，而不是让后续代码崩在saveBtn.addEventListener
需要动态查多个同类元素？用 querySelectorAll + Array.from 缓存为数组
getElementsByClassName 和 getElementsByTagName 返回的是“实时集合”（live HTMLCollection），每次访问 .length 或索引都会触发重查；而 querySelectorAll 返回的是静态快照（NodeList），更适合缓存。
实操建议：
- 用
const items = Array.from(document.querySelectorAll('.list-item'))转成真数组，后续遍历、filter、map 都安全 - 别写
for (let i = 0; i —— 每次循环都查一遍 - 如果元素会动态增删，且你确实需要响应式集合，那就明确接受开销，并考虑用 MutationObserver 替代轮询查
函数级缓存（慎用）：只适合极少数稳定 ID/TagName 场景
像资料里提到的给函数加 cache 属性这种写法，本质是手动模拟模块级变量，但容易引发隐蔽问题：
- 缓存键若依赖参数拼接（如
name + '-container'），容易因空格、大小写、特殊字符出错 - DOM 被移除后，缓存里的引用仍存在，变成“悬空引用”，后续操作报错或静默失败
- 无法感知元素是否已从文档中 detach，也不适用于 Shadow DOM 内部查询
真正适合它的场景极少，例如：
- 全局工具函数中，频繁查固定标签名（如所有
script标签），且确认页面生命周期内不会动态插入/删除 - 构建极简脚手架，不依赖框架，又想省几行变量声明
示例（仅作说明，非推荐默认方案）：
function getScriptTags() {
if (!getScriptTags.cache) {
getScriptTags.cache = document.querySelectorAll('script');
}
return getScriptTags.cache;
}
注意：这种写法绕过了作用域控制，调试和单元测试都更难，除非你清楚自己在做什么，否则优先用变量引用。
最容易被忽略的一点：缓存本身不解决“元素还没挂载”的问题。如果在 <script></script> 标签里直接执行查询，而对应 HTML 还没解析到，结果就是 null。确保执行时机——放
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
