
> 《micro-one-api 拆解》第 30 篇
> 代码核对：`v0.41.0` / `372391f`

---

## 0. 0.019168 元能证明什么

11 月 8 日，我把核账范围压到四笔请求：一个来源、一个模型、四个入口，全部命中同一段闲时价格。四次上游尝试都没有重试，最终用量是 19,052 个未缓存输入、29 个输出。上游费用页在延迟窗口结束后导出的小时行是 0.019168 CNY；我按同一组原币单价独立延展，差额是 0。

这个数字很小，小到很像一次演示。它确实只覆盖一次受控验收：四笔随机 ASCII 测试数据、最多四次上游尝试、每次最多 64 tokens、预算 1 元。但它也第一次把下面三件事放在同一条时间线上：

| 我看到的金额 | 它回答的问题 | 它不能回答什么 |
| --- | --- | --- |
| 平台 191 quota | 我的定价、预扣、usage 和账本有没有按当前规则扣 | 供应商最终实际收了多少钱 |
| 响应里的 usage | 上游这一次报告了多少 token | 供应商账单有没有迟到更正 |
| 独立导出 0.019168 CNY | 供应商在已结束小时里报告的费用和数量 | 一个完整账期、真实业务流量或长期结算正确 |

前一篇讲的是账号安全的证据分层，这一篇讲钱。A3、A4、B1 各自补了一种能力，N1 只是拿四笔受控调用把其中一段跑通。它们放在一起，恰好能说明我为什么不愿意把“接口返回 200、金额对上了”写成“计费验完了”。

---

## 1. 计价与支付这四条线的来源

A3/A4/B1/N1 不是同一版发布。A3、A4 在 v0.37.0；B1 在 v0.38.0；N1 是 v0.39.3 之后的生产核账；价格页、毛利和未定价监控的修复又分别落在 v0.38.1、v0.39.2、v0.39.3。下面先把来源分开：

| 包或修复 | 来源 | 代码 / 验收 | 关键提交 |
| --- | --- | --- | --- |
| A3 服务档位 | `docs/design/a3-service-tier-contract-2026-10-27.md`、`docs/releases/release-v0.37.0.md` | `docs/runbooks/a3-service-tier-acceptance-2026-10-27.md` | `716bae15`、`39d0caf2` |
| A4 微信 Native | `docs/design/next-stage-plan-2026-10-26.md`、`docs/releases/release-v0.37.0.md` | `docs/runbooks/a4-wechat-native-acceptance-2026-10-28.md` | `a0c4c789` |
| B1 上下文 / 忙闲 | `docs/design/b1-context-time-pricing-contract-2026-10-29.md`、`docs/releases/release-v0.38.0.md` | `docs/runbooks/b1-context-time-pricing-acceptance-2026-10-29.md` | `62edafdc`、`29323ed7` |
| N1 闲时核账 | `docs/design/next-stage-plan-2026-11-08.md` | `docs/runbooks/n1-pricing-readonly-2026-11-08.md`、`docs/runbooks/n1-off-peak-paid-2026-11-08.md` | `f537f242`；实际调用不产生代码提交 |
| 价格页展示 | `docs/design/b1-context-time-pricing-contract-2026-10-29.md` 第 5 节 | `docs/runbooks/pricing-time-display-fix-2026-11-01.md` | `7852b717` |
| 模型价格发布 | `docs/releases/release-v0.39.2.md` | `docs/runbooks/model-pricing-publish-production-2026-11-02.md` | `b651b8bf` |
| 毛利 / 未定价监控 | `docs/releases/release-v0.39.3.md` | `docs/runbooks/billing-monitoring-recovery-2026-11-03.md` | `bde87d0f`、`629d5158` |

这张表也解释了为什么文章里经常出现“已部署但默认关闭”。A3/A4/B1 的代码上线，N1 的真实付费调用，和完整账期核验是三件不同的事；release note 里的部署状态不能替代后面的金额证据。

---

## 2. A3：请求的档位不等于实际执行的档位

A3 做的是单来源、单模型的服务档位计价。用户可以在请求里选择 default、priority、flex，但上游实际按哪个档位执行，不能从请求字段反推。请求写 priority，供应商回一个默认档位，这两件事都可能是真的。

所以我把一次计价拆成三层：

- 请求档位和实际档位分别记录；
- 预扣按所有可能的五桶价格取最高上界；
- 接纳时冻结来源、模型、价格和规则，结算时不再读实时配置。

