Postman 中 Cookie 名称无法直接编辑，因 Name 是唯一标识且保存后设为只读；实际需删除后重新添加，并严格匹配 Domain 等字段。
Postman 里不能直接“修改”已保存 Cookie 的名称，只能删掉重加——因为 Cookie 名称（name）是其标识核心，编辑界面只允许改值（value）、过期时间、路径等字段，不开放重命名入口。
为什么 Cookie 名称无法在 UI 中直接编辑
Postman 的 Cookies 管理面板（点击右上角 Cookies 弹出）中，每个 Cookie 条目显示为 Cookie_1=xxx 这类占位名。它本质是 UI 渲染的临时标识，真实生效的是你输入的 Name 字段内容。但该字段在保存后即固化，后续双击或点击编辑时，Name 输入框处于只读状态（灰显），仅 Value、Path、Expires 等可修改。
这是设计使然：HTTP Cookie 机制中，Set-Cookie: oldName=value 和 Set-Cookie: newName=value 是两个完全独立的键；服务端靠 name 区分身份，不存在“改名”语义，只有覆盖或删除重建。
实际操作：用“删+加”替代“重命名”
想把 JSESSIONID=abc123 改成 sessionId=abc123？按以下步骤操作：
- 打开
Cookies面板，找到对应域名下的那条JSESSIONID记录，点右侧×删除 - 在同一域名分组下，点
Add Cookie - 在弹出表单中填入：
-
Name:sessionId -
Value:abc123 -
Path: 通常填/（确保覆盖全站） -
Domain: 必须与请求域名严格一致（如127.0.0.1或example.com，不能带http://或端口） -
Expires: 手动设一个未来时间（否则浏览器视为 session cookie，关闭 Postman 后丢失）
-
- 点
Save，新 Cookie 即刻生效
Headers 方式更灵活，但需手动拼接
如果只是临时测试、不想动 Cookie 管理器，直接在请求的 Headers 标签页添加更可控：
Postman 12.27.7 Windows x64 官方安装包，适用于 API 设计、调试、测试与协作。该系列包含 Enterprise 云端性能测试静态 IP 出口能力，以及接口规范标签管理改进，适合受限网络测试与规范资源组织场景。
- Key 填
Cookie - Value 填完整字符串，例如：
sessionId=abc123; otherKey=xyz - 注意：多个 Cookie 用英文分号 + 空格分隔（
;后必须有空格），否则部分服务端解析失败 - 这种方式绕过域匹配逻辑，不校验
Domain或Path，适合调试跨域或非标准路径场景
预请求脚本动态设置（适合自动化流程）
若需在 Collection Runner 或自动化测试中批量切换 Cookie 名称，用 Pre-request Script 更可靠：
pm.request.headers.upsert({ key: 'Cookie', value: 'sessionId=' + pm.variables.get('session_id') });
关键点：
- 用
upsert()而非add()，避免重复添加Cookie头导致服务端解析异常 - 变量
session_id可从登录接口提取（用tests或Tests脚本写入） - 此方式完全跳过 UI 管理器，不受“不可重命名”限制，适合 CI/CD 流水线
真正容易被忽略的是 Domain 字段的匹配规则：Postman 发送请求时，只把 Cookie 发给**完全匹配**该字段的域名（含端口差异）。比如你设了 Domain=127.0.0.1，但请求地址是 http://127.0.0.1:8080，它仍能匹配；但若设成 Domain=localhost，而请求用 127.0.0.1，就失效——这时候连“删+加”都救不了，得先核对域名一致性。
