首页 / 使用指南 / Codex / Cursor / OpenAI API Key 安全管理：.env、Git 与 VPS 开发机 | VPS推荐
📚 技术教程 ID: ai-api-key-env-security-guide

Codex / Cursor / OpenAI API Key 安全管理：.env、Git 与 VPS 开发机 | VPS推荐

面向 AI 开发工具用户，讲清楚 OpenAI API Key、Codex、Cursor、项目 .env、Git 提交、远程 VPS、CI/CD 和泄露后的安全处理流程，避免把密钥提交到仓库、截图或日志里。

作者：VPS推荐技术评测组
核验时间：2026-09-30
预计阅读：5-8 分钟
已通过真实命令复核

用 Codex、Cursor、Claude Code、OpenAI API 写代码时，最容易被忽略的不是模型怎么调用，而是 API Key、.env、SSH 私钥和 Git Token 在哪里生成、保存、传递和失效。很多泄露不是因为服务器被直接攻破，而是密钥被提交到 Git、发到截图、贴给 AI 或留在远程 VPS 的日志里。

本文只讨论正常开发、学习和团队协作场景。凡是已经公开、推送到远端、发给别人或贴进日志的 Key，都按“已泄露”处理：先吊销或轮换，再清理代码和仓库历史。

🧑‍💻 这篇文章适合谁

  • 正在用 Codex、Cursor、OpenAI API、Claude Code 或 GitHub Copilot 写代码的人。
  • 项目里已经有 .env，但不确定能不能提交到 Git 的小白。
  • 把开发环境放到海外 VPS、VS Code Remote 或 Cursor Remote 的用户。
  • 准备把项目部署到 Vercel、Cloudflare、GitHub Actions、Docker 或 systemd 的开发者。
  • 已经误提交过 API Key，想知道下一步该怎么补救的人。

如果你还在搭 AI 开发网络环境，可以先看 稳定 AI 网络环境指南；如果已经准备把 Codex / Cursor 放到 VPS 上，再配合 海外 VPS 远程开发机指南 一起读。

✅ 先给结论：新手照这 6 条做

不要写进代码

代码里只读取环境变量，例如 process.env.OPENAI_API_KEY，不要把真实 Key 写进 .ts、.js、.py、.astro。

不要提交到 Git

.env 要进 .gitignore，仓库里只保留 .env.example 这种无密钥模板。

不要截图和粘贴

找人排查时只贴错误码和脱敏后的前后文，不贴完整 Key、Cookie、Header、日志。

每个场景分开 Key

本地实验、远程 VPS、生产部署、团队项目尽量用不同 Key，泄露后影响范围更小。

泄露就轮换

已经公开或提交过的 Key 当作失效处理，先去平台后台吊销 / 轮换，再清理代码和历史。

最小权限

能用项目级、环境级、只读或短期凭据时，不要用主账号长期万能 Token。

这 6 条先覆盖最常见的泄露入口；后面再按本地、Git、AI 工具、远程 VPS 和部署平台逐步补齐，并在密钥轮换和权限变化后重新检查。

🔐 哪些东西算敏感信息

新手常把“密码”当敏感信息，却忽略 API Key、Token、连接串和截图。实际开发里，下面这些都要当敏感信息处理。 类型 例子 风险 AI / API OpenAI API Key、Anthropic Key、Gemini Key、第三方 API Token 会产生费用、暴露账号额度和项目权限。 代码平台 GitHub Token、GitLab Token、Deploy Key、SSH 私钥 可能让别人拉取、修改或删除你的仓库。 服务器 SSH 私钥、面板密码、数据库连接串、Redis 密码 可能直接导致 VPS、网站和数据被接管。 部署平台 Vercel / Cloudflare / Netlify Token、CI/CD Secrets 可能修改生产环境、读取环境变量或重新部署恶意代码。 日志截图 完整请求 Header、.env 截图、报错堆栈、终端历史 很多泄露不是来自代码，而是来自截图和排查日志。

🧭 API Key 安全的基本原则

API Key 的安全目标不是“永远不出错”，而是让错误更难发生，发生后影响范围更小、恢复更快。

  • 项目代码和密钥分离：代码进 Git，密钥进环境变量或 Secret 管理。
  • 本地、远程 VPS、CI/CD、生产部署使用不同密钥，避免一处泄露拖垮所有环境。
  • 能限制权限、额度、项目或组织范围时，就不要使用过大的主账号权限。
  • 多人协作时不要共享个人 Key；每个人使用自己的凭据，团队环境使用专门的部署凭据。
  • 排查问题时只暴露错误码、请求路径和脱敏后的配置，不暴露完整 Header、Cookie、Token。

尤其是 OpenAI API 这类按量计费服务，泄露后不仅是账号风险，还可能产生真实费用。密钥一旦离开你的控制范围，就别再侥幸继续用。

