原生 <thead> + position: sticky 在多数项目中静默失效，根本原因是 <table> 的 display: table 渲染模型不提供 sticky 所需的定位上下文，<tr> 全浏览器忽略 sticky，<th> 支持极不稳定，且横向滚动时列宽错位、父容器含 overflow: hidden 或 transform 会直接切断 sticky 行为；唯一稳定方案是用 div 模拟表头与主体，拆分为两个独立滚动区域并手动同步列宽和 scrollLeft。

原生 <thead> + position: sticky 在多数真实项目中会静默失效，不是你写错了，而是浏览器渲染模型根本不支持——<table> 的 display 行为不提供 sticky 所需的定位上下文，Firefox 至今完全不认 <th> 上的 sticky，Chrome 也只在特定版本（99+）部分支持，且横向滚动时列宽错位、首列无法固定等问题无法规避。

为什么+top:0经常看起来“没反应”

根本原因不在 CSS 写法，而在表格的渲染限制：

• <table> 默认是 display: table，它不构成 sticky 定位所需的「滚动上下文」
• <tr> 根本不支持 sticky（所有浏览器均忽略），<th> 支持度极不稳定
• 即使 <th> 看似吸顶，一旦开启横向滚动，列宽因 table-layout: auto 动态重算，表头和内容列就错位了
• 父容器只要带 overflow: hidden 或 transform（比如 transform: translateZ(0)），sticky 就直接被切断

用div模拟表头 + sticky（唯一稳定方案）

绕过表格渲染模型，把表头和主体拆成两个独立滚动区域，手动同步列宽：

• 表头容器必须设 position: sticky、top: 0 和显式 z-index（否则可能被 body 内容遮住）
• 主体区域需设固定高度（如 max-height: 400px）和 overflow-y: auto，否则无法触发滚动
• 列宽不能靠 table-layout: fixed（div 布局里无效），必须用硬编码 width 或 JS 同步：例如用 getBoundingClientRect().width 获取第一行单元格宽度，再赋给表头对应 div
• 表头与主体的列结构必须严格一致：th 数量、顺序、colspan/rowspan 逻辑一一对应

Element UI 等组件库的吸顶是怎么工作的

像 el-table 这类封装组件，内部早已放弃原生 <table>，其 .el-table__header-wrapper 是个普通 div，所以能真正用上 sticky：

Wechat HTML Publisher

直接上传HTML富文本到微信公众号草稿箱。支持完整的HTML格式,无需Markdown转换。

下载

立即学习“前端免费学习笔记（深入）”；

• 只需加属性 is-sticky，再通过 CSS 变量控制 --sticky-top 和 --stick-zIndex
• 关键前提：父容器不能有 overflow: hidden 或 overflow: auto，否则会截断 sticky 行为
• 开启横向滚动时，需确保表头和 tbody 的 scrollLeft 同步（部分版本要手动监听 scroll 事件设置）
• 多级表头需为每层 .el-table__column 单独设 top 偏移，例如第一层 top: 0，第二层 top: 42px（含第一层高度）

sticky 失效时优先查这三件事

别急着重写样式，先快速验证是否卡在基础干扰上：

• 打开 DevTools → Elements → 选中目标元素 → Computed 面板看 position 最终值是不是 sticky；如果不是，说明祖先节点已覆盖
• 从该元素向上逐级检查：有没有父级设了 overflow: hidden、overflow: auto、transform 或 will-change
• 确认滚动行为发生在哪个容器上——如果滚动条属于 .content 区域，而表头在 .app 顶层，中间隔了多个容器，那 sticky 就永远找不到上下文

真正麻烦的不是怎么写 sticky，而是怎么让 sticky 有路可走。列宽同步、滚动容器归属、层叠上下文冲突——这些细节漏掉一个，效果就断在用户眼皮底下。