Postman文件夹认证不继承集合设置，需手动覆盖；生效前提为集合已保存非No Auth配置，且请求未覆盖为No Auth或留空；凭证应通过环境变量安全存储，OAuth 2.0需前置获取token。
文件夹认证不继承集合设置，必须手动覆盖
Postman 中文件夹默认走 Inherit auth from parent，但这个“继承”是只读的——它不会自动同步父级后续修改，也不会把集合里改好的认证透传下来。你看到文件夹授权类型显示为“从父继承”，不等于它真的在用集合的配置；它只是当前没被显式覆盖而已。
真正起效的前提是：集合本身设置了非 No Auth 的认证（比如 Basic Auth），且该设置已保存。否则哪怕你在集合里选了 Bearer Token，只要没填 Token 值，文件夹实际发出的请求仍是无认证的。
- 右键文件夹 → 编辑 → 切到
Authorization选项卡 - 把
Type从Inherit auth from parent改成你要的类型（如Basic Auth） - 填入对应凭证：
Username/Password或Token值，支持环境变量（如{{api_user}}） - 点 Update 保存，此时文件夹内所有请求才真正使用新认证
为什么改了文件夹认证，子请求还是 401？
常见原因是请求层级优先级没理清。Postman 认证生效顺序是：Request > Folder > Collection。如果某个请求自己在 Authorization 页签里又选了 No Auth 或留空，那它会无视文件夹设置，直接发裸请求。
Postman 12.27.7 Windows x64 官方安装包，适用于 API 设计、调试、测试与协作。该系列包含 Enterprise 云端性能测试静态 IP 出口能力，以及接口规范标签管理改进，适合受限网络测试与规范资源组织场景。
- 检查每个出问题的请求：点开它的
Authorization页签，确认Type不是No Auth，也不是空着 - 如果想统一用文件夹认证，就把请求里的
Type显式设为Inherit auth from parent - 用
Preview Request按钮看实际发出的Authorization请求头，比猜靠谱得多
Basic Auth 和 Bearer Token 在文件夹里怎么安全存凭证
别把明文密码或 token 写死在文件夹配置里。Postman 会把它们明文存在本地 JSON 文件中，一旦导出或误传就泄露。
- 在
Environment里定义变量：auth_user、auth_pass、access_token - 文件夹
Authorization配置中，输入框里直接写{{auth_user}}、{{auth_pass}}等 - 敏感环境（如测试/生产）单独建环境，避免混用；导出环境时取消勾选
Export values - 如果是
Bearer Token，注意 token 过期后要手动更新变量值——Postman 不会自动刷新
OAuth 2.0 文件夹认证容易漏掉的关键步骤
OAuth 2.0 是唯一需要两步走的认证类型：先获取 token，再用 token 发请求。文件夹只能管第二步，第一步必须靠前置请求或脚本完成。
- 不能只在文件夹设
OAuth 2.0类型就完事——它不会自动帮你调/oauth2/token - 得先建一个独立请求，用
POST调取 token 接口，响应里提取access_token并存到环境变量 - 再在文件夹里设
Bearer Token，值填{{access_token}}；或者用OAuth 2.0类型并勾选Get new access token（但仅限单次调试，不适合自动化） - 注意
scope、client_id、client_secret这些参数必须和 token 获取时一致，否则 401
文件夹认证最常被忽略的一点：它不管理生命周期。token 过期、密码轮换、API Key 失效，这些变化不会触发任何提醒，全靠人盯。建议在 Pre-request Script 里加个简单校验逻辑，比如检查 pm.environment.get('access_token') 是否为空或过短。
