Postman文件夹支持无限嵌套，但建议不超过3级（Collection→Folder→Sub-folder），因超3层会导致Runner丢失子文件夹Pre-request Script继承；需手动开启“Inherit auth from parent”才能继承token和环境变量；导出必须选v2.2.0格式以保留嵌套结构。
Postman里能创建几级文件夹？
能无限嵌套，但实际建议控制在 3 级以内：Collection → Folder → Sub-folder（再往下就难维护）。Postman 的 Folder 本身不支持“子文件夹直接拖入”，必须通过右键父级 Folder 或 Collection 的 Add Folder 按钮逐层添加。
常见误操作是试图把一个已存在的 Folder 拖进另一个 Folder —— 这不会生效，界面无反馈，也不报错，容易让人以为“功能没加载出来”。
- 正确路径：选中目标父级 → 点击右上角
⋯→Add Folder - 层级命名建议用业务语义，比如
user-auth→login-flow→token-refresh，别用folder1、test02这类无意义名 - 超过 3 层后，Runner 批量执行时会丢失部分子文件夹的
Pre-request Script继承关系，尤其当脚本放在中间层 Folder 时
如何让子文件夹自动继承父级的 token 和环境变量？
关键不是“自动”，而是靠显式设置继承策略。Postman 默认不自动继承任何配置，必须手动开启。
Postman 12.27.7
下载
Postman 12.27.7 Windows x64 官方安装包，适用于 API 设计、调试、测试与协作。该系列包含 Enterprise 云端性能测试静态 IP 出口能力，以及接口规范标签管理改进，适合受限网络测试与规范资源组织场景。
- 在父级
Folder或Collection的Authorization标签页中，选择类型（如 Bearer Token），填入{{token}} - 然后在子
Folder的Authorization页，必须选Inherit auth from parent—— 这个选项默认不勾选，很多人漏掉 - 环境变量同理：父级设置
pm.environment.set("base_url", "https://api.dev")后，子级脚本里直接用{{base_url}}即可，无需重复 set - 注意：如果子
Folder自己设置了 Authorization 类型（哪怕只是点开又关掉），就会覆盖继承，变成“无授权”状态，接口 401
为什么导出 Collection 后，嵌套文件夹里的请求不见了？
导出时没选对格式。Postman 导出支持两种 JSON 格式：v2.1（旧）和 v2.2.0（当前默认），但只有 v2.2.0 完整保留多层 Folder 结构和其中的 Request 顺序。
- 导出操作：右键 Collection →
Export→ 勾选Collection v2.2.0→ 确保Include environment variables不勾选（环境变量不属于 Collection 结构） - 导入时若选了
v2.1，所有子Folder会被拍平成同级，请求随机散落，且Pre-request Script全部丢失 - 验证方法：导出后用文本编辑器打开 JSON，搜索
"type": "folder"，v2.2.0 中每个 folder 都有"item"数组嵌套下一层结构；v2.1 中只有扁平的"item"列表
嵌套文件夹里怎么复用同一套 Pre-request Script？
不能“复用”，只能“继承+覆盖”。Postman 的脚本作用域是严格按层级向下传递的，但子级可以覆盖父级同名逻辑。
- 父级
Folder的Pre-request Script会运行在它所有子请求前，包括子Folder里的请求 - 如果子
Folder也写了Pre-request Script，它会**完全替代**父级脚本，不是追加执行 —— 这点和 Authorization 继承逻辑不同 - 想“组合逻辑”，得手动在子级脚本里显式调用父级逻辑，例如：
eval(pm.collection.variables.get("parentScript"))（不推荐，脆弱） - 更稳妥的做法：把通用逻辑抽成
pm.globals.set("commonAuth", "...")，各层脚本统一读取并拼装，避免脚本嵌套依赖
