关键不是“怎么配”，而是“怎么确保测试时用的是CI里真实跑起来的那个库”：容器网络中需用服务别名（如mysql）而非localhost，且必须显式等待端口就绪、通过环境变量覆盖配置、在测试函数中安全读取DB_HOST。
CI中如何让测试代码连接到Docker启动的数据库
关键不是“怎么配”，而是“怎么确保测试时用的是CI里真实跑起来的那个库”。硬编码localhost:5432在CI里必然失败——容器网络里没有localhost这个概念，得用服务别名。
GitLab CI示例中，services下定义的mariadb:latest会被自动分配别名mysql，应用代码必须通过这个别名连接：
DB_HOST=mysql DB_PORT=3306
Spring Boot或Go这类框架，要让DB_HOST被实际读取，需确认：
-
application-test.yml里不能写死localhost，应留空或设为占位符，如${DB_HOST:localhost} - 环境变量优先级高于配置文件（Spring Boot默认规则），所以CI中设置
DB_HOST=mysql就足够覆盖 - Go项目若用
os.Getenv("DB_HOST")，必须确保该变量在容器启动前已注入，而非仅在script阶段设置
为什么Flyway在CI里总连不上数据库
常见错误是迁移脚本执行早于数据库容器就绪。Flyway启动时发现Connection refused，不是配置错，是时机错。
解决方法不是加重试逻辑，而是控制依赖顺序：
- GitLab CI用
services声明数据库，但需显式等待其监听端口可用，例如：while ! nc -z mysql 3306; do sleep 1; done - Testcontainers-go中，
Started: true已隐含等待，但若手动调用container.MappedPort(ctx, "3306/tcp")获取端口，必须在Started之后 - Flyway配置中
flyway.url不能写jdbc:mysql://localhost:3306/...，而要用jdbc:mysql://mysql:3306/...（对应服务别名）
Spring Boot profile和环境变量混用时谁生效
环境变量永远赢。哪怕application-prod.yml写了spring.datasource.url=jdbc:mysql://prod-server:3306/db，只要CI里设了SPRING_DATASOURCE_URL=jdbc:mysql://mysql:3306/test_db，后者就会生效。
这既是优势也是陷阱：
- CI中用
SPRING_PROFILES_ACTIVE=test激活application-test.yml，再用SPRING_DATASOURCE_URL覆盖其中的URL，是最干净的组合 - 避免在
application-test.yml里写具体IP或端口，只保留数据库名、用户名等不随环境变的部分 - 如果用了
spring.config.import导入optional:file:./config.yml，注意该文件里的值仍会被环境变量覆盖
Go测试里怎么安全读取CI传入的数据库地址
不要在init()里直接os.Getenv("DB_HOST")，因为测试包初始化顺序不可控，且go test可能并行运行多个包。
推荐做法是每个测试函数自己拉取：
func TestUserHandler_Create(t *testing.T) {
dbHost := os.Getenv("DB_HOST")
if dbHost == "" {
t.Fatal("DB_HOST not set — run with 'DB_HOST=mysql' in CI")
}
// 构建DSN：fmt.Sprintf("user:pass@tcp(%s:3306)/test_db", dbHost)
}
更健壮的方式是封装成测试辅助函数，并统一处理缺失时的panic提示，避免不同测试各自重复判断。
真正容易被忽略的点是：CI环境变量注入时机。某些Runner（如shared runner）可能在shell session启动后才加载变量，而Go测试进程若由Makefile间接调起，需确认变量是否透传——最稳妥是把env显式写进.gitlab-ci.yml的variables块，而非只靠script里export。
