企业官网建设流程全解析

做后台管理系统做过几年的朋友，大概率都和 iView（现在叫 View UI）的 Table 组件打过交道。表格本身好说，把 columns 和数据一绑就出来了，真正让人纠结的往往是分页：数据一多，表格样式先不说，光是翻页、跳页、改每页条数这一堆联动，就够写小半天。这个项目标题说得很直白，就是把 iView 的 Table 和 Page 组件串起来，做一个能直接用、能应付真实业务的分页方案。这篇内容我打算按实际开发的顺序来讲，从最基础的结构搭建开始，再引入服务端分页场景，顺带把接口联调、动态查询和几个容易翻车的细节都过一遍。

先说结论：Table 和 Page 是两个独立组件，没有现成的绑定关系，所有联动都靠 data 里的几个字段和 Page 暴露的事件自己串。思路理清了，写起来比想象中要简单。

1. 从需求到方案：Table 分页的核心设计思路

1.1 分清"前端分页"和"服务端分页"两种场景

我见过不少新人一上来就把所有数据一次性塞进 Table，然后用 Page 组件在前端做切片。这么做在你只有几十条测试数据时看不出问题，等数据量涨到几千条甚至上万条，页面渲染就会明显变卡。所以在动手之前，先想清楚你到底属于哪种场景。

• 前端分页：后端一次性返回全部数据，前端通过计算属性对数组做 slice 切片。适合数据量小、基本不变的情况，比如字典列表、省份城市选择这种配置型数据。
• 服务端分页：后端只返回当前页的数据，前端把 currentPage、pageSize 作为请求参数发给后端，拿到数据后再渲染。适合数据量大、需要按条件筛选的真实业务场景。

这个项目题目的核心是"结合使用"，意味着前端要把 Table 和 Page 用起来，但真正的数据来源往往是接口。我建议直接把服务端分页作为默认方案，前端分页作为一种兜底手段。一个用过几年的老组件，别指望它能扛住几千行 DOM 的性能压力。

1.2 Page 组件的属性要优先搞清楚

Page 是 iView 里专门做分页的组件，常见属性有 total、current、page-size、show-total、show-sizer、show-elevator。先解释几个容易理解的：

• total：数据总条数，这个必须后端告诉你，或者前端数组的长度。
• current：当前页码，控制翻到第几页。
• page-size：每页显示条数。

这三个属性决定了分页的"骨架"。show-total、show-sizer、show-elevator 是 UI 增强：

• show-total 会在左侧展示"共 x 条"。
• show-sizer 会显示一个可以切换每页条数的下拉框，默认选项是 [10, 20, 30, 40]。
• show-elevator 会提供一个跳页输入框，允许用户直接输入页码快速跳转。

实际业务中，show-total 和 show-sizer 我基本都是开着的。show-elevator 看产品需求，如果列表本身就短，跳页意义不大。

1.3 数据流转：从接口到 Page 再到 Table

如果你的数据停留在"页面内定义好了"的程度，这不算完整的方案。真实流程应该是：

1. 页面加载时触发加载函数，默认请求第 1 页、pageSize 为 10 的数据。
2. 接口返回数据后，把 rows 塞给 Table 的 data，把 total 塞给 Page 的 total。
3. 用户点击 Page 翻页时，触发 on-change 事件，更新 currentPage，再次请求接口。
4. 接口返回新数据后，重新赋值给 Table 的 data，表格自动刷新。

这套逻辑看起来不复杂，但每一步都有关键细节。我在第二节把代码完整写出来。

2. 核心实现：Table 与 Page 组件的联动配置

2.1 页面结构：模板、数据、方法先搭起来

直接看一段最小可用的示例代码，基于 Vue 2 + iView 3.x / View UI 4.x：

