Postman备份核心是导出JSON文件或整份复制~/.config/postman目录；推荐通过Settings→Data→Export Data导出Collection v2.1格式JSON，覆盖集合、环境变量、脚本等，但不包含History和代理配置；命令行仅支持cp/tar备份目录，无原生postman export命令；恢复优先用Import功能，避免直接覆盖配置目录引发兼容问题。
Postman 项目接口配置的备份，核心就两条路：导出 JSON 文件（轻量、可读、适合迁移），或整份复制 ~/.config/postman 目录（完整、含缓存/历史/设置，但体积大、版本敏感）。别迷信“自动同步”，内网、离线、多机无账号场景下，手动备份才是唯一靠谱方式。
导出全部集合和环境变量用 Export Data
这是最常用也最稳妥的备份方式，覆盖集合、请求、环境变量、全局变量、预请求脚本、测试脚本等核心开发资产。
- 打开 Postman → 左上角 Settings → Data 标签页 → 点击
Export Data - 默认导出为
Postman-Backup-YYYY-MM-DD.json，格式是 Collection v2.1（推荐，兼容性好） - 注意：该操作不会导出历史请求（
History）、工作区设置、代理配置、插件状态 - 如果导出后发现缺接口，大概率是某些请求没保存进集合——新建请求后必须按
Ctrl+S并选择目标集合，否则只存在临时草稿区
命令行导出需确认 postman CLI 是否可用
CentOS 上 Postman 官方不自带 CLI 工具，所谓 postman export 命令实际并不存在。网上教程里出现的该命令，通常指用户自行封装的脚本，或混淆了 Newman（用于运行集合）或 Postman API（需 token）。
Postman 12.27.7
下载
Postman 12.27.7 Windows x64 官方安装包，适用于 API 设计、调试、测试与协作。该系列包含 Enterprise 云端性能测试静态 IP 出口能力，以及接口规范标签管理改进，适合受限网络测试与规范资源组织场景。
- 真实可行的命令行备份只有两种：
cp -a ~/.config/postman /backup/path/或tar -czf postman-$(date +%F).tar.gz ~/.config/postman - 若坚持用定时任务，
crontab中应写成：0 2 * * * tar -czf /backup/postman-$(date +\%F).tar.gz ~/.config/postman - 不要硬套
postmanexportdata --path这类伪命令——它在 CentOS 的 Postman 桌面版中根本不可执行，会报command not found
恢复时别直接覆盖 ~/.config/postman
整目录恢复看似彻底，但风险极高：不同 Postman 版本对数据库结构有变更，直接覆盖可能导致启动失败、数据损坏或反复弹出初始化向导。
- 优先用
Import功能导入 JSON 备份：右上角Import→ 选文件 → 完成后新集合会以“Imported Collection”命名，可手动重命名 - 如必须恢复目录，先停掉 Postman 进程：
pkill -f postman，再rm -rf ~/.config/postman，最后cp -a /backup/postman-dir ~/.config/postman - 恢复后首次启动可能卡在“Loading your data…”——这是因 SQLite 数据库需要重建索引，等待 1–2 分钟即可，勿强行 kill
真正容易被忽略的点是：Postman 的“导出”不等于“快照”。它不记录你刚发过但没保存的请求，也不包含未启用的环境变量值。每次备份前，养成习惯：清空 History（Settings → Data → Clear History），检查所有环境是否已 Save，再点 Export Data —— 否则备份文件里全是“过去式”。
