> ## Documentation Index
> Fetch the complete documentation index at: https://docs.oddspapi.io/llms.txt
> Use this file to discover all available pages before exploring further.

# Sharp 盘口交易与 CLV —— 限额、延迟与收盘线价值

> 在 OddsPapi 上针对 sharp 博彩商盘口交易：每条价格的投注限额、各博彩商的实测观察延迟、主盘过滤、陈旧数据处理，以及 CLV 测量。

Sharp 博彩商是市场其余部分定价的基准。要在其上交易得好，需要三样普通赔率数据源通常给不了的东西：**该价格上的可成交量**、**可测量的延迟**，以及**用于给自己打分的收盘线**。

***

## 只有价格不够 —— 把量一起拿走

[`odds`](/zh/websocket/channels/odds) 频道上的每个 outcome 都携带 `limit`：该价格上可接受的最大投注额，跨博彩商归一化，且几乎每家 sharp 博彩商都携带。

```json theme={null}
{
  "bookmaker": "pinnacle",
  "outcomeId": 111,
  "price": 1.155,
  "limit": 19354,
  "mainLine": true,
  "bookmakerChangedAt": 1776717657043,
  "changedAt": 1776717657402
}
```

### `limit` 与深度回答的是不同的问题

同一条赔率行上可能传来两个规模信号，把二者混为一谈是过度定量的常见方式：

* **`limit`** 约束的是单笔订单 —— 博彩商在这个价格上最多接受多少。
* **阶梯**（`meta.back` / `meta.lay`，见于交易所与预测市场）约束的是成交结果 —— 触及价之后还挂着多少量，也就是清掉某个规模要付出多少成本。

在传统 sharp 博彩商上没有阶梯，`limit` 就是全部答案：一个数字、一笔订单，想要更多就只能等博彩商重新挂出。在交易所与预测市场上您两者兼有，且二者各自独立地构成约束 —— 面对一个稀薄的阶梯，再宽松的 `limit` 也只会成交得很差。

在有深度的地方，**请以成交量加权均价而非触及价来给这笔成交定价。** 沿阶梯走到您的目标规模，并使用由此得到的均价；只要超出第一档，盘口顶部价就是一个您拿不到的数字。按触及价定量，正是让建模出的优势在您最想做的那几笔交易上变成实际亏损的原因。

深度同样是**按场馆计的，绝不能汇总。** 把各家的阶梯加总，得到的是一个您无法据以交易的总量，因为一个场馆的订单不会去吃另一个场馆的挂单。请按博彩商建模可执行规模，再在选项层面做比较。

### 限额下调本身就是信号

限额变化以普通赔率更新的形式、在同一个 `oddsId` 上到达，因此某家博彩商收紧可成交量会出现在同一条数据流中 —— 往往**更早**，也往往信息量更大。一家 sharp 博彩商维持价格却把限额砍半，这传达的信息是价格本身没有的。

