直接在终端用export设置密码类变量是高风险操作，因命令历史、ps输出和日志可能暴露明文；安全做法是避免键入敏感值，改用envpane图形界面、加密文件静默解密注入、专用凭证工具动态加载，或ci平台secrets管理，并严格限定环境变量作用域。
直接在终端里用 export 设置密码类变量是高风险操作——命令历史、进程列表、日志都可能留下明文痕迹。安全做法不是“怎么设”，而是“不让敏感值出现在终端命令行里”。
避免明文暴露：不执行 export 命令
不要这样写：
export DB_PASSWORD="my-secret-123"
这会让密码出现在 shell 历史、ps aux 输出、甚至系统日志中。正确思路是让环境变量从外部安全来源注入，且全程不经过命令行输入。
- 用 EnvPane 图形界面设置：安装后在系统偏好设置中打开，填入变量名和值，勾选“对 GUI 应用生效”，无需终端命令，也不留历史记录
- 用 ~/.zprofile（或 ~/.bash_profile）中读取加密文件：把密码存进一个仅你可读的加密文本（如用
openssl enc加密），再在配置文件里解密并 export —— 解密过程在 shell 启动时静默执行，不显示明文 - 用 专用凭证工具：如
op（1Password CLI）或aws-vault，在脚本中运行eval $(op item get "MyDB" --fields password)动态注入，密码只存在于内存中，不落地、不打印
限定作用域：只给需要它的程序用
全局 export 会让所有子进程（包括编辑器、Git、构建工具）都能读到密码，大幅扩大泄露面。应尽可能缩小范围：
- 在启动特定命令前临时注入：
FIREBASE_API_KEY=$(op read op://Dev/Credentials/FirebaseKey) xcodegen generate - 为某项目写个封装脚本，在脚本开头读取凭证、设置变量，然后 exec 启动主程序，避免污染当前 shell
- 配合 XcodeGen 等工具时，直接在
project.yml中引用${DB_PASSWORD}，但确保该变量仅由 CI 环境或本地 EnvPane 注入，而非手动 export
开发与生产分离：不同环境用不同机制
本地开发和 CI/CD 流水线应使用不同方式提供敏感变量：
- 本地开发：用 EnvPane 或本地加密文件，禁止提交任何含密钥的配置
- CI 环境（如 GitHub Actions）：利用平台内置的 Secrets 管理，通过
env:映射到 job 步骤，绝不硬编码、不打印 - 测试环境：用 Vault 或本地轻量服务（如 HashiCorp Vault dev 模式）统一分发，避免每个开发者维护自己的副本
核心原则就一条：敏感值不该被“键入”，而应被“受控加载”。终端只是入口，真正的安全发生在加载路径、作用域控制和生命周期管理上。
