配置是后端服务里最容易被低估的部分。初学者常常先把端口、数据库地址、超时时间写死在代码里，等部署到不同环境时再匆忙改成环境变量。结果是默认值散落各处，启动时不校验，线上才发现某个配置拼错了。
一个清楚的配置系统不一定复杂。小型 Go 服务可以用结构体表达配置，用默认值提供本地体验，用环境变量覆盖部署差异，再在启动阶段做一次校验。本文用一个 HTTP 服务配置做例子。
定义配置结构
先把配置集中成结构体：
type Config struct {
HTTPAddr string
DatabaseURL string
ReadTimeout time.Duration
WriteTimeout time.Duration
ShutdownTimeout time.Duration
Debug bool
}
字段名要表达业务含义，而不是直接等于环境变量名。环境变量是外部接口，结构体是程序内部模型。两者可以映射，但不要完全绑死。
默认值
默认值让本地开发更轻松：
func DefaultConfig() Config {
return Config{
HTTPAddr: ":8080",
ReadTimeout: 5 * time.Second,
WriteTimeout: 10 * time.Second,
ShutdownTimeout: 15 * time.Second,
Debug: false,
}
}
注意 DatabaseURL 没有默认值。因为数据库地址通常必须由环境决定，随便给一个默认值可能连到错误数据库。默认值不是越多越好。适合默认的是端口、超时、开关这类本地可接受的值；密钥、生产数据库、外部服务凭证应该显式提供。
从环境变量覆盖
可以写一个小 loader：
func LoadConfigFromEnv() (Config, error) {
cfg := DefaultConfig()
if v := os.Getenv("HTTP_ADDR"); v != "" {
cfg.HTTPAddr = v
}
if v := os.Getenv("DATABASE_URL"); v != "" {
cfg.DatabaseURL = v
}
if v := os.Getenv("DEBUG"); v != "" {
debug, err := strconv.ParseBool(v)
if err != nil {
return Config{}, fmt.Errorf("parse DEBUG: %w", err)
}
cfg.Debug = debug
}
if v := os.Getenv("READ_TIMEOUT"); v != "" {
d, err := time.ParseDuration(v)
if err != nil {
return Config{}, fmt.Errorf("parse READ_TIMEOUT: %w", err)
}
cfg.ReadTimeout = d
}
if err := cfg.Validate(); err != nil {
return Config{}, err
}
return cfg, nil
}
这里没有引入配置库，是为了看清楚基本流程：先默认值，再环境变量覆盖，再校验。项目变大后可以换成库，但这个顺序仍然适用。
启动校验
配置校验应该在服务启动时完成：
func (c Config) Validate() error {
if c.HTTPAddr == "" {
return errors.New("HTTPAddr is required")
}
if c.DatabaseURL == "" {
return errors.New("DatabaseURL is required")
}
if c.ReadTimeout <= 0 {
return errors.New("ReadTimeout must be positive")
}
if c.WriteTimeout <= 0 {
return errors.New("WriteTimeout must be positive")
}
if c.ShutdownTimeout <= 0 {
return errors.New("ShutdownTimeout must be positive")
}
return nil
}
不要等到第一个请求进来时才发现数据库地址为空。启动失败虽然直接，但比带着错误配置运行更安全。日志里也应该明确写出哪个配置不合法。
在 main 中使用
main 里加载配置，然后传给各个组件：
func main() {
cfg, err := LoadConfigFromEnv()
if err != nil {
log.Fatal(err)
}
server := &http.Server{
Addr: cfg.HTTPAddr,
Handler: routes(),
ReadTimeout: cfg.ReadTimeout,
WriteTimeout: cfg.WriteTimeout,
}
log.Printf("listen addr=%s debug=%v", cfg.HTTPAddr, cfg.Debug)
if err := server.ListenAndServe(); err != nil && err != http.ErrServerClosed {
log.Fatal(err)
}
}
不要在业务函数里到处 os.Getenv。那样配置来源会散落到项目各处，测试也会变困难。配置应该在启动阶段读取一次，然后作为结构体传给需要它的组件。
测试配置读取
Go 的 testing.T 提供了 t.Setenv：
func TestLoadConfigFromEnv(t *testing.T) {
t.Setenv("DATABASE_URL", "postgres://example")
t.Setenv("HTTP_ADDR", ":9090")
t.Setenv("READ_TIMEOUT", "2s")
cfg, err := LoadConfigFromEnv()
if err != nil {
t.Fatal(err)
}
if cfg.HTTPAddr != ":9090" {
t.Fatalf("HTTPAddr = %q", cfg.HTTPAddr)
}
if cfg.ReadTimeout != 2*time.Second {
t.Fatalf("ReadTimeout = %s", cfg.ReadTimeout)
}
}
t.Setenv 会在测试结束后恢复环境变量，避免测试互相污染。不要手动改全局环境后忘记恢复。配置测试通常不复杂，但非常值得写，因为部署问题很多都来自这里。
配置命名要稳定
环境变量名一旦被部署脚本、容器平台、文档使用，就不宜频繁变化。建议使用清楚、稳定、带项目前缀的名字，比如：
APP_HTTP_ADDR=:8080
APP_DATABASE_URL=postgres://...
APP_READ_TIMEOUT=5s
前缀可以减少和系统环境变量冲突。时间配置建议用 Go 支持的 duration 字符串，如 500ms、5s、1m，比裸数字更不容易误解。裸数字到底是秒还是毫秒，迟早会让人犯错。
不要把密钥打印到日志
启动日志可以打印端口、debug 开关、超时，但不要打印数据库密码、API token、私钥。即使日志系统权限严格，也不要把敏感信息当普通文本传播。可以打印“是否已配置”：
log.Printf("database configured=%v", cfg.DatabaseURL != "")
更严格的做法是把敏感配置单独建类型，避免默认格式化时泄漏。入门阶段至少要养成习惯：日志里不出现完整密钥。
小结
Go 服务配置可以从简单结构开始：DefaultConfig 提供合理默认值，环境变量覆盖部署差异，Validate 在启动阶段阻止错误配置进入运行态。业务代码不要到处读取环境变量，而是接收已经解析好的配置结构。
配置系统的目标不是花哨，而是可预期。默认值清楚、命名稳定、类型转换明确、启动失败及时，服务上线后就少很多低级事故。
继续阅读
探索更多技术文章
浏览归档，发现更多关于系统设计、工具链和工程实践的内容。