分页查询在分布式事务中不一致，因依赖的“当前数据快照”不存在；GORM的Limit/Offset不锁定行、不注册读操作，Seata AT模式对SELECT无感知，易致跳过或重复记录。
分页查询在分布式事务中为何会不一致
因为分页依赖的“当前数据快照”在分布式事务里根本不存在。GORM 的 Limit() + Offset() 或 Page() 插件，底层只是拼 SQL 的 LIMIT 和 OFFSET，它不锁定任何行、不开启事务级一致性视图，更不会向 Seata 或 Dapr 等协调器注册读操作。一旦其他服务在你两次分页请求之间提交了新数据（比如插入或软删除），OFFSET 20 下一页就可能跳过或重复某条记录。
GORM 分页 + Seata AT 模式下必须避开的写法
Seata 的 AT 模式只保证写操作（INSERT/UPDATE/DELETE）的 undo 日志和回滚能力，对 SELECT 完全无感知——哪怕你在 tm.Begin() 后调用 db.Find()，GORM 也只会走原生 *sql.DB 查询，不会触发全局事务上下文绑定。常见错误包括：
- 直接对未代理的
*gorm.DB实例调用Limit().Offset().Find()，此时 XID 未透传，TC 完全不知道这次查询属于哪个全局事务 - 在 GORM 中用了
Session(&gorm.Session{NewDB: true})创建新会话，导致连接脱离 Seata 的DBProxy代理链 - 用
Raw()执行分页 SQL，绕过了 GORM 的钩子机制，自然也不会被 Seata 拦截
真正能保分页一致的替代方案
不要指望靠事务“锁住”分页结果。可行路径只有两条：用游标分页（cursor-based pagination）替代偏移分页，或把分页逻辑下沉到单体数据库层并显式加 SELECT ... FOR UPDATE（仅限强一致性场景且需确认隔离级别支持）。
- 游标分页要求业务字段有严格单调性（如
created_at+id），GORM 可写成：db.Where("created_at - 若必须用偏移分页且接受短暂不一致，至少确保查询走 Seata 代理：用
datasource.NewDBProxy(gormDB.Statement.ConnPool.(*sql.DB), config)构造代理，再通过gorm.Open(mysql.New(...), &gorm.Config{ConnPool: proxyDB})重建 GORM 实例 - 禁止在分页查询中混用
Transaction()方法——GORM 的Transaction()是本地事务，和 Seata 全局事务 XID 无关，反而容易造成嵌套事务误判
为什么 GORM 的 Count() 在分布式分页里特别危险
Count() 和分页主查询不是原子执行的。你在事务中先 Count() 得到总数 1000，再 Limit(20).Offset(40) 查第 3 页，但中间若有其他服务插入 5 条记录，实际第 3 页数据就已偏移。更糟的是，Seata 不会对 SELECT COUNT(*) 生成任何分支事务日志，所以这个 Count() 结果连“最终一致”都算不上，纯粹是那一刻的瞬时快照。
真正要显示总页数，要么放弃实时精确值（改用“下一页是否存在”布尔判断），要么把 Count() 和主查询放在同一个数据库事务中并加读锁——但这只在单库、低并发、可接受性能损耗时成立，跨服务场景下基本不可行。