📁 本地项目怎么放 .env

最适合小白的方案是：真实密钥放 .env，仓库只提交 .env.example。这样别人拉取项目后知道需要哪些变量，但看不到你的真实 Key。

# AI / API secrets
.env
.env.*
!.env.example

# Local-only runtime files
*.local
npm-debug.log*
yarn-debug.log*
yarn-error.log*

仓库里可以保留一个模板文件，变量名写清楚，真实值留空。

# .env.example
# 只放变量名和说明，不放真实密钥
OPENAI_API_KEY=
OPENAI_PROJECT_ID=

# 其他服务按项目需要增加
DATABASE_URL=
GITHUB_TOKEN=

代码里读取环境变量，而不是写死真实密钥：

// Node.js / Astro / Next.js 示例
const apiKey = process.env.OPENAI_API_KEY;

if (!apiKey) {
  throw new Error("OPENAI_API_KEY is not configured");
}

临时排查时，也可以只给当前终端会话设置环境变量。这个方式适合测试命令，不适合长期生产部署。

# Linux / macOS / VPS：仅当前终端会话生效
export OPENAI_API_KEY="your_openai_api_key_here"

# Windows PowerShell：仅当前窗口生效
$env:OPENAI_API_KEY="your_openai_api_key_here"

小白容易误会的一点

.gitignore 只能阻止“未被 Git 跟踪的新文件”进入仓库。如果 .env 以前已经被提交过，后来再加 .gitignore 不会自动把它从历史里清掉。

🧪 提交前怎么检查 Git

每次提交 AI 项目之前，先花 30 秒看一眼暂存区。很多泄露都是因为 git add . 之后没有看 diff。

# 看这次准备提交哪些文件
git status --short
git diff --cached --name-only

# 提交前看暂存区完整 diff，确认没有 Key、Token、Cookie
git diff --cached

# Linux / macOS / Git Bash：检查是否已经有 .env 被 Git 跟踪
git ls-files | grep -E '(^|/)\.env(\.|$)'

# Windows PowerShell：检查是否已经有 .env 被 Git 跟踪
git ls-files | Select-String -Pattern '(^|/)\.env(\.|$)'

# 搜索常见敏感变量名，正式项目建议接入 secret scanning
# 排除依赖、构建产物和 Git 元数据，减少无关结果
rg -n --hidden --glob '!node_modules' --glob '!dist' --glob '!.git' "OPENAI_API_KEY|ANTHROPIC_API_KEY|GITHUB_TOKEN|DATABASE_URL|sk-" .

如果发现 .env 已经被 Git 跟踪，先移出索引，再确认 .gitignore 已经生效。

# 如果 .env 已经被 Git 跟踪，先把它从 Git 索引移除
# 这不会删除你本地的 .env 文件
git rm --cached .env

# 确认 .gitignore 已经包含 .env 规则后再提交
git status --short
git commit -m "Remove env file from git tracking"

注意：如果真实 Key 已经进入过 Git 提交，单纯 git rm --cached .env 不够。你还需要先轮换 Key，并按公开仓库、私有仓库、是否推送远端来决定是否清理历史。

🤖 Codex / Cursor 使用时怎么避免泄露

AI 编程工具能读代码、改文件、运行命令，效率很高；但也意味着你要更清楚哪些内容不能放进上下文。

  • 不要把完整 API Key 粘给 Codex、Cursor、聊天窗口或工单。
  • 不要让 AI “帮我打印所有环境变量”“帮我上传日志”，除非你能确认日志已经脱敏。
  • 让 AI 改配置时，要求它使用变量名和占位符，例如 OPENAI_API_KEY=your_key_here。
  • 提交前自己看 git diff，不要完全依赖 AI 判断有没有敏感信息。
  • 如果工具支持忽略文件或上下文排除，把 .env、私钥、日志、备份文件加入忽略列表。

一个实用习惯是：让 AI 看到 .env.example，不要让它看到 .env。它知道项目需要什么变量，但不需要知道真实值。

🖥️ 远程 VPS 开发机怎么存密钥

把 Codex / Cursor 放到海外 VPS 上跑时，密钥风险会变成两层：仓库不能泄露，服务器本身也不能被轻易读取。至少先做好文件权限、目录隔离和轮换入口；chmod 600 只能限制普通文件访问，不能替代 SSH 加固、系统更新和主机权限管理。

# VPS 上创建项目级 .env 后，收紧权限
chmod 600 .env

