Xorm 事务需手动管理资源，Begin() 后必须 defer tx.Close() 防连接泄漏；Insert/Update 返回 (int64, error)，Get 返回 (bool, error)；不支持嵌套事务自动回滚，Commit 失败后 MySQL 需显式 Rollback。
Xorm 能直接替代 GORM 做事务管理，但接口风格和错误处理逻辑完全不同，不能简单替换函数名就完事。
为什么 Xorm 的 Begin() 必须搭配 defer tx.Close()
Xorm 的事务对象是 *xorm.Session，不是无状态的链式调用器。它内部持有数据库连接和事务上下文，不显式关闭会导致连接泄漏——尤其在微服务长连接场景下，很容易触发 too many connections 错误。
-
tx := engine.NewSession()后必须defer tx.Close()，否则即使事务已提交，连接也不会归还到池中 -
tx.Begin()失败时，tx.Close()仍需执行，否则该 session 占用的连接会一直卡住 - 不要把
tx传给其他函数再操作，Xorm 不像 GORM 那样支持跨函数复用事务对象
tx.Insert() 和 tx.Update() 返回值含义与 GORM 不同
GORM 的 Create() 或 Save() 返回的是 *gorm.DB，错误藏在 .Error 字段；Xorm 的 Insert()、Update() 等方法直接返回 (int64, error)，第一个值是影响行数，第二个才是错误。
- 写法必须是：
_, err := tx.Insert(&user)，不是err := tx.Insert(&user).Error -
tx.Get()返回(bool, error)，表示“是否查到”，不是error单独返回 - 批量插入用
tx.Insert(&users)（切片），但要注意单次最多约 1000 条，超限可能触发 MySQL packet too large
微服务中嵌套事务失败时，Xorm 不支持自动回滚上层
Xorm 没有类似 GORM 的 db.Transaction() 函数封装，所有事务控制都是手动的。如果 A 函数开启事务并调用 B 函数，B 函数又自己开新事务，那两个事务完全独立——B 回滚不影响 A，A 提交也不代表 B 已提交。
立即学习“go语言免费学习笔记（深入）”；
- 微服务常见模式（如订单创建含库存扣减+日志记录）必须把所有操作写在同一个
tx上，不能拆到多个函数里各自Begin() - 若需复用逻辑，应把数据操作封装为接受
*xorm.Session参数的函数，例如：func deductStock(tx *xorm.Session, sku string, qty int) error - 没有上下文传播机制，
context.Context无法透传事务对象，别指望靠中间件自动注入tx
MySQL 和 PostgreSQL 下 tx.Commit() 的兼容性差异
Xorm 对不同数据库的事务行为封装并不完全一致。PostgreSQL 在 tx.Commit() 失败后会自动 rollback，而 MySQL 不会——它只返回 error，但底层事务仍处于 open 状态，下次用这个 tx 会报 invalid transaction state。
- 务必在
tx.Commit()后检查 error，并显式调用tx.Rollback()（即使刚 commit 过） - 推荐统一写法：
if err := tx.Commit(); err != nil { tx.Rollback(); return err } - SQLite 在某些版本中不支持 savepoint，嵌套
tx.Begin()会 panic，生产环境慎用
真正麻烦的不是语法转换，而是 GORM 那套“隐式事务生命周期”思维惯性——Xorm 把事务当成一个需要你亲手掐断的资源，漏掉任何一环都可能让连接、锁、事务状态卡死在数据库侧。
