最常用方式是在Headers中添加Accept头，值为application/vnd.yourapi.v1+json或X-API-Version: 1.2；推荐用环境变量{{api_version}}实现自动切换，避免手动修改出错；Accept头语义更准确、缓存友好且网关支持更好。
Postman怎么在Header里传API版本号
直接在 Headers 标签页加一行 Accept 或自定义头（如 X-API-Version），值填对应版本标识，是最常用且服务端兼容性最好的方式。Spring Boot、Express、FastAPI 等主流框架都原生支持基于 Accept 头的版本路由。
常见写法有两类：
-
Accept: application/vnd.yourapi.v1+json—— 基于内容协商的标准做法，适合 RESTful 设计 -
X-API-Version: 1.2—— 更直白，后端解析简单，但属于非标准扩展头
注意：如果后端用的是 Spring MVC 的 @RequestMapping(params = "version=1")，那 Header 传版本号无效，必须走查询参数或自定义注解，这点容易踩坑。
Postman里怎么让Header版本号随环境自动切换
别手动改 Headers 里的值——用环境变量 + 双花括号语法才是可持续方案。
操作步骤：
- 点击左上角「Environments」→「Add」新建环境，比如叫
dev - 添加变量：
api_version→ 值填v1；再建一个prod环境，api_version设为v2 - 在请求的
Headers中写：Accept→application/vnd.yourapi.{{api_version}}+json
这样切换环境时，Header 自动更新，避免发错版本导致 406 或 500。如果误把 {{api_version}} 写成 {{ api_version }}（带空格），Postman 不会报错但变量不生效，请求头实际发的是字面量 {{ api_version }}，后端收不到版本信息。
为什么用 Accept 头传版本比 query 参数更推荐
因为版本本质是「客户端期望的响应语义」，不是业务查询条件，放在 Accept 头语义更准确，也符合 HTTP 规范。
Postman 12.27.7 Windows x64 官方安装包，适用于 API 设计、调试、测试与协作。该系列包含 Enterprise 云端性能测试静态 IP 出口能力，以及接口规范标签管理改进，适合受限网络测试与规范资源组织场景。
对比影响：
-
GET /users?version=v2：URL 变了，CDN 缓存、日志聚合、网关路由规则都要额外适配 version 参数 -
GET /users+Accept: application/vnd.yourapi.v2+json：URL 不变，缓存友好，网关可统一做版本分流，后端也能复用同一套路径逻辑
另外，某些网关（如 Kong、APISIX）原生支持基于 Accept 头做路由分发，而 query 参数需要额外配置正则提取，维护成本更高。
Pre-request Script 动态生成版本头的适用场景
只有当版本号依赖运行时计算（比如要拼接时间戳、哈希或从上一个响应中提取）时，才需要用脚本。
例如：
pm.request.headers.upsert({key: "X-API-Version", value: `v2-${Date.now().toString().slice(-6)}`});
但绝大多数业务版本是静态的（v1/v2/stable/beta），硬套脚本反而增加调试难度。更常见的错误是：脚本里写了 pm.environment.set("api_version", "v2")，却忘了在 Headers 里用 {{api_version}} 引用，结果 Header 还是空的。
复杂点在于，如果团队同时用 Header 和 query 两种方式传版本，后端没做冲突校验，就可能出现「Header 说要 v2，query 却传 v1」这种不一致，建议在 Pre-request Script 里加一行日志：console.log("Using API version:", pm.environment.get("api_version"))，方便快速定位问题。
