很多团队把 The Graph 视作「读数据」的组件，因此放松了安全审计。然而子图一旦出现逻辑漏洞或查询接口被滥用，损失可能波及整个产品。本文从攻防视角整理一份审计清单。
子图逻辑层的审计要点
Mapping 函数虽然不直接持有资金，但它决定了下游数据的真实性。审计重点包括：事件解析是否正确、字段类型转换是否安全、外部合约调用是否做了空值校验。任何一项疏漏都可能让攻击者通过精心构造的事件污染统计结果。可结合 The Graph常见错误 中的高频问题逐条核对。
查询接口的滥用防护
GraphQL 查询的灵活性是双刃剑。攻击者可以构造极深的嵌套或大范围分页，把节点拖入慢查询。建议在网关层设置查询复杂度上限，并对高频 IP 做限速。涉及敏感字段时，配合 JWT 做白名单。具体配置可参考 The Graph进阶教程 中的网关章节。
Indexer 信任边界
在去中心化网络上，Indexer 是独立运营的第三方。即便 GRT 质押机制提供了一定威慑，仍建议项目方多接入两到三个 Indexer 做交叉验证。一旦某个 Indexer 返回异常数据，立即切到备用方。
供应链与依赖审计
子图通常依赖 graph-cli、graph-ts 与若干 npm 包。审计时要核对版本锁、源代码哈希，以及是否引入了未审计的脚本。建议把依赖白名单写入 CI，新增依赖必须经过 review。
升级与回滚演练
安全审计不仅是「找问题」，更要演练「出了问题怎么办」。每季度做一次完整的演练：从发现异常、暂停查询、切换版本到恢复数据，全流程跑通。参考 The Graph最佳实践 中的演练剧本，可以快速搭建团队 SOP。
与外部审计机构协作
关键业务子图建议至少接受一次外部审计。提供完整的 schema、Mapping 源码与部署历史，让审计师在最短时间内进入状态。审计报告中的每条 Issue 都要跟进闭环，避免「写完即归档」。
把安全前置到子图开发的第一天，未来的运维压力会小得多。这份清单可以直接作为项目的安全基线，结合自身业务持续扩展。