在调用分页 API 时，前端常误将每页数据的本地索引（如 index + 1）作为全局序号，导致翻页后序号重置为 1；正确做法是根据当前页码和每页条数动态计算全局序号。
在调用分页 api 时，前端常误将每页数据的本地索引（如 `index + 1`）作为全局序号，导致翻页后序号重置为 1；正确做法是根据当前页码和每页条数动态计算全局序号。
在构建带序号的分页列表（如“第 1 条”“第 27 条”）时，若直接使用循环中的 index（例如 Vue 的 v-for="(item, index) in list" 中的 index + 1），该序号仅反映当前页内的位置，而非数据在整个数据集中的全局顺序编号。因此切换页码时，序号必然从 1 重新开始——这正是你截图中出现的问题。
✅ 正确解法：使用数学公式计算每条记录的全局序号
假设：
-
currentPage：当前页码（从 1 开始，常见于后端分页参数如page=1） -
pageSize：每页条数（如 10） -
index：当前页内数据的零基索引（即循环中的i，从 0 开始）
则该条记录的真实序号为：
globalIndex = (currentPage - 1) * pageSize + index + 1
? 示例（Vue 3 + Composition API）：
<template>
<ul>
<li v-for="(user, i) in userList" :key="user.id">
{{ (currentPage - 1) * pageSize + i + 1 }}. {{ user.name }}
</li>
</ul>
<Pagination
:current="currentPage"
:page-size="pageSize"
:total="total"
@change="handlePageChange"
/>
</template>
<script setup>
import { ref, computed } from 'vue'
const currentPage = ref(1)
const pageSize = 10
const total = ref(127)
const userList = ref([])
// 模拟 API 获取当前页数据
const fetchPage = async () => {
const res = await api.get('/users', {
params: { page: currentPage.value, limit: pageSize }
})
userList.value = res.data.list
}
const handlePageChange = (page) => {
currentPage.value = page
fetchPage()
}
</script>⚠️ 注意事项：
- 确保
currentPage与后端约定一致（多数 RESTful 接口使用 1-based 页码，切勿传 0）； - 若后端返回的是
offset/limit形式（如/users?offset=20&limit=10），则全局序号 =offset + index + 1； - 不要依赖前端缓存全部数据再做序号渲染（尤其数据量大时），应以服务端分页逻辑为准，仅计算当前页可见序号；
- 如需支持「跳转到第 N 条」等高级功能，建议后端在响应中直接返回
start_index字段，避免前端重复计算。
总结：序号不是视觉装饰，而是数据位置的准确表达。抛弃 index + 1 的简单思维，拥抱 (page - 1) × size + index + 1 的确定性逻辑，即可一劳永逸解决分页序号重置问题。
