go 不支持运行时动态 import，必须在编译期通过构建标签（如 //go:build prod）或注册表模式实现环境隔离；推荐用接口+构建标签分离实现，避免环境变量分支和类型断言。
Go 里没有运行时 import，别试图用字符串路径动态加载包
Go 编译期就确定所有依赖，import 是静态声明，不是函数调用。你写 import "net/http"，编译器立刻解析符号、检查类型、链接对象；不存在“根据环境字符串拼出包名再导入”这回事。常见错误是看到 Python 的 importlib.import_module 或 JS 的 import() 动态语法，就想在 Go 里照搬——结果卡在编译报错：import path must be a string literal。
真正能做的，是把不同环境的实现提前写好，再通过接口 + 构建标签（build tag）或初始化逻辑来选载：
- 用
//go:build dev等构建标签控制哪些文件参与编译 - 定义统一接口（如
ConfigLoader），让dev_loader.go、prod_loader.go各自实现，靠构建条件决定最终链接哪个 - 避免在
init()里做环境判断并赋值全局变量——它执行时机不可控，且跨包初始化顺序难保证
用构建标签（build tags）分离环境相关代码更可靠
比起运行时 if-else 判断 os.Getenv("ENV")，构建期切包更干净：编译出来的二进制不带无关逻辑，无反射开销，也杜绝了误读环境变量导致加载错实现的问题。
典型结构：
立即学习“go语言免费学习笔记（深入）”；
// loader_dev.go
//go:build dev
package config
func NewLoader() Loader { return &devLoader{} }
// loader_prod.go
//go:build prod
package config
func NewLoader() Loader { return &prodLoader{} }
编译时指定：go build -tags=prod，只有 loader_prod.go 被纳入。注意两点：
- 每个文件顶部的构建注释必须是第一行非空非注释行，且格式严格为
//go:build xxx（Go 1.17+ 推荐写法） - 多个标签用逗号连接，如
//go:build linux,amd64；用!表示取反，但慎用，容易漏掉隐式依赖 - 不要混用旧式
// +build和新式//go:build，go tool 会忽略后者
如果真要“模拟”动态加载，用 map[string]func() interface{} + 初始化注册
某些场景（比如插件式配置后端：etcd / file / vault）需要运行时选实现，又不想暴露具体类型。这时可建一个注册表，在各实现包的 init() 函数里登记自己：
// config/loader.go
var loaders = make(map[string]func() Loader)
func Register(name string, fn func() Loader) {
loaders[name] = fn
}
func GetLoader(name string) Loader {
if f, ok := loaders[name]; ok {
return f()
}
panic("unknown loader: " + name)
}
// config/loader_file.go
func init() {
Register("file", func() Loader { return &fileLoader{} })
}
关键约束：
- 所有实现包必须被 main 包显式 import（哪怕只写
_ "myapp/config/loader_file"），否则init()不触发，注册不会发生 - 不能用
import . "xxx"，会导致命名冲突；用空白导入最安全 - 注册名大小写敏感，建议统一小写加下划线，避免配置文件里写错
- 这种模式绕过了编译期检查——如果某 loader 实现漏注册，错误只在运行时暴露
环境变量 + 类型断言不是配置策略，是临时补丁
有人把不同环境的配置结构体全写进一个包，靠 os.Getenv("ENV") == "prod" 分支返回不同 struct，再用类型断言强转——这会让代码迅速失控。问题不止于难测试：
- IDE 失去类型提示，
cfg.Timeout在 dev 下存在、prod 下不存在？编辑器无法校验 - JSON/YAML 解析时字段缺失默认零值，但业务逻辑可能依赖非零默认，而你根本没意识到 prod 配置里漏写了那个字段
- 单元测试必须 mock
os.Getenv，且每个测试都要覆盖所有分支，维护成本指数上升
正确做法是：每个环境对应一份独立的配置结构体（哪怕字段高度重合），用专用解析函数加载，再通过接口向上抽象。复杂点不在“怎么选”，而在“怎么让不同环境的差异收敛到最小、可验证、不污染主逻辑”。
