环境变量并不是密钥保险箱，而是一种配置注入机制。它的主要价值，是把 API 密钥与代码、公开配置文件分离，降低误提交和多人协作中反复传递的风险。但密钥只要被注入应用，就会进入运行环境；如果日志、错误信息、构建记录、备份文件或部署平台配置页面处理不当，环境变量仍可能成为泄露源。

泄露发生在“使用链路”中

常见误区是认为“没有写进代码”就等于安全。实际上，应用调试时打印配置内容，异常处理时输出完整环境信息，构建流程保存带有敏感值的记录，备份系统同步配置文件，都可能让密钥离开原本的保护边界。某些第三方平台也需要读取环境变量；一旦项目权限过宽，密钥就不再只属于实际需要它的应用。

环境变量还容易制造环境混用。开发、测试和正式环境若共用同一把密钥，测试代码、临时脚本或低权限账户都可能获得不必要的访问能力。即使没有发生外部攻击，这种设计也会让泄露后的排查和撤销变得困难：无法快速判断密钥被哪些项目使用，也无法确认旧密钥是否仍然有效。

正确的安全边界

首先，应把环境变量视为“运行时可读取的敏感配置”，而不是永久存储。代码、公开文档、截图和聊天记录中不应出现真实密钥；日志、错误报告、构建记录和备份则需要专门检查，避免意外打印或同步。

其次，按服务和环境拆分密钥，并限制项目、应用或运行环境的读取范围。开发环境不应默认使用正式环境凭证，应用也不应因为配置方便而获得全部密钥。对于不再使用或疑似泄露的密钥，应优先撤销或轮换，再排查泄露路径。

最后，工具选择应服从业务复杂度。单个本地脚本可以采用不进入版本控制的配置文件；存在多个部署环境时，应关注环境隔离、访问控制和变更记录；当应用数量、协作者或权限关系增加，再考虑具备审计和运行时访问能力的云端密钥管理服务。真正有效的方案，不是把密钥换个地方放，而是明确谁能读取、何时读取，以及泄露后能否迅速切断访问。