添加 Certyo 时你的代码会变成什么样：一个 5 行代码的集成走查

最小集成

如果你有一个把记录写到数据库的服务，最小的添加就是在每次写之后向 /api/v1/records POST 一次。请求体是记录本身加上租户标识。响应是一个 202 Accepted，里面有一个记录标识，你可以把它存在你那一行旁边。

读取路径不变。你的应用继续像以前一样从你的数据库里读。完整性证明在验证时按需计算——不是每次读都算。这就是让集成变小的设计选择：完整性是写入路径上的加法关切，不是读取路径的重写。

代码到底长什么样

三个具体例子——Node、Go、Python——同一个最小集成。每个大约 5 行新代码加进现有的写入处理函数：

• Node——在已有的 INSERT 后面紧接着 `await fetch(url, { method: 'POST', headers, body: JSON.stringify({ tenantId, clientId, record }) })`。在快乐路径下 fetch 是 fire-and-forget；202 响应确认记录进入了摄入队列。
• Go——一次 `http.Post` 调用，payload 形状一样。如果想要非阻塞写就把它包进 goroutine，如果想在返回给用户前要硬持久化就同步调用。
• Python——在已有的 ORM save 旁边写 `requests.post(url, json={'tenantId': ..., 'clientId': ..., 'record': ...})`。如果你配了 session，库会处理连接复用和网络故障重试。

生产级版本会加什么

5 行版是真的，能跑 staging 或 PoC。生产版会在上面加三件事：幂等键，让重试请求不会重复锚定；本地 outbox，让瞬时网络故障不会丢记录；结构化错误处理，让锚定失败不会打断面向用户的写入。这些都不是 Certyo 特有的——任何带进程外副作用的工程任务你都会用同样的模式。

生产级版本算上幂等、outbox 和可观测性大概在 30 到 80 行。绝对值上仍然很小——和加任何带 at-least-once 语义的内部服务调用差不多。工程师会去摸 Outbox 或 Debezium 这类工具，理由在这里同样适用：写入路径上的持久副作用是已经被解决的问题。

集成实际是怎么流的

从你的应用到链上可验证证明的端到端流程有五个阶段。你的代码只参与第一阶段。后面的所有事情都由平台运行——你这边没东西要集成、要维护、要扩容：

验证步骤是另一个代码路径起作用的地方：当审计员或下游消费者想证明某条记录完好，他们调用 POST /api/v1/verify/record。这个调用也是单行的。验证结果是确定性的、任何第三方都能对照链上的 Merkle 根重新执行。这部分进的是交给合规的证据包，不进你的应用代码。

真正的工程成本在哪里

5 行的说法对集成是诚实的，但它可能掩盖了三个需要真正工程思考的地方。没有一个是阻塞性的，但工程师应该提前知道：

• 幂等设计 — 如果你的写入处理在失败时会重试——大多数构建得不错的处理函数都会——你需要确保重试请求不会产生重复的锚定记录。平台支持幂等键；工程决策是你数据里哪个自然键足够稳定可以当幂等键（通常是记录 UUID 或交易标识）。
• 故障模式策略 — 如果锚定调用失败，面向用户的写入该怎么办？阻塞直到锚定成功（强持久性，更高延迟）？继续往下走、之后再对账（更好的延迟，需要 outbox）？这是个策略决策，取决于记录的关键程度。大多数团队对绝大多数记录选"之后再对账"，对一小部分高风险记录选同步锚定。
• 把验证暴露出去 — 最小集成会锚定记录，但不会把验证暴露给最终用户。如果你的应用要在界面上显示"这条记录在 X 时间戳被验证过"，那就是读取路径上一点额外的小集成。不是免费，但也不是大多数团队的起点。

向你的工程评审者要什么

如果安全或合规负责人正在和工程一起评审 Certyo，正确的请求是一天的 spike：用 5 行版本搭起 staging 集成，让它跑过有代表性的写入子集，在验证 UI 里看结果，把生产级缺口写下来（幂等键、outbox、错误策略）。这个产出就是对完整集成可信的内部估算。它也是一个能跑的 staging 环境，让下一阶段的决定从理论变成具体。关于验证 API 的细节，见开发者门户。关于部署拓扑，见 /zh/about。

在写入路径上加完整性就是一个 HTTP 调用。读取路径不变。剩下的工程工作——幂等、重试、可观测性——和你为任何持久副作用做的工作是一样的。没有意外。