Postman Collection“删不干净”因保存的是手动Save的请求，含临时、旧版或下线接口残留；删除需防空文件夹残留及无回收站风险；批量清理宜导出JSON编辑后导入；History清空不影响Collection。
为什么Collection里“删不干净”接口示例
Postman 的 Collection 本身不存“接口示例”，它只保存你手动 Save 过的请求。所谓“过期的接口示例”，其实是你调试时随手保存的临时请求、命名混乱的旧版本、或已下线接口的残留副本。它们混在 Collection 里，靠肉眼很难分辨哪些该留、哪些该删——尤其当集合里有几十个请求、还嵌套了 Folder 时。
删除单个请求：右键 Delete 不等于立刻消失
右键点击某个请求 → 选 Delete → 确认弹窗点 Delete，这是最直接的方式。但注意两个坑：
- 如果这个请求属于某个
Folder，删除后 Folder 不会自动折叠或隐藏，空文件夹仍会显示，容易误以为还有内容； - 桌面版 Postman 删除后无法撤回，网页版也无回收站——删错只能靠历史记录（
History）里重发再保存，或从备份的.json文件恢复。
批量清理 Collection：用 Runner + 数据文件驱动删除
当你面对的是大量过期请求（比如测试环境切换后整批失效），手动删效率极低。这时候得反向操作：把要保留的请求 ID 列出来，其余全删。实际中更常用的是「导出 → 编辑 JSON → 导入」流程：
- 先导出整个 Collection：
Export→ 选Collection v2.1→ 得到一个.json文件； - 用编辑器打开，搜索
"request":{，每个请求块都以它开头，结合"name"字段快速定位过期项； - 删掉整段对应 JSON（注意保留合法结构，别删漏逗号或括号）；
- 导入修改后的文件：
Import→Upload Files，覆盖原集合。
这方法绕开了 UI 层限制，适合一次清理 10+ 请求，且能确保 Folder 结构和变量定义不被意外破坏。
Postman 12.27.7
下载
Postman 12.27.7 Windows x64 官方安装包，适用于 API 设计、调试、测试与协作。该系列包含 Enterprise 云端性能测试静态 IP 出口能力，以及接口规范标签管理改进，适合受限网络测试与规范资源组织场景。
彻底清空 History 但保留 Collection
很多人混淆 History 和 Collection。History 是自动记录的请求快照，按天分组，里面全是临时调试痕迹；Collection 才是你主动归档的正式接口资产。清空 History 不影响 Collection，但能避免误点旧请求覆盖当前调试：
- 点左上角
History标签 → 右上角Clear all； - 或者对某一天记录点
?图标单独清除； - 若想长期禁用自动记录，进
Settings→ 关闭Save requests to History。
真正难清理的从来不是“怎么删”，而是“删哪些”——建议每季度做一次 Collection 审计：检查 name 是否含版本号、url 是否还指向有效环境、tests 脚本是否仍在跑通。过期的不只是接口，更是没维护的断言和变量引用。