<template> <div class="table-page-wrap"> <Table :columns="columns" :data="tableData" :loading="loading" border> </Table> <Page :total="total" :current="currentPage" :page-size="pageSize" show-total show-sizer show-elevator @on-change="handlePageChange" @on-page-size-change="handlePageSizeChange" style="margin-top: 16px; text-align: right;" /> </div> </template> <script> export default { data() { return { columns: [ { title: 'ID', key: 'id', width: 80 }, { title: '用户', key: 'name' }, { title: '邮箱', key: 'email' }, { title: '创建时间', key: 'created_at' } ], tableData: [], total: 0, currentPage: 1, pageSize: 10, loading: false }; }, methods: { async loadTableData() { this.loading = true; try { // 模拟接口请求，实际项目替换成 axios 调用 const params = { pageNum: this.currentPage, pageSize: this.pageSize }; const res = await this.fetchData(params); this.tableData = res.list; this.total = res.total; } catch (error) { // 实际项目可以在这里做统一错误提示 console.error('获取表格数据失败', error); } finally { this.loading = false; } }, handlePageChange(page) { this.currentPage = page; this.loadTableData(); }, handlePageSizeChange(size) { this.pageSize = size; this.currentPage = 1; this.loadTableData(); }, // 模拟接口，实际项目中删除 async fetchData(params) { return { list: [ { id: params.pageNum, name: '张三', email: 'zhangsan@example.com', created_at: '2024-01-01' } ], total: 100 }; } }, mounted() { this.loadTableData(); } }; </script>

这段代码注意几个地方：

• Table 加:loading="loading"，在请求期间会自动显示 loading 效果，省得自己写遮罩层。
• Page 的current属性绑定的是currentPage，而且必须是"受控"的，不然翻页后高亮状态可能会错乱。
• handlePageSizeChange里把currentPage重置为 1，这个非常重要。你在第 5 页把每页条数从 10 改成 20，如果不重置页码，很可能第 5 页已经没有数据了，界面上出现一个空表格。

2.2 前端分页的写法：纯前端 slice 是另一种活法

如果你的接口确实返回了全量数据，又不想改后端代码，也可以用前端分页方案。这种场景下，Page 组件只负责"看起来分页了"，数据实际全在内存里。实现方式是在 template 里对 tableData 做处理，或者借助 computed 属性先 slice 再传给 Table。

<template> <div> <Table :columns="columns" :data="pagedData" border></Table> <Page :total="allData.length" :current="currentPage" :page-size="pageSize" show-total show-sizer show-elevator @on-change="handlePageChange" @on-page-size-change="handlePageSizeChange" /> </div> </template> <script> export default { data() { return { allData: [], // 后端返回的全量数据 currentPage: 1, pageSize: 10 }; }, computed: { pagedData() { const start = (this.currentPage - 1) * this.pageSize; const end = start + this.pageSize; return this.allData.slice(start, end); } }, methods: { handlePageChange(page) { this.currentPage = page; }, handlePageSizeChange(size) { this.pageSize = size; this.currentPage = 1; } } }; </script>

前端分页的好处是切页不用再请求接口，交互流畅。代价是首次加载慢，因为所有数据都在一次请求里返回了。我一般只在字典表、组织树这些数据量确定不会很大的地方用。

2.3 .sync 修饰符带来的坑：为什么 current 会失灵

这里有个 iView 特有的坑，我必须单独拎出来说。

有些资料会写:current.sync="currentPage"，这种做法在 iView 3 部分版本里可能让你在翻页时看到页码跳了一下又弹回去，或者组件内高亮状态和你的数据对不上。原因是：Page 组件本身维护了内部页码状态，使用 .sync 时，组件通过 update:current 事件尝试同步外部数据，但如果你还在 handlePageChange 里手动改 currentPage，两者可能产生覆盖顺序问题。

我在实际项目中更推荐只绑定不使用 .sync：

<Page :total="total" :current="currentPage" :page-size="pageSize" @on-change="handlePageChange" />

这样唯一的数据源就是你的 currentPage 变量，每次变化都走你的方法，逻辑清晰可控。

2.4 表格空数据和加载状态别忽视

数据为空时，Table 默认会显示一行"暂无数据"，这个其实是 iView 的默认配置，不用额外处理。但要注意一个体验问题：如果接口返回慢，用户切页后看不到任何反馈，会以为点了没反应。所以 loading 状态必须加上。

另外，如果你有筛选条件，在查询条件变化后也需要重新拉数据。列出几个必须注意的触发场景：

• 点击查询按钮，重置 currentPage 为 1，然后加载数据。
• 点击重置按钮，先把条件表单重置，再重置页面，加载数据。
• 切换每页条数后，页码重置为 1，再加载数据。

这些逻辑如果遗漏，分页就会出现"我在第 8 页查了关键字，结果还是第 8 页的数据"这种让人抓狂的问题。

3. 服务端分页实操：从接口到页面渲染的完整链路

3.1 接口参数约定：pageNum 和 pageSize 是主流规范

服务端分页的请求，后端一般要求两个参数：页码、每页条数。有些项目用 pageNo 和 pageSize，有些用 page 和 limit，还有些后端老系统用 start 和 length。建议前端统一封装一个分页请求工具，别在每一个接口里手动拼参数。

参数格式上没有统一标准，核心是前后端约定一致。我习惯用 pageNum 和 pageSize，因为这种命名在 Java 生态里很常见，后端拿到手基本不用转换。

// api/user.js import request from '@/libs/request'; export function getUserList({ pageNum, pageSize, keyword, status }) { return request({ url: '/api/user/list', method: 'get', params: { pageNum, pageSize, keyword, status } }); }

3.2 后端返回结构兼容：list 和 total 是标配

后端返回的 JSON 结构对前端的取值逻辑影响很大。我见过几种不同的返回风格：

• 直接返回{ list: [], total: 100 }
• 返回{ rows: [], total: 100 }
• 返回{ data: { records: [], total: 100 } }
• 甚至返回{ result: { items: [], totalCount: 100 } }

不同后端框架返回的字段差异巨大，比如 MyBatis-Plus 的 IPage 序列化之后，字段可能是 records、total、size、current。如果你在项目里遇到和我一样的情况，不想被后端字段绑定死，可以在封装层做一次映射。

function normalizePageData(res) { return { list: res.list || res.rows || res.records || res.data?.list || [], total: res.total ?? res.totalCount ?? res.data?.total ?? 0 }; }

我这里用了 nullish coalescing（??），保证 0 也能正确取值，注意别用||，否则 total 为 0 时会被误判成 fallback 的 0，虽然结果一样，但语义不对。

3.3 搜索条件与分页参数的联动处理

真实项目里，Table 上面一定会有一个搜索表单。查询条件和分页参数必须联动，否则会出现逻辑漏洞。通常的做法是：

data() { return { searchForm: { keyword: '', status: '' } }; }, methods: { buildQueryParams() { return { pageNum: this.currentPage, pageSize: this.pageSize, keyword: this.searchForm.keyword, status: this.searchForm.status }; }, async loadTableData() { const params = this.buildQueryParams(); // 请求接口 }, handleSearch() { this.currentPage = 1; this.loadTableData(); }, handleReset() { this.searchForm = { keyword: '', status: '' }; this.currentPage = 1; this.loadTableData(); } }

搜索按钮和重置按钮都会重置页号，这是分页最容易漏掉的一环。如果用户在第 10 页输入关键字搜索，不重置页码的话，请求会带着第 10 页的参数，而第 10 页在筛选条件下根本不存在。

3.4 分页请求封装：loading 放在 hook 层而不是每个页面

很多项目会在每个页面里重复写 loading 的开关，我早期也这么干，后来发现这种重复代码没太大意义。比较稳妥的做法是利用一个自定义 hook 或者 mixin，把分页表格的加载逻辑统一封装。

Vue 2 中可以用 mixin：

// mixins/tablePage.js export default { data() { return { tableData: [], total: 0, currentPage: 1, pageSize: 10, loading: false }; }, methods: { async loadTableData() { if (this.fetchTableData) { this.loading = true; try { const res = await this.fetchTableData(this.buildQueryParams()); this.tableData = res.list; this.total = res.total; } catch (error) { // 统一处理 } finally { this.loading = false; } } }, handlePageChange(page) { this.currentPage = page; this.loadTableData(); }, handlePageSizeChange(size) { this.pageSize = size; this.currentPage = 1; this.loadTableData(); } } };

在这个 mixin 里，只要求使用方实现 fetchTableData 方法，返回固定格式的数据即可。很多后台项目几十个页面都是这种翻页结构，封装之后每个页面里只需要写表格列和接口函数，省下大量重复代码。

4. 踩坑记录：Table 和 Page 结合时最容易翻车的细节

4.1 current 的响应式丢失问题

Page 组件的 current 属性，在 iView 早期 3.x 的某些版本里存在"外部改了 current 但页码高亮不更新"的问题。例如你点击查询按钮把 currentPage 从 3 改为 1，Page 组件的显示却还停留在 3。

排查思路：

• 先确认 currentPage 是否真的变了：打印到控制台看看。
• 如果变量变了但 UI 没变，可以用:key强制刷新 Page 组件。
• 升级 iView / View UI 版本，这个 bug 在 View UI 4.x 中基本修复。

用 key 的写法简单有效：

<Page :key="pageKey" :total="total" :current="currentPage" ... />

在重置页码时顺手把 pageKey 增加 1，强制让 Page 重新渲染。虽然这个方案不够优雅，但在老版本项目里是个稳定兜底。

4.2 表格不能自动回到顶部

用户翻页后，如果整个页面可以滚动，表格会停留在原来的滚动位置，新数据从当前滚动位置开始渲染，观感很糟糕。特别是数据多的时候，翻到第 3 页，你明明在表格底部，结果新内容出现在表格顶部，页面滚动条却不动，用户还得手动滚回去。

解决方法就是在翻页成功后，把滚动容器滚动到顶部。如果你用的是 window 滚动，直接：

window.scrollTo(0, 0);

如果是表格内部滚动，可以在 Table 外层 ref 上操作：

this.$nextTick(() => { this.$refs.tableWrap.scrollTop = 0; });

4.3 每页条数切换引发的"空页"问题

之前提过切换 pageSize 时要把 currentPage 重置为 1，这里我再详细解释一次。假设当前在第 5 页，每页 10 条，总共 100 条。你把每页条数改成 20 之后，总页数从 10 页变成 5 页，第 5 页仍然有效。但如果你在第 8 页，改成 20 条后总页数是 5，当前页 8 已经不存在了，表格就会空白。

所以最稳妥的做法是，在任何改变查询范围的操作里，都先把 currentPage 设置成 1。包括搜索、重置、切换每页条数、切换 Tab 分类。

4.4 表格列的筛选排序和分页的冲突

iView Table 支持列排序和筛选，但当排序生效时，服务端分页不会自动帮你排序。你需要监听 Table 的 on-sort-change 事件，把排序字段和排序顺序一起带给后端。

<Table :columns="columns" :data="tableData" @on-sort-change="handleSortChange" />

handleSortChange({ column, key, order }) { // order 的值为 asc / desc / normal this.sortField = key; this.sortOrder = order === 'normal' ? '' : order; this.currentPage = 1; this.loadTableData(); }

如果漏掉这一步，就会出现"当前页排序了，但翻页后排序失效"的假象，项目的测试很容易踩到。

4.5 大数据量下 Table 的性能：开启虚拟滚动或合理分页

iView Table 本身并没有内置虚拟滚动，如果你的数据量非常大（单页上千行），即使分页了，单页渲染压力也不小。这时候建议控制单页数据量，10 到 50 行之间是合理的，真要展示超大列表，可以换成专业的虚拟滚动表格组件。分页的意义本来就不是"一次显示所有数据"，而是"让用户在当前页看得舒服"。如果单页 100 条都卡，该考虑的不是分页逻辑，而是产品设计是不是出了问题。

5. 常见问题速查：分页相关的排查笔记

5.1 问题-原因-解决对照表

下面整理几个我在实际项目中遇到过、且不止一次有人来问的问题：

5.2 调试分页逻辑的实用小技巧

分页联调时，建议打开浏览器 DevTools 的 Network 面板，先确认每次点击翻页是否发出了正确的请求，Request URL 里的 pageNum 和 pageSize 是否和预期一致。如果请求参数正确但数据不对，问题在后端；如果请求参数没变，问题在前端事件绑定。

另一种排查思路是"固定数据复现"。在本地开发环境里，把接口返回写死成一个固定列表，手动模拟翻页操作，看是前端的切片问题还是接口数据问题。这种方法虽然简单粗暴，但在前后端扯皮时非常有用。

5.3 关于 antd Table 的对比参考

有些项目同时用过 iView 和 antd，其实两者的分页思路很相似。antd 的 Table 自带 pagination 属性，可以直接在列配置同级传入 total、current、pageSize 和 onChange，不需要单独的 Page 组件。而 iView 的 Table 没有内部分页，必须靠 Page 组件手动组合。理解这一点后，你从 iView 切到 antd 或者反过来，思路都能很快对齐，差异只在于配置位置和事件命名。

6. 最终落地：一个可以直接抄的后台分页示例

6.1 完整的单文件示例

把前面讲的内容整合成一个比较标准的页面，可以直接粘贴到 vite 或 webpack 的 Vue 项目中。示例包含搜索、重置、分页、状态切换、字段映射，基本覆盖日常需求。

<template> <div class="user-page"> <Card> <Form inline @submit.native.prevent> <FormItem label="关键字"> <Input v-model="searchForm.keyword" placeholder="请输入用户名" clearable style="width: 200px;" @on-enter="handleSearch" /> </FormItem> <FormItem label="状态"> <Select v-model="searchForm.status" style="width: 120px;"> <Option value="">全部</Option> <Option value="1">启用</Option> <Option value="0">禁用</Option> </Select> </FormItem> <FormItem> <Button type="primary" @click="handleSearch">查询</Button> <Button style="margin-left: 8px;" @click="handleReset">重置</Button> </FormItem> </Form> <Table ref="mainTable" :columns="columns" :data="tableData" :loading="loading" border @on-sort-change="handleSortChange" > </Table> <Page :total="total" :current="currentPage" :page-size="pageSize" show-total show-sizer show-elevator style="margin-top: 16px; text-align: right;" @on-change="handlePageChange" @on-page-size-change="handlePageSizeChange" /> </Card> </div> </template> <script> import { getUserList } from '@/api/user'; export default { name: 'UserList', data() { return { searchForm: { keyword: '', status: '' }, columns: [ { title: 'ID', key: 'id', width: 80 }, { title: '用户名', key: 'username', sortable: true }, { title: '邮箱', key: 'email' }, { title: '状态', key: 'status', render: (h, params) => h('Tag', { props: { color: params.row.status === 1 ? 'green' : 'default' } }, params.row.status === 1 ? '启用' : '禁用') }, { title: '创建时间', key: 'created_at', sortable: true } ], tableData: [], total: 0, currentPage: 1, pageSize: 10, loading: false, sortField: '', sortOrder: '' }; }, methods: { buildQueryParams() { const params = { pageNum: this.currentPage, pageSize: this.pageSize, keyword: this.searchForm.keyword.trim(), // 去除首尾空格 status: this.searchForm.status }; if (this.sortField) { params.sortField = this.sortField; params.sortOrder = this.sortOrder; } return params; }, async fetchTableData() { return await getUserList(this.buildQueryParams()); }, normalizePageData(res) { return { list: res.list || res.rows || res.records || res.data?.list || [], total: res.total ?? res.totalCount ?? res.data?.total ?? 0 }; }, async loadTableData() { this.loading = true; try { const res = await this.fetchTableData(); const { list, total } = this.normalizePageData(res); this.tableData = list; this.total = total; } catch (error) { // 项目中一般在这里调用统一错误提示 this.$Message.error('加载数据失败'); } finally { this.loading = false; } }, handleSearch() { this.currentPage = 1; this.loadTableData(); }, handleReset() { this.searchForm = { keyword: '', status: '' }; this.currentPage = 1; this.loadTableData(); }, handlePageChange(page) { this.currentPage = page; this.loadTableData(); }, handlePageSizeChange(size) { this.pageSize = size; this.currentPage = 1; this.loadTableData(); }, handleSortChange({ key, order }) { this.sortField = key; this.sortOrder = order === 'normal' ? '' : order; this.currentPage = 1; this.loadTableData(); } }, mounted() { this.loadTableData(); } }; </script>

这个示例里的 normalizePageData 是我比较推荐加的一层防护，因为不同团队、不同后端语言的返回结构差异太大，前端做了兼容后，就不会因为后端改了一个字段名导致整个页面崩掉。

6.2 关于"复用"的进一步建议

如果你的项目有大量类似列表页，除了复制粘贴这个模板，还可以把 loadTableData、handlePageChange、handlePageSizeChange 这些通用方法抽出去。我在 3.4 中给出的 mixin 思路可以继续扩展，但要注意：不是所有页面都需要排序，不是所有表格都有筛选条件，所以封装时别把逻辑写死，留好扩展入口。

我个人现在的习惯是，公司后台维护了一个 tablePageMixin，基础的分页字段和事件都在里面，业务页面只需要覆盖 fetchTableData 和一些特殊处理。新来的同事写列表页，第一条最短路径就是参考这个 mixin，效率提升很明显。

7. 扩展方向：分页组件还能怎么优化

7.1 为 Page 组件增加"每页条数"的记忆功能

很多产品希望用户切换了每页条数后，下次进入页面还能记住这个偏好。实现方式有两种：

• 使用 localStorage 存储 pageSize，打开页面时读取并赋值。
• 后端在用户配置表里记录分页偏好，每个接口请求时带上。

前端方案简单，不涉及后端改动，我一般优先用 localStorage。注意 key 要区分用户，避免多用户共用浏览器时相互影响。

7.2 把分页状态同步到 URL，方便分享和刷新保持

这是个容易被忽略的需求：用户翻到第 3 页，刷新后应该还停留在第 3 页。最简单的做法是把当前页和每页条数放在 URL query 上。

// 切换页码时更新路由 this.$router.replace({ query: { ...this.$route.query, pageNum: this.currentPage, pageSize: this.pageSize } });

页面初始化时从this.$route.query读取 pageNum 和 pageSize，再加载数据。这样刷新页面、复制链接给同事，都能保持分页状态。

7.3 总结成一套"表格页"通用模板

其实很多后台项目需要的不是一个单纯的 Table 分页 Demo，而是一整套"搜索区域 + 表格区域 + 分页区域"的组合模板。除了分页联动，最好还包括：

• 表单验证
• 操作列按钮（编辑、删除、启用禁用）
• 批量选择与批量操作
• 列宽度自动适配

这套模板的完整实现会牵扯到更多 iView 组件知识，比如 Table 的 selection、render 函数、Modal 确认框等。分页作为其中的基础能力，先把本节内容搞透，后面扩展其他功能会顺手很多。

我在公司内部就维护了一套这样的模板，每次新后台页面直接复制出来改改配置就能用。项目中的分页虽然只是一个小小的交互点，但把它的"连接"工作做好，整个表格页的体验能提升一大截，后续维护也少很多糟心事。