最有效的做法是从开发流程源头切断明文泄露路径：用 godotenv 隔离本地配置、.env 加入 .gitignore、CI 用原生变量注入、os.LookupEnv 显式校验、敏感字段脱敏打印、构建标签控制硬编码密钥，全员坚守防线意识。

Go 项目中敏感信息（如 API 密钥、数据库密码、JWT 秘钥）一旦硬编码在源码或 Git 历史里，就极难彻底清除，且极易被 CI/CD 流水线、Docker 镜像、日志输出意外暴露。最有效的做法不是“加密存储”，而是从开发流程源头切断明文泄露路径。

用 godotenv + .env 文件隔离本地开发配置

Go 标准库不内置环境变量加载，godotenv 是事实标准，但必须严格限制其使用范围：

• 只在 main 或 cmd 包中调用 godotenv.Load()，绝不放在可复用的 pkg 或 internal 模块里
• .env 文件必须加入 .gitignore，且不能提交到任何远程仓库（包括私有仓库）
• 提供 .env.example 文件（不含真实值），仅声明变量名和类型，例如：

  DB_HOST=localhost
  DB_PORT=5432
  API_KEY=your_api_key_here  # ← 注释说明此处留空或填占位符

• CI 环境禁止使用 .env 文件——应通过平台原生方式注入变量（如 GitHub Actions 的 secrets、GitLab CI 的 variables）

用 os.LookupEnv 替代 os.Getenv 避免 panic

os.Getenv 在变量不存在时返回空字符串，容易掩盖配置缺失问题；而 os.LookupEnv 返回 (string, bool)，能显式判断是否设置：

if apiKey, ok := os.LookupEnv("API_KEY"); !ok {
    log.Fatal("missing required environment variable: API_KEY")
} else if len(apiKey) == 0 {
    log.Fatal("API_KEY cannot be empty")
}

• 所有关键配置项都应这样校验，尤其在 init() 或服务启动前
• 不要依赖默认值兜底敏感字段（如 os.Getenv("API_KEY") || "dev-key"）
• 若需 fallback，fallback 值也应是明确的测试专用字符串（如 "test-only-api-key-123"），而非生产可用值

禁止在日志、错误消息、HTTP 响应中打印敏感变量

哪怕只是调试阶段，fmt.Printf("%+v", cfg) 或 log.Println("config:", cfg) 都可能把 SecretKey 打进日志文件或 Sentry 上报中：

• 定义结构体时，对敏感字段加 json:"-" 和 yaml:"-" 标签，并实现自定义 String() 方法（返回脱敏形式，如 "SecretKey: ***"）
• 使用 log/slog 时，避免直接传入含敏感字段的 struct；改用键值对并手动过滤：slog.String("db_host", host)，不传整个 dbConfig
• HTTP handler 中，永远不要将 os.Environ() 或 os.Getenv("...") 的结果写入响应体

用 go:build + 构建标签控制密钥注入逻辑

某些场景（如离线部署、嵌入式设备）需要将密钥编译进二进制，此时必须用构建标签隔离风险代码：

//go:build with_secrets
// +build with_secrets
package main
import "os"
func getHardcodedSecret() string {
return "prod-secret-abc123" // ← 只在显式启用该 tag 时才存在
}

• 默认不启用该构建标签，日常开发和 CI 构建均跳过此文件
• 启用方式为：go build -tags with_secrets，且该命令不应出现在 Makefile 或 CI 脚本中，仅限受控离线环境手工执行
• 配合 gosec 扫描工具，可配置规则告警所有含 with_secrets 的构建标签使用

真正难的不是技术方案，而是让每个协作者都理解：环境变量不是“方便”，而是“防线”。一次 git add .env、一次 fmt.Printf、一次未过滤的 os.Environ()，都可能绕过所有加密与权限控制。