Postman中Inherit auth from parent是默认授权继承机制，子请求仅在未手动覆盖时沿用父级认证；常见失效原因是子请求或文件夹显式设置了No Auth等类型而切断继承链。

Inherit auth from parent 是 Postman 中每个请求的默认授权类型，它不是“开关”，而是一种层级继承机制——只要没显式覆盖，请求就会自动沿用上级（集合或文件夹）设置的认证方式。

---

为什么改了集合的 Authorization，子请求还是没带认证头？

常见错误是只改了集合的 Authorization 类型，但没检查子请求是否被手动覆盖：

• 请求级别的 Authorization 选项卡里，如果选了 No Auth 或 Bearer Token 等具体类型，就会切断继承链，无视父级设置
• 文件夹（Folder）本身也是一级可配置节点：如果文件夹设为 Inherit auth from parent，它只是中转站，不提供实际凭证；只有集合（Collection）或该文件夹自己设置了具体认证方式（如 Basic Auth），下级才会真正拿到值
• Pre-request Script 中用 pm.variables.set("token", ...) 写入变量后，必须在父级的 Authorization 配置里显式引用，例如 Bearer Token 类型中填 {{token}}，否则变量不会自动注入

---

如何让整个集合统一用登录接口返回的 token？

这是最典型的继承使用场景，关键在于三步闭环：

• 在集合的 Pre-request Script 中调用登录接口，并提取并保存 token：

  pm.sendRequest({
    url: 'https://api.example.com/login',
    method: 'POST',
    body: {
        mode: 'raw',
        raw: JSON.stringify({ username: 'admin', password: '123' })
    }
  }, (err, res) => {
    if (!err) {
        const token = res.json().access_token;
        pm.collectionVariables.set('auth_token', token);
    }
  });

• 在集合的 Authorization 选项卡中，类型选 Bearer Token，Token 字段填 {{auth_token}}
• 所有子请求保持默认的 Inherit auth from parent 即可，无需额外操作

注意：pm.collectionVariables.set() 比 pm.variables.set() 更稳妥，避免环境变量污染；且必须确保登录请求在其他请求之前执行（靠集合层级天然保证顺序）

Postman 12.27.7

Postman 12.27.7 Windows x64 官方安装包，适用于 API 设计、调试、测试与协作。该系列包含 Enterprise 云端性能测试静态 IP 出口能力，以及接口规范标签管理改进，适合受限网络测试与规范资源组织场景。

下载

---

文件夹想用独立认证，但又不想影响同级其他文件夹？

文件夹不是装饰性分组，而是真正的继承节点，可以独立配置：

• 右键点击目标文件夹 → Edit → 切换到 Authorization 选项卡
• 把类型从 Inherit auth from parent 改为你要的具体方式，比如 API Key，Key 设置为 X-API-Key，Value 填 {{folder_api_key}}
• 在该文件夹的 Pre-request Script 或对应环境/集合变量中提前定义好 folder_api_key
• 同级其他文件夹和请求完全不受影响，它们仍走各自父级（集合或其他文件夹）的配置

容易忽略的一点：文件夹一旦设为非继承模式（如直接选 Basic Auth），它的子请求就不再看集合的认证设置，哪怕集合后来改了，这个文件夹下的请求也不会更新——继承只在创建/加载时解析一次，不实时监听父级变更。

---

Postman 的认证继承看着简单，实际依赖的是「谁设了真实凭证」+「谁切断了继承链」这两个隐性判断。最常出问题的地方不是不会配，而是误以为改了集合就全局生效，却忘了某个请求或文件夹早已手动选了 No Auth 或硬编码了另一个 token。