Postman不支持在Header表格中直接添加备注，因HTTP协议严格要求Key: Value格式，非法字符会导致400错误；替代方案是通过环境变量命名（如auth_token_dev_from_jwt）、Pre-request Script注释及Preset语义化命名来实现可维护的“备注”。
Postman 本身不支持给单个请求头（Header）直接添加备注或注释字段，你看到的 Key 和 Value 表格里没有“备注”列，强行在 Key 或 Value 里写说明（比如 Content-Type: application/json # JSON格式）会导致请求失败——服务器会把整行当键或值解析，而 # 不是 HTTP 头合法字符。
为什么不能在 Header 表格里加备注
HTTP 协议规定请求头必须是严格的 Key: Value 格式，中间只允许一个冒号，前后不能有空格以外的控制符或注释符号。Postman 的 Headers 表格底层就是按此规范校验并序列化发送的。一旦你在 Key 栏填 Authorization # token来源，它会被当作一个非法键名发送，服务器返回 400 Bad Request 或直接忽略。
替代方案：用 Pre-request Script 注释 + 环境变量命名来留痕
真正可落地、不影响请求且能长期维护的“备注”方式，是把说明信息藏在环境变量名或预请求脚本的注释里：
Postman 12.27.7
下载
Postman 12.27.7 Windows x64 官方安装包，适用于 API 设计、调试、测试与协作。该系列包含 Enterprise 云端性能测试静态 IP 出口能力，以及接口规范标签管理改进，适合受限网络测试与规范资源组织场景。
- 把 token 来源写进环境变量名，比如定义变量
auth_token_dev_from_jwt而不是笼统叫token，在Authorization的Value中写Bearer {{auth_token_dev_from_jwt}} - 在
Pre-request Script里加 JavaScript 注释，说明该头的用途和生成逻辑，例如：/* x-rio-signature: 网关要求的SHA256签名，基于timestamp+secret+nonce 来源：PAAS平台接入规范 v2.1 第4.3节 */
- 对需要多环境复用的头组合，用
Preset名称承载语义，如命名为Prod-APIv3-with-Signature而非Headers-1
批量调试时靠 Console + Tests 验证头是否生效
备注最终是为了避免配错、方便回溯。比“写备注”更关键的是确保头真被发出去了：
- 打开
View → Show Postman Console，发送请求后检查原始请求头输出，确认Authorization、Content-Type等字段值是否符合预期 - 在
Tests里加断言，例如：pm.test("Content-Type is set", () => { pm.expect(pm.request.headers.get("Content-Type")).to.eql("application/json"); }); - 如果头由脚本动态注入（如签名），在
Pre-request Script结尾加console.log("x-rio-signature generated:", signature);，Console 里就能看到计算过程
真正的难点不在“怎么写备注”，而在于让团队成员一眼看懂某个 X-Custom-Id 是测试用还是生产用、过期时间在哪查、谁负责更新——这些信息没法塞进 Header 表格，得靠变量命名规范、Preset 命名习惯和脚本里的中文注释共同承载。
