应使用 os.LookupEnv 替代 os.Getenv 判断环境变量是否存在，因其返回 (value string, exists bool) 可明确区分未设置与设为空；.env 文件需严格遵循格式规范，避免空格、引号、行内注释等错误；HTTP Server 必须显式设置 Read/Write/Idle 超时；goroutine 必须接收并监听 context.Done() 以防止泄漏。
os.Getenv 会静默返回空字符串，别直接用
关键配置缺失时，os.Getenv 不报错也不提示，而是返回空字符串，导致服务在后续逻辑中 panic 或连错数据库。这不是“没设环境变量”，而是 Go 标准库的设计选择——它不区分“未设置”和“设为空”。
- 用
os.LookupEnv替代：它返回(value string, exists bool)，能明确判断变量是否存在 - 对必填项（如
DB_HOST、REDIS_URL）必须检查exists，而不是只判空字符串 - 避免写
if os.Getenv("FOO") == ""—— 这无法区分是值为空，还是根本没设 - Kubernetes 中滚动更新时环境变量可能短暂丢失，
LookupEnv+ 日志告警比静默容忍更早暴露问题
环境变量注入到容器时，.env 文件格式极易出错
Docker Compose 或本地开发用 .env 文件加载变量时，看似简单的键值对，实际解析器（比如 godotenv）对格式极其敏感，一个空格或引号就能让整个配置失效。
-
DB_HOST=localhost✅ 正确；DB_HOST = localhost❌ 等号两侧有空格 → 解析失败 -
PASSWORD=secret123✅；PASSWORD="secret123"❌ 引号会被当作文本一部分，导致密码含双引号 - 注释必须独占一行：
# this is ok✅；KEY=value # inline comment❌ 多数解析器不支持行内注释 - 多行值不被原生支持，不要试图写
MULTILINE=first\nsecond—— 换成 base64 编码或拆成多个变量
HTTP Server 缺少超时设置，连接池会悄无声息耗尽
Go 的 http.Server 默认所有超时都是 0（即无限），在生产环境中极易因客户端异常断连、网络抖动或慢请求堆积，最终占满文件描述符或连接数。
Golang Spf13 Viper
下载
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
- 必须显式设置三类超时：
ReadTimeout（读请求头）、WriteTimeout（写响应体）、IdleTimeout（空闲连接保持） - 数值要匹配业务节奏：例如 API 响应通常
WriteTimeout: 10 * time.Second，后台任务接口可放宽到 60 秒 - 别依赖反向代理（如 Nginx）的超时兜底——Go 应用自身应具备独立防护能力
- 使用
http.TimeoutHandler对单个 handler 做更细粒度控制，但不能替代 Server 级超时
goroutine 启动后没加 context 控制，泄漏几乎必然发生
微服务里大量 HTTP handler 内部启动 goroutine 处理异步任务（如发消息、记日志、调下游），一旦父请求 cancel 或超时，这些 goroutine 却继续运行，内存和 goroutine 数持续增长。
立即学习“go语言免费学习笔记（深入）”；
- 永远不要写
go doSomething()—— 必须传入ctx context.Context - 在 goroutine 内部用
select监听ctx.Done()，收到信号就退出 - 避免在 goroutine 中直接关闭 channel —— 多个 goroutine 可能同时 close 同一个 channel，触发 panic
- 用
sync.WaitGroup等待 goroutine 结束仅适用于已知数量且生命周期可控的场景，不适合请求驱动型服务
真正难的不是写出能跑的代码，而是让代码在流量高峰、节点故障、配置漂移时仍保持行为可预期。环境变量、超时、context、channel 这四类问题，在日志里往往只表现为“服务变慢”或“OOM”，但根因全在启动那一刻的几行配置和并发逻辑里。
