Apifox 的全局全局 Cookies 功能，说白了就是全局让你在多个接口之间共享同一套 Cookie 数据，不用每次请求都手动加 Cookie 头。全局这个功能藏得不算深，全局但在实际调试带登录态的全局接口时，能省掉大量重复劳动。全局

我最初用 Apifox 的全局时候，每个需要登录的全局接口都手动在 Header 里贴 Cookie，贴到第三四个接口就开始烦了。全局后来发现它其实有全局 Cookies 管理，全局位置在环境管理旁边，全局点进去可以直接编辑键值对。全局更关键的全局是，它和 Postman 的全局 Cookie 管理逻辑不太一样——Apifox 把 Cookie 分成了全局和接口级两层，全局的全局会默认注入到所有请求里，接口级的只对当前接口生效。

它到底怎么工作的

Apifox 在发送请求前，会先检查当前接口有没有设置接口级 Cookie。如果有，就优先用接口级的；如果没有，就把全局 Cookies 拼到请求头里。这个优先级逻辑很实用，比如你全局配了用户 A 的登录态，但某个接口想用用户 B 的身份测试，直接在接口级覆盖就行，不用动全局配置。

有个细节值得说：全局 Cookies 的域名匹配规则。Apifox 不会无脑把所有 Cookie 塞进每个请求，它会根据请求 URL 的域名去匹配 Cookie 的 domain 属性。如果你手动添加 Cookie 时没写 domain，它默认当成当前环境的主域名。这个行为在调试多域名接口时容易踩坑——比如你调 api.example.com 和 auth.example.com，Cookie 的 domain 如果写死了，另一个域名就带不上。

一个真实的使用场景

上周帮同事排查一个订单接口的 401 问题。他每次请求都手动贴 Cookie，贴了七八个接口，结果其中一个接口的 Cookie 少复制了一段，死活调不通。我让他把登录接口返回的 Set-Cookie 直接存到全局 Cookies 里，后面所有接口自动带，问题当场消失。他之前不知道这个功能，一直用最笨的办法。

操作路径很简单：先调登录接口，在响应里找到 Set-Cookie 头，复制那串 sessionid=xxx; path=/; domain=.example.com，然后打开全局 Cookies 面板，点“从响应导入”或者手动添加。手动添加时注意把 domain 和 path 填对，否则匹配不上。

几个容易忽略的点

全局 Cookies 和环境是绑定的。你切到测试环境，之前生产环境配的 Cookie 不会自动带过去。这个设计合理，但如果你习惯一套 Cookie 走天下，记得每个环境单独配。

另外，Apifox 的全局 Cookies 不支持脚本动态修改。想在请求前用脚本改 Cookie 值，得走前置脚本里 pm.request.headers.add 那套。全局 Cookies 更适合静态的、长期不变的登录态。

还有个坑：如果你在全局 Cookies 里配了某个域名的 Cookie，但请求走的是代理，域名可能被代理改写，导致 Cookie 匹配失败。这种情况要么关代理，要么在接口级手动加 Cookie 头绕过匹配逻辑。

值不值得用

如果你的接口调试涉及登录态，而且接口数量超过三个，全局 Cookies 基本是必开的。它把“复制粘贴 Cookie”这个动作从每次请求一次降到整个项目一次。省下来的时间不算多，但烦躁感下降很明显。尤其是调试那种需要保持会话的流程——比如下单前要登录、加购、领券——全局 Cookies 让整个链路顺畅很多。

当然，它也不是银弹。遇到需要频繁切换用户身份的测试，还是得靠环境变量或者接口级覆盖。但作为日常调试的默认配置，全局 Cookies 够用了。