1. 从需求说起隔行变色到底在解决什么问题1.1 一个再常见不过的展示场景先别急着写代码想一下你有多久没看过一张完全没有底色交替的纯白表格了不管是后台管理系统里的订单列表还是数据分析平台上的指标明细只要表格里的数据超过十行纯白底色的表格就会变成一场视觉灾难。读者扫一眼眼神很容易在前一行和后一行之间跑偏尤其是在列数很多、单元格内容特别长的时候找错行简直是分分钟的事。隔行变色也叫斑马纹、条纹样式的核心作用就是给相邻两行之间制造一个可辨别的亮度差。人眼对亮度差异的敏感度比对边框粗细高得多当奇数行和偶数行在背景色上有明显的层次区分时阅读视线会被“引导”到正确的横向轨道上信息扫读效率能提升不少。这个需求本身极其朴素但它覆盖了一个非常重要的前端基本功如何用 JavaScript 去批量操作页面上的元素并在数据变化时保持视觉状态的一致性。所以这个看似“简单到不能再简单”的案例其实是初学者理解 DOM 操作、循环逻辑、样式切换的绝佳切入点。我做前端练习的时候也喜欢用这种小案例练手。别看不起它一张表格里塞满一百行数据再配合排序、筛选、动态加载隔行变色就会从“写几行代码搞定”变成“怎么保证每次数据变化后颜色都正确”这时候你再回头看它就明白为什么要把它当成独立案例来写了。1.2 为什么用 JavaScript 而不是纯 CSS可能会有同学说“隔行变色不是用 CSS 的:nth-child(even)就能解决吗为什么还要用 JavaScript 去遍历每一行然后设置背景色”这个问题问得很好。从最终视觉效果来看CSS 的方案确实更简洁性能也更好tbody tr:nth-child(even) { background-color: #f8f8f8; } tbody tr:hover { background-color: #e6f7ff; }只要样式表里写上这两行表格打开就有斑马纹无需任何 JS。那为什么我们的练习项目还特意叫“JavaScript 练习”原因在于CSS 方案有一个隐藏前提表格的行结构在页面生命周期里基本保持不变或者说即使新增了行浏览器也会重新匹配:nth-child规则。这个前提很多时候是成立的但另一些场景下就不一定了。举个实际例子表格里的行不是静态渲染出来的而是通过接口异步加载再在用户点击“加载更多”后追加到tbody里的。这种情况下CSS 依然能自动适配因为:nth-child是基于元素在父节点中的实际位置计算的新行插入后选择器会自动重新匹配。所以单纯从“变色”这件事上说CSS 确实够用。但我们的练习目标并不只是“变个色”而是要学会“如何用程序控制样式状态”。在实际项目中你可能需要根据行数据里的某个字段决定颜色。比如库存低于安全线的行显示浅红高库存显示浅绿。这时候使用:nth-child就力不从心了。又比如用户点击表头排序后DOM 顺序发生变化如果你用的是 JS 遍历就必须在排序逻辑之后重新调用着色函数如果你用 CSS浏览器会自动重新匹配看上去反而没什么麻烦。那 JS 的意义到底在哪核心意义在于它让你具备了“按数据条件动态控制样式”的能力。这种能力不是 CSS 能替代的它是前端交互逻辑的基础部分。所以这个练习的正确打开方式不是“用 JS 干掉 CSS”而是“先了解更常规的 CSS 方案再深入学习 JS 方案理解两套机制各自的边界”。2. 核心概念拆解DOM 操作与循环里的小心机2.1 拿到表格和行的几种方式现在开始动手。要隔行变色第一步是把表格和所有行找出来。初学者最常犯的错误就是用getElementById去拿一堆元素结果拿到null然后就对着空对象一脸茫然。这里我习惯这样分工getElementById(tableId)负责拿唯一表格容器getElementsByTagName(tr)负责拿表格里的所有行querySelectorAll(#tableId tbody tr)一步到位直接拿到tbody范围内的所有行。三种方式各有适用场景。我比较推荐第三种因为在实际表格中往往还有thead里的表头行。如果直接用getElementsByTagName(tr)会把表头那几行也一起包括进来后面用索引奇偶判断时表头就会变成第一行变色逻辑瞬间错乱。用querySelectorAll(#tableId tbody tr)可以把范围限定在tbody内从根上避免这个问题。这里还有一个容易被忽视的小坑querySelectorAll返回的是NodeList它长得像数组但不是真的数组。你直接对它调用.map()或.filter()会报错。不过现代浏览器里的NodeList已经支持forEach日常遍历没有大问题。保险起见你可以用Array.from()把它转成真数组后面做筛选、排序也更顺手。const table document.getElementById(dataTable); const tbody table ? table.querySelector(tbody) : null; if (!tbody) { console.warn(未找到 tbody请检查页面结构); return; } const rows Array.from(tbody.querySelectorAll(tr));简单解释一下这个代码的作用先拿表格再找tbody最后把tbody里的所有行放进数组rows。每一步都做了空判断避免后续脚本因为找不到节点直接崩溃。这个写法看起来多写了几个判断但放在真实项目里非常有用——很多接口异常、页面结构调整导致的问题都是靠这种空判断提前挡住而不是让整个脚本报红。2.2 用取模运算切换颜色拿到行之后最直接的思路就是给每一行设背景色。奇偶判断的标准写法是rows.forEach((row, index) { if (index % 2 0) { row.style.backgroundColor #ffffff; } else { row.style.backgroundColor #f2f2f2; } });这里index % 2的结果是 0 或 10 对应偶数行1 对应奇数行。注意这里的index是从 0 开始的所以数组里的第一行是“偶数行”会拿到白色背景第二行拿到灰色背景。如果视觉上你希望第一行是灰色把判断条件反过来就好。但如果你用的是querySelectorAll(#tableId tr)并且表格里有thead那表头行也算进了index里。比如表头占第 0 行第一行数据变成第 1 行。如果你希望表头保持自己的背景色同时数据区域从第 1 行开始按索引取模那就要处理一下偏移。最省事的方法还是只在tbody范围内选择让索引归零完全绕开表头的干扰。另外提醒一句直接给行设置style.backgroundColor会写入内联样式。内联样式优先级最高后续如果想用 CSS 类去覆盖它就很麻烦。所以更推荐的做法是定义两个 CSS 类比如.row-even和.row-odd然后用classList.add去切换。这样样式归样式逻辑归逻辑后续维护轻松得多。.row-even { background-color: #ffffff; } .row-odd { background-color: #f5f7fa; }rows.forEach((row, index) { row.classList.remove(row-even, row-odd); row.classList.add(index % 2 0 ? row-even : row-odd); });2.3 循环比逐个赋值更高效看到这里你可能会想几十行代码用得着讲“效率”吗还真用得着。当你用forEach遍历每一行并设置样式时如果表格只有几十行性能完全没压力。但当数据量变成几千行或者表格嵌套在经常触发重绘的页面里每一次style赋值都可能引起同步的样式计算。虽然现代浏览器优化得很好但养成“批量操作 DOM”的好习惯总没错。有几点经验可以参考循环开始前先遍历一次行数据把需要上色的行分类好再统一处理尽量减少在循环里做重复的 DOM 查询如果只是要切换奇偶颜色classList操作比直接改style更轻——浏览器对类名变化会走样式重算但至少不会产生逐行的内联样式解析如果表格行是动态加载的每次都全量遍历也没关系因为通常不会快到产生感知差异。但如果是数据大屏一类的展示页面可以改用 CSS 方案把压力交给渲染引擎。这里我想强调一个心态练习这个案例的时候不要追求“炫技”先把最朴素的方案写对再去想优化。你不妨故意写一个“把所有行都拿到然后每行单独设置背景色”的版本再对比“循环 类名切换”的版本观察代码的可读性和后续扩展难度。这一对比你才会真正理解为什么项目里普遍用类名而不是内联样式。3. 完整实现从最简单到带交互的版本3.1 基础版页面加载时给所有行上色我们先写一个最小可运行的完整页面。这个页面包含 HTML 结构、CSS 样式和 JavaScript 逻辑不依赖任何框架放到浏览器里直接能跑。!DOCTYPE html html langzh-CN head meta charsetUTF-8 title表格隔行变色基础版/title style #dataTable { width: 100%; border-collapse: collapse; } #dataTable th, #dataTable td { border: 1px solid #ddd; padding: 8px 12px; text-align: left; } #dataTable thead th { background-color: #304156; color: #fff; } .row-even { background-color: #ffffff; } .row-odd { background-color: #f5f7fa; } /style /head body table iddataTable thead tr th序号/th th姓名/th th城市/th th状态/th /tr /thead tbody trtd1/tdtd张三/tdtd北京/tdtd正常/td/tr trtd2/tdtd李四/tdtd上海/tdtd正常/td/tr trtd3/tdtd王五/tdtd广州/tdtd异常/td/tr trtd4/tdtd赵六/tdtd深圳/tdtd正常/td/tr !-- 实际项目中这里可能有几十上百行 -- /tbody /table script function applyStripe() { const tbody document.querySelector(#dataTable tbody); if (!tbody) return; const rows Array.from(tbody.querySelectorAll(tr)); rows.forEach((row, index) { row.classList.remove(row-even, row-odd); row.classList.add(index % 2 0 ? row-even : row-odd); }); } applyStripe(); /script /body /html这段代码看起来很短但已经包含了几个可复用的好习惯。第一applyStripe被定义成一个独立函数这样页面加载时调用一次以后数据发生变化时还能继续调用。第二classList.remove先清空再添加保证同一行不会同时存在两个颜色类。第三选择了tbody下的tr表头那一行完全不受影响。在浏览器里打开这个页面你会看到第一行是白色第二行是浅灰交替出现。如果你希望第一行就是浅灰只需要把index % 2 0后面的类名顺序换一下或者直接判断index % 2 ! 0。这个细节根据团队视觉规范调整即可没有统一标准。3.2 升级版点击表头排序后重新着色基础版只能应付静态页面。实际项目里表格一般都有排序、筛选这些操作。点击表头排序意味着 DOM 里行的顺序会改变。这时候如果还是打开页面时调用一次applyStripe排序之后的颜色就会错乱——原本是灰色的行可能变成白色白色行变成灰色斑马纹被打断。解决思路也很简单每次排序完成后再调用一次applyStripe。这里顺便讲一下排序的实现。为了演示我给表头加一个点击事件按“序号”列从小到大排序。排序逻辑本身不复杂但里面藏着不少坑。const table document.getElementById(dataTable); const tbody table.querySelector(tbody); const thead table.querySelector(thead); thead.addEventListener(click, function (e) { const th e.target.closest(th); if (!th) return; const allTh Array.from(thead.querySelectorAll(th)); const index allTh.indexOf(th); // 这里只对单列进行数值排序实际场景可能要根据列类型做不同处理 const rows Array.from(tbody.querySelectorAll(tr)); rows.sort((rowA, rowB) { const cellA rowA.children[index].textContent.trim(); const cellB rowB.children[index].textContent.trim(); const valueA parseFloat(cellA) || cellA; const valueB parseFloat(cellB) || cellB; if (typeof valueA number typeof valueB number) { return valueA - valueB; } return String(valueA).localeCompare(String(valueB)); }); rows.forEach(row tbody.appendChild(row)); applyStripe(); });重点看最后两步。rows.forEach(row tbody.appendChild(row))会把排好序的行重新按顺序追加到tbody末尾。这里用到了一个浏览器特性appendChild在插入一个已经存在于页面中的节点时不会产生副本而是把原节点移动到新位置。所以这个操作本质上是“移动节点”不是“复制节点”。移动完之后绝对不能忘了重新调用applyStripe()。我在练习时故意注释掉这行代码然后点排序果然颜色全乱套了。通过这种“出错—排查—修复”的过程对“数据变化后要同步刷新视觉状态”这件事的印象会特别深刻。排序这里还有一个隐藏问题如果点击“姓名”这一列文本排序用localeCompare中文也能排如果点击“状态”列可能想要的是按自定义优先级排那就要额外维护一个排序映射。这里不展开但它提醒我们真实项目里的表格排序远比这个复杂隔行变色只是排序后需要顺手处理好的一环。3.3 悬停高亮与隔行变色的碰撞有时候产品经理会提这样一个需求鼠标移到某一行这一行要高亮方便用户盯住当前行。听起来不难但和隔行变色放在一起时就会遇到“移开鼠标后颜色回不去了”的问题。这是因为悬停改变了行的背景色但移开鼠标后如果直接恢复默认背景色红色会丢失原本是灰还是白的信息。比较稳妥的方案是在悬停时临时加一个类名比如.row-hover移开时移除这个类名。具体做法是在每一行上绑定mouseenter和mouseleave事件。为了减少绑定次数可以用事件委托的方式在tbody上统一监听。tbody.addEventListener(mouseenter, function (e) { const row e.target.closest(tr); if (!row) return; row.classList.add(row-hover); }); tbody.addEventListener(mouseleave, function (e) { const row e.target.closest(tr); if (!row) return; row.classList.remove(row-hover); });对应的 CSS 加上.row-hover { background-color: #e6f7ff !important; }注意这里的!important。为什么要加它因为.row-even和.row-odd的背景色也是直接作用于tr上的如果两个类同时存在CSS 会根据层叠规则选择第二个或者更具体的那个。由于.row-even和.row-extra的优先级相同都是一个类选择器后出现的样式会覆盖前面的。为了不让悬停效果被斑马纹覆盖加上!important是最直接的办法。当然更好的做法是把三者放在同一个样式表里通过源码顺序保证悬停规则写在最后就不需要!important。这个细节能体现一个初学者对层叠样式的理解是否到位。还有一个更优雅的方案悬停时不额外加背景色而是改变文字颜色或加一个左边边框。比如.row-hover { color: #1890ff; }这样就不会和背景色的类名打架。不过具体选哪种要看你的产品视觉要求。我只是想说解决“样式冲突”不只有一个思路关键是理解 CSS 的优先级规则找到适合当前场景的方式。4. 常见问题与排查技巧实录4.1 颜色没有生效先检查选择器拿没拿到节点这个案例最普遍的问题就是脚本写了但页面上一点变化都没有。遇到这种情况我习惯性的第一反应不是看逻辑而是先在控制台打印一下用选择器拿到的内容。console.log(tbody); console.log(rows);如果tbody打印出null说明选择器没写对最常见的原因是页面里存在多个table对应同一个 id或者表格是动态渲染的脚本执行的时候表格还没插入到 DOM 里。如果你是写在head里直接运行肯定拿不到后面的节点因为浏览器解析到脚本时还没看到表格。解决动态渲染问题有两个办法一是把脚本放到/body前执行二是用window.addEventListener(DOMContentLoaded, fn)包装一下。现代框架下还要考虑组件生命周期里渲染完成后才能操作 DOM不然一样会踩空。但回到原生练习最简单的就是把script放在表格后面或者用 DOMContentLoaded 事件。如果tbody不是null但rows是空数组那就是tbody里确实没有tr可能是数据还没加载出来或者你把tr写到了thead里。这种通过console.log立刻就能定位。4.2 表头和第一行数据同时变色了索引没算对代码看起来是对的但打开页面发现表头那一行也参与了斑马纹变色整个配色都乱了。这个问题的根源非常典型使用了getElementsByTagName(tr)或querySelectorAll(#dataTable tr)这两种方式都会把所有tr都选进来包括thead里的表头行。由于表头行排在前面它自然被算成了第 0 行数据区的第一行就变成了第 1 行。表头加了斑马纹颜色同时数据区的奇偶顺序也完全反了两边看着都不对劲。修法有两种。第一种是改用querySelectorAll(#dataTable tbody tr)就像前面代码里写的那样。第二种是拿到所有行之后用Array.prototype.slice.call(rows, 1)把表头行切掉但这样写不够灵活一旦thead里有多个表头行就会出错。最推荐的还是从源头区分thead和tbody。这个问题的本质是“DOM 范围选择不当”。你可以在代码里加一段校验打印出行集合里每一行的父节点看看是不是都在期望的容器里。Array.from(document.querySelectorAll(#dataTable tr)).forEach(row { console.log(row.parentElement.tagName); // 可能是 THEAD 或 TBODY });这样就能直观看到tr都归属在哪儿了。4.3 动态新增行后颜色不对需要封装函数另一个高频场景是页面加载时颜色正常但用户点了“加载更多”或“新增一行”之后新加进来的行没有颜色或者奇偶关系全部被打乱。这是因为你只在页面初始化时调用了一次着色函数后续 DOM 结构变了颜色的义务没人承担。正确的做法是把“给所有行上色”的逻辑封装成独立的函数比如applyStripe()然后规定凡是会引起行增删、排序、过滤的操作做完之后都要调用一次。如果你用原生方式实现一个“新增一行”的功能代码如下function addRow(data) { const tbody document.querySelector(#dataTable tbody); const newTr document.createElement(tr); newTr.innerHTML td${data.id}/td td${data.name}/td td${data.city}/td td${data.status}/td ; tbody.appendChild(newTr); applyStripe(); }每次新增之后原来的行位置不动新行出现在末尾。重新执行applyStripe索引重新计算所有行都会被正确上色。这里有同学会问如果把新行插入到中间位置而不是末尾奇偶关系也会自动重算因为applyStripe是完整遍历重新赋类不是增量更新。这是“全量重绘”的思路简单、可靠、不会留下奇怪的状态。缺点是数据量特别大的时候可能会有性能损耗但作为练习案例先保证正确性是最重要的。我见过有人为了省性能只给新增的行设置颜色却没有更新后面所有行的颜色结果几行数据之后斑马纹就乱了排查起来反而更费劲。所以我的建议是小中型表格放心全量重绘不要提前优化。4.4 不要用 JS 设置背景色覆盖了其他样式最后一类坑跟 CSS 优先级有关。如果用row.style.backgroundColor #f2f2f2这种方式来上色内联样式的优先级会压过外部样式表里的类样式。假设表格行原本有一种特殊的背景色是用来表示“禁用”你想在禁用行上保留原来的颜色却因为隔行变色逻辑写成了内联样式于是所有行都被统一覆盖禁用行的标志色不见了。解决这个问题最干净的方法就是一直坚持用类名管理颜色状态。定义好.row-even和.row-odd之后再用其它类名去控制禁用、悬停、选中等状态。每个状态各自负责自己的样式配置清楚不容易互相污染。代码里最好避免直接出现style.赋值把样式问题全部交给 CSS。这里有一个额外的经验当你发现某个行的背景色持续不对劲像是怎么改都改不过来的话打开开发者工具选中那一行查看计算样式和已应用规则的优先级。这时候你会看到某个内联样式或者!important正在覆盖你的规则。不要急着改 JS先看看样式源头在哪里往往几下就能定位。4.5 针对这个案例的速查表症状最可能的原因快速处理办法完全没颜色脚本运行时机太早节点没渲染把脚本放到/body前或用 DOMContentLoaded表头也变色选择器范围过宽改为table tbody tr第一行颜色和想的不一样index从 0 开始调整取模判断条件或改变类名对应关系排序后颜色错乱着色函数没有在排序后重新调用排序方法末尾调用applyStripe()新增行没颜色动态插入后未重新着色每次新增、删除、排序后统一调用applyStripe()悬停取消后颜色丢了悬停样式覆盖了斑马纹类用独立类名和事件绑定并注意样式优先级编辑表格行时背景色变了内联样式把类样式覆盖了避免使用style.backgroundColor改用类名这张表基本涵盖了我自己从入门到写真实项目时踩过的所有坑类型。你可以把这张表存下来以后遇到隔行变色相关的问题先对号入座效率会高很多。5. 再聊聊两种常见变体5.1 按数据条件变色而不是按行号隔行变色只是入门真正在项目里用得多的其实是“按行数据值进行条件变色”。比如订单金额超过一万的行标注浅红库存为零的行标注浅黄。这时候就不能用index % 2来决定了而是要从行对应的数据对象里拿字段来匹配。实际开发里行的数据常常存在一个全局数组里比如const tableData [{ id: 1, name: ..., amount: 20000 }]。当你渲染行的时候可以根据amount 10000来给行追加一个.row-warning类。如果表格同时要保留斑马纹就需要把.row-warning和.row-even、.row-odd一起使用然后通过样式表定义优先级确保警告色不会被斑马纹盖住。.row-warning { background-color: #fff1f0 !important; }这种玩法的技巧在于斑马纹只是“默认状态”它会根据数据被覆盖成更醒目的状态色。这里有一个开发规范值得推荐定义状态类时把它们的优先级高于斑马纹或者在 JS 里通过更明确的类名组合来表达当前行处于哪种状态。比如一行可以同时有row-odd和row-warning但只要有row-warning最终样式走警告风格。我之前做过一个库存表格最初的做法是每次setData都重新生成所有行行类名全部从row-odd和row-warning的组合中计算出来。刚开始还挺顺利后来状态多了一会儿是“断货”一会儿是“滞销”类名组合越来越冗长。后面改成在tbody上维护一份dataMap渲染时直接查表代码反而清爽得多。这个方向其实已经进入“状态管理”的范畴了对练习者来说可以先不深入但要意识到隔行变色只是样式管理的一个小入口。5.2 大数据量下的性能取舍如果你在练习时好奇过“一万行的表格会怎样”我可以告诉你结论直接循环一万行设置类名浏览器可能会卡一下但也没有到不能用的地步。真正让页面变慢的往往不是上色而是反复重绘、布局抖动以及大量 DOM 节点的增删。隔行变色在这种场景下比较激进的做法是每十行循环一次用 CSS 直接写一整段的规律其实并不复杂但没有必要。你只要别在每次滚动时都重新调applyStripe()也不会遇到真实的性能瓶颈。如果你有接入框架的经验会发现框架里的列表渲染天然会带 Vue 或 React 的虚拟 DOM 机制隔行变色直接写 CSS 更合适。所以这个练习案例在框架里反而不是重点。但原生 JavaScript 的方式能帮你建立底层逻辑的概念去理解为什么框架推荐 CSS 而不是 JS 来做这一类纯展示样式。我的建议是把性能优化放到最后再考虑。先确保逻辑正确、代码可读再考虑要不要做防抖、重绘优化。大多数人写普通管理系统表格完全不需要担心性能问题。很多所谓的“性能优化”反而是过早优化徒增复杂度。6. 写在最后的小技巧如果你已经把这个案例练得比较熟练我建议你再做一个小改动把applyStripe写成一个可以传入表格选择器或 DOM 对象的通用函数放到一个公共工具文件里以后任何页面需要隔行变色时一行代码调用就行。这种“把常用能力沉淀成工具函数”的思路能让你从“练手”向“做项目”过渡得更自然。再分享一个我的个人习惯写完隔行变色之后我会在表格里故意插入一行观察数据变化后颜色是否还正确。很多人练习时只写静态表格测试也只看打开页面的效果这样漏掉动态场景的概率很高。多测几种操作你会积累出更多排查经验这些经验比代码本身珍贵得多。这个练习虽然简单但它背后涉及的选择器、循环、事件绑定、样式优先级、动态渲染哪一样都是前端每天的日常。把基础打扎实后面遇到复杂表格组件时你才不会一头雾水。