# SSH 私钥也要收紧权限
chmod 600 ~/.ssh/id_ed25519
chmod 700 ~/.ssh
  • 每个项目单独 .env，不要把所有 Key 都塞进 ~/.bashrc。
  • 不要长期使用 root 用户写代码，创建普通开发用户更稳。
  • 不要把数据库、Redis、管理面板暴露在公网，只开放必要端口。
  • 多人共用 VPS 时，不要共用同一套 API Key 和 SSH 私钥。
  • 备份代码和配置时，不要把明文 .env 直接同步到公共网盘或公开仓库。

如果项目用 systemd 管理，可以把环境变量放进仅服务用户和 root 可读的 EnvironmentFile。实际部署前还要确认文件所属用户、服务用户和备份策略，不要把凭据直接写进 unit 文件。

# /etc/my-app/my-app.env
OPENAI_API_KEY=your_openai_api_key_here
DATABASE_URL=postgres://...

# systemd service 片段
[Service]
User=dev
UMask=0077
EnvironmentFile=/etc/my-app/my-app.env
WorkingDirectory=/opt/my-app
ExecStart=/usr/bin/node server.js

如果项目用 Docker Compose，可以用 env_file，但 .env 仍然必须被 .gitignore 忽略。

# docker-compose.yml
services:
  app:
    image: my-app:1.2.3
    env_file:
      - .env
    ports:
      - "3000:3000"

# 注意：镜像应按已审阅版本固定，.env 仍然必须在 .gitignore 里

🚀 CI/CD 和生产部署怎么处理

CI/CD 和生产部署里最忌讳把 Key 写进仓库配置文件。GitHub Actions、Vercel、Cloudflare Pages、Netlify 这类平台都有自己的环境变量或 Secrets 功能；配置完成后仍要确认预览、生产和构建日志不会回显敏感值。

  • GitHub Actions：把 Key 放到 Repository Secrets 或 Environment Secrets，再在 workflow 里读取。
  • Vercel / Netlify / Cloudflare：在项目设置里配置环境变量，区分 development、preview、production。
  • Docker 镜像：不要把 .env 打进镜像层；构建参数和运行时环境变量要分清。
  • 生产环境：尽量使用单独的生产 Key，并限制调用范围、额度和可访问项目。

有前端页面时要特别小心：只要变量被打包进浏览器端代码，就可能被用户看到。真正私密的 API Key 应该在后端、Serverless Function、VPS 服务端或平台 Secret 中使用。

🧯 如果已经泄露了怎么办

密钥泄露时，顺序很重要：不要先花半小时美化提交记录，先让泄露的 Key 失效。

1. 先吊销或轮换

去 OpenAI、GitHub、云平台或数据库后台立刻删除 / 轮换泄露凭据。不要先慢慢改代码。

2. 判断泄露范围

看 Key 是否进入公开仓库、截图、聊天记录、CI 日志、部署日志、Pagefind 产物或第三方排查工具。

3. 移除当前代码里的密钥

把真实 Key 改成环境变量读取，提交 .gitignore、.env.example 和代码修复。

4. 如果推送到远端，按平台文档清理历史

只删最新提交不代表历史里没有。公开仓库要参考 GitHub 官方敏感数据清理流程。

5. 更新部署环境

把生产、预览、VPS、CI/CD、Docker、systemd 里的旧 Key 全部替换。

6. 复盘并加防线

开启 Secret Scanning，增加提交前 diff 检查，让同类问题下次更早被拦住。

如果泄露发生在公开 GitHub 仓库，还要检查 fork、Actions 日志、部署日志、Release 包和构建产物。已经进入公开历史的敏感信息，按 GitHub 官方“移除敏感数据”流程处理，不要只靠删除最新文件；清理历史也不能替代先轮换凭据。

🧰 推荐工具与适用场景

不同阶段适合不同工具。个人练手不用一上来就引入复杂 Secret 平台；团队和生产环境也不应该只靠一个 .env 文件硬撑。 场景 推荐方式 说明 个人本地项目 .env + .env.example + .gitignore 最简单、最适合小白。重点是 .env 永远不提交，.env.example 只留空变量名。 GitHub 仓库 GitHub Secret Scanning 适合拦截仓库里的 Token 泄露。公开仓库和团队项目尤其应该开启。 GitHub Actions Repository / Environment Secrets CI 里不要把 Key 写到 YAML 文件，放到 GitHub Secrets，再由工作流读取。 远程 VPS 受限权限的项目级 env 文件 适合 Codex / Cursor 远程开发机。文件权限收紧，项目分目录、分 Key。 生产部署平台 Vercel / Cloudflare / Netlify 环境变量 适合网站和 API 部署。不要把生产 Key 放在源码里。 团队或多项目 1Password / Bitwarden / Doppler / Infisical 当 Key 多、成员多、环境多时，用专门的密码管理或 Secret 管理工具更稳。
如果你只是一个人做小项目，先把 .env、.env.example、.gitignore 和提交前检查做好。等项目进入多人协作、生产部署或客户代码阶段，再引入 GitHub Secrets、平台环境变量和专门的 Secret 管理工具。

