开始之前

接口路径没变，旧客户端也可能失效。本例同时引入两个独立变化：请求必须提供 region，响应 id 从字符串变成整数。它们应分别评估，不能只靠提高版本号解决。

边看边操作在 接口版本兼容性对比 中打开实际工作区
01

载入旧版文档

在左侧放入这个可直接复现的基线。旧调用方只需要在路径里提供订单 id。

示例
{
  "openapi": "3.0.3",
  "info": {
    "title": "订单查询示例",
    "version": "1.0.0"
  },
  "paths": {
    "/orders/{id}": {
      "get": {
        "operationId": "getOrder",
        "parameters": [
          {
            "name": "id",
            "in": "path",
            "required": true,
            "schema": {
              "type": "string"
            }
          }
        ],
        "responses": {
          "200": {
            "description": "成功",
            "content": {
              "application/json": {
                "schema": {
                  "type": "object",
                  "required": [
                    "id"
                  ],
                  "properties": {
                    "id": {
                      "type": "string"
                    },
                    "status": {
                      "type": "string"
                    }
                  }
                }
              }
            }
          }
        }
      }
    }
  }
}
02

载入有风险的新版

右侧放入下面文档，再开始分析。注意响应的数字 ID 和路径参数的字符串 ID 属于不同位置。

示例
{
  "openapi": "3.0.3",
  "info": {
    "title": "订单查询示例",
    "version": "2.0.0"
  },
  "paths": {
    "/orders/{id}": {
      "get": {
        "operationId": "getOrder",
        "parameters": [
          {
            "name": "id",
            "in": "path",
            "required": true,
            "schema": {
              "type": "string"
            }
          },
          {
            "name": "region",
            "in": "query",
            "required": true,
            "schema": {
              "type": "string"
            }
          }
        ],
        "responses": {
          "200": {
            "description": "成功",
            "content": {
              "application/json": {
                "schema": {
                  "type": "object",
                  "required": [
                    "id"
                  ],
                  "properties": {
                    "id": {
                      "type": "integer"
                    },
                    "status": {
                      "type": "string"
                    }
                  }
                }
              }
            }
          }
        }
      }
    }
  }
}
03

找到两条风险

预期至少看到“新增必填参数”region 和“类型变化”id；通常还会看到操作定义变化的 review。按参数位置和响应媒体类型逐项核对，不用报告条数代替风险判断。

04

验证旧调用方并选择迁移方式

在自己的测试环境，用不带 region 的旧请求，以及按字符串读取 id 的客户端分别验证。可考虑让新参数先可选并给出明确默认行为，或保留旧版接口与响应格式；具体策略由真实服务契约决定。

不要用删掉 required 掩盖实际要求

只有服务端确实允许缺省值，才能把参数改为可选。文档与实现不一致会把故障转移到联调阶段。修订后重新比较，再运行受影响的消费者测试。

风险提示并非漏洞结论

这里的 risk 表示兼容性风险线索，不代表安全漏洞，也不代表工具执行过失败请求。删除接口、删除响应状态、缩小枚举等变更也需要复核。

规范依据与检查范围

以 OpenAPI 3.0 / 3.1 为输入。工具在浏览器本地执行基础结构检查，不调用实际 API，不自动获取外部引用，也不替代完整规范校验、鉴权测试或消费者契约测试。

要点总结
  • 新增请求必填项可能使旧请求失效。
  • 类型变化要在真实客户端验证。
  • 迁移方案应同时修改文档、实现和测试。