goland测试中需通过run configuration手动配置命令行参数或环境变量，而非硬编码；flag方式须在测试函数内显式调用flag.parse()，环境变量推荐使用t.setenv()（go 1.17+）保障隔离。
GoLand 测试中无法直接载入外部配置文件，是因为 go test 不自动传递命令行参数或环境变量——你得手动配运行/调试配置，否则 loadConfig() 读到的永远是空字符串或默认路径。
测试时传配置路径必须用 Run Configuration，不是改代码
很多人在 TestXxx 函数里硬编码 os.Setenv("CONFIG_PATH", "test.yaml")，这看似能跑通，但实际掩盖了两个问题：一是环境变量污染（多个测试并发时互相干扰），二是脱离真实启动场景（生产是靠 -config 参数或环境变量启动的）。GoLand 的正确做法是把参数/环境变量声明在「运行配置」里，和 go run main.go -config=config.yaml 行为一致。
- 右键点击测试函数名 → Debug 'TestXxx' 或 Run 'TestXxx'
- 首次运行会生成临时配置，点击右上角下拉框旁的
⚙️图标 → Modify Run Configuration - 在 Program arguments 输入框填：
-config=./testdata/config.yaml（如果代码用flag.String("config", ...)） - 或在 Environment variables 输入框填：
CONFIG_PATH=./testdata/config.yaml（如果代码用os.Getenv("CONFIG_PATH")） - 勾选 Include tests 和 Working directory 设为项目根目录（确保相对路径解析正确）
flag 解析必须在测试函数里显式调用 flag.Parse()
很多测试失败是因为只声明了 var configPath = flag.String("config", "config.yaml", "")，却没在 TestXxx 开头调用 flag.Parse()。Go 的 flag 包不会自动解析测试上下文里的命令行参数——它只认 os.Args，而 GoLand 传入的参数已写进 os.Args，但不调用 flag.Parse() 就等于没读。
使用ydata-profiling（前身为pandas-profiling）生成全面的数据质量报告，包含相关性分析、缺失值模式和基数检测。导出交互式HTML仪表板和JSON摘要。
- 测试函数开头必须加：
flag.Parse() - 不能放在
init()或包级变量初始化里，因为测试是单独进程，init()执行时机不可控 - 如果用了多个 flag（比如
-env、-log-level），全部要在同一处flag.Parse()后读取 - 示例片段：
func TestLoadConfig(t *testing.T) { flag.Parse() // 必须有 path := *configPath cfg, err := loadConfig(path) if err != nil { t.Fatal(err) } // ... }
环境变量方式要注意测试间隔离
用 os.Setenv 在测试里设环境变量，看似简单，但 go test -parallel 下极易出错：A 测试设了 CONFIG_PATH=a.yaml，B 测试还没读就覆盖成 b.yaml，结果 A 读到的是 B 的值。这不是 GoLand 的问题，是 Go 测试并发模型本身的限制。
- 若坚持用环境变量，每个测试开头加：
t.Setenv("CONFIG_PATH", "./testdata/a.yaml")（Go 1.17+ 支持，自动清理） - 旧版本 Go 或需手动
defer os.Unsetenv("CONFIG_PATH")，且必须在os.Setenv后立即 defer，否则可能被其他测试抢先修改 - 避免在
init()或全局变量里读取环境变量——它只在包加载时执行一次，后续测试全共享同一个值 - 推荐优先用 flag 方式，语义更清晰，也和 main 启动逻辑一致
真正容易被忽略的点是：GoLand 的「临时配置」每次右键 Run/Debug 都会新建一个，改完参数后不点保存，下次运行就还原成默认值；而永久配置一旦保存，所有同名测试都复用它——如果你有多个测试依赖不同配置文件，得为每个建独立的永久配置并命名清楚，比如 TestLoadProdConfig 和 TestLoadDevConfig。