⚠️ 常见错误做法

把 .env 提交后再删除

删除最新版文件不等于历史安全，别人仍可能从 Git 历史、Fork、缓存或 CI 日志里看到。

把 Key 发给 AI 帮忙排查

AI 工具可能读取、保存或回显上下文。排查时只贴脱敏日志和错误码。

所有项目共用一个 Key

一个练手项目泄露，就会影响生产项目、远程 VPS 和所有调用额度。

在前端暴露私密 Key

浏览器端代码、构建产物和 sourcemap 都可能被用户看到。需要后端代理或平台安全方案。

把 .gitignore 当保险箱

.gitignore 只能阻止未跟踪文件被新增提交，不能保护已被 Git 跟踪的文件。

把 Key 写进终端历史和工单

命令行、截图、工单、聊天记录和日志平台都可能成为二次泄露点。

📋 提交前检查清单

每次提交 AI 项目前，按下面清单过一遍。它不高级，但很管用。

  • 仓库里只有 .env.example，没有真实 .env。
  • git status --short 里没有 .env、私钥、日志、截图、备份压缩包。
  • git diff --cached 没有任何服务的真实 Key、Cookie、Token、连接串；不要只搜索 sk- 这种固定前缀。
  • AI 工具生成的代码只读取环境变量，没有把 Key 写死在源码里。
  • 远程 VPS 上 .env 权限收紧，项目之间没有乱共用 Key。
  • CI/CD 使用平台 Secrets，不在 workflow、Dockerfile、Compose 文件里写真实 Key。
  • 如果 Key 曾经公开，已经先轮换或吊销，不继续使用旧 Key。

🧭 站内下一步推荐

[

先把开发环境放稳：Codex / Cursor 海外 VPS 远程开发机

查看 ->
把 GitHub、NPM、Docker、OpenAI API 和 AI CLI 放进同一台海外开发机。 ](/guides/codex-cursor-remote-vps-dev-guide)[

排查 API 不通：AI 工具终端网络排查

查看 ->
区分终端代理、DNS、API 认证、状态码和远程 VPS 出口问题。 ](/guides/ai-terminal-network-troubleshooting-guide)[

搭稳定出口：稳定 AI 网络环境指南

查看 ->
判断机场、固定 IP、VPS 落地、住宅 / ISP IP 和海外开发机怎么选。 ](/guides/stable-ai-network-environment-guide)[

补 SSH 基础：SSH 连接与基础操作

查看 ->
密钥登录、SSH 配置、文件权限和远程连接基础。 ](/guides/ssh-basics)[

做长期备份：数据备份与灾难恢复

查看 ->
代码进 Git，数据和配置有备份，但不要备份明文密钥。 ](/guides/data-backup)[

提高服务器安全：服务器安全进阶

查看 ->
防暴力破解、端口暴露、Fail2ban、隐藏真实 IP 和入侵痕迹排查。 ](/guides/security-advanced)

📚 资料来源

🚀 下一步行动

密钥安全做好之后，再把 AI 开发环境的网络、远程开发机和终端排查补齐： [ 💻

Codex / Cursor 海外 VPS 远程开发机

把 AI 开发工具、GitHub、NPM、Docker 和 API 调用放进同一台海外开发机。 开始学习 ](/guides/codex-cursor-remote-vps-dev-guide)[ 🔍

AI 工具终端网络排查

排查 Cursor、Codex、npm、GitHub、Docker 和 OpenAI API 超时问题。 开始学习 ](/guides/ai-terminal-network-troubleshooting-guide)[ ⭐

VPS 推荐榜单

查看 VPS 实测与服务商索引，先看结论再去官网。 查看推荐 ](/vps-recommendations)[ 📚

浏览更多教程

继续探索服务器安全、网站搭建、性能优化和 AI 环境主题。 探索教程 ](/guides)
读完后建议 先验证，再选择 把判断落到具体选择 准备购买 VPS 时，先对照推荐榜单和真实测评确认线路、价格、用途与风险；只是继续学习，可以回到教程索引按主题往下看。 查看推荐榜单 回到教程索引

VPS

关于本文作者与审校团队

了解内容准则

本文由 VPS推荐技术评测组 联合撰写与维护。团队成员具备多年海外 VPS 部署、Linux 系统调优与网络架构实践经验。所有指南均以命令行真实回显、安全性优先及可回退步骤为原则。

VPS推荐 vpstuijian.pro

专业的全球云服务器与网络工具指南。致力于消除信息差，提供真实可复现的 VPS 测速证据、服务器优化脚本与网络架构参考。

选购推荐

实测与教程

实用工具

关于与索引

© 2026 VPS推荐 (vpstuijian.pro) · 保留所有权利