真正安全的做法是不让敏感值以明文形式出现在进程内存以外的任何地方；须用os.LookupEnv双重校验必填字段，结构体加json:"-"标签脱敏，禁用日志打印完整配置，.env文件限域加载且严格.gitignore，文件路径仅存环境变量中并设600权限。
直接暴露在代码或环境变量里，api key 就已经不安全了。真正安全的做法是：不让敏感值以明文形式出现在进程内存以外的任何地方——包括 shell 历史、ps 输出、日志、配置文件、git 提交记录。
os.LookupEnv + 显式校验必须写在启动入口
用 os.Getenv 读取敏感字段是危险的起点：它对缺失、空值、空白符全无提示，容易让服务带着空密钥静默启动。正确做法是在 main() 或 init() 中强制校验：
- 用
os.LookupEnv获取(string, bool)二元结果，明确区分“未设置”和“设为空字符串” - 对每个必填敏感字段（如
API_KEY、DB_PASSWORD）做双重判断：!ok或len(value) == 0 - 校验失败立即
log.Fatal，不 fallback 到测试密钥——测试密钥也应带test-前缀并仅限本地构建标签启用
敏感字段绝不进日志、JSON、HTTP 响应体
哪怕只在调试时 fmt.Printf("%+v", cfg) 或 log.Println(cfg)，都可能把密钥打到 stdout、Sentry、ELK 里。结构体定义必须主动防御：
- 对敏感字段加
json:"-" yaml:"-"标签，阻止自动序列化 - 实现
String()方法，返回脱敏形式，例如Password: *** - HTTP handler 中禁止传整个配置 struct 给
slog.With；必须手动提取非敏感字段构造键值对 - 绝不在响应中返回
os.Environ()或任意os.Getenv结果
避免 .env 文件提交风险，但可用 godotenv 限域加载
.env 文件本身不是问题，问题是它被误提交、误同步、误用于 CI。安全用法有严格边界：
- 只在
cmd/包的main.go开头调用godotenv.Load()，绝不放在internal/或pkg/ -
.env必须进.gitignore，且配套提供.env.example（只含变量名和注释，无值） - CI 环境禁用
.env——GitHub Actions 用secrets，Kubernetes 用Secret挂载，Docker Compose 用environment+env_file分离 - 本地开发若需快速启动，可配合
go:build dev标签，让godotenv只在 dev 构建中生效
文件加载比环境变量更可控，但路径本身要保密
把密钥存在文件里（如 ./secrets/api.key）再通过环境变量指向路径，能规避 shell 历史和 ps aux 泄露，但前提是路径不暴露：
- 使用
gh_mirrors/en/env的file标签：APIKey string `env:"API_KEY,file"` - 环境变量只存路径，如
export API_KEY="./secrets/api.key"，该路径本身不能含密钥信息（避免API_KEY_PROD_2026.key这类命名） - 文件权限设为
600，且所在目录不可被 Web 服务器或静态文件服务访问到 - 注意：文件加载仍会把内容读入进程内存，所以后续仍需遵守脱敏打印、不透出等规则
最常被忽略的一点：敏感配置的安全性不取决于你用了多强的加密算法，而取决于它从加载进内存那一刻起，是否被任何非必要代码路径触达过——包括反射、通用日志、panic 堆栈、pprof profile 输出。越早切断传播链，越接近真正安全。
