Bitget API Key 安全设置完整教程
sub-account 隔离、IP 白名单、Passphrase 三个关键

你要把 TradingView 信号、或某个交易机器人接到 Bitget 自动下单，第一件事就是建一把 API key——这也是 Bitget API key security 这件事真正被决定的一步。90% 的人在这一步权限给得太宽——照着网上 Binance 版教程随手勾一勾，忘了 Bitget 多了一个 Passphrase、少了一个「Read」独立勾选项，还有一整套 sub-account 可以自己管 API 的机制没有用到。这篇把 Bitget 官方 API 文档、加上我们自己 跨 10 家交易所的权限检查清单已经查证过的部分，整理成 Bitget 专用版，只讲会影响你风险大小的三件事：权限最小化、IP 白名单、以及那个很多人没开的 sub-account 隔离。

这篇不比较 Bitget 跟其他家的安全谁做得更好——那需要跨交易所实测与内部制度审计，我们没做过，这篇也不会做。这篇不教你怎么在 Bitget 上做交易策略，只讲 API key 这一层。范围缩在这里，是因为只要这一层设对了，就算某个下游工具将来被黑，你的资金也搬不走；设错了，后面所有防护都变成装饰。

Bitget 的 API key 权限模型：两套 API、两种界面

Bitget 目前并存两套 API：Classic API（现货与合约各自独立的旧界面）与 UTA（Unified Trading Account，统一交易账户）——后者是 Bitget 官方文档标「🔥 Recommended」的新一代界面。权限模型在两套里稍有不同，UI 上实际能勾的选项也随账户模式而变。这一点跟 Binance／BingX 只有一组固定权限清单不同，是Bitget 特有的复杂度。

还有一个 Bitget 跟 Binance／BingX 不一样的地方——Bitget 的 API 认证要三把 key，不是两把：ACCESS-KEY、Secret Key、加上一个 Passphrase。这个 Passphrase 是你建 key 当下自己设的密码，官方文档写得很直白：「if the Passphrase is forgotten, it cannot be retrieved and the APIKey needs to be re-created」——忘了就得重建一把 key。这一点跟 OKX 的做法一样，跟 Binance／BingX 只有 API Key + Secret 两把不同。实务意义是：你的三把 key 任何一把泄露，都可能造成资产损失——Bitget 官方风险提示的原文是「The leakage of any one of these three keys may cause the loss of your assets」——所以 Passphrase 也要当秘密看待，跟 API Key／Secret 一起存进密码管理工具。

三个必做设置：关 Withdraw、绑 IP、用 sub-account

设置一：不要勾 Withdraw 权限

这一条的重要性在于它决定了 key 泄露时的损失规模，其他两条决定的是泄露概率。就算你把 IP 白名单设得再严、Passphrase 藏得再深，只要哪天 key 从别的地方漏出去——电脑中毒、SaaS 平台被黑、自己手滑 push 到公开 repo——Withdraw 有没有勾，决定的是黑客能不能直接把钱搬走。

Bitget 在 key 层级可以把交易跟提币完全分开——这一点我们的跨交易所检查清单里逐条对照过，Bitget 属于「可以分开」的 9 家之一（Gate.io 是唯一例外）。所以这件事的难度不是技术限制，是你有没有记得不勾而已。Bitget 对 Withdraw 权限有一个额外要求——只要你勾了 Withdraw，就会被要求绑 IP 白名单，这是强制的。其他家（Binance、BingX）也一样有这个规则，是这个小圈子里的业界共识。

设置二：绑 IP 白名单

Bitget 官方 UTA 快速入门文档的原文是「For security reasons, it is strongly recommended that you bind an IP address when creating the API Key」——「强烈建议」，不是强制（除非你勾了 Withdraw）。这是 Bitget 跟其他家不同的地方：Binance、BingX 对「没绑 IP 的 key」都加了强制的自动删除规则（30 天／14 天），Bitget 官方文档目前没有写这种到期机制。这个差别对你的实务意义是：Bitget不会帮你把懒得绑 IP 的 key 定期清掉，你自己得主动绑，不然它就会一直放着。

