原生 <thead> + position: sticky 不可靠，因 <table> 渲染模型不提供 sticky 定位上下文，且浏览器支持差异大；稳定方案是用 div 模拟表头并手动同步列宽。
原生 <table> 的 <thead> 直接加 position: sticky 在多数场景下不可靠，尤其跨浏览器时大概率失效；真正能稳定工作的方案是绕过表格渲染模型，用 div + sticky 模拟表头，并手动对齐列宽。
为什么 <thead> + sticky 经常不生效
根本原因不是写法错，而是浏览器渲染机制限制：<table> 的 display: table 不构成 sticky 所需的「定位上下文」，且 <tr>、<th> 在不同浏览器中支持程度差异极大：
- Chrome 99+ 支持
<th>和<td>上的top: 0，但<tr>仍被忽略 - Firefox 至今（2024 年起持续至今）完全不支持表格单元格的
sticky - 即使生效，横向滚动时首列无法同步固定，列宽也容易因
table-layout: auto动态变化而错位
用 div 模拟表头 + sticky（兼容性最佳）
这是目前唯一能在 Chrome、Firefox、Safari 及主流 Electron/小程序 WebView 中稳定运行的方案。核心是把表头和内容拆成两个独立滚动区域，并严格控制列宽同步：
- 表头容器必须设
position: sticky、top: 0和显式z-index（否则可能被主体内容遮挡） - 主体区域需设固定高度（如
max-height: 400px）和overflow-y: auto，否则无法触发滚动 - 列宽不能依赖
table-layout: fixed（它在div布局中无效），必须用硬编码width或 JS 同步（例如通过getBoundingClientRect().width获取并复用） - 表头与主体的列结构必须完全一致（
th数量、顺序、colspan/rowspan逻辑需一一对应）
Element UI 等组件库中 el-table 的吸顶实践
像 Element UI 这类封装好的表格组件，内部其实已规避了原生表格限制，其 .el-table__header-wrapper 是一个 div 容器，所以能直接应用 sticky：
立即学习“前端免费学习笔记（深入）”；
- 只需给表格加属性
is-sticky，再配合 CSS 变量控制--sticky-top和--stick-zIndex - 关键点在于：父容器不能有
overflow: hidden或overflow: auto，否则会截断 sticky 行为 - 若开启横向滚动，需额外确保表头和 body 的
scrollLeft同步（部分版本需监听scroll事件手动设置） - 多级表头（如分组列）需为每层
.el-table__column单独设top偏移，例如第一层top: 0，第二层top: 42px（含第一层高度）
常见失效原因与快速排查项
哪怕用了 div 方案，sticky 仍可能静默失效。以下检查项比重写代码更高效：
- 父容器是否意外设置了
overflow: hidden、overflow: auto或transform（如transform: translateZ(0)在 iOS Safari 15.4–16.3 中会禁用 sticky） - sticky 元素是否被包裹在
display: flex或display: grid的直接子元素中（某些浏览器下 flex 容器会干扰 sticky 计算） - 是否只写了
position: sticky却漏了top（或bottom/left/right）——没偏移值等于没写 - 滚动区域是否真有足够内容撑开高度？sticky 需要“可滚动空间”，空容器或高度不足都会导致不触发
最易被忽略的是：sticky 元素吸顶后仍占据原始文档流位置，若后续内容没做避让（比如没加 margin-top），就会出现内容从表头底下钻出的视觉 bug。
