DeepSeek API Key 获取教程：注册、充值与安全管理全流程

DeepSeek API Key 是调用 DeepSeek-V3 和 R1 模型的唯一凭证。整个流程只需 5 分钟：注册账号 → 创建密钥 → 充值 → 替换代码参数即可开始调用。本文逐步说明每个环节的操作细节与注意事项。

我见过不少团队第一次接 DeepSeek 都栽在同一个地方：密钥复制少了一位、base_url 多打了个斜杠、或者赠额用完了没充值就直接上生产——这几个坑本文都会点出来，照着走一遍基本不会踩雷。

第一步：注册 DeepSeek 开放平台账号

1. 打开 platform.deepseek.com；
2. 点击「注册」，使用手机号完成实名注册（国内号码）；
3. 验证手机验证码后设置密码，完成账号创建；
4. 登录后进入控制台首页，左侧导航可见「API Keys」和「用量统计」。

若你已有 DeepSeek 聊天应用账号，平台账号需单独注册，两者相互独立。

注册这一步看着简单，但有两个细节容易被忽略：一是手机号只能绑定一个平台账号，如果你换了手机号又想用旧账号，得先在旧账号里解绑，别指望客服帮你强制转移；二是企业用户如果打算走对公发票报销，建议注册后立即在「账户设置」里补全企业信息（统一社会信用代码、开票抬头），等到充值完再补，走发票流程会更慢——具体开票规则以平台当时的公示为准，各家政策会调整，别按老经验想当然。

第二步：创建 API Key

1. 在控制台左侧点击 「API Keys」；
2. 点击右上角 「创建 API Key」 按钮；
3. 填写名称（如 my-project-prod），点击「确认」；
4. 系统弹出密钥，格式为 sk-xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx；
5. 立即复制并保存——此密钥仅展示一次，关闭弹窗后无法再次查看。

建议按项目/环境分别创建密钥（如 dev-key、prod-key），便于权限隔离和独立轮换。

命名这件事别小看，团队人一多，密钥列表里一堆 my-project-prod 这种模糊名字，出问题时根本分不清是谁的锅。我自己的习惯是用「项目-环境-负责人拼音首字母」的格式，比如 chatbot-prod-zs、crawler-dev-lw，控制台一眼就能看出这把密钥归谁管、跑在哪个环境。如果你们是多人协作的团队，还有一个更实际的建议：给每个接入 DeepSeek 的微服务单独开一把密钥，而不是全公司共用一把。理由很直接——一旦某个服务的密钥因为日志打印疏忽泄露到 GitHub 上（这种事故每年都有真实案例），你只需要吊销这一把、重新生成，其他服务完全不受影响；如果大家共用一把密钥，出事就是全员停摆，还得挨个通知改配置。

第三步：充值余额

1. 控制台左侧点击 「充值」；
2. 选择金额，支持微信、支付宝；
3. 充值到账后可在「用量统计」查看余额与调用明细；
4. 新用户注册后通常有免费赠额，可先用赠额完成测试。

截至 2026-06，以官方公示为准：DeepSeek-V3 价格位于国产最低区间，可用 价格对比表 估算预算。

充值这一步最容易被忽视的是余额提醒阈值。控制台一般能设置一个余额低于多少就发短信/邮件提醒，很多人图省事没配，结果生产环境跑到一半余额归零，接口直接报错，业务方还以为是代码 bug，排查半天才发现是账户没钱了。建议充值后第一件事就是把提醒阈值设成一个够你反应时间的数（比如预估三天用量），别等到余额跑空才后知后觉。

另外提醒一句：免费赠额和充值余额是分开计费、按顺序扣减的，具体的扣减顺序和赠额到期规则以控制台当时的说明为准（不同批次注册用户的赠额政策可能不一样）。如果你在「用量统计」里发现赠额没扣但余额在掉，大概率是赠额已经用完或者过期了，去用量明细里翻一下扣费记录就能确认，别凭感觉猜。

第四步：接入代码（OpenAI 兼容写法）

第四步：接入代码（OpenAI 兼容写法）

获取密钥后，只需替换 api_key 和 base_url 即可调用：

from openai import OpenAI

client = OpenAI(
    api_key="sk-xxxxxxxxxxxxxxxx",          # 替换为你的 DeepSeek API Key
    base_url="https://api.deepseek.com/v1",
)

response = client.chat.completions.create(
    model="deepseek-chat",   # deepseek-chat = V3；deepseek-reasoner = R1
    messages=[
        {"role": "user", "content": "你好，请用一句话介绍 DeepSeek"}
    ],
)
print(response.choices[0].message.content)

Node.js 示例：

import OpenAI from "openai";

const client = new OpenAI({
  apiKey: "sk-xxxxxxxxxxxxxxxx",
  baseURL: "https://api.deepseek.com/v1",
});

const resp = await client.chat.completions.create({
  model: "deepseek-chat",
  messages: [{ role: "user", content: "Hello DeepSeek" }],
});
console.log(resp.choices[0].message.content);

这两段代码能这么短，是因为 DeepSeek 的接口协议直接兼容 OpenAI 的 Chat Completions 规范——OpenAI 这个客户端类本质上只是把请求打到 base_url 指定的地址，只要接口的请求体、响应体字段跟 OpenAI 对得上，换个 base_url 就能无缝切换供应商。这也是为什么原来用 GPT 系列接口的项目，迁移到 DeepSeek 通常只需要改两行配置，业务代码一行不用动。反过来说，如果你自己封装了一层适配层，也可以照着这个思路把多家国产模型统一收口到一个接口形态，减少切换供应商的改造成本。

流式输出（打字机效果）：如果你在做对话类产品，一次性等模型把整段话生成完再显示，用户体验会很差，通常都要开流式：