你自己搭的 VPS 通常就 1 个固定 IP，用 SaaS 平台的话对方会给你一组固定出口 IP（TVSBot 给的是一组，其他工具数量不一，接工具之前先问清楚）。IP 白名单的字段在 Bitget 建 key 的界面里是明确存在的一个输入框，填了之后只有来自这些 IP 的请求会被接受。

设置三：把跑机器人的 key 放在 sub-account——这是 Bitget 的差异化做法

这一条是这篇跟 Binance 版最大的不同，也是 Bitget 官方文档里真的做得比较细的地方——Bitget 的 sub-account 可以自己建、自己管 API key，不需要主账号帮忙操作。这一节值得单独拆一个 H2 讲清楚。

sub-account 隔离：Bitget 官方支持、但默认是关的

Bitget 官方 UTA 文档把这件事写得很清楚——「Sub-accounts (virtual sub-accounts and standard sub-accounts) can create and manage their own API Keys independently, without requiring the main account to operate on their behalf」。翻成白话：你可以在主账号底下建一个 sub-account，把资金分过去，让那个 sub-account 自己建 API key 跑机器人——主账号完全不需要建任何 key。这带来的好处是隔离，如果那把 sub-account 的 key 出问题（泄露、策略失控、单子乱下），影响范围限缩在该 sub-account 的资金，主账号其他资产不会被波及。

但这件事有个关键前提是很多人漏掉的——这个功能默认是关闭的。Bitget 官方 UTA 文档用一整段警告：「Prerequisite: The main account must enable the API Key Management permission for the sub-account. This setting is disabled by default. The main account can configure it under sub-account permission settings」。所以你不是「建了 sub-account 就能用」，而是要主动去主账号的 sub-account 权限设置里，把 API Key Management 这个权限打开，之后 sub-account 才能自己建 key。开启之后 sub-account 可以做的事，官方列了四件：

• Create API Key（建 key）
• View API Key（查看 key 信息）
• Edit API Key permissions（改权限）
• Delete API Key（删除 key）

同一节官方另外补了一句：「The main account retains full control and can view, edit, or delete any sub-account's API Keys at any time」——主账号随时可以看、改、删 sub-account 的所有 key。这件事的实务意义是：你把跑机器人的权限下放给 sub-account，并没有失去对它的控制权——sub-account 是操作单位，主账号永远是 root。

这张对比表不是要判 Bitget 的做法比较好——两家的思路不一样，各有适合的情境。Bitget 的「sub-account 自己管 API」对不同人跑不同机器人的团队比较友善（例如你跟合作伙伴各管一个策略），主账号不用当中转站。Binance 那种主账号一手代管的做法，对单人单机器人的散户反而是简单的——反正一切都在你手上。挑哪个，看你实际场景。

Bitget 没有明文到期机制，意味着什么

对比其他家的做法你就能看出这个差异的分量——Binance 对没绑 IP 的 key 是 30 天闲置删除，BingX 是 14 天，OKX 是 14 天。Bitget 官方 UTA 快速入门、以及 Classic API 文档里，都查不到针对「没绑 IP 的 key」或「闲置多久」的自动到期规则。这件事在我们的跨 10 家交易所检查清单里也是同样的结论。

这个差异对你的实务意义有两层：好处是你不用担心机器人某天早上因为 key 到期静默断线——Bitget 不会这样做。坏处是失效的 key（例如你早就不用某个工具了、但忘了删 key）会一直躺在你的 API 管理页面里，多一把悬在那里不会被清掉的攻击面。这一条你得靠自己：定期回 Bitget 的 API 管理页面核对，把不用的 key 主动删掉——这件事没有交易所会帮你做。

建 Bitget API Key 的实际流程

Bitget 的 UI 会偶尔改版，这里不写具体像素位置的按钮动线——只给你必经的步骤骨架。实际设置时请以 Bitget 账户页当下显示为准。假设你要走「sub-account 跑机器人」这条路，流程比单建一把主账号 key 多两步，但整个 workflow 只做一次，之后就稳了。

