横向滚动条遮挡最后一行本质是layui双滚动区域未预留滚动条空间，需在.layui-table-box设overflow:hidden、.layui-table-body设max-height并加padding-bottom:17px，同时同步固定列滚动。
横向滚动条遮挡最后一行？本质是滚动容器高度没算准
这不是 layui 的 bug，而是它把表格内容和表头拆成两个独立滚动区域（.layui-table-header 和 .layui-table-body）后，.layui-table-body 的 height 没预留滚动条空间导致的。浏览器在显示纵向滚动条时会压缩可用宽度，而 layui 默认按“无滚动条”尺寸渲染内容区，结果内容行被纵向滚动条顶上去、最后一行卡在可视区外。
必须给 .layui-table-body 预留纵向滚动条高度
直接加固定高度不靠谱——不同系统滚动条宽度不同（Windows 约 17px，macOS 隐藏式，Linux 可变），硬写 height: calc(100% - 17px) 在 macOS 下反而多出空白。正确做法是让容器自己感知：
- 确保父容器（如
.layui-table-box）有明确 height，且设为overflow: hidden（layui 默认就是） - 给
.layui-table-body加max-height: calc(100% - 45px)—— 这里的 45px 是表头高度（默认值），可按实际调整 - 关键：补上
padding-bottom: 17px，强制底部空出滚动条位置，避免内容被遮 - 如果用了
height: 'full-xx'配置，需配合limit参数控制单页条数，否则高度计算更不稳定
scrollX: true 开启后仍遮挡？检查列宽与容器宽度是否对齐
开启横向滚动本身会加剧纵向滚动条出现概率，一旦列总宽略超容器，就会触发双重滚动（x + y），此时 .layui-table-body 高度更难精确。常见踩坑点：
- 列配置中混用
width（像素）和minWidth（百分比），导致 layui 内部宽度累加误差 -
.layui-table-box父级有padding或border，但未在 width 计算中扣除 - 调用
table.resize('id')时传入的 id 错误，或在done回调里过早调用，DOM 尚未重排完成 - 移动端需额外加
-webkit-overflow-scrolling: touch，否则 iOS Safari 渲染延迟会让遮挡更明显
固定列（fixed: true）场景下遮挡更严重？同步滚动是关键
固定列和普通列是分离的 DOM 结构，.layui-table-fixed 不会自动跟随 .layui-table-body 的 scrollTop。当纵向滚动发生时，固定列不动，视觉上就像“最后一行被吸走”：
- 监听
.layui-table-body的scroll事件，手动设置.layui-table-fixed的scrollTop - 不要用
scrollTop = e.target.scrollTop直接赋值，先取整：Math.round(e.target.scrollTop)，避免小数导致渲染抖动 - 若固定列也设置了
fixed: 'right'，需同时操作.layui-table-fixed-right - 这个逻辑必须在表格渲染完成（
done回调）后绑定，且建议用once防止重复绑定
横向滚动条遮挡最后一行，表面是样式问题，实际是 layui 表格双滚动结构 + 动态高度计算 + 跨平台滚动条差异共同作用的结果。最稳的解法不是调一个 CSS，而是从容器高度预留、列宽收敛、滚动同步三处同时控制。
