go中无真正嵌套事务，本质是通过savepoint在单个sql.tx上实现局部回滚；需手动执行tx.exec("savepoint sp_name")和tx.exec("rollback to savepoint sp_name")，保存点名须唯一，且仅在事务活跃期内有效。
Go里用sql.Tx实现嵌套事务本质是保存点（savepoint）
Go标准库的database/sql不支持真正的嵌套事务，所谓“嵌套”只是在同一个sql.Tx上手动管理保存点。调用tx.Exec("SAVEPOINT sp_name")才是实际生效的操作，tx.Commit()和tx.Rollback()只作用于整个事务，不会自动回滚到保存点。
如何在sql.Tx中安全创建和回滚到保存点
保存点名必须唯一且符合SQL标识符规则；回滚到保存点后，该点之后的所有操作失效，但事务仍可继续执行其他语句。常见错误是重复使用保存点名导致ERROR: savepoint "xxx" does not exist或意外覆盖。
- 创建保存点：
_, err := tx.Exec("SAVEPOINT sp_user_create") - 回滚到保存点：
_, err := tx.Exec("ROLLBACK TO SAVEPOINT sp_user_create") - 释放保存点（可选，仅PostgreSQL支持）：
_, err := tx.Exec("RELEASE SAVEPOINT sp_user_create") - 注意：MySQL 8.0+ 支持
SAVEPOINT，但不支持RELEASE SAVEPOINT；SQLite支持但不区分大小写保存点名
封装保存点逻辑时容易忽略的边界情况
很多人封装WithSavepoint函数时直接defer回滚，结果在外部事务已Commit()后再执行ROLLBACK TO SAVEPOINT会报错current transaction is aborted（PostgreSQL）或静默失败（MySQL）。根本原因是保存点只在事务活跃期内有效。
- 务必在回滚前检查
tx.Stats().StartTime是否为零值（非活跃）——但这不可靠，更稳妥的是由调用方显式控制生命周期 - 不要在defer中无条件执行
ROLLBACK TO，应结合业务逻辑判断是否需要回滚 - 避免跨goroutine共享同一
sql.Tx并操作不同保存点，可能引发竞态或顺序错乱 - 如果用
pgx等第三方驱动，可用tx.Savepoint("name")方法替代原生SQL，它会自动处理驱动差异
PostgreSQL、MySQL、SQLite对保存点的实际行为差异
不是所有数据库对SAVEPOINT语义一致。例如MySQL在执行ROLLBACK TO SAVEPOINT后，后续语句若出错，ROLLBACK仍会回滚整个事务；而PostgreSQL允许在回滚到保存点后继续提交剩余操作。
- PostgreSQL：
ROLLBACK TO SAVEPOINT后可继续COMMIT，且支持RELEASE SAVEPOINT - MySQL：
ROLLBACK TO SAVEPOINT后若发生新错误，再ROLLBACK会清空全部变更（包括保存点前的） - SQLite：保存点名不区分大小写，且
ROLLBACK TO后不能RELEASE，否则报错no such savepoint - 测试时务必用目标数据库真实执行，不能只依赖mock或内存DB
sql.Tx。一旦父事务Rollback()，所有保存点一并消失。golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
