gorm无内置cli分页命令，goreleaser与此无关；终端分页应由shell层处理（如go run main.go | less -r），后端需用limit/offset或游标分页安全切片数据并校验参数。
goreleaser 无法识别 GORM CLI 工具的分页命令
GORM 官方并没有提供内置的命令行工具（CLI），更不存在原生支持终端分页的 gorm 命令。如果你在终端里运行类似 gorm migrate 或 gorm dbinfo 并期待它自动分页，那大概率是误用了第三方封装或混淆了其他工具（比如 golang-migrate 或自研脚本）。goreleaser 是 Go 项目发布工具，和 GORM 运行时行为完全无关——它不会、也不能干预 CLI 分页逻辑。
想在 Go 程序中用 GORM 输出带分页的终端列表？自己加 less 或 more
Go 本身不处理终端分页，得靠 shell 层。最轻量且可靠的做法是：让程序输出纯文本（如 JSON 或表格格式），由用户自己用管道交给分页器。例如：
go run main.go list-users | less -R
注意点：
-
less -R能正确渲染 ANSI 颜色（如果你用github.com/olekukonko/tablewriter渲染表格） - 不要在 Go 程序里调用
exec.Command("less", ...)—— 这会阻塞 stdin/stdout，导致交互异常，尤其在管道场景下直接失效 - 若需默认分页（即不加管道也分页），可检测
os.Stdout.Fd()是否为终端：isTerminal := isatty.IsTerminal(os.Stdout.Fd())，但仅作提示，仍应把分页交给用户控制
用 github.com/charmbracelet/bubbletea 做真终端分页？不推荐用于 GORM CLI 场景
虽然 bubbletea 可以实现带滚动、搜索、高亮的交互式列表，但它面向的是 TUI（Text-based User Interface）应用，不是传统 CLI 工具。对 GORM 来说：
- 它需要接管整个终端，和
grep、jq等管道链路天然冲突 - 每个分页动作都要查一次数据库（比如每次按 ↓ 加载下 20 条），容易触发 N+1 查询，除非你提前用
OFFSET/LIMIT+ 总数预估 - GORM 的
Limit().Offset()在 MySQL/PostgreSQL 行为一致，但在 SQLite 中OFFSET性能差，大数据集慎用
真正该关心的：分页参数怎么传给 GORM 查询
终端分页只是展示层，核心是后端如何安全、高效地切片数据。常见错误是把页码当偏移量硬算：offset = (page - 1) * size，却忽略总数校验和边界处理：
- 永远用
Count()先查总数（或用估算值），避免用户翻到空页还显示“无数据”却不告知已到底 - 对恶意输入（如
page=9999999）要截断，GORM 不会自动防护，得自己做if page - 用
SELECT COUNT(*)比SELECT *+ len() 更准，尤其涉及 JOIN 或 WHERE 过滤时 - PostgreSQL 可考虑
cursor-based pagination（用上一页最后 ID + WHERE id > ? LIMIT N），比 offset 更稳定
分页不是加个 | less 就完事；真正的复杂点在 offset 边界、总数一致性、以及不同 SQL 引擎对 LIMIT/OFFSET 的解释差异。别让终端看起来能翻页，结果后端查了全表再切片。