stream = client.chat.completions.create(
    model="deepseek-chat",
    messages=[{"role": "user", "content": "写一段关于秋天的描写"}],
    stream=True,
)
for chunk in stream:
    delta = chunk.choices[0].delta.content
    if delta:
        print(delta, end="", flush=True)

注意流式模式下拿到的是一段一段的 delta，不是完整回复，前端要自己拼接展示；如果你的业务逻辑需要拿到完整文本再做后处理（比如敏感词过滤），记得在收完流之后把所有 delta 拼成完整字符串再处理，不要在每个 chunk 上单独跑一遍过滤逻辑，否则一个词可能被切成两半，过滤规则会失效。

并发请求与重试退避：生产环境调用量上去之后，单个请求偶尔超时或被限流是正常现象，直接让请求失败会影响体验，靠谱的做法是加指数退避重试：

import time
from openai import OpenAI, APIError, APITimeoutError

client = OpenAI(api_key="sk-xxxxxxxxxxxxxxxx", base_url="https://api.deepseek.com/v1")

def chat_with_retry(messages, max_retries=3):
    for attempt in range(max_retries):
        try:
            return client.chat.completions.create(
                model="deepseek-chat",
                messages=messages,
                timeout=30,  # 单次请求超时时间（秒），按你的场景调整
            )
        except (APIError, APITimeoutError) as e:
            wait = 2 ** attempt  # 1s -> 2s -> 4s
            print(f"第 {attempt + 1} 次调用失败：{e}，{wait}s 后重试")
            time.sleep(wait)
    raise RuntimeError("重试次数已用尽，仍未调用成功")

这里的 timeout 参数很关键，很多人第一次接入时不设置，用默认值，结果碰到模型响应慢（尤其是长上下文或者 R1 推理模型思考时间长的场景），请求挂在那里几十秒才超时，用户早就等不及关掉页面了。建议根据你的业务场景显式设置一个合理的超时——纯问答类场景 20-30 秒够用，长文档摘要或复杂推理场景可以放宽到 60 秒以上，但一定要显式设置，别依赖默认值。

API Key 安全管理建议

• 不要硬编码密钥：使用环境变量（DEEPSEEK_API_KEY）或密钥管理服务（如 Vault）；
• 设置用量告警：在控制台配置消费上限，防止意外超支；
• 定期轮换：每季度或发现泄露后立即在控制台删除旧密钥、创建新密钥；
• .gitignore 排除 .env 文件：避免密钥随代码提交到 GitHub；
• 最小权限原则：开发/测试环境用独立密钥，不与生产密钥共用。

如果是 CI/CD 流水线里要用到密钥（比如自动化测试要真实调用接口），不要图省事写死在 workflow 文件里，用 GitHub Actions 的 Secrets、GitLab CI 的 Variables 或者你们内部的密钥管理系统注入，流水线日志里也记得检查一下有没有把密钥打印出来——不少人因为 print(response) 或者调试日志里带上了完整请求头，密钥就这样进了 CI 日志，而 CI 日志的可见范围往往比想象中更宽。

真出现密钥疑似泄露（比如误传到公开仓库、日志外泄），别纠结要不要观察一下，第一时间在控制台把这把密钥删掉，同时创建新密钥替换所有用到旧密钥的地方——泄露的密钥没有「先小范围观察」这一说，删除的操作是不可逆的，但保留一把已经泄露的密钥继续用，风险远比重新配置一次麻烦。

# .env 文件（不要提交到版本库）
DEEPSEEK_API_KEY=sk-xxxxxxxxxxxxxxxx

import os
from openai import OpenAI

client = OpenAI(
    api_key=os.environ["DEEPSEEK_API_KEY"],
    base_url="https://api.deepseek.com/v1",
)

常见问题

创建好密钥但调用报 401 Unauthorized 怎么办？ ① 检查 api_key 是否完整复制（无前后空格）；② 确认 base_url 为 https://api.deepseek.com/v1（末尾不加额外路径）；③ 检查账户余额是否充足（赠额用尽后需充值）。

调用时报 429 Too Many Requests 是什么情况？ 这是触发了限流，通常出现在短时间内并发请求量超过账户当前等级允许的速率上限。排查思路：先看是不是代码里有并发循环短时间内打了一大批请求（比如批量处理任务没做限速），如果是，加个请求间隔或者用信号量控制并发数；如果业务量确实大，可以在控制台查看当前账户的限流等级说明，评估是否需要申请更高等级。不要一遇到 429 就疯狂重试，这样只会让限流更严重，前面重试退避的代码示例里已经带了指数退避逻辑，就是为了应对这种情况。

长文本调用报错提示上下文超限怎么办？ DeepSeek 各模型有各自的上下文长度上限，具体数值以官方文档当时公示为准。如果你的输入（历史对话 + 当前问题 + 系统提示词）加起来超过了上限，接口会报错拒绝。解决办法：一是用 Token 计数器 工具提前估算好文本对应的 token 数，二是对多轮对话做历史裁剪（比如只保留最近几轮 + 一个摘要），别把所有历史消息无脑拼接进 messages 数组。

API Key 能共享给团队成员使用吗？ 技术上可行，但不建议。建议每个成员/服务各自创建独立密钥，便于追踪用量和独立吊销。企业用户可申请企业账号，统一管理子账号权限。

忘记保存密钥怎么办？ DeepSeek 控制台无法再次显示明文密钥，只能删除原密钥后重新创建一个。请在创建时立即保存到密码管理工具（如 1Password、Bitwarden）。

---

相关阅读：国产大模型 API 全景指南 · DeepSeek API 接入详解 · DeepSeek-R1 推理模型用法

分类导航：国产模型专题

实用工具：价格对比表 · Token 计数器