不能直接用 math.ceil(total / pagesize)，因为 total 为 0 时返回 0（应为 1），且浮点误差可能导致错误结果；安全写法是 (total === 0 ? 1 : math.floor((total - 1) / pagesize) + 1)。
为什么不能直接用 Math.ceil(total / pageSize)
看似最直觉的写法，但实际会出错：当 total 为 0 时，Math.ceil(0 / pageSize) 得到 0，而业务上“0 条数据”通常应显示 1 页（空列表页），或至少需与后端约定一致；更隐蔽的问题是浮点误差——比如 total = 10、pageSize = 3，理论上 10 / 3 ≈ 3.333...，Math.ceil 应得 4，但若因精度丢失变成 3.3333333333333335 还好，万一变成 3.2999999999999998（极少见但可能），Math.ceil 就会错误返回 3。
安全写法：整数除法模拟 + 显式边界处理
绕过浮点计算，改用整数运算逻辑判断余数：
function getTotalPages(total, pageSize) {
if (total <p>这个公式等价于“向上取整”，且全程用整数运算，无精度风险。原理是：把 <code>total</code> 拆成 <code>k * pageSize + r</code>（<code>r ∈ [0, pageSize)</code>），则 <code>(total - 1) / pageSize</code> 的 floor 值恒为 <code>k - 1</code>（当 <code>r = 0</code>）或 <code>k</code>（当 <code>r > 0</code>），再加 1 即得正确页数。</p>
-
total = 0→ 返回1（常见默认） -
total = 12, pageSize = 5→Math.floor((12-1)/5) + 1 = Math.floor(11/5) + 1 = 2 + 1 = 3 -
total = 10, pageSize = 3→Math.floor(9/3) + 1 = 3 + 1 = 4
和后端对齐时要注意的三个细节
前端算出的总页数必须和后端分页接口返回的 totalPages 一致，否则翻页按钮会错乱：
- 后端是否把
total = 0当作totalPages = 0？前端就得保持一致，不能硬写return 1 - 后端分页是否基于 SQL 的
OFFSET/LIMIT？它的totalPages通常由COUNT(*)计算，而 COUNT 可能受权限、软删除等影响，前端不能假设total是原始数据量 - 某些后端框架（如 Spring Data JPA）的
Page.getTotalPages()内部就是用(int) Math.ceil((double) total / size)，这时反而要接受浮点误差，并在前端做兼容（例如对结果+ 0.000001再 ceil）
React 中避免重复计算和状态漂移
如果 total 和 pageSize 来自 props 或 state，别在 render 里直接调用 getTotalPages，尤其当它被用于生成页码数组：
const totalPages = useMemo(() => getTotalPages(total, pageSize), [total, pageSize]);
否则每次 re-render 都执行，且若 total 是异步加载的初始值（如 undefined 或 null），函数内没判空就会报 NaN，导致整个组件崩溃。更稳妥的是在数据加载完成后再计算，或在自定义 Hook 里封装校验逻辑。
真正容易被忽略的，是「谁负责定义 0 条数据对应的页数」——它不是数学问题，而是前后端契约问题。一旦定下规则，所有地方（分页组件、接口 mock、测试用例）都得同步，而不是靠某个 Math.ceil 调用来“碰运气”。