若想利用这一点，请把限额历史与价格历史一并记录。REST [历史赔率](/zh/api-reference/concepts#历史赔率与-clv)接口承载同样的赔率行，因此该序列既可以实时观察，也可以事后重建。

***

## 掌握各博彩商的延迟

四个时间戳随数据一同传输，因此延迟是可验证的，而非假定的：

| 阶段 | 字段                   | 含义                 |
| -- | -------------------- | ------------------ |
| t0 | `bookmakerChangedAt` | 博彩商自己的变更时间戳（如有提供）  |
| t1 | `changedAt`          | OddsPapi 观察到该变更的时间 |
| t2 | `ts`（信封）             | 网关发送消息的时间          |
| t3 | —                    | 您的接收时间             |

`changedAt − bookmakerChangedAt` 即该条更新的观察延迟。各博彩商的上限发布在 `GET /bookmakers`（`maxDelayLiveInSec`、`maxDelayPregameInSec`、`maxDelayPregameMainInSec`），代表性滚动 p50 见[延迟与新鲜度](/zh/api-reference/reliability#延迟与新鲜度)。

有两件事值得尽早接入：按成交记录 t0–t3，以便将糟糕的成交归因到正确的环节；以及[部署在网关附近](/zh/api-reference/concepts#服务器位置很重要) —— 最后一跳是您唯一能掌控的部分。

***

## 当博彩商不再是最新时停止交易

| 信号                    | 频道                                                | 含义                     |
| --------------------- | ------------------------------------------------- | ---------------------- |
| `staleOdds`           | [`bookmakers`](/zh/websocket/channels/bookmakers) | 与该博彩商的连接已降级 —— 新鲜度无法保证 |
| `suspended`           | `bookmakers`                                      | 该博彩商的赔率已暂停             |
| `marketActive: false` | `odds`                                            | 整个盘口已关闭                |
| `active: false`       | `odds`                                            | 该 outcome 不可用          |

请把 `staleOdds` 当作按博彩商的熔断开关，而不是一条警告 —— 陈旧的 sharp 盘口比没有盘口更糟，因为它看起来仍然可交易。

同时关注 `bookmakers` 频道上的 `participantsRotated`：某家博彩商的主客队分配若与 OddsPapi 基准不同，会被误读为并不存在的套利机会。

***

## 主盘与变更过滤

* `mainLine` 标记该博彩商在某盘口上的主盘，让您无需订阅所有替代盘口即可跟踪头部价格。
* `GET /fixtures/odds/main` 在快照中仅返回主盘。
* 赔率接口上的 `since` 过滤（纪元**毫秒**）让您只回填发生变化的部分。参见[时间戳](/zh/api-reference/concepts#时间戳秒与毫秒)。

请记住每个线值都是独立的 `marketId` —— "大 2.5"与"大 3.5"是不同盘口，而非同一盘口的两个选项。计算水位与归一化时按 `marketId` 分组。

***

## 亚洲盘口

亚洲让分盘与四分之一盘是一等公民：`marketType` 为 `spreads`，线值在 `handicap` 中（例如 `-0.25`），结算在 `WIN` / `LOSE` / `PUSH` 之外返回 `HALFWIN` / `HALFLOSS` 用于半注结算。参见[枚举 → settlementStatus](/zh/api-reference/enumerations#settlementstatus)。

对于以加密货币或非美元法币报价的博彩商，[`currencies`](/zh/websocket/channels/currencies) 频道提供法币与加密货币对美元的汇率，用于本金与限额换算。

***

## 以收盘线给自己打分

用数据流交易，用 REST 测量。实时频道以固定约 10 毫秒窗口交付合并状态 —— 最新值始终会到达，但同一窗口内被取代的中间跳动不会，因此数据流不是逐跳账本。需要完整变动与开/收盘价时：

| 用途        | 赛事                              | 期货                             |
| --------- | ------------------------------- | ------------------------------ |
| 完整价格时间线   | `GET /fixtures/odds/historical` | `GET /futures/odds/historical` |
| 开盘 vs 收盘线 | `GET /fixtures/odds/clv`        | `GET /futures/odds/clv`        |

两者与实时数据流共用 `oddsId` 键（`{fixtureId}:{bookmaker}:{outcomeId}:{playerId}`），因此成交记录无需映射步骤即可关联到自己的收盘线。

<Steps>
  <Step title="记录成交">
    存储 `oddsId`、您的成交价，以及交易时刻的 t0–t3。
  </Step>

  <Step title="拉取收盘">
    赛事开始后，对这些 `oddsId` 调用 `/fixtures/odds/clv`。
  </Step>

  <Step title="打分">
    将成交价与收盘价对比得到 CLV，与记录的时间线（`/fixtures/odds/historical`）对比做滑点归因。
  </Step>

  <Step title="结算">
    使用 `GET /fixtures/settlement` 获取逐 outcome 结果，而不是自建结算逻辑。
  </Step>
</Steps>

一个按博彩商、按延迟区间记录 CLV 的交易台，通常在积累一周数据后就能看清自己的优势究竟来自哪里 —— 以及自己所支付的延迟是不是真正重要的那一段。

***

## 您可以依赖的保证

* **延迟按博彩商逐家公布，且为实测值。** `maxDelayLiveInSec` / `maxDelayPregameInSec` / `maxDelayPregameMainInSec` 在博彩商提供可用时间戳时来自「观测时刻对比博彩商时刻」的实测，在其不提供时则明确标注为估算值。四段时间戳链意味着您可以用自己的时钟去核对这些数字，而不必只能选择相信。
* **不会丢弃任何变化。** 更新在固定约 10 ms 的窗口内合并，最新值一定会送达 —— 数据流是最新状态，而非有损采样。需要每一跳时，REST 历史接口中都有。
* **ID 跨赛季保持可寻址。** 盘口分类法只追加 —— 随着覆盖增长会出现新的 `marketType` 值，已有值的含义永不改变 —— 且同一组坐标始终解析到同一个 `marketId` / `outcomeId`。针对上赛季数据编写的回测，今天寻址到的仍是同一批选项。