<p>math.Ceil 返回 float64 是因数学精度设计，但分页需整数；应使用 (total + pageSize - 1) / pageSize 实现无误差向上取整，避免浮点误差与类型转换问题。</p>
math.Ceil 为什么返回 float64，而分页需要 int？
因为 math.Ceil 和 math.Floor 的设计目标是数学精度，它们统一返回 float64。但分页场景中，总页数、当前页码、偏移量这些都必须是整数——直接用 int(math.Ceil(x)) 看似可行，却容易在边界上出错：比如 math.Ceil(10.0) 返回 10.0，转 int 没问题；但浮点计算误差可能导致 9.999999999999998 被 ceil 成 10.0，也可能出现 10.000000000000002 这种“本该是整数却略大”的情况。稳妥做法是先加一个小 epsilon 再截断，或改用整数运算。
用整数除法代替 math.Ceil 实现向上取整分页
假设每页 pageSize = 20，总记录数 total = 57，要算总页数：用 math.Ceil(float64(total)/float64(pageSize)) 不如直接写 (total + pageSize - 1) / pageSize。这是经典的无浮点、无误差向上取整技巧，前提是 total >= 0 且 pageSize > 0。
常见错误现象：total = 0 时，该表达式结果为 0（合理）；但若误写成 (total - 1) / pageSize + 1，total = 0 会触发负数除法，结果为 -1（Go 中负数除法向零截断）。
- 确保
pageSize是正整数，否则除零 panic 或逻辑错乱 - 如果
total可能为负（极少见），需额外判断，一般分页不考虑 - 该方法比
math.Ceil快，且完全避免浮点精度和类型转换开销
math.Floor 在分页里基本没用，除非你手动算 offset
math.Floor 对分页本身几乎无直接价值。你不会说“第 math.Floor(3.9) 页”，而是用它辅助算偏移量：比如前端传了页码 page = 3.7，你想安全转成第 3 页，才用 int(math.Floor(page))。但更常见也更健壮的做法是直接用整数类型接收参数，或用 strconv.Atoi + 错误检查。
真正关键的 offset 计算应始终基于整数：offset = (page - 1) * pageSize，其中 page 已校验为 ≥1 的整数。若硬要用 math.Floor，务必注意：
-
math.Floor(-1.2)返回-2.0，不是-1.0，负页码会彻底错乱 - 永远先做范围校验：
if page ，别依赖 floor “兜底” - 数据库 LIMIT/OFFSET 场景下，offset 必须 ≥0，否则 PostgreSQL 报错，MySQL 可能静默忽略
完整分页计算示例：安全、可读、无浮点
以下是一个生产可用的分页参数处理片段（省略输入校验，仅聚焦计算逻辑）：
func calcPagination(total, pageSize, page int) (totalPages, offset, limit int) {
if pageSize <= 0 {
pageSize = 20
}
if page <= 0 {
page = 1
}
totalPages = (total + pageSize - 1) / pageSize
if totalPages == 0 {
totalPages = 1 // 至少有 1 页，即使 total == 0
}
offset = (page - 1) * pageSize
limit = pageSize
return
}注意 totalPages = 1 的兜底——空列表仍需返回第 1 页，否则前端可能卡死。这个细节常被忽略，但 API 设计上必须明确语义：页码从 1 开始，且第 1 页永远存在。