完整保存 default/priority/flex 五桶售价，以及可选的采购估价。实际档位缺失、未知或与请求冲突时，不猜一个更便宜的；按 `actual_or_max_v1` 的最高价策略结算，并把证据缺口留在账本里。usage 缺失、非法、取消或流不完整时释放预扣，不用一个估算值冒充成功结算。

A3 冻结契约只接纳有明确输出上限的自包含纯文本。Chat 使用 `max_completion_tokens`，Responses 使用 `max_output_tokens`；图片、音频、工具、文件、外部会话状态、后台任务和多份生成不进入档位计价。这个范围看起来很窄，但每一类排除都对应一个无法从现有证据里确定最高价的边界。

入口矩阵也不是“所有请求都套新价格”：

| 入口 | 命中启用来源 | 未命中或关闭 |
| --- | --- | --- |
| OpenAI Chat Completions JSON/SSE | 支持有界纯文本 | 默认策略兼容；priority/flex 拒绝 |
| OpenAI Responses JSON/SSE | 支持自包含、有输出上限的纯文本 | 默认策略兼容；priority/flex 拒绝 |
| executor / 原生执行证据 v2 | 拒绝档位计价 | 不混用两套结算证据 |
| Responses WS | 拒绝档位计价 | 保持原策略 |
| 订阅来源、其他 provider / 协议 | 不在首期范围 | priority/flex 拒绝 |
| 图片、音频、文件、工具、外部会话/previous_response_id、后台任务、多份生成 | 转发前拒绝 | 保留原入口能力与默认策略 |

配置只允许 `source_kind=channel`、正整数 ID 和一个精确模型名；`prices` 必须同时提供三档，采购估价一旦提供也必须完整。显式零价格有效，遗漏或 null 不自动当免费。整个对象通过带 `expected_revisions` 的单事务批量入口保存；读取需要全局售价与采购读取权限，写入需要两类全局写权限。Config-service 的同名配置不是生效来源。

三库真实 owner 链路从 Relay HTTP 进入，经过生成的 Billing/Log gRPC，再落到真实 SQLite/MySQL/PostgreSQL。Priority、Flex、默认回落、实际缺失/未知、JSON/SSE、执行中改价和重复结算都走了同一套价格快照。这里没有真实收费来源，默认也关闭；工程通过不等于生产计价已经放量。

---

## 3. A4：支付页最怕的不是失败，是“不知道结果”

微信 Native 充值接进来时，我先划掉了几个很容易扩大的范围：只做一个单商户 provider，只支持 CNY 余额充值，微信订阅购买明确拒绝，不做平台原路退款、拒付、多商户、JSAPI/H5/APP。

剩下的主链路仍然有一个资金问题：请求发出去了，网络超时了，二维码到底有没有生成？如果这时直接当失败，用户重新下单，平台和商户侧就可能出现两个订单；如果直接当成功，订单还没拿到可信终态，钱包又不能加钱。

最后的处理是先把本地订单持久化，再请求平台。充值请求带幂等键，订单号固定长度；同键重试先查单，只有可信的 NOTPAY / ORDER_NOT_EXIST 且订单未到期时，才用原订单号和原参数重入。二维码恢复在 Prepay 前用一个 30 秒条件认领，HTTP 超时 10 秒；写回必须带同一认领凭证，租约替换后迟到的响应不能覆盖新二维码。

支付状态可以压成下面这张表：

| 现场状态 | 平台结果不确定时怎么做 | 不能做什么 |
| --- | --- | --- |
| 本地订单已建，Prepay 超时 | 保留 pending，同键先查单 | 不能直接重新下单 |
| 查单返回可信 NOTPAY / ORDER_NOT_EXIST | 未到期时用原订单号和参数重入 | 不能换一个新订单号绕过幂等 |
| 回调签名失败、时间戳过期、金额/币种不符 | 拒绝发放，保留审计 | 不能靠“回调到了”直接加钱 |
| 已支付后收到迟到关闭 | 保留 paid，不改状态 | 不能被关闭事件覆盖 |
| 已关闭后收到迟到成功 | 拒绝再次发放 | 不能把关闭订单重新打开 |
| 并发查单 + 通知 | 同一事务只写一次钱包和充值账本 | 不能靠进程内锁当正确性保证 |

支付成功边界分成两层：

