uni-app 不支持原生 <table> 标签的完整功能，尤其 APP 和小程序端 colspan/rowspan 渲染不可靠、错位频发；需用 view + CSS + 逻辑模拟复杂表格布局。
uni-app 没有原生 <table> 标签的完整支持，尤其在 APP 端和小程序端，colspan/rowspan 渲染不可靠、错位频发，直接写 HTML 表格大概率翻车。真要实现复杂布局（比如跨列表头、固定行列、多级表头、动态合并），得绕开原生 table 思路，用 view + CSS + 逻辑控制来模拟。
为什么不能直接用 <table> 标签
uni-app 的 <table> 在 H5 端能跑通基础功能，但 APP 和小程序端 WebView 内核对表格渲染支持极弱：
- colspan 和 rowspan 在 APP 端常被忽略或计算错误，导致单元格错位、列宽塌陷
- 多层嵌套 <table> 会触发父容器 overflow 隐式截断，iOS 上尤其明显
- 表格高度无法准确测量，scroll-view 套 table 后滚动卡顿、抖动严重
- uView 的 u-table 组件底层也是 view 模拟，不支持真正的 rowspan，仅靠 colspan + 占位格“假装”跨行
uv3-table 的 colspan 能力与边界限制
uv3-table 是目前最接近“开箱即用”的方案，但它只支持列方向跨列（colspan），不支持跨行（rowspan）。它的实现本质是：把一个逻辑上的“跨两列单元格”，拆成两个并排的 <u-th> 或 <u-td>，再通过样式隐藏中间 border + 合并背景色来视觉模拟。
- 必须显式设置每列
width（如"20%"或"150rpx"），否则colspan计算会失准 -
colspan: 2只影响当前单元格的渲染宽度，不会自动拉伸相邻列 —— 相邻列仍按自身width占位，需手动调小它们的宽度来腾出空间 - 表头跨列后，对应数据行的列数必须严格对齐，否则
data-source渲染会错列 - APP 端若开启
border-stripe，跨列单元格的边框可能断裂，建议关闭或用自定义 border 样式覆盖
手动实现跨行 + 固定行列的 view 表格结构
当需要真正跨行（比如第一行表头占两行）、或同时固定表头+左侧列时，必须放弃组件库封装，手写三层嵌套结构：
- 外层用
scroll-view设置scroll-x和scroll-y，但禁止它直接包裹表格内容 - 表头区域单独抽离，用
position: sticky; top: 0实现垂直固定（注意：父容器需设height且不能有overflow: hidden） - 左侧列用
position: sticky; left: 0，但必须确保所有左侧列单元格高度一致 —— 高度不齐会导致 APP 端列错位，需用空白<view>占位补高 - 主体表格用绝对定位 +
transform: translate(x, y)模拟滚动，避免 scroll-view 的重绘抖动；滚动事件里动态更新translate值，而非操作 DOM
示例关键 CSS：
`.sticky-header { position: -webkit-sticky; position: sticky; top: 0; z-index: 10; } .sticky-left { position: -webkit-sticky; position: sticky; left: 0; z-index: 9; }`
APP 端错位问题的典型修复点
错位不是偶发 bug，而是 APP WebView 对 flex 布局和 sticky 定位的渲染差异导致的必然结果：
- 所有列容器（
col-group）的width必须严格等于其内部子元素总宽，子元素超宽会撑开父容器，挤压后续列 - 不同区块行数不一致时（如左区 10 行、右区 2 行），必须统一用
height+ 空白<view>补齐，不能依赖align-items: flex-start - 避免在表格内使用
flex-wrap: wrap或text-overflow: ellipsis，APP 端计算溢出宽度极不稳定 - 固定列的
z-index必须高于滚动内容层，且不能和scroll-view的z-index冲突（APP 端层级渲染顺序和 H5 不同）
最易被忽略的是：APP 端的 sticky 行为依赖父容器的 height 和 overflow 组合，而 uni-app 的页面容器默认没有显式 height，必须在 scroll-view 外层加一层 view 并设 height: 100vh 或具体数值，否则 sticky 完全不生效。
