Go go-pretty 的分页大小与实际数据行数有什么区别

Go go-pretty 里的“分页大小”默认不是数据库查询那种“每页几条数据”。table.Table.Length()反映待渲染的数据行数量，而 Pager(PageSize(n)) 的 n 更接近一页允许输出的渲染行预算：一个单元格换成多行时会消耗多个单位，表头和页脚也不会计入这个预算。把这几个概念混在一起，就会出现设置了 10 却没有得到 10 条数据一页的情况。

官方地址：https://github.com/jedib0t/go-pretty

如果目标是让终端用户翻阅已经加载好的长表，使用 Pager；如果目标是让数据库只返回第 3 页的 20 条记录，就应先在业务层切片或查询层使用明确的 offset/limit，再把这一页交给 go-pretty 展示。

先分清三个数量

先把“数据集合”和“输出页面”拆开看。AppendRow 或 AppendRows 把数据放进表对象，Length() 返回当前待渲染的数据行数；它不等于最终输出的物理行数，也不直接告诉你有多少页。

可以用下面这张速查表建立正确的接口预期：

这里的“行”还要注意语境：go-pretty 的渲染器会把一个带换行的单元格拆成多条物理输出线，因此一条逻辑数据行可能占用多条渲染行。表格边框、表头和页脚属于展示结构，不能用它们反推数据条数。

理解页大小为什么不等于数据行数

在 v6 的实现里，分页大小被保存为渲染器的行预算。每渲染一条普通输出线，计数就增加；达到预算且后面仍有内容时，渲染器会补上页边界，并重新画表头。源码还明确说明，页头和页脚行不参与分页计算。

因此，下面这些情况都会让“每页实际数据条数”发生变化：

• 某个单元格因为宽度限制换成两行或更多行，一条数据会占用多个预算单位。
• 数据行主动包含换行符，逻辑行和物理行不再是一对一。
• 表头会在新页重复显示，但它不消耗 PageSize 的行数。
• 最后一页不足预算是正常结果，不会为了凑满数据条数补空数据。

所以 PageSize(4) 更准确的描述是“每页累计到 4 条渲染线后拆页”，不是“每页取 4 个 Row”。如果业务需求是严格的 4 条数据一页，应在进入展示器之前就完成数据切分。

选择 Pager API 还是业务层分页

新版接口优先使用 Pager(PageSize(n))。它返回一个 Pager，负责把完整表格拆成页，并提供 Next、Prev、GoTo、Location 和 Render。这是一份展示层导航契约：数据仍然在同一个 Table 里，页码变化不会重新查询数据。

package main

import (
	"fmt"

	"github.com/jedib0t/go-pretty/v6/table"
)

func main() {
	tw := table.NewWriter()
	tw.AppendHeader(table.Row{"编号", "名称"})
	tw.AppendRows([]table.Row{
		{1, "短行"},
		{2, "内容较长，可能因列宽限制而换行"},
		{3, "第三行"},
		{4, "第四行"},
		{5, "第五行"},
	})

	// PageSize 面向渲染行，不承诺每页固定的数据 Row 数量。
	pager := tw.Pager(table.PageSize(4))
	fmt.Println("当前页:", pager.Location())
	fmt.Println(pager.Render())

	// 示例只展示导航方法；实际交互应由按键或界面状态驱动。
	pager.Next()
	fmt.Println("下一页:", pager.Location())
	fmt.Println(pager.Render())

	// GoTo 使用从 1 开始的页码，调用方应先处理没有数据的业务场景。
	pager.GoTo(1)
	fmt.Println("回到第一页:", pager.Location())
}

示例只用于说明导航接口，不应把页面字符串相等当成通用的业务终止条件：不同页面理论上可能渲染出相同文本。更稳妥的做法是用 Location() 与你掌握的页数状态控制交互，或者在命令行按键事件中直接调用 Next 和 Prev。

如果项目仍使用 SetPageSize，它表达的也是渲染行上限，而且在 v6 API 文档里已标记为 deprecated，迁移时可以改成 Pager(table.PageSize(n))。不要因为更换 API 就把它解释成数据分页。

需要固定数据条数时在业务层分页

报表导出、接口响应或数据库查询通常需要“第几页、每页多少条”的稳定契约，这时把分页做在数据层更清楚。示例只做内存切片，实际项目可以把同样的 page 和 pageSize 转换为查询参数；返回空页、负页码和过大的页大小也要由业务规则决定。

package main

import "github.com/jedib0t/go-pretty/v6/table"

// slicePage 只负责按逻辑数据行切页，不考虑终端换行高度。
func slicePage(rows []table.Row, page, pageSize int) []table.Row {
	if page = len(rows) {
		return nil
	}
	end := start + pageSize
	if end > len(rows) {
		end = len(rows)
	}
	return rows[start:end]
}

func renderDataPage(rows []table.Row) string {
	tw := table.NewWriter()
	// 数据页已经由业务层确定，展示器只负责排版，不再次猜测页数。
	tw.AppendRows(rows)
	return tw.Render()
}

这类代码的边界是明确的：slicePage 决定一页包含哪些逻辑行，renderDataPage 决定这些行如何排版。若某一行最终换成三条终端输出线，业务页仍然只算一条数据；代价是终端上可能出现视觉上的“页很长”。

把过滤、排序和换行边界写进接口说明

go-pretty 的表格还可以过滤和排序。调用方如果先记录总行数、再过滤或排序，得到的页数说明就会过时。建议把数据处理顺序写成一个稳定约定：先确定数据集合，再应用过滤和排序，最后选择展示分页或业务分页。

最后记住三个判断：看到 Length() 时问的是“有多少条逻辑数据”；看到 PageSize 时问的是“每页允许多少条渲染线”；看到 Pager 时问的是“如何读取和导航展示页”。只要先确定需求属于哪一个边界，分页大小和实际数据行数就不会再被混为一谈。

PageSize 能不能直接替代 SQL 的 LIMIT？

不能。它控制 go-pretty 的展示拆页，SQL 的 LIMIT 控制数据库返回多少条记录，两个参数作用层不同。

单元格换行会不会增加数据行数？

不会增加 Table.Length() 的逻辑行数，但会增加渲染时占用的物理行数，所以同一个 PageSize 可能容纳不同数量的数据行。

为什么最后一页看起来更短？

因为页边界按已有渲染内容拆分，剩余内容不足一个页大小时会直接形成最后一页，不会补齐空行。

技术依据：https://pkg.go.dev/github.com/jedib0t/go-pretty/v6/table、https://raw.githubusercontent.com/jedib0t/go-pretty/v6.8.3/table/table.go、https://raw.githubusercontent.com/jedib0t/go-pretty/v6.8.3/table/render.go。