接口清单为什么是根基
接口评估的质量上限由资产清单决定：清单不全，后面的越权、数据暴露、旧版本检查都只能覆盖冰山一角。做法是把三方数据合并成一份接口总表——网关访问日志（真实流量）、开发维护的 OpenAPI 文档（设计意图）、App 与前端抓包样本（实际调用），再比对出入找未纳管的影子接口。
基本信息
| 来源 | 网关访问日志、OpenAPI/Swagger 文档、App 与前端流量 |
|---|---|
| 产出 | 接口总表：方法 / 路径 / 版本 / 认证方式 / 业务归属 |
| 重点对象 | 旧版本接口、内部接口、测试残留与调试端点 |
| 周期 | 评估开始时建立，结束后沉淀给客户持续维护 |
典型使用场景
- 评估启动阶段建立覆盖完整的测试基线
- 排查未纳管的影子接口与未下线测试端点
- 核对文档与实际实现的差异（文档写有鉴权、实际没有）
- 移动端与小程序接口的独立清单整理
- 为网关策略与限流规则提供配置依据
核对步骤
核对步骤
1. 导出网关访问日志中的路径与方法，按调用量排序形成候选清单
2. 合并 OpenAPI 文档与抓包样本，标注每个接口的业务归属与负责人
3. 与开发台账比对，标出未登记项（影子接口）与已下线仍在响应的项
4. 对影子接口确认生命周期：补齐鉴权、纳入网关管控或安排下线
5. 输出：接口总表 + 差异清单 + 处置建议数据来源与局限
| 来源 | 能反映什么 | 局限 |
|---|---|---|
| 网关日志 | 真实被调用的接口 | 内部直连与同机调用不经网关 |
| OpenAPI 文档 | 设计意图与参数定义 | 更新滞后，可能与实现不符 |
| App 与前端抓包 | 实际使用路径与版本 | 覆盖不全，难以发现后台工具接口 |
| 代码仓库路由 | 全部已注册路由 | 包含未启用与历史代码，噪音大 |
| 开发访谈 | 业务归属与生命周期 | 依赖受访者记忆，需要交叉验证 |
多版本 API 并存是常态：清单必须带版本维度（路径版本、请求头协商版本、子域版本），否则测试覆盖面会出现系统性缺口。
接口总表的字段里“业务归属”最重要：没有归属的接口在报告后无人整改，也没有人能在业务变更时同步维护。