Postman导出集合不包含本地文件二进制数据，form-data中文件仅保存字段名和提示路径（如"src": "avatar.jpg"），导入后需手动重新选择文件；迁移含文件上传的请求应优先选用cURL或HAR，而非collection_v2.json。
Postman导出集合不会包含本地上传的文件内容
导出的 collection_v2.json 文件里只保存请求结构、参数、Headers、Body（含 raw/json/form-data 的键名和值），但绝不会嵌入你通过 form-data 上传的本地文件二进制数据。这是根本性限制，不是格式或版本问题。
常见错误现象：你在 Postman 里用 form-data 选了一个 /tmp/avatar.jpg，导出后再导入到另一台机器，请求发出去却报 400 或空文件 —— 因为导入时只还原了字段名 avatar 和“文件名”字符串 avatar.jpg，但没带文件本体。
- Postman 导出时会把 form-data 中的文件字段记为
{"key": "avatar", "type": "file", "src": "avatar.jpg"}，src只是提示性路径，不参与传输 - 导入后该字段在新环境里显示为“未选择文件”，必须手动重新选取本地文件才能发出有效请求
- 如果想保留可执行性，得把这类请求改用
binary类型 + Base64 内联（不推荐，体积大、不可读），或改用raw+ 模拟 multipart boundary（复杂且易错）
form-data 请求迁移前必须人工核对字段类型
Postman 对 form-data 的字段类型判断依赖 UI 操作，导出 JSON 后无法反推原始操作意图。一个叫 config 的字段，可能是 text、file 还是 file array，仅靠 src 字段是否存在无法 100% 判定。
使用场景：团队交接时收到一个别人导出的 collection，里面有多个 form-data 请求，但没文档说明哪些字段要传文件、哪些传文本。
Postman 12.27.7 Windows x64 官方安装包，适用于 API 设计、调试、测试与协作。该系列包含 Enterprise 云端性能测试静态 IP 出口能力，以及接口规范标签管理改进，适合受限网络测试与规范资源组织场景。
- 打开导出的 JSON，搜索
"type": "file"，定位所有文件字段；再搜"type": "text"确认文本字段 - 特别注意数组型文件上传（如多图），Postman 会生成多个同 key 的
file条目，导出后结构是扁平的 item 列表，导入时顺序可能错乱 - 如果原请求用了 Postman 的
{{file_path}}变量动态填src，导出后变量值会丢失，只剩空字符串或默认名
替代方案：用 cURL 或 HAR 更可靠地固化文件上传行为
当必须保证“一次导出、处处可运行”时，collection_v2.json 不是最佳载体。cURL 命令或 HAR 文件反而更贴近真实请求语义。
性能 / 兼容性影响：cURL 能精确描述 multipart boundary、content-type、文件路径（仅限执行机本地）；HAR 包含完整 request body 二进制快照，但体积大、不可编辑。
- 从 Postman 发送一次请求 → 打开右键菜单 →
Copy as cURL (bash)→ 粘贴到脚本中执行，文件路径保持不变 - 用浏览器 DevTools 抓包导出 HAR → 在 Postman 的
Import→File中导入，它会重建带真实文件引用的请求（仍需本地存在同名文件） - 不要依赖
Export功能传递含文件上传的集合用于自动化回归，Newman 运行时同样会卡在“找不到文件”
Apifox 迁移时 form-data 字段会自动降级为 text
如果你把含 form-data 文件字段的 Postman 集合导入 Apifox，且未在 Apifox 中手动切换字段类型，该字段大概率被识别为普通文本，导致后端收不到文件流。
容易踩的坑：Apifox 的导入解析器对 type: file 的兼容逻辑不如 Postman 严格，尤其当 src 字段为空、或字段名含空格/特殊字符时。
- 导入后务必逐个点开 form-data tab，检查每个字段右侧的类型下拉框是否仍是
File - 如果变成
Text，需手动重选，并点击右侧文件图标重新指定路径（路径只是示意，实际发送仍需本地存在） - Apifox 不支持像 Postman 那样用变量填充
src，所以{{upload_path}}这类写法导入后直接失效，得硬编码或改用环境变量注入文件名（不含路径）
