表格元素加 z-index 无效是因为 <table>、<tr>、<td> 默认 position: static，而 z-index 仅对定位元素生效；正确做法是先设 position: relative 等定位属性，再设置 z-index。
表格元素加 z-index 为什么没效果？
因为 <table>、<tr>、<td> 默认是 position: static，而 z-index 只对定位元素生效。直接给 <td> 写 z-index: 999 完全被忽略——浏览器压根不解析它。
常见错误现象：
- 给
<table>设置z-index，但没加position，结果被后面一个普通<div>盖住 - 用
border-collapse: collapse后试图靠z-index控制某列边框“浮在上面”，无效
正确做法：必须先让目标单元格或容器脱离默认流。例如：
.highlight-cell {
position: relative;
z-index: 10;
}
注意：不要给 <tr> 加 position —— 大多数浏览器会忽略（表格行不是标准定位上下文容器），优先操作 <td> 或外层包裹 <div>。
立即学习“前端免费学习笔记（深入）”；
想让表格某部分“盖住”其他元素，该动哪一层？
真正能参与层叠比较的，不是边框本身，而是承载边框的元素。边框（border）没有独立层级，它依附于所在元素的渲染层。
所以关键动作是：把需要“上浮”的内容放进一个带定位和 z-index 的容器里，而不是去调边框样式。
- 如果要高亮某单元格边框并让它压过相邻浮动按钮：给
<td>加position: relative+z-index: 100，再用border样式描边 - 如果整张表要浮在弹窗之上：给
<table>外层套一个<div class="table-wrapper">，然后对这个<div>设position: relative和z-index - 避免直接对
<table>设position: absolute—— 会破坏表格固有布局逻辑，尤其在响应式场景下容易错位
表格内嵌元素的 z-index 被父级截断怎么办？
当表格或其祖先元素触发了新的堆叠上下文（比如设置了 opacity: 0.99、transform: translateY(0) 或 z-index: 0 的 position: relative），内部所有 z-index 都只在该上下文内有效，无法突破到外部比大小。
典型场景：
- 模态框（
.modal）里放表格，表格中某个<span>设了z-index: 9999，却仍被模态框遮罩层盖住 → 因为.modal自身已创建堆叠上下文 - 用
will-change: transform优化表格滚动性能，结果导致某列固定头“突然沉底” →will-change触发了新上下文
排查建议：
- 打开 Chrome DevTools → Elements → 右键目标元素 → 「Show all DOM nodes」→ 在「Computed」面板搜
stacking context，看是否标为「Yes」 - 临时注释掉父级的
opacity、transform、filter等属性，观察层级是否恢复 - 真要突破，只能把需上浮的元素移出表格 DOM 结构，用
position: fixed或同级插入方式重挂载
移动端表格边框层级异常，iOS Safari 特别容易翻车
iOS Safari 对 transform: translateZ(0) 和 will-change: transform 极其敏感，哪怕只是为开启 GPU 加速而加，也可能意外创建堆叠上下文，让本该平铺的表格边框“跳出来”盖住导航栏。
更隐蔽的问题是：表格中使用 input 或 select 时，这些原生控件在 iOS 上属于“窗口类元素”，它们天然高于普通 CSS 渲染层，z-index 无法压制 —— 这不是 bug，是平台限制。
- 解决输入框遮挡：不要试图用
z-index把表格单元格盖在<input>上，改用pointer-events: none配合绝对定位浮层替代 - 避免在表格父容器上滥用
transform—— 尤其是scale()或translateZ()，测试时务必真机验证 - iframe 嵌入表格时，
z-index完全失效：iframe 内容与父页完全隔离，覆盖只能靠同级 DOM 插入 + 父容器更高堆叠上下文
真正决定谁在上面的，从来不是数字大小，而是谁在哪个堆叠上下文里——表格结构越深，越容易藏一个悄悄当“小 boss”的父级。
