纯CSS计数器最稳定方案是：在设counter-reset: rowNumber，对的首用::before配合counter-increment: rowNumber和content: counter(rowNumber)生成序号，避免JS延迟与DOM变动错乱。
用 counter-reset 和 ::before 生成序号列最稳定
纯 CSS 方案能避免 JS 渲染延迟、排序后序号错乱、服务端渲染不一致等问题。关键不是给每行写数字，而是让浏览器自动计数。
常见错误是直接在 <td> 里写 <code>1、2，结果表格排序或增删行后序号就断掉；或者用 JS 绑定 rowIndex，但 SSR 或动态加载时容易取不到值。
- 给
<tbody> 设置 <code>counter-reset: rowNumber; - 给
<tr> 的第一个 <code><td>（或伪元素）用 <code>counter-increment: rowNumber; - 用
::before显示计数值，避免污染实际单元格内容
table { counter-reset: rowNumber; }
tbody tr td:first-child::before {
counter-increment: rowNumber;
content: counter(rowNumber);
}需要兼容 IE8–IE10？改用 data- 属性 + 简单 JS
CSS 计数器在 IE8–IE10 中对 ::before 支持不全，且 counter-reset 在 <tbody> 上可能失效。这时不如退一步，用轻量 JS 控制。<p>注意别用 <code>document.querySelectorAll('tr').forEach(...) 遍历后赋值——如果表格异步加载或后续有 DOM 变动，序号不会自动更新。
立即学习“前端免费学习笔记（深入）”；
- 只在表格初始化或数据重载后调用一次更新函数
- 用
setAttribute('data-row-index', i + 1)写入属性，再配合 CSS[data-row-index]::before显示，保持样式与逻辑分离 - 避免操作
innerHTML或频繁读取rowIndex（它包含<thead> 行，易出错）<pre class='brush:php;toolbar:false;'>function updateSerialNumbers(table) { const rows = table.querySelectorAll('tbody tr'); rows.forEach((tr, i) => { tr.firstElementChild.setAttribute('data-row-index', i + 1); }); }</pre><h3>表格带分页或虚拟滚动时，序号必须按全局数据序号而非当前页显示</h3> <p>用户看到的是第 2 页的 10 条数据，但序号应是「第 51–60」，不是「1–10」。这时候 CSS 计数器和页面级 JS 都会失效——它们只数当前 DOM 节点。</p> <p>本质问题不是“怎么加序号”，而是“序号语义属于数据层还是视图层”。如果后端返回的数据本身带 <code>index字段（如分页接口返回items: [{id: 123, index: 57}, ...]），就该直接渲染这个字段。- 前端计算全局序号 =
(currentPage - 1) * pageSize + rowIndexInPage + 1，但需确保currentPage和pageSize始终准确 - 虚拟滚动中，DOM 节点复用会导致
counter-increment错乱，绝对不要依赖 CSS 计数器 - 如果使用 React/Vue，序号应作为数据属性传入 item，而不是在模板里写
{{ index + 1 }}（容易漏掉偏移量）
为什么不用
<ol></ol>包裹<tr>？<p>有人尝试把 <code><tbody> 换成 <code><ol></ol>，每行用<li>包裹<tr>，指望浏览器自动编号。这违反 HTML 表格规范：<code><tr> 只能是 <code><table>、<code><thead>、<code><tbody>、<code><tfoot> 的子元素。多数浏览器会静默修正 DOM 结构，导致 <code><li>被丢弃或错位，序号自然消失。更隐蔽的问题是：这类写法会让屏幕阅读器误读表格结构，丧失可访问性。序号列本质是辅助信息，不该破坏语义层级。
真正难的不是生成数字，是让序号在排序、筛选、分页、服务端渲染、无障碍访问这些场景下都保持正确。多数人卡在第一步，却没意识到后面五步更费劲。
- 前端计算全局序号 =
