表格高度自适应这种需求做中后台系统的基本都会遇到。尤其是在那些列表页里顶部一个搜索栏底部一个分页器中间夹着一张数据表格窗口稍微一拉伸或者缩放表格要么被挤得只剩一截要么底部空出一大片怎么看怎么别扭。Element UI的table组件本身又不会自己感应外层容器的高度变化你给它定多少高就是多少高卡在这一步的人不在少数。这篇文章我就围绕element-ui table高度自适应这个话题把自己在项目里踩过的坑、试过的方案、最后沉淀下来的通用写法完整拆一遍。内容会从需求分析讲到计算原理再到具体代码和封装思路最后附上常见的排查技巧尽量做到看完就能直接用。1. 需求拆解表格高度自适应的本质是什么1.1 中后台页面的典型痛点你可以想象一下最常见的后台页面骨架顶部导航固定左侧菜单固定右侧内容区需要铺满剩下的空间。在内容区里从上到下依次是搜索表单、操作按钮、数据表格、分页组件。多数产品经理的需求是“表格尽量撑满中间区域数据多的时候表格内部滚动不做页面级滚动”。听起来很简单但如果你直接把table丢进一个常规的布局流里会发现几个尴尬的现象表格只按照内容高度渲染当你只有三条数据时表格底部到分页器之间会空出一大截。当你有几百条数据时表格把页面撑高整个页面开始滚动而不是表格内部滚动。窗口一缩放表格高度纹丝不动布局立刻失衡。其实这些问题都指向同一个核心诉求让表格的高度跟随外部容器的可用空间动态变化而不是由内容撑开。所谓“可用空间”通常是“容器的高度减去上方占用的高度”。只要把这两个数算清楚表格自己内部就有滚动条页面整体保持稳定。1.2 为什么不用纯CSS方案遇到这个问题第一反应多半是布局上用flex让内容区直接铺满然后表格区域flex:1。这个思路在部分场景下是有效的但放到Element UI的table上就有偏差。原因在于table内部还有一个自己的滚动容器你需要的是“让这个内部滚动容器获得一个明确的高度”而不是仅仅让外层div撑开。如果外层div是靠flex撑开的table组件却不知道自己该渲染多高它依然会按内容高度来渲染结局跟不用flex也没有本质区别。还有朋友尝试用百分比高度比如给table设置height: 100%结果发现问题更复杂table的高度百分比大概率不会按照你预期的父容器去计算尤其是在父容器高度没有显式指定时百分之百变成无效值表格直接塌下去或撑开。Element UI官方对height属性的解释也明确接受number或string而当height传字符串时更多情况下是当成CSS样式的像素值来用。纯CSS方案不好使JS动态计算就成了一条最稳定可控的路。核心思路并不复杂拿到视口高度减去表格渲染区域距离视口顶部的偏移减去表格上方其他区域占用的高度剩下来的就是表格应该拿到的高度然后把这个值实时同步给table的height属性。1.3 方案选型的对比实现方式核心思路优势局限纯flex布局让外层容器撑开table高度为百分比代码简单适合固定卡片场景表格内部滚动容器拿不到明确高度不生效CSS calc计算用视口高度减固定值无JS开销其他元素高度变化时需要改代码不灵活JS动态计算高度getBoundingClientRect加resize监听实时赋值给height精确、通用、适配复杂布局需要处理监听时机和销毁逻辑第三方表格库直接使用支持自动高度的库开箱即用迁移成本高不一定符合现有技术栈从我实践的结果来看JS动态计算方案是主流选择。它不需要改动表格组件本身又能覆盖绝大多数动态布局。下文我会把重点放在这个方案上。2. 核心原理高度计算要从哪里入手2.1 表格高度的计算模型在动手写代码之前先把计算模型理清楚。假设页面结构是div classpage-container div classsearch-area搜索区域约80px/div div classtoolbar操作按钮区域约50px/div div classtable-wrapper el-table reftable :heighttableHeight/el-table /div div classpagination-area分页区域约56px/div /div表格想要填满table-wrapper区域并且把分页区域挤到底部那么表格高度可以表达成这样一个公式表格高度 视口可用高度 - 表格区域距离视口顶部的距离 - 表格区域下方需要的预留高度用一张更直观的拆解来看视口可用高度window.innerHeight表格区域距离视口顶部的距离document.querySelector(.table-wrapper).getBoundingClientRect().top表格区域下方需要的预留高度主要是分页器高度 上下留白把table的height属性设置为这个差值表格内部就刚好在边界处出现滚动条。2.2 该用哪些浏览器API这里需要区分两个概念获取元素的位置和获取元素的高度。获取位置推荐用getBoundingClientRect().top。它返回的是元素左上角相对于视口的距离用的是视口坐标跟页面是否滚动无关。窗口滚动后这个值会自动变化比较适合作为实时计算的基准。获取高度有几种方式clientHeight表示元素内部可见高度不含边框和滚动条offsetHeight含边框和滚动条getBoundingClientRect().height返回渲染后的实际高度含边框。通常我们计算表格高度时优先用clientHeight或getBoundingClientRect().height来读取参考元素的高度。2.3 影响计算结果的几个变量页面有无整体滚动条。如果页面本身就能滚动window.innerHeight仍然是视口高度但getBoundingClientRect().top会变化公式依然成立。是否存在弹窗、抽屉临时遮挡。如果表格被包在el-dialog里计算基准就不能再使用视口高度而是对话框内容区域的top和高度。是否有浏览器工具栏自动缩进。移动端浏览器地址栏隐藏时innerHeight会变化resize事件会触发需要合理处理。在多数后台管理系统中页面本身是不滚动的内容区在里面滚动所以上面的基础模型足够覆盖九成以上场景。3. 实操实现从单页面到通用封装3.1 最基础的单页面实现先写一个最直接的版本让你直观感受到计算逻辑在Vue组件里是怎么跑的。template div classpage-container div classsearch-area el-input placeholder搜索关键词 stylewidth: 240px / /div div classtable-wrapper el-table :heighttableHeight :datatableData el-table-column propname label名称 / el-table-column propstatus label状态 / /el-table /div div classpagination-area el-pagination layouttotal, prev, pager, next :total100 / /div /div /template script export default { data() { return { tableData: [], tableHeight: 500 } }, mounted() { this.updateTableHeight() window.addEventListener(resize, this.updateTableHeight) }, beforeDestroy() { window.removeEventListener(resize, this.updateTableHeight) }, methods: { updateTableHeight() { this.$nextTick(() { const wrapper this.$el.querySelector(.table-wrapper) if (!wrapper) return const top wrapper.getBoundingClientRect().top const bottomGap 56 20 // 分页器高度 底部留白 this.tableHeight window.innerHeight - top - bottomGap }) } } } /script这段代码干的事很直白在组件挂载完毕后算出表格高度监听窗口大小变化时重新计算。bottomGap里的56来自分页器的默认高度20是分页器下方的留白。实际操作时你需要根据自己的间距微调这个值。3.2 计算参数的细节与边界上面代码里最需要打磨的地方就是那几处魔法数字。分页器高度并非固定不变。Element UI的el-pagination在不同尺寸下高度不同有small属性时会矮一些。更稳妥的方式是在计算时读取分页元素的实际高度而不是硬编码getBottomReservedHeight() { const pagination this.$el.querySelector(.pagination-area) const paginationHeight pagination ? pagination.getBoundingClientRect().height : 0 // 再加上分页器下方留白 return paginationHeight 20 }同时如果你的页面里搜索区域不固定高度比如动态展开收起最好也动态读取它的当前高度。这里还有一个容易踩的坑图片和异步数据会导致高度不准确。比如表格里有一列渲染的是图片图片加载前高度是0加载后把页面撑高了此时用getBoundingClientRect计算出来的top值已经变了。针对这类情况可以在数据加载完成的回调里再调一次updateTableHeight或者监听图片的onload事件。3.3 封装成可复用的混入单页面里的代码写多了你会发现每个列表页都在重复复制粘贴高度计算逻辑。此时就该考虑封装。我习惯用mixin抽出一个公共逻辑因为Vue2项目里mixin接入成本最低业务代码改动最小。// tableHeightMixin.js export default { data() { return { tableHeight: 500, // 表格区域容器选择器默认取当前组件根节点下第一个 .table-wrapper tableWrapperSelector: .table-wrapper, // 底部预留区域选择器如果留空则使用固定值 tableBottomSelector: .pagination-area, // 兜底固定值当底部选择器找不到时使用 tableBottomReservedHeight: 76, // 是否开启resize监听 tableUseResizeListener: true } }, mounted() { this.updateTableHeight() if (this.tableUseResizeListener) { window.addEventListener(resize, this.updateTableHeight) } }, beforeDestroy() { if (this.tableUseResizeListener) { window.removeEventListener(resize, this.updateTableHeight) } }, methods: { updateTableHeight() { this.$nextTick(() { const wrapper this.$el.querySelector(this.tableWrapperSelector) if (!wrapper) { return } const wrapperTop wrapper.getBoundingClientRect().top let bottomHeight this.tableBottomReservedHeight if (this.tableBottomSelector) { const bottomEl this.$el.querySelector(this.tableBottomSelector) if (bottomEl) { bottomHeight bottomEl.getBoundingClientRect().height 20 } } this.tableHeight Math.max(200, Math.floor(window.innerHeight - wrapperTop - bottomHeight)) }) } } }注意这里用Math.max(200, ...)做了下限保护。表格高度最少保留200像素防止在某些极端情况下算出来一个很离谱的小值导致表格完全不可用。业务页面引入这个mixin后只需要保证模板里有.table-wrapper这个类名然后在el-table上绑定:heighttableHeight就可以了。如果某个页面的布局特殊可以覆盖对应的data字段比如把tableBottomSelector改为.custom-footer。3.4 组件内主动刷新高度有些场景下窗口没有变化但布局变了。比如点击按钮把搜索区域展开或者某个tab切换导致表格上方多了提示条。这些情况下不会触发resize事件需要主动调用刷新。在mix里暴露一个公共方法methods: { // ...其他方法 refreshTableHeight() { this.updateTableHeight() } }页面中需要刷新的时候this.$refs.xxx.refreshTableHeight()或者如果你没引用子组件实例而是在同一个组件里使用mixin直接调用this.refreshTableHeight()。这个主动刷新能力非常实用。我第一次做自适应的时候就遇到过侧边栏收起导致内容区宽度变化表格宽度是跟着变了但高度莫名奇妙的没更新排查到最后发现是有个按钮把搜索区域高度改变了resize没触发手动调用刷新后立刻恢复。4. 常见问题与排查技巧实录4.1 表格高度计算不准总是高一点或低一点这个问题的根源在于底部预留高度和顶部偏移的取值时机。图片未加载完成时getBoundingClientRect().top会比真实值大算出来的表格高度就偏小。解决办法是在mounted阶段用this.$nextTick()延迟执行并不能百分百保证图片加载完成更稳妥的是在数据到达视图刷新后再执行一次高度计算。数据请求完整写法参考async fetchTableData() { const res await fetchList(this.queryParams) this.tableData res.list this.$nextTick(() { this.updateTableHeight() }) }如果做的是搜索查询可能还需要在拿回数据之前把表格高度先重置成一个预期值防止表格因为高度突变出现跳动。4.2 resize事件触发过于频繁页面卡顿窗口拖拽放大缩小时resize事件可以在一秒内触发几十次。如果你在每次事件里都操作DOM、修改表格高度Element UI内部会重新计算布局代价很高。事件监听里建议加一层节流或防抖。import { debounce } from lodash created() { this.updateTableHeight debounce(this.updateTableHeight, 200) }这样窗口拖拽时不会疯狂执行计算只在停顿后执行一次页面会流畅很多。注意这里要在created阶段覆盖方法而不是在methods里定义时就包裹否则beforeDestroy里移除监听时对不上引用。4.3 固定列或固定表头出现错位表格高度频繁变化时Element UI自带的固定列和固定表头有时会渲染出偏移或者错列。遇到这种情况可以在高度更新完成后调用table实例的doLayout方法。updateTableHeight() { // ...计算高度逻辑 this.$nextTick(() { this.$refs.table this.$refs.table.doLayout() }) }doLayout会重新计算表格内部各列宽度和固定列的位置是解决错位的官方手段。不过不要每次都调用只在有fixed属性列时使用否则白白增加性能开销。4.4 汇总数据固定在表格底部有一种需求是把汇总行固定在表格底部不随数据滚动走。Element UI里开启show-summary就能显示汇总行默认它会固定在表格底部。如果你用的是自定义底部统计区域记得把它算进表格高度计算时的底部预留高度否则汇总区域会被遮挡或者跟分页器重叠。下面的代码展示一个简单的自定义汇总栏el-table :heighttableHeight :datatableData show-summary :summary-methodgetSummary el-table-column propname label名称 / el-table-column propamount label金额 / /el-tablegetSummary({ columns, data }) { return columns.map((column, index) { if (index 0) { return 合计 } if (column.property amount) { const total data.reduce((acc, row) acc Number(row.amount || 0), 0) return total.toFixed(2) } return }) }汇总行自身高度也会影响可用空间如果用的是默认summary方案建议在底部预留高度里额外加上28到40个像素。4.5 页面里嵌套多个表格一个页面出现两个甚至更多表格时每个表格都单独监听resize事件逻辑上没问题但代码会很冗余。我更推荐只监听一次用一个公共调度者统一刷新所有表格高度。简单场景下也可以在mounted里分别初始化每个表格的计算函数更新时一起调用。最好还是抽一个useTableHeight似的服务利用事件总线或者Vuex的模块状态不过对于不需要跨页面的小项目来说多个mixin实例各算各的并不会互相干扰只是内存占用稍微大一点。实测下来二三十个mixin实例不会有明显影响。5. 进阶优化让表格高度自适应的体验更完善5.1 与flex布局结合之前的计算模型不排斥flex布局两者可以结合使用。外层页面用flex让内容区铺满表格容器本身也设为flex:1此时高度是动态的然后依然用JS算出这个动态区域的真实像素高度传给table。这样既保持了布局的弹性也让table拿到精确的高度。div classpage-container div classsearch-area.../div div classtable-wrapper el-table :heighttableHeight :datatableData/el-table /div div classpagination-area.../div /div.page-container { display: flex; flex-direction: column; height: 100vh; } .table-wrapper { flex: 1; overflow: hidden; }此时计算高度时表格的top值不变底部预留高度依然按分页器加留白计算并不冲突。这种方式比纯JS算最终高度更稳定因为flex保证了区域本身的弹性JS计算只是把弹性区域的高度值翻译给table。5.2 用ResizeObserver替代window.resizewindow.resize事件只能监听到浏览器窗口的变化监听不到某个容器尺寸的变动。如果你的表格外层容器是动态变化的比如侧边栏折叠后内容区宽度变宽用window.resize就可能捕捉不到。这时候可以用ResizeObserver监听容器本身。mounted() { const wrapper this.$el.querySelector(.table-wrapper) if (wrapper typeof ResizeObserver ! undefined) { this.ro new ResizeObserver(() { this.updateTableHeight() }) this.ro.observe(wrapper) } } beforeDestroy() { this.ro this.ro.disconnect() }ResizeObserver在主流浏览器中已经广泛支持用它监听容器尺寸变化比window.resize精确得多。并且当窗口变化导致容器尺寸变化时window.resize里不再需要重复执行高度计算两者可以并存但推荐优先使用ResizeObserver。用ResizeObserver之后更新高度还是要小心死循环如果updateTableHeight内部修改了wrapper的样式导致wrapper尺寸变化ResizeObserver又会触发新一轮回调导致循环执行。所以我通常在回调里只读取wrapper的位置信息而不修改它的宽高只修改表格的height属性。5.3 应对keep-alive缓存页面页面使用keep-alive缓存切换回来时表格高度可能已经不适应新视口。比如用户把浏览器缩放后切走再切回来mounted不会再触发高度需要用activated钩子恢复。activated() { this.updateTableHeight() }注意activation每次进入都会触发如果页面上有弹窗类组件也被keep-alive缓存同样需要处理好刷新时机。在activated里执行updateTableHeight时最好也包一层nextTick确保DOM已更新。5.4 处理表格数据动态变化导致的高度波动数据加载前表格没有内容高度如果已经被设置为很大的值页面会看到空白区域。可以把这个场景也考虑进去数据为空时给一个最小高度数据加载后再重新计算。或者采用两段式处理第一次先设置一个最小高度拿到数据后调整至计算值。结合“Element UI table表格数据汇总固定在表格底部”这个热搜需求数据加载后不仅表格内容在变汇总行也在变汇总行的出现会影响实际内容区高度此时重新计算是必要的。我在项目里做的是在数据接口return之后不管数据量如何都统一调用this.$nextTick内的updateTableHeight保证表格拿到最新的可用高度。5.5 动态表头或列显隐时的宽度适配表格高度自适应往往会和列显隐联动。列变多了横向出现滚动条此时表格内部会出现横向滚动条。对高度自适应本身没有直接影响但要注意固定列和横向滚动条会根据表格宽度重新计算建议在列变化后同样调用doLayout。handleColumnToggle() { this.showColumn !this.showColumn this.$nextTick(() { this.$refs.table this.$refs.table.doLayout() }) }6. 写在最后的体会我在多个中后台项目里反复使用这套高度自适应方案最深的感受是问题本身不难难的是把所有边界情况都考虑到。你只要记住了“视口高度减去位置偏移减去底部预留”这个公式再围绕它做好resize监听和nextTick时机的控制就足以应对绝大多数场景。如果你刚开始做我只建议你做两件事第一封装一个mixin把所有高度计算逻辑收敛到一处后续维护起来会省心很多第二给表格高度设一个最小值底线防止特殊情况下算出来的高度让表格消失。除此之外多用doLayout多在数据请求完成后主动刷新一次基本不会出大乱子。我踩过最深的一个坑是某次把resize监听加在了弹窗内部的表格容器上结果每次打开弹窗都会注册好几个监听器关闭弹窗时又没移除内存直接飙上去。后来我给每个需要高度自适应的组件都养成了在beforeDestroy里统一移除监听的习惯这个细节值得你特别留意。
