理论永远抵不过真实事故。本文复盘几起 The Graph 生态中被公开讨论过的漏洞与运营事故，从原因到对策一一拆解。读完之后，你应能在自己的项目中预先规避同类问题。
案例一：事件解析漏掉小数位
某币安智能链上的 DEX 子图，将代币精度硬编码为 18 位，遇到 6 位精度的稳定币时全部错算。前端展示的总锁仓量瞬间膨胀百倍，引发用户恐慌。复盘发现根因在 Mapping 函数中没有调用合约的 decimals 方法。修复方法：始终用合约调用获取精度，并把结果缓存到实体里。更多类似踩坑详见 The Graph常见错误。
案例二：起始区块设错导致历史数据缺失
一个借贷协议在升级时把 subgraph.yaml 的 startBlock 改成了升级后的区块号。结果新子图查不到任何历史借贷记录，前端图表出现断崖式空白。最终通过回滚到旧版本并合并数据才恢复。预防办法是把 startBlock 写入参数文件，由 CI 校验是否与合约首次部署区块一致。
案例三：查询接口被恶意爬取
某 NFT 行情站把 The Graph 接口直接暴露给前端，没有任何限速。攻击者用脚本批量爬取所有藏品历史，导致节点 CPU 飙升、其他正常用户查询超时。整改后接入了 Cloudflare 限速与查询复杂度评估，事件没有再发生。完整网关方案在 The Graph进阶教程 中有详细描述。
案例四：Indexer 同步落后未及时告警
去中心化网络上的某子图，由于唯一 Indexer 节点出问题，同步落后 5 万个区块，但项目方未察觉。直到用户反馈数据陈旧才发现。教训是：永远不要依赖单一 Indexer，并为同步进度设置严格告警。运维基线可参考 The Graph最佳实践。
案例五：依赖包供应链投毒
某中型团队引入了一个名字相似的「graph-ts-utils」，结果它在编译时会上传环境变量到外部服务器。万幸团队在 CI 中做了出口流量审计，及时发现并下架。该案例提醒所有人，npm 上看似无害的小工具同样需要严格审核。
复盘机制建设
事故发生不可怕，没有复盘才可怕。建议每起事故都形成可分享的报告，并把改进项纳入下一季度的 OKR。参考 The Graph官方文档 中的 Incident Template，可以快速搭建团队的复盘模板。
把别人的事故变成自己的常识，是工程团队最划算的投资。希望这些案例能帮助你的项目在子图侧少走弯路。