0. 连续五次失败，但这不是 flaky
我有一条每夜跑的 E2E：起一套完整的 compose（MySQL、Redis、所有服务），然后用 Playwright 跑管理后台的关键路径。
Tag: kratos
0. 两次看起来相反的判断
这篇讲两个性能决策，它们的结论看起来是相反的。
0. 这篇是给"想照抄这套结构"的人写的
前面 24 篇讲的是"我为什么这么做"。这一篇不一样——它讲具体怎么做。
0. 我给自己做了一次代码审查，然后否决了它的大部分方案
有一阵子我觉得代码里积了不少问题——文件越来越大、有几处逻辑我自己都记不清了。于是我让一个模型对 develop 做了一轮系统性审查，产出一份问题清单。
0. 差点发生的事：审计日志一条都没记
这段代码注释是我在 review 自己的时候发现的，编号 platform-L9：
0. 第一版对账：全是误报
我第一版的对账逻辑很简单：把钱包余额和账本净额比一下，不一致就报出来。
0. 两个现象，一个共同的形状
这篇复盘两次问题。它们表面上看没有关系：
0. 一个接口设计的取舍：用户没订阅，算不算错误
做这个接口的时候遇到的第一个问题不是技术问题，是语义问题。
0. 问题：缓存怎么知道该失效了
第 12 篇讲了三层缓存，但留了一个尾巴没讲：缓存什么时候该失效。
0. 一个数字让我决定加缓存
第 1 篇里算过一笔账：relay-gateway 处理一个请求，要打四次下游 gRPC——identity 鉴权、channel 选路、billing 预扣、billing 结算，外加写日志。
0. 一个编号，两种假设
我第一版迁移就是一个编号序列：001_xxx.sql、002_xxx.sql……每个文件一个号，跑的时候按号排序。
0. 一个看起来很简单的问题，答案不简单
用户买了一个月的套餐，付了 20 块。用了 10 天，要求退款。
摘要
这套结构里真正需要照抄的东西不多，但如果不照抄那几样，后面就很难改回来。这篇分成两部分：第一天必须有的（不做后面会痛），和可以后补的（做早了是浪费）。然后走一遍"加一个资源"的完整步骤。
0. 一个迟早要面对的问题
订阅账号会有各种"暂时不能用"的情况：被上游限流了、额度用完了、凭据过期了、上游在抖动。这些状态都要有退出机制——总不能因为一次 429 就永远不再用这个账号。
0. 一个第一次写 OAuth 刷新很容易漏掉的事
我第一版的 token 刷新逻辑大概是这样的：
0. 先说结论：只有四家需要真正写代码
接上游 provider 这件事，我一开始以为是"一家一个适配器"。写了才发现不是：三十多个渠道类型里，真正需要单独写协议转换逻辑的只有四家，其余二十多家全是同一个适配器的不同配置。
0. 一个把我绕进去的概念冲突
做订阅功能的时候，我脑子里只有一个"额度"概念：用户买了套餐，每个月能用 20 美元，超过就停。
摘要
有一批请求要的模型在所有渠道上都没配置，channel-service 全部返回"没有可用渠道"。这个错误跨 gRPC 回来是 codes.Unknown，而我的熔断器把它算作失败——于是用户传错一个模型名，整个网关的流量都被熔断器拒了。这篇讲这次之后我怎么重排错误分类，以及跨服务降级的其他几处取舍。
v0.30.0 是 v0.29.0 之后的 MINOR 启用与稳定性收口版本。v0.29.0 交付的分组重设计 v2（阶段 A–F）全部能力默认关闭、未经真实链路验收；本版按 v0.30 阶段路线图完成 P0 / P1 / P2 三个优先级共 7 项任务：接通部署开关并完成 MySQL / SQLite 真实服务验收，补齐路由 / outbox 可观测性与告警，收口管理台汇总性能与降级语义，为迁移 runner 增加旧元数据表预检，并补齐分组日常操作与账务解释链路。
摘要
这个项目还没上线。我在开发过程中把结构翻了一遍，而且方向还相反：第一次是把一个 2391 行的 internal/relay/server/http.go 拆开，第二次是把拆出去的九个服务收进 Kratos 大仓结构、抽出共享层，并写脚本卡住服务之间互相 import。这篇讲哪些线是我真的按需要切的，哪些只是抄了微服务的目录形状。
v0.29.0 是 micro-one-api 的 MINOR 路由分组重设计版本，交付分组重设计 v2 的全部实施阶段（A–F）。
v0.28.0 是 micro-one-api 项目在模型可观测性方向的一个重要版本。本版新增按来源与上游模型粒度的被动模型健康监测与管理台看板，修复了多轮 /v1/responses Websocket 连接按累计 usage 重复计费的问题，并把 404 模型不可用判定收窄到 API 形状响应体，避免误配 base_url 把整渠道模型标红。
v0.27.0 是 micro-one-api 项目面向个人部署者与运维审计场景的一个收口版本。本版修复了 SQLite Lite 从空环境到首个聊天请求之间的结算死锁与方言 schema 缺口，补齐了可重复验证的部署 Quickstart，新增只读的历史账务审计工具，并把 K3 canonical charge 灰度的验收 SQL 口径与安全依赖基线彻底固化。
摘要
本文整理 micro-one-api 从 v0.24.0 到 v0.26.5 共 8 个版本的发布内容。这个周期先完成控制台可用性、双语界面与用户协议和隐私协议基础，随后补齐模型模态与每 1M tokens 定价注册表，再进入用量语义与计费审计的核心建设，最后收口 Go 1.27 工具链、Relay 路由、控制台性能和 Responses 来源归因。范围覆盖 v0.23.3..v0.26.5，共 436 个文件变更、+18.1k/-5.7k 行。
micro-one-api v0.23.x 系列（v0.23.0 / v0.23.1 / v0.23.2）是项目在 relay-gateway 执行架构上的一个重要里程碑。这个系列为 /v1/chat/completions 与 /v1/responses 引入了一套 transport-neutral 的 executor 执行层，并通过 token allowlist 灰度门禁、失败矩阵测试和生产 canary 观察，在小流量、可回滚的前提下完成了新旧路径的验证与切换准备。与此同时，三个补丁版本持续加固了渠道健康、用量日志安全、协议兼容和失败边界。
本文是区块链浏览器系列的第五篇，项目完整代码在这里。