Polymarket 有测试网吗？

这让从加密货币交易所转过来的人很意外，因为在交易所里测试网是标配。Binance 有测试网。Polymarket 最接近的竞争对手 Kalshi 在 demo-api.kalshi.com 运行着一个完整的沙盒，用虚拟资金镜像生产 API。Polymarket 没有任何对应的东西。

所以实际的问题不是测试网在哪里，而是当唯一的环境就是生产环境时，我该如何降低策略的风险？有四种方法，它们能发现的 bug 类型各不相同。大多数人需要不止一种。

为什么没有测试网

理解原因是值得的，因为它解释了为什么测试网不太可能出现。Polymarket 是一个在 Polygon 上结算的链上订单簿。测试网需要的不只是一份 API 的副本，还需要一套并行部署的 CTF 交易所合约、一个测试网 pUSD、一个撮合引擎，以及一个双边都有真实流动性的合成订单簿。

最后这一项才是难点。一个只有虚假流动性的沙盒订单簿几乎教不了你任何有用的东西，因为你真正需要了解的是你的订单如何与真实对手方交互：什么能成交、以什么价格成交、有多少滑点。测试网给你的是一个能跑通的集成，以及一种虚假的优势感。可以说这比什么都没有还糟。

没有测试网时的四种测试方法

1. 免费测试所有不涉及下单的部分

相当比例的机器人 bug 与交易本身毫无关系。认证、请求签名、时钟漂移、分页、小数处理、重连逻辑、速率限制退避，这些都可以对着生产环境的只读端点进行检验，不花一分钱，也不下一笔订单。

市场数据端点是公开的，无需认证。把你的机器人指向它们，跑上一天，你就能在任何资金面临风险之前发现大部分集成缺陷。

# Public, unauthenticated, safe to hammer (within rate limits).
curl -s "https://clob.polymarket.com/book?token_id=<TOKEN_ID>" | jq .

# Confirm your auth works without placing an order:
# a 200 here proves your key, secret, passphrase and clock are all correct.
curl -s "https://clob.polymarket.com/auth/api-keys" \
  -H "POLY_ADDRESS: $ADDRESS" \
  -H "POLY_SIGNATURE: $SIG" \
  -H "POLY_TIMESTAMP: $TS" \
  -H "POLY_NONCE: 0" | jq .

2. 基于历史订单簿回测

这是现有的最接近测试网的东西，而且它能回答一个任何测试网都无法回答的问题：这个策略真的能赚钱吗？

问题在于 Polymarket 自己的 API 无法提供这些数据。它只提供订单簿的当前状态。没有历史深度存档，市场一旦结算，它的订单簿就会返回 404。无论哪个速率限制档位、哪个套餐，你都无法通过 API 重建上周二 14:03:17 时订单簿的样子。

所以回测需要有人在市场运行期间记录下来的时点快照。这正是 PolyTest 做的事：240M+ 条 Polymarket 加密货币 Up/Down 市场快照，双边 8 档订单簿深度，亚秒级时间戳，已结算的市场会被保留而不是丢弃。

# List recent BTC 5-minute Up/Down markets
curl -H "X-API-Key: $POLYTEST_KEY" \
  "https://api.polytest.io/api/v1/markets?coin=btc&market_type=5m&limit=20"

# Replay one market's book, snapshot by snapshot
curl -H "X-API-Key: $POLYTEST_KEY" \
  "https://api.polytest.io/api/v1/markets/$MARKET_ID/snapshots?include_orderbook=true"

3. 基于实时价格模拟交易

回测证明的是优势在历史上存在过。模拟交易证明的是你的机器人现在能用：它能重连、能处理 429、能正确读取时钟，并能在真实条件下实时生成信号。

Polymarket 没有专门的端点做这件事，所以你需要自己搭建：让你的实盘策略循环对着生产市场数据运行，不调用 POST /order，而是把预期订单连同那一刻的订单簿状态写入日志。然后对照订单簿接下来的变化来评估它。

// A paper-trading shim: identical interface, no capital at risk.
interface OrderIntent {
  tokenId: string;
  side: "BUY" | "SELL";
  price: number;
  size: number;
}

class PaperExecutor {
  readonly fills: Array<OrderIntent & { at: number; bookTop: number }> = [];

  async submit(intent: OrderIntent, book: { asks: { price: number; size: number }[] }) {
    // Record what the book actually looked like at decision time —
    // this is what lets you mark the trade honestly afterwards.
    this.fills.push({ ...intent, at: Date.now(), bookTop: book.asks[0].price });
  }
}

// Swap this for the real CLOB client only once the numbers look right.
const executor = new PaperExecutor();

这种方法的局限是实实在在、无法避免的：模拟成交假设你拿到了成交。用这种方式你学不到排队位置或市场冲击。但你能知道你的机器人能否连续稳定运行一周，这是另一件同样必要的事。

4. 小规模上线实盘

最终你必须下一笔真实订单。说实话，这才是真正的测试，之前的一切都只是彩排。要有计划地进行：最小规模、单一市场、硬性仓位上限，以及一个你真正测试过的紧急停止开关。

• 从市场最小下单量开始，而不是从你预期的规模开始。
• 在代码里限制总敞口，而不是在脑子里。
• 先测试撤单路径，再测试入场路径。无法退出比无法入场更糟。
• 显式处理 503 仅取消模式：一个先重新报价再撤单的机器人可能会陷入循环，而不是平仓。
• 第一周记录每一个请求和响应。你会用得上的。

Polymarket US 呢？

Polymarket US，即面向美国的受监管实体，是另一回事。它曾在入驻流程中为合格的集成合作伙伴提供沙盒环境访问，之后再发放生产凭证。这是面向已获批合作伙伴的商业入驻流程，而不是自助式测试网：你没法今天下午注册就开始调用它，而且它对基于主要的国际 CLOB 进行开发的人也没有帮助。

一套行之有效的测试流程

1. 只读集成测试，对着生产市场数据进行。验证认证、解析和退避。免费，一天即可。
2. 基于历史订单簿回测，并进行真实的成交模拟。证明优势存在并能扛住价差。大多数策略都死在这一步，死在这里总比在真金白银上死好。
3. 实盘模拟交易至少一周。证明机器人在运维上可靠：持续运行、重连、速率限制、时钟。
4. 以最小规模上线实盘，设置硬性敞口上限和经过测试的紧急停止开关。
5. 只有在实盘数据与模拟数据吻合后才扩大规模。如果两者有差距，说明你的成交模型错了，回到第 2 步。

第 1、3、4 步你几天内就能自己搭好。第 2 步需要从 Polymarket 拿不到的数据，而它也是最常帮人省钱的一步。在 PolyTest 开始免费试用：三天足够看出你的想法是否站得住脚。