1. provider 验签、时间戳、解密报文、AppID、商户号、Native 类型和 CNY；
2. 共享业务边界再核对本地订单、渠道、金额、币种和平台交易号。

查单和回调最终都进 `PaymentUsecase → MarkOrderPaid`。订单行锁、钱包增量、充值账本和幂等 claim 在同一事务完成。已支付订单不会被迟到的关闭覆盖，已关闭订单也不会因为迟到的成功通知再次发放。

工程验证里，16 路查单和通知并发只增加一次钱包余额、只写一条充值账本；三库都跑过完整迁移和真实 SQL；回调用官方 SDK `v0.2.21` 做 RSA 验签/AEAD 解密，超过 64 KiB、非 POST、未配置和错误签名在发放前拒绝。真实微信商户、付款和平台回调仍然是空着的门，默认关闭，不能用 fixture 代签。

---

## 4. B1：把时间和上下文一起冻结

B1 加的是长上下文和忙闲时段。两者都能改变整张价格表，单靠请求结束时再读一次配置，结算就会漂移。

长上下文的规则是单阈值、严格大于 T 才切整单五桶价；输入量包含缓存输入，输出不参与触发。忙闲时段支持显式时区、多个周内窗口、节假日排除和日历有效期。预扣时冻结时段带和完整 tariff，实际 usage 到了以后再判断上下文档位；异步恢复、跨时段结束、执行中改价和幂等重放都继续使用冻结规则。

这里有一个看似小的选择：阈值刚好等于 T 时不算长上下文。这样配置中的阈值只有一个含义，测试用例也直接跑 T−1 / T / T+1。另一个选择是缓存读取按四输入桶计算，输出排除；如果只看一个“总输入”字段，缓存命中和未命中的差异会被合并掉。

配置默认关闭，示例里的 null 不能启用。11 月 5 日，生产 `ServiceTierPricing` 从 revision 1 更新到 revision 2：日历有效期从 2026-12-31 延到 2027-12-31，节假日从空数组变成 62 个日期，忙时窗口和双倍价格不动。写入走管理端 owner 路径，产生三条成功审计，没有重启 billing 或 admin。

节假日表也有一个我明确没补的边界：调休上班日落在周末时，当前配置无法表达“额外工作日”。只改 `peak_windows` 会把所有周末都变成忙时；那需要新增 workday 覆盖字段，不能靠配置里的一段日期字符串糊过去。日历到期后 `BandAt` 会报错，计费冻结拒绝该来源/模型，不会静默按旧日历收费。

B1 的工程验收还抓到过协议层的歧义字段：typed JSON 大小写兼容和 map 精确键曾导致限额/TOOLS 绕过，回归里 400 实际返回 200 且上游被调用；修复后 22 个 Chat、18 个 Responses 歧义字段用例都 400、0 上游、释放预扣，4 个真实发送上限控制通过。另有一次独立审查发现定价页没有展示已启用的忙闲价格，v0.38.1 从同一 owner 投影公开售价并刷新缓存；公开响应不带采购估价和内部来源。

---

## 5. N1：四笔请求怎么走到 0.019168

N1 的授权范围很窄：只测分时来源，最多四次上游尝试，每次最多输出 64 tokens，预算 1 CNY。目标固定为 channel 11 / `deepseek-flash`，当天是周日，四次都应该命中 Asia/Shanghai 的 off_peak。

为了不让默认分组的其他渠道混进来，我用 owner 接口创建了两组短生命周期测试夹具，只授予维护者账号、只含 channel 11，固定路由 Key 限该模型、10,000 quota、显式到期时间。第一组用于首笔 JSON；第二组只跑余下三笔。四笔请求都是随机 ASCII 输入，没有重放首笔，没有调用其他来源。

| 北京时间 | 入口 | 终态 | 未缓存输入 | 输出 | 平台 quota | 实际档位 |
| --- | --- | --- | ---: | ---: | ---: | --- |
| 18:47:31–18:47:32 | Chat JSON | 200 / stop | 4,784 | 12 | 48 | missing，按 max |
| 18:55:19–18:55:20 | Chat SSE | 200 / `[DONE]`，完整 usage | 4,805 | 15 | 49 | missing，按 max |
| 18:55:21–18:55:22 | Responses JSON | 200 / completed | 4,739 | 1 | 47 | reported default |
| 18:55:23–18:55:24 | Responses SSE | 200 / `response.completed` | 4,724 | 1 | 47 | reported default |
| 合计 | 4 请求 / 4 上游尝试 | 全通过 | 19,052 | 29 | **191** | 缓存读取、创建均为 0 |

