用 -p=1 强制包级串行可解决跨包数据库冲突，因默认并行导致多包共用同一 PostgreSQL 实例而互相干扰；-parallel 0 或 -cpu 1 仅限单包内并发控制，无效于包间隔离。
用 -p=1 强制包级串行，解决跨包数据库冲突
Go 测试互相影响，最常见就是多个包（比如 ./pkg/user 和 ./pkg/order）同时跑 go test，抢同一个 PostgreSQL 实例，报错如 ERROR: relation "users" does not exist。这不是你代码写错了，而是默认并行让它们在同一个 DB 上建表、删表、清数据，互相踩脚。
-parallel 0 或 -cpu 1 没用——它们只控制单个包内测试函数的并发，不拦包间并行。真正能切断包间干扰的，只有 -p=1：
-
go test -p=1 ./pkg/...：一次只构建并运行一个包，等它所有测试结束再切下一个 - 适用场景：所有依赖共享外部资源（PostgreSQL / Redis / 临时目录）的集成测试包
- CI 中建议固定加这个参数，尤其当测试用的是本地或共享 DB 时
用 //go:build integration 标签物理隔离测试类型
单元测试不该连数据库，但又不能删掉集成测试代码——靠环境变量开关（比如 if os.Getenv("INTEGRATION") == "1"）是危险的：它无法阻止编译期初始化，init() 里连 DB 的逻辑照常执行，全局连接池早就在进程里建好了。
构建标签是在编译阶段就把文件剔除，从源头隔离：
立即学习“go语言免费学习笔记（深入）”；
- 给集成测试文件加注释：
//go:build integration，且必须空一行后接package xxx - 运行时显式选择：
go test .只跑单元测试；go test --tags=integration .才加载集成测试 - 避免同一包下多个文件带相同 tag，否则编译报错
duplicate definition
每个测试自己管状态：别信 init()，也别复用全局 *sql.DB
Go 测试复用进程，init() 只执行一次，但全局变量不会自动重置。前一个测试把计数器加到 5，后一个测试断言 0 就必然失败。
正确做法是“每个测试自给自足”：
- 临时目录用
os.MkdirTemp("", "test-*")动态生成，结尾配defer os.RemoveAll(tempDir) - 数据库连接每次新建：
db := setupTestDB(t)，结尾defer db.Close() - 绝对不要在
init()里初始化可变状态（缓存 map、HTTP transport、计数器） - 如果用 Yaegi 等解释器，更要为每个测试启动独立实例——文件级隔离靠的是进程边界，不是函数作用域
事务回滚比内存 SQLite 更真实，但要注意 DDL 限制
对业务逻辑验证，用真实数据库 + 事务包裹是最轻量可靠的隔离方式。每个测试开始前 db.Begin()，结束强制 tx.Rollback()，哪怕 panic 也不留脏数据。
但得清楚它的边界：
- PostgreSQL 不支持在事务内执行
CREATE DATABASE、CREATE EXTENSION等 DDL，这类操作要提前在测试外准备 schema - SQLite 的
:memory:模式虽快且天然隔离，但无法覆盖jsonb、ILIKE、物化视图等 PG 特性，仅适合 CRUD 逻辑初筛 - 业务函数应接受
Querier接口（如interface{ QueryContext(), ExecContext() }），而非硬绑*sql.DB，才能自然注入*sql.Tx
最易被忽略的一点：事务回滚本身不是魔法，它依赖你的业务代码真的只用了传入的 tx。如果 DAO 层偷偷又 new 了一个全局 db 去查，那回滚就形同虚设。
