Go程序依赖环境变量动态配置，需确保正确加载与校验；开发用godotenv加载.env，生产由系统级方式注入；推荐用env库绑定结构体并校验必填项与类型。
Go 程序本身不强制依赖环境变量，但绝大多数生产服务（数据库连接、API密钥、日志级别、监听端口等）都靠 os.Getenv 读取环境变量来动态配置。配置错或漏了，程序常会 panic 或静默失败——比如连不上数据库却只报 "connection refused"，根本看不出是 DB_HOST 没设。
用 os.Getenv 读取前必须确认变量已加载
Go 不自动加载 .env 文件，也不读 shell 的 export 声明（除非你是在该 shell 下启动程序）。常见错误是本地写好 .env 就直接 go run main.go，结果 os.Getenv("PORT") 返回空字符串。
- 开发时最稳妥的方式：用
direnv或手动source .env && go run main.go - 部署时确保启动命令在正确环境中执行，例如 systemd service 文件里用
EnvironmentFile=/etc/myapp/env - 绝对不要在代码里写
os.Setenv("DEBUG", "true")来“模拟”环境变量——它只对当前进程及子进程生效，且容易被后续覆盖
用 github.com/joho/godotenv 加载 .env 文件（仅限开发）
这个库只应在开发阶段使用，它会把 .env 中的键值对调用 os.Setenv 注入进程。线上环境应由运维通过系统级方式注入，而非让 Go 程序自己读文件。
import (
"log"
"os"
"github.com/joho/godotenv"
)
func init() {
if os.Getenv("ENV") != "prod" {
if err := godotenv.Load(); err != nil {
log.Println("No .env file found, skipping")
}
}
}
- 注意
godotenv.Load()默认读.env，可传路径如godotenv.Load(".env.local") - 它不会覆盖已存在的环境变量，所以
export PORT=8080 && go run main.go仍以 shell 设置为准 - 别把它用在容器镜像构建阶段——Dockerfile 中
RUN go run会把密钥硬编码进镜像层
用结构体 + mapstructure 统一解析和校验
直接满屏 os.Getenv 很难维护，也缺乏类型和必填校验。推荐用 mapstructure 把环境变量解码到结构体，并配合 env 库（如 github.com/caarlos0/env）做自动绑定。
立即学习“go语言免费学习笔记（深入）”；
type Config struct {
Port int `env:"PORT" envDefault:"8080"`
DBHost string `env:"DB_HOST" envRequired:"true"`
LogLevel string `env:"LOG_LEVEL" envDefault:"info"`
}
var cfg Config
if err := env.Parse(&cfg); err != nil {
log.Fatal(err)
}
-
envRequired:"true"能在启动时立刻报错，而不是等到第一次查数据库才崩 - 数值型字段（如
int,bool）自动转换，不用自己调strconv.Atoi - 避免手写重复的
if val := os.Getenv(...); val == "" { ... }校验逻辑
容器和 CI/CD 中的典型陷阱
Docker 和 GitHub Actions 容易让人误以为环境变量“写了就生效”。实际中高频出问题的是作用域和时机。
- Dockerfile 中
ENV FOO=bar是构建期环境变量，对go build有效；但运行时要用docker run -e BAR=baz或--env-file才能传给二进制 - GitHub Actions 的
env:块只对当前 step 生效，跨 job 必须用outputs+needs - Kubernetes 中
envFrom: configMapRef和env:顺序会影响覆盖行为——后者优先级更高
环境变量不是“设了就完事”，关键在它被谁、何时、以什么作用域注入到 Go 进程。本地跑通不等于上线可靠，尤其当不同环境用不同方式注入时，最容易漏掉某一层的传递。
