原生 + position: sticky 在多数项目中静默失效，根本原因是 的 display: table 渲染模型不提供 sticky 所需的定位上下文， 全浏览器忽略 sticky， 支持极不稳定，且横向滚动时列宽错位、父容器含 overflow: hidden 或 transform 会直接切断 sticky 行为；唯一稳定方案是用 div 模拟表头与主体，拆分为两个独立滚动区域并手动同步列宽和 scrollleft。
原生 <thead> + <code>position: sticky 在多数真实项目中会静默失效，不是你写错了，而是浏览器渲染模型根本不支持——<table> 的 display 行为不提供 sticky 所需的定位上下文，Firefox 至今完全不认 <code><th> 上的 <code>sticky，Chrome 也只在特定版本（99+）部分支持，且横向滚动时列宽错位、首列无法固定等问题无法规避。
为什么+top:0经常看起来“没反应”
根本原因不在 CSS 写法，而在表格的渲染限制：
<table> 默认是 <code>display: table，它不构成 sticky 定位所需的「滚动上下文」
<tr> 根本不支持 <code>sticky（所有浏览器均忽略），<th> 支持度极不稳定
<li>即使 <code><th> 看似吸顶，一旦开启横向滚动，列宽因 <code>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>，其 <code>.el-table__header-wrapper 是个普通 div，所以能真正用上 sticky：
- 只需加属性
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 有路可走。列宽同步、滚动容器归属、层叠上下文冲突——这些细节漏掉一个，效果就断在用户眼皮底下。
<table> 默认是 <code>display: table，它不构成 sticky 定位所需的「滚动上下文」
<tr> 根本不支持 <code>sticky（所有浏览器均忽略），<th> 支持度极不稳定
<li>即使 <code><th> 看似吸顶，一旦开启横向滚动，列宽因 <code>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>，其 <code>.el-table__header-wrapper 是个普通 div，所以能真正用上 sticky：
- 只需加属性
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 有路可走。列宽同步、滚动容器归属、层叠上下文冲突——这些细节漏掉一个，效果就断在用户眼皮底下。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
