本地部署 DeepSeek，如何防止 API 密钥泄露？

把 DeepSeek 部署到本地后，API 密钥是你与服务之间的“身份证”。
一旦泄露，别人不仅能白嫖你的算力，还可能通过你暴露的接口访问内网资源。
别慌，只要在部署时做好这几点，就能大幅降低泄露风险。

先准备好这些

• 一台 Linux 服务器（本文以 Ubuntu 22.04 为例，CentOS 类似）
• Docker 已安装并正常启动（docker --version 检查）
• 你手头有一个可用的 DeepSeek API 密钥（比如通过官方平台申请的 sk-xxxx）
• 一个文本编辑器（nano / vim 都行）

第一步：用环境变量文件代替硬编码

千万不要把密钥直接写进代码或 Docker 命令里。
创建一个专门存放密钥的环境变量文件 .env：

# 切换到项目目录（假设是 /opt/deepseek）
cd /opt/deepseek
# 创建 .env 文件并写入密钥
echo 'DEEPSEEK_API_KEY=sk-你的真实密钥' > .env

如果你用 Docker 部署，在 docker-compose.yml 里这样引用：

services:
  deepseek:
    image: your-deepseek-image
    env_file:
      - .env

这样密钥就不会暴露在命令历史或 Docker Inspect 的输出里了。

第二步：锁死 .env 文件的权限

即使有人拿到服务器登录权限，也不该让他轻易读取密钥。
执行：

chmod 600 /opt/deepseek/.env
chown root:root /opt/deepseek/.env   # 或者你的运行用户

600 表示只有属主能读写，其他人连看都不行。

第三步：把 .env 加入 Git 忽略列表

如果你用 Git 管理部署配置，一定不要让 .env 被提交到仓库。
在项目根目录创建（或编辑）.gitignore 文件，加上一行：

.env

然后用 git status 确认 .env 没出现在待提交列表中。
如果你之前不小心已经提交过，立刻用 git rm --cached .env 清除缓存，并更改密钥。

第四步：防止密钥出现在日志和错误输出

很多框架或应用默认会在日志里打印环境变量（比如 Laravel 的 debug 模式）。
检查你的应用日志配置，确保：

• 禁用 debug 模式
• 使用日志过滤器屏蔽包含 api_key、password 等敏感字段
• 如果使用 Docker，在 docker-compose.yml 里设置 logging: 选项，防止日志泄露到宿主机

对于 DeepSeek 官方镜像，通常不会自动输出密钥，但如果你在代码里手动打印了 env 函数的结果，务必删掉。

常见踩坑与解决方案

Q：密钥已经写在命令里了，历史记录怎么清？
如果用了 docker run -e DEEPSEEK_API_KEY=xxx，这个明文会留在 shell 历史里。执行 history -c 只能清当前会话，建议立即轮换密钥，并养成用 --env-file 的习惯。

Q：我的 .gitignore 加了 .env 但还是被提交了？
可能是 Git 缓存了旧版本。先执行 git rm --cached .env，再提交一次更新 .gitignore 的文件。之后新克隆仓库就不会包含 .env 了。

Q：有没有更自动化的密钥管理方案？
对于生产环境，可以用 HashiCorp Vault 或 Docker Secrets，但学习成本较高。新手先用 .env + 权限控制就足够应对大多数场景。

验证你的密钥是否安全

1. 检查 .env 权限：ls -la /opt/deepseek/.env，输出应为 -rw-------。
2. 检查命令历史：history | grep -i api_key，应该没有任何包含密钥的明文。
3. 检查 Git 状态：在项目目录运行 git ls-files | grep .env，应该无输出。
4. 重启应用后，用 docker logs 查看启动日志，确认没有打印“DEEPSEEK_API_KEY=...”字样。

如果以上检查全部通过，你的 DeepSeek 密钥在本地部署环境中的安全性就基本扎实了。
后期随着业务增长，还可以引入更完善的密钥轮换和审计机制。
现在就对照步骤操作一遍，花十分钟换一个长期省心。