三年前接手这套数据库测试平台前端时我做的第一件事是把项目里的 jquery 版本号翻出来看了一眼——1.8。那一刻心情有点复杂。这套平台的页面结构远比想象中复杂集群节点树、上万行的用例表格、按用例类型动态拼出来的执行参数表单、SQL 编辑区、结果集左右对比面板每一块都在大量直接操作 DOM。很多人一听到DOM 操作就默认这是老掉牙的话题觉得上了组件化框架之后就再也不用碰 document.querySelector 了。真做过这类测试平台的人会笑一下定制化需求一旦压下来框架那层抽象经常兜不住最后还是要伸手去摸真实的节点。这篇内容聊的就是这套平台前端里 DOM 操作相关的实战经验。它适合三类人看正在维护或改造类似测试平台的同学、想搞清楚框架之外那一层到底怎么回事的初中级前端、以及需要在前端做大量表格和树形交互的后端转前端开发者。下面不会讲 getElementById 有多少种写法那种教科书内容全部围绕真实页面里会遇到的问题怎么渲染一万行不卡、事件怎么绑才不炸、动态表单克隆出来为什么会互相干扰、第三方编辑器挂载失败该怎么查、以及一次真实的点了没反应是怎么定位到根的。1. 为什么在这类测试平台上DOM 基本功比框架 API 更值钱1.1 平台前端的真实长相表格、树、动态表单三件套先把页面结构摊开说不然聊技术选型都是空的。这套测试平台的核心页面大概就三类。第一类是用例管理页一个巨大的表格列有十几项包括用例名、所属模块、SQL 类型、数据集、预期结果、最近执行状态、执行耗时。每行右边挂四个行内按钮编辑、复制、执行、删除。顶部还有全选、批量执行、批量删除。这个表格在数据量大的项目里轻松过万行。第二类是集群与节点管理页一棵树。根是集群往下是节点组再往下是具体节点每个节点上挂一个状态色点点击节点右边联动展示详情面板。树节点要支持展开收起、搜索过滤后高亮命中路径、拖拽调整顺序。第三类是执行配置弹层一个动态表单。选了什么类型的用例下面就出现什么输入项可能是一组参数键值对、可能是一个 SQL 编辑器、可能是一组并发数和超时时间的数字输入。用户可以点再加一行参数也可以删掉某一行。这三类页面有一个共同点它们都是高度数据驱动的列表和层级结构但又都有大量局部状态需要即时反馈——勾选、展开、悬停、临时编辑。这类高频、局部、不需要持久化的交互恰好是直接操作 DOM 最划算的场景。1.2 框架抽象兜不住的四个瞬间我不反对上框架这套平台后来也逐步引入了组件化方案。但有四个瞬间你最终还是要跟真实节点打交道。第一个瞬间是接第三方组件。SQL 编辑区用的编辑器有自己的 DOM 结构和事件体系它不管你外面是 jQuery 还是什么框架初始化时只认一个容器节点。容器什么时候存在、宽高是不是零、有没有被 display:none 的父元素包着这些都得你自己盯。第二个瞬间是结果集对比面板。左右两个表格左边是基线结果右边是本次执行结果差异单元格要单独着色行要按差异类型高亮滚动要双向同步。这种逐单元格的粒度操作用数据绑定去驱动会产生巨大的 diff 开销直接拿到单元格节点改 class 反而干净利落。第三个瞬间是大表格性能。上万行的表格如果完全交给数据层驱动重渲染一次勾选全选就能让页面卡两秒。而如果只是切换行的 classDOM 层的代价几乎可以忽略。第四个瞬间是历史代码迁移期。老页面用 jQuery 写的新组件是另一套方案两者混在同一个 DOM 树里。这时候你必须清楚谁在管哪块节点否则一个 remove() 就能让另一边的引用变成悬空指针。1.3 一条判据什么时候该直接碰 DOM什么时候必须绕回数据层这是我踩了多次坑之后总结出来的一条线写成了表格团队里新人上手时我直接甩给他们看。操作类型是否直接操作 DOM判断理由行选中态、展开态切换是高频、临时、不入库改 class 最快列表数据增删改否必须回数据层DOM 只是投影单元格文本临时更新如执行中状态是只影响一个节点不必全表重渲染表单提交值视情况受控场景走数据层非受控可直接读 value第三方组件内部结构严禁版本升级即崩只能调它的公开 API拖拽过程的视觉反馈是占位符、拖影都是纯视觉不入数据拖拽结束后的顺序落库否顺序是业务数据必须回数据层这条线背后其实就一句话DOM 是数据的投影凡是需要被记住、被同步、被持久化的东西都归数据层管凡是转瞬即逝的视觉反馈交给 DOM。分不清这条线的人写出来的代码要么满屏手动同步、要么状态和界面各说各话。2. 用例列表页上万行表格的渲染方式与性能账2.1 字符串拼接、innerHTML 与 DocumentFragment 的实测差距先说渲染。最初这个表格是这么写的循环拼一个巨大的 HTML 字符串最后一次 tbody.innerHTML str。这种写法在几百行时看不出问题上千行开始能感觉到明显停顿。原因不复杂。字符串拼接本身不慢慢在两件事一是每次 innerHTML 赋值浏览器都要重新解析这段 HTML、构建节点树、计算样式、布局二是如果这个赋值发生在循环里那就是 N 次完整的解析加布局代价是灾难级的。即便只在循环外赋值一次超大字符串的解析本身也有成本而且这种方式绑不了事件——你只能在渲染完之后重新给每行绑又是一轮开销。我做过一轮简单的对比测试在同一台机器、同样的行结构每行六列加四个按钮、同样的数据下用三种方式渲染 5000 行渲染方式大致耗时量级主要问题循环内逐行 appendChild明显偏慢每行都触发一次布局计算拼字符串后一次性 innerHTML中等解析成本高事件需二次绑定DocumentFragment 批量插入最快一次插入一次布局具体数字会随机器和浏览器版本浮动我这里不写绝对值因为环境一变就没参考意义了但相对关系是稳定的DocumentFragment 明显领先。它的原理是把所有节点先挂到一个游离的文档片段上这个片段不在渲染树里往里加节点不会触发任何布局最后一次性把整个片段插进真实 DOM只触发一次重排。实际代码大概长这样function renderCaseRows(tbody, rows) { const frag document.createDocumentFragment(); for (let i 0; i rows.length; i) { const item rows[i]; const tr document.createElement(tr); tr.dataset.caseId item.id; tr.dataset.status item.status; tr.innerHTML td classcol-name escapeHtml(item.name) /td td classcol-module escapeHtml(item.module) /td td classcol-status statusText(item.status) /td td classcol-ops button>tbody.addEventListener(click, function (e) { const btn e.target.closest(button[data-action]); if (!btn || !tbody.contains(btn)) return; const tr btn.closest(tr); const caseId tr tr.dataset.caseId; if (!caseId) return; const action btn.dataset.action; switch (action) { case edit: openEditDialog(caseId); break; case copy: duplicateCase(caseId); break; case run: runCase(caseId, btn); break; case del: confirmDelete(caseId); break; } });这段代码有三个关键点。第一是 closest它从实际点击的元素向上找最近的匹配祖先这样即使用户点的是按钮里的图标或者文字也能正确命中。第二是 tbody.contains(btn) 这个校验看着多余其实是在防一类边界情况如果按钮被移出 tbody 又重新插入或者有别的浮层复用了同样的>function updateRowStatus(caseId, status, costMs) { const tr tbody.querySelector(tr[data-case-id caseId ]); if (!tr) return; tr.dataset.status status; const statusCell tr.querySelector(.col-status); if (statusCell) { statusCell.textContent statusText(status); statusCell.className col-status status- status; } const costCell tr.querySelector(.col-cost); if (costCell) { costCell.textContent costMs ms; } }这里只动了两个单元格的文本和 class浏览器需要重算的范围极小用户完全无感。这就是前面那张表里说的临时状态可以走 DOM的典型例子——执行状态最终当然也要回到数据层但界面上的即时反馈没必要等数据层驱动。注意querySelector 的属性选择器里拼接 caseId 时如果 id 可能包含引号或特殊字符会破坏选择器语法。稳妥的做法是把 id 再做一层白名单校验只允许数字和字母或者干脆维护一个 id 到节点的映射表。2.4 表格重排之后丢失的三样东西这一节是纯经验文档里基本不会写。表格一旦发生重排有三样东西会悄悄消失而且这三样都是测试人员高频使用的。第一样是滚动位置。用户滚到第五百行点了个批量操作代码把 tbody 清空重渲染滚动条瞬间回到顶部。用户骂人的心都有了。解决方式是在重渲染前记下 scrollTop渲染后还原。但要注意如果新数据量比原来少还原时要判断目标值是否超过了新的最大滚动高度否则会卡在一个尴尬的位置。第二样是勾选状态。批量操作最怕的就是勾选丢失。如果勾选状态只存在 DOM 的 class 上重渲染后必然全丢。所以勾选必须以 caseId 集合的形式存在数据层渲染时根据集合回填 class。这也是前面那条判据的具体应用勾选是要被记住的所以它属于数据层DOM 上的选中样式只是投影。第三样是焦点。如果用户正在某个单元格上编辑重排之后焦点会落到 body 上输入法直接断掉。处理方式是在重排前记录当前聚焦元素的标识重排后重新 focus。但更根本的做法是编辑态不要触发整表重排编辑就是编辑跟列表刷新解耦。3. 集群节点树与拖拽排序层级操作和高频事件的边界3.1 树形结构里找节点closest 够用就别写递归树形结构的 DOM 一般是嵌套的 ul/li或者嵌套的 div每个节点上带一个>treeRoot.addEventListener(click, function (e) { const nodeEl e.target.closest([data-node-id]); if (!nodeEl || !treeRoot.contains(nodeEl)) return; const nodeId nodeEl.dataset.nodeId; const isLeaf nodeEl.dataset.leaf 1; const expanded nodeEl.classList.contains(is-expanded); if (!isLeaf) { nodeEl.classList.toggle(is-expanded); toggleChildren(nodeEl, !expanded); } selectNode(nodeId); });closest 从点击位置向上找到最近一个带>function expandAncestors(nodeEl, rootEl) { let p nodeEl.parentElement; while (p p ! rootEl) { if (p.dataset p.dataset.nodeId) { p.classList.add(is-expanded); } p p.parentElement; } }这段代码看着朴素但它比任何递归写法都好读而且不会栈溢出。3.2 拖拽排序三个事件、一个占位符、一个插入位置集群节点和用例都有拖拽排序需求。原生拖拽看起来简单实际要处理的东西不少核心就三个事件。dragstart 里做两件事给被拖元素加一个 dragging class 做视觉标识同时把它的标识写进 dataTransfer。dragover 里必须调用 preventDefault否则 drop 事件根本不会触发——这是新手最常卡住的地方代码看着都对就是拖不动。同时要在这里计算插入位置拿到鼠标当前所在的那一行判断鼠标是在它的上半部分还是下半部分据此决定占位符插在它前面还是后面。drop 里做收尾根据占位符位置把节点实际移动过去然后清理所有临时状态。list.addEventListener(dragover, function (e) { e.preventDefault(); const dragging list.querySelector(.dragging); if (!dragging) return; const overEl e.target.closest(tr[data-case-id]); if (!overEl || overEl dragging) return; const rect overEl.getBoundingClientRect(); const isAfter (e.clientY - rect.top) rect.height / 2; if (isAfter) { overEl.parentNode.insertBefore(dragging, overEl.nextSibling); } else { overEl.parentNode.insertBefore(dragging, overEl); } });注意这里没有用占位符节点而是直接移动被拖元素本身。这种做法在简单列表里够用视觉上也直观。但有个副作用dragover 触发极其频繁鼠标每移动一像素都可能触发如果每次都在里面做重计算或者触发数据层排序页面会明显卡顿。所以这里规定死一条dragover 里只允许做 DOM 位置调整不允许碰数据层。3.3 顺序到底谁说了算DOM 先行还是数据先行这是拖拽里最容易出架构问题的地方。如果 dragover 期间就直接把数据层的顺序改了那么用户拖了一半松手取消数据就脏了。如果 drop 之后才改数据层中间那段时间数据和 DOM 是对不上的。我的做法是分两段。拖拽过程中DOM 随便动数据层一动不动同时用一个内部标记标识正在拖拽中这个标记期间禁止其他任何刷新逻辑介入。drop 事件触发后先扫描一遍 DOM 当前的顺序生成新的 id 数组再拿这个数组去调后端接口。接口成功什么都不用做DOM 已经是对的接口失败用旧顺序重新渲染一次把 DOM 掰回去。list.addEventListener(drop, function (e) { e.preventDefault(); const dragging list.querySelector(.dragging); if (dragging) dragging.classList.remove(dragging); const newOrder Array.from(list.querySelectorAll(tr[data-case-id])) .map(function (tr) { return tr.dataset.caseId; }); saveOrder(newOrder) .then(function () { isDragging false; showToast(顺序已保存); }) .catch(function () { isDragging false; reloadList(); }); });这套流程的好处是失败可回滚坏处是用户会看到一次闪回。如果后端接口很快闪回几乎察觉不到如果接口慢可以考虑先本地写入失败时再提示并回滚。具体选哪种看你们对顺序准确性的容忍度。还有一个坑必须提如果列表是按分页加载的拖拽到当前页之外是不合法的drop 逻辑里要判断拖拽源和目标是同一页跨页的拖拽直接拒绝并给出提示。这个细节不做用户把用例拖到页面边缘时会以为排序成功了刷新一看全白干。4. 动态表单与参数编辑克隆、模板与节点回收4.1 cloneNode 的深拷贝陷阱id 重复、值残留、事件丢失执行配置弹层里用户可以动态增加参数行一行是一个键输入加一个值输入加一个删除按钮。最开始我用 cloneNode(true) 克隆一个隐藏的模板行用了没多久就出了三个问题。第一个问题是 id 重复。模板行上如果写了 id克隆出来的每一行都带着同一个 id页面上一下子出现好几个相同 id 的元素label 的 for 指向直接错乱用 getElementById 拿到的永远是第一个。解决方式很干脆模板里根本不要写 id全部用 class 和>function addParamRow() { const row tplRow.cloneNode(true); row.classList.remove(is-hidden); row.querySelectorAll(input).forEach(function (input) { if (input.type checkbox || input.type radio) { input.checked false; } else { input.value ; } }); paramContainer.appendChild(row); return row; }第三个问题最隐蔽事件丢失。有些同事习惯在克隆前先把模板行的事件绑好然后指望克隆出来的行带着事件。但 cloneNode 不会拷贝通过 addEventListener 绑的监听器那些绑定在模板上的监听器克隆出来一个都没有。所以事件必须绑在容器上做委托或者克隆之后单独绑一次。4.2 模板管理用 template 标签别用 display:none 的隐藏行早期我用的是一个真实的 table 行加上 display:none 藏在页面角落克隆时把 class 去掉。这种做法能用但不干净这一行会参与布局计算虽然不可见会被全选逻辑误扫到也会在打印或者导出时冒出来。后来统一改成了 HTML 的 template 标签。浏览器会把它里面的内容当作惰性片段处理不渲染、不参与布局、不会被任何选择器扫到取的时候通过 content 属性拿template idtpl-param-row div classparam-row input typetext classparam-key placeholder参数名 input typetext classparam-val placeholder参数值 button typebutton classparam-del删除/button /div /templateconst tpl document.getElementById(tpl-param-row); function createParamRow() { const row tpl.content.firstElementChild.cloneNode(true); return row; }这样干净很多模板和真实列表彻底隔离。缺点是 template 的 content 里取子节点要注意 firstElementChild直接 firstChild 可能拿到换行产生的文本节点。4.3 内存泄漏节点被移除了监听器还活着这是动态表单里最容易被忽略的地方。用户删掉一行参数代码调 row.remove()视觉上确实没了。但如果当初给这一行的输入框单独绑过监听器而这些监听器里又闭包引用了外部的数据结构比如整个参数对象、整个表格实例那么这些引用会一直挂在那个已经脱离文档的节点上垃圾回收不掉。单次泄漏微不足道但用户在一个弹层里反复增删几十行、再反复打开关闭弹层几十次内存曲线就明显往上走了。表现出来就是页面用久了越来越卡刷新一下又好了。排查这个问题的方法很直接在浏览器开发者工具的控制台里选中那个元素用 getEventListeners 看它身上挂了什么再看这些回调里引用了什么。如果是委托在容器上的监听器本来就不需要清理如果是绑在行内元素上的删除时必须配对地解绑。function removeParamRow(row) { const inputs row.querySelectorAll(input); inputs.forEach(function (input) { input.oninput null; input.onchange null; }); row.remove(); }如果一开始就用事件委托绑在 paramContainer 上这个清理动作完全不需要。所以我的建议很明确动态增删的元素事件一律绑在稳定的父容器上。这一条能省掉九成的泄漏排查工作。5. 编辑区与结果对比面板和第三方组件分权5.1 挂载时机容器没有尺寸组件初始化必炸SQL 编辑区用的第三方编辑器初始化时需要读取容器的宽高来算行高和光标位置。如果容器此时还没插入文档或者父级是 display:none 的弹层宽高读出来是零组件就会以错误尺寸初始化。用户第一次看到的现象通常是编辑器渲染出来了但只有一条缝那么高或者光标位置完全错位输入时光标跑到文字上面。这类问题的根因不在组件在挂载顺序。常见的错误写法是把初始化代码写在弹层隐藏的时候就执行。正确顺序是先让弹层显示出来哪怕是 visibility:hidden 只占位等布局完成下一帧再初始化。function openSqlDialog() { dialog.classList.remove(is-hidden); dialog.style.visibility hidden; requestAnimationFrame(function () { dialog.style.visibility visible; if (!editor) { editor createEditor(dialog.querySelector(.editor-host)); } editor.refresh(); }); }用 requestAnimationFrame 是为了等一帧让样式和布局都算完。这不是玄学是很实在的一步同步代码块里刚改完的 class浏览器还没做布局计算此时读 clientHeight 拿到的可能是旧值。5.2 滚动同步一个标志位解决循环触发结果对比面板的左右两个表格要同步滚动。最直接的写法是给左边绑 scroll把 scrollTop 赋给右边再给右边绑 scroll把 scrollTop 赋给左边。写完一跑页面开始疯狂抖动因为 A 的赋值触发了 B 的 scroll 事件B 又把值写回 A进入死循环。解法是加一个锁标志let syncLock false; leftBody.addEventListener(scroll, function () { if (syncLock) return; syncLock true; rightBody.scrollTop leftBody.scrollTop; rightBody.scrollLeft leftBody.scrollLeft; requestAnimationFrame(function () { syncLock false; }); }); rightBody.addEventListener(scroll, function () { if (syncLock) return; syncLock true; leftBody.scrollTop rightBody.scrollTop; leftBody.scrollLeft rightBody.scrollLeft; requestAnimationFrame(function () { syncLock false; }); });锁为什么要用 requestAnimationFrame 解锁而不是立刻解因为滚动事件的触发是异步的赋值之后浏览器会在下一帧才派发目标元素的 scroll 事件。如果同步代码里立刻把锁放开等事件真正派发时锁已经不存在了死循环照旧。放到下一帧释放正好卡在事件派发之后。5.3 浮层、层级与事件冒泡的三方混战平台里到处都是浮层字段筛选下拉、行操作菜单、执行进度提示。这些浮层跟表格、跟弹层、跟第三方编辑器交织在一起时最常出问题的就是 z-index 和事件冒泡。z-index 的问题不在于谁大谁小而在于层叠上下文。一个元素如果父级设置了 transform、filter 或者 opacity 小于 1它就会创建新的层叠上下文内部的 z-index 再大也跳不出父级这个盒子。所以经常出现的情况是弹层的 z-index 写了 9999结果还是被一个 z-index 只有 10 的元素盖住原因是那个 10 的元素的祖先链上有一个 transform。排查方法很土但很有效在开发者工具里从上往下逐层选中看屏幕上的高亮块哪一层的盒子把弹层框住了问题就在哪儿。修复原则是尽量让所有浮层挂到 body 下避开父级层叠上下文。事件冒泡的问题更常见。行操作菜单点开之后点空白处要关掉于是给 document 绑了一个 click 关闭。结果点击菜单里的按钮时冒泡到 document菜单先关了按钮的 click 还没来得及执行。这种要用 stopPropagation或者更稳妥的做法是在 document 的监听里判断点击目标是否在菜单内部document.addEventListener(click, function (e) { if (menu.contains(e.target)) return; closeMenu(); });用 contains 判断比 stopPropagation 好在不破坏事件流其他需要冒泡的逻辑不受影响。6. 排查实录一次用例表格按钮点了没反应的完整定位6.1 现象描述与第一轮误判那次的问题很奇怪用例表格里编辑、复制、执行三个按钮都正常唯独删除按钮点了完全没反应既不弹确认框控制台也没报错。第一反应是事件委托里的 switch 漏了 del 分支。翻代码一看分支在逻辑也对。第二反应是按钮的>tr.addEventListener(click, function (e) { if (e.target.closest(.col-ops)) return; toggleDetail(tr.dataset.caseId); });改完之后删除按钮恢复正常整行展开也不受影响了。验证时我特意跑了三种点击路径点操作列的空白处、点三个正常按钮、点删除按钮三种行为都符合预期。6.5 举一反三一套通用的排查顺序这次经历之后我把这类某个按钮失灵的排查顺序固化了下来团队里通用顺序检查项判断依据1控制台有无报错有错先看错别急着往下查2委托回调第一行加断点没命中说明事件没到容器3Event Listeners 面板看祖先链找出谁在拦截事件4搜代码里的 stopPropagation定位阻断点5检查元素的 pointer-events、disabled有时是样式层的屏蔽6检查元素是否被遮挡上面的透明浮层也能吃掉点击第六项是最容易被忽略的一条。有一次查了半天最后发现是一个透明遮罩层忘了隐藏它没挡住视觉但挡住了所有点击。查这种问题最快的办法是在页面上右键检查看选中的元素是不是你以为的那个——如果不是说明有东西盖在上面了。7. 写在最后的一些零散体会这类测试平台的前端有个共性页面看起来都挺朴素但交互密度极高测试人员一天要在这个表格上点几百次。所以性能优化不能只看首屏加载更要看那些会被重复上千次的小操作的代价。改一个 class 和重建一张表在用户感知上是天壤之别。另一个体会是老技术栈不等于烂技术栈。这套平台用了很多年的 jQuery很多地方写得确实不好看但它在处理局部状态即时反馈这件事上依然高效。真正的问题是缺乏分层规范DOM 操作和数据操作混在一起写导致后来加需求时互相踩脚。后来我们做的一件很值的事是在团队里立了一条规矩任何一次 DOM 改动先问一句这是数据还是视图。答案清楚了代码写在哪一层也就清楚了。最后一个提醒关于测试平台上那些看似无害的优化。有一次为了提升表格滚动流畅度我加了节流结果测试人员反馈勾选框响应变迟钝了。把节流阈值从 100 毫秒降到 16 毫秒才勉强接受。这类参数没有标准答案只能拿真实的操作频率去试。别拿理想环境下的测试机数据去下结论去坐到一个真实测试人员旁边看他操作十分钟你会推翻很多自己拍脑袋的判断。