四笔各有唯一 consume 账本和 version 4 的不可变分时快照。时区、`time_unix`、`off_peak`、倍率 1 和实际单价逐项核对；逐桶重放与四笔扣量一致。两笔 Chat 没有上游实际档位，采购估价保持 `unpriced/0`，两笔 Responses 报告 default，采购估价各自 47 quota。

上游费用页在调用前固定本日、项目 Key 筛选，基线是 0 请求、0 token、0.00 CNY。四笔最后结束于 18:55:24，我在 19:00:24 之后读取延迟窗口，避免把“还没出账”当成“没有费用”。独立小时行报告 0.0191680000000000 CNY（Paid），数量行也是 4 请求、19,052 未缓存输入、29 输出。

原币精确延展是：

```text
19,052 × 0.000001 + 29 × 0.000004 = 0.019168 CNY
```

输入/输出 CSV 的单价分别为 0.000001 / 0.000004，差额严格为 0。

这里还有一次验收脚本自己的时序问题。首笔响应在 18:47:32.865 完成，消费行在 18:47:33.248 才写入，差约 0.38 秒。脚本当时立即查账得到 0 行，保护条件让它停下来。后续只读查询确认同一请求已经 committed；我修改临时验收脚本，等结算终态再清理，没有改业务代码，也没有为了掩盖脚本问题再花一笔调用。账本异步落盘本来就可能比 HTTP 响应晚，拿“刚返回就查账”验收，测到的是脚本的急性子。

清理也按 owner 路径做：两枚测试 Key 通过接口删除，两条授权撤销，临时分组归档并保持成员为空，默认组仍为 2，channel 11 保持启用。测试账本和审计永久保留，不当夹具删除；配置 revision 因为夹具增删正常递增，不回退。

---

## 6. 价格发布和毛利告警的两次返工

N1 之前，模型页和价格页还有两个看起来不像计费的问题。

v0.39.2 修的是模型编辑页保存价格后，正式定价没有同步发布；用户必须再去管理价格页保存一次。修复后，模型页直接走正式价格发布入口并刷新公开/管理缓存。验收模型始终非公开、没有上游映射，读回模型库和正式配置后，只清理临时模型和价格键，保留写入审计。

v0.39.3 修的是告警口径。原来的毛利告警同时有全零窗口误报和净负差额漏报：仅看 P50 的符号，或者只统计盈利请求，会把一致方向看反。现在用整数负值边界 `-1` 做直方图，用非负盈利、亏损计数器的速率之差计算总差额，只在落账或事务提交成功后观测；重试、拆账和回滚都有回归覆盖。

未定价监控则是另一个权限边界。后台每分钟调用 `ListUnpricedRoutedModels` 得到 `PermissionDenied`，admin-api 能采集却没有计数。修复没有把人工读取权限放宽，而是新增仅限专用 admin 服务身份的 gRPC `CountUnpricedRoutedModels`，只返回两种来源的计数；人工接口仍走 owner 校验。读取失败时保留上次计数和求值失败，成功时间不刷新，指标缺失不会被当成 0。

11 月 3 日部署后，`unpriced routed metric evaluation failed` 从每分钟 1 条降到 0，成功值为 1 且持续刷新。毛利告警仍然 firing，原因是缓存读取售价 $0.006/百万 token 低于采购估价 $0.007/百万 token；这是配置价差，不是修复误报。我没有为了让告警消失去改价。

---

## 7. 这四笔能证明什么，不能证明什么

| 已经有的证据 | 结论 | 仍然不能证明 |
| --- | --- | --- |
| A3 三库 owner 链路、档位快照、改价冻结 | 档位计价代码在同一组测试规则下可重放、可结算 | 真实来源的实际档位和付费调用 |
| A4 SQLite/MySQL/PostgreSQL 并发、真实 Native SDK fixture、回调边界 | 同一订单不会重复加钱，签名/金额/币种错误会拒绝 | 真实商户扫码、真实付款、平台回调 |
| B1 T−1/T/T+1、时区、节假日、跨时段恢复 | 冻结时段和长上下文规则按预期解释 | 每天持续运行的日历和完整账期 |
| N1 四入口、4 次尝试、191 quota、独立导出 0.019168 | 这一个来源、这一个小时、这四笔请求的金额和数量严格一致 | 忙时、普通计价、其他模型、其他供应商、长期结算 |
| v0.39.2 / v0.39.3 生产记录 | 价格发布和监控链路在受控部署上可见、可回读 | 售价与采购价长期保持正毛利 |