【第一次设置：把 sub-account 打开】
        1. 登入 Bitget → 右上角头像 → Sub-Accounts（子账户管理）
        2. Create Sub-Account → 填 sub-account 名称、Email、密码
        3. 在该 sub-account 的权限设置里，勾选 API Key Management
           （官方文档明讲：这一项默认是关的，你要主动开）
        4. 把主账号要分给机器人的资金，通过 Transfer 移到 sub-account

        【建 API key：用 sub-account 身份】
        5. 登出主账号 → 用 sub-account 账号登入（或用 sub-account 切换功能）
        6. 右上角 → API Management → Create API Key
        7. 填 Label（例如：tvsbot-prod、grid-bot-01）
        8. 设置 Passphrase（自己想一组 8~32 字符的密码，忘了得重建 key）
        9. 完成 2FA 验证
        10. 拿到三把 key：API Key、Secret Key、Passphrase
            （Secret Key 只显示一次，立刻复制）

        【设权限：只勾要的、不勾提币】
        11. 点该 key 进入 Edit：
            - 勾选需要的 Trade 类别（Spot 或 Futures，依你策略）
            - 不要勾 Withdraw
            - 不要勾 Transfer（除非你的机器人需要自动调度保证金）
            - 填入 IP 白名单（Bitget 官方「strongly recommended」，你就照做）
        12. Save changes

Secret Key 只会显示一次——这是所有交易所的共通规则。Bitget 因为多了 Passphrase，一起要存好——这三把 key 任何一把泄露，官方都写得明白会导致资产损失。密码管理工具（1Password、Bitwarden、macOS Keychain）都可以；贴进纯文本文件、Slack、Email 是不好的习惯，一次养成一次痛。

怎么挑串接 Bitget 的自动化工具

Bitget 目前是我们自己 TradingView Webhook 支持交易所整理里列为「有官方 REST／WebSocket API 可对接、能接自动下单」的名单成员——这代表市面上不少工具都声称能接。挑工具时值得问清楚三件事：

• 它会不会要求你把 key 开 Withdraw 权限？会的话直接跳过这个工具——现货与合约下单这件事，技术上永远不需要提币权限，会要求就是架构有问题。
• 它给你的固定 IP 有几个？多数 SaaS 是 1~3 个，你都塞得进 Bitget 的 IP 白名单字段；有些工具是动态出口 IP（每次调用可能不一样），这种你就没办法绑 IP 白名单，得回头权衡是不是可以接受。
• 你的三把 key（尤其是 Passphrase）存在他们那边的方式是什么？明文存在数据库是警讯；加密存储而且加密主密钥跟数据库实体分开存放，是值得问清楚的基本门槛。

就我们自己来说：TVSBot 用 Fernet（AES-128-CBC + HMAC-SHA256）加密存储你的三把 key，加密主密钥只存在环境变量、跟数据库本身分开存放；每一笔下单都直接用你自己的 key 调用 Bitget API，我们不会持有你的资金；设置文档建议使用者只开 Trade 权限、并提供一组固定出口 IP 让你填进 Bitget 白名单，并强烈建议把 key 建在 sub-account 而不是主账号。同一份 checklist 适用于任何非托管工具，不只是 TVSBot——所以就算你最后选了别家，这一节的清单也用得上。

诚实的一段：这篇文章没解决的问题

即便你把上面三个设置全部做好，还有一些风险是这篇教程无法帮你消除的，写在这里是为了让你有正确的预期：

第一，交易所本身被黑这件事没有 API key 层级的防御可以挡——你的资产放在 Bitget 上，就是承担 Bitget 这个平台的营运风险。这一层要靠交易所的 Proof of Reserves、保险基金、以及你自己分散持有到多家平台或冷钱包来处理，不是靠 key 怎么设置。

第二，你自己的策略把钱亏掉，跟 API key 安全无关——这篇没有讨论任何策略层面的风险。任何自动化交易架构都不会替你保证赚到钱，这件事永远成立；即使是最保守的 grid bot、资费套利，遇到极端行情都会亏损。策略层面的风险评估请看我们的 Kelly 公式与仓位大小、ATR 波动率动态调整仓位两篇。

第三，我们没能对 Bitget 做完整的内部制度审计——本文所有关于 Bitget 官方规则的叙述，都是根据可公开查证的文档与账户页面内容整理出来的，查证日期 2026 年 7 月。交易所政策会在没有太多预告的情况下变动，实际设置前建议自己再去 Bitget 官方 API 文档页面确认一次现行规则。

常见问题