N1 结束后，维护者明确说忙时和普通计价不再重测；所以我不把这两项写成“已通过”，只记成“明确不需要本轮测试”。四枚测试 Key、授权和临时分组都已清理，历史和审计保留。账本不回写，配置 revision 也不回退。

四笔请求走到 0.019168 元，我能负责的结论是：这条受控链路里，平台扣量、上游用量和独立人民币费用对上了。下一笔真实流量的价格、供应商的迟到更正、一个完整账期的对账，还在另一层。把这三层分开，才是我现在敢说“这四笔验过了”的原因。

下一篇离开计费，去看备份：导入只花了 21.184 秒，我为什么仍然不写“可以恢复”。

### 代码与阅读入口

| 想核对的内容 | 仓库入口 |
| --- | --- |
| A3 档位配置、五桶价格和最高预扣 | `domain/billing/service_tier.go`、`app/billing/internal/biz/service_tier.go`、`docs/design/a3-service-tier-contract-2026-10-27.md` |
| B1 长上下文整单价与阈值 | `domain/billing/long_context.go`、`app/billing/internal/biz/long_context_test.go`、`docs/design/b1-context-time-pricing-contract-2026-10-29.md` |
| 忙闲时段、节假日和日历边界 | `domain/billing/time_pricing.go`、`domain/billing/time_pricing_test.go` |
| 价格快照与冻结重放 | `app/billing/internal/biz/pricing_snapshot.go`、`app/billing/internal/biz/pricing_snapshot_test.go`、`app/billing/internal/data/pricing_snapshot_repo.go` |
| 微信 Native 创建、查单、回调和幂等 | `app/billing/internal/biz/payment_wechat.go`、`app/billing/internal/data/payment_wechat.go`、`app/billing/internal/data/payment_wechat_concurrency_test.go` |
| 毛利和未定价监控 | `app/billing/internal/biz/gross_profit_metric_test.go`、`app/admin/internal/service/unpriced_metric.go`、`app/channel/internal/server/unpriced_metric_test.go` |
| 验收与事实边界 | `docs/runbooks/a3-service-tier-acceptance-2026-10-27.md`、`docs/runbooks/a4-wechat-native-acceptance-2026-10-28.md`、`docs/runbooks/b1-context-time-pricing-acceptance-2026-10-29.md`、`docs/runbooks/n1-pricing-readonly-2026-11-08.md`、`docs/runbooks/n1-off-peak-paid-2026-11-08.md` |
| 版本与发布记录 | `docs/releases/release-v0.37.0.md`、`docs/releases/release-v0.38.0.md`、`docs/releases/release-v0.39.2.md`、`docs/releases/release-v0.39.3.md` |


《micro-one-api 拆解》第 30 篇 代码核对：v0.41.0 / 372391f

四笔请求、0.019168 元：我为什么还不肯说计费验完了

后端

基于micro-one-api v0.41.0代码与账本核验，四笔受控请求（19,052输入/29输出）独立导出费用0.019168CNY，与平台扣量、上游用量严格一致。文章厘清A3/A4/B1/N1功能边界与证据分层，明确验证范围仅限该小时、该模型，不涵盖忙时定价、长期账期及供应商更正。价格发布与毛利告警修复已上线，但生产计费全面验证仍需完整账期支撑。

代码解释

PostgreSQL

DeepSeek

路由

SQLite

MySQL

JSON

腾讯云双十一大促

apigw

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

基于micro-one-api v0.41.0代码与账本核验，四笔受控请求（19,052输入/29输出）独立导出费用0.019168CNY，与平台扣量、上游用量严格一致。文章厘清A3/A4/B1/N1功能边界与证据分层，明确验证范围仅限该小时、该模型，不涵盖忙时定价、长期账期及供应商更正。价格发布与毛利告警修复已上线，...

四笔请求、0.019168 元：我为什么还不肯说计费验完了-腾讯云开发者社区-腾讯云

四笔请求、0.019168 元：我为什么还不肯说计费验完了

四笔请求、0.019168 元：我为什么还不肯说计费验完了

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