用途
apifox-import-export 是 Apifox CLI 技能集中的一个导入导出与质量门禁技能,用于处理 API spec 与项目数据的导入、导出、迁移、备份和复制。使用前需先阅读 ../apifox-cli/SKILL.md;若旧总入口与本技能的领域规则冲突,以当前 CLI help 和本技能为准。
主要能力
导入
- 从代码库、PRD、需求文档、测试文档、讨论记录生成 API spec 并导入 Apifox。
- 导入 OpenAPI、Postman、HAR、Apifox 原生格式等项目数据。
- 配置自动导入。
导出
- 导出 OpenAPI、Markdown、HTML、Postman 或 Apifox 原生格式。
- 原生格式支持全量导出,也支持按接口、目录或标签范围导出,并可控制是否包含接口调试与单接口用例。
质量门禁
- 导入前校验文件格式、OpenAPI 质量门禁、路由骨架风险、tags 分组、原生格式模块策略、ignoreCount 以及是否需要干净项目验证。
- 必须实际解析生成的 OpenAPI 文件并报告真实统计值,统计指标包括 paths、operations、schemas、writes、withBody、emptyObjectBodies。
- 判断 spec 是否为"路由骨架":接口规模大、写接口多但 schemas 极少属疑似路由骨架;写接口很多但 withBody 覆盖不足、emptyObjectBodies 很多属强风险。小型、纯 GET、健康检查、webhook 透传项目 schemas 少可能合理。
- 校验 tags 与文档可读性,检查 operation 是否有业务化 tags、tags 是否按业务域分组,不推荐按 URL path 机械分组。
使用方式
标准流程
- 明确任务类型(生成 spec 并导入 / 直接导入已有文件 / 配置自动导入 / 导出文档或 OpenAPI / 迁移备份 / 把已有资源导入测试场景)。
- 搜索项目内已有生成器(openapi、swagger、routegen、docs generator、cmd/openapi 等),优先运行项目自带生成器,避免手写脚本只提取 method + path 骨架。
- 生成 spec 并确认文件格式,不要根据扩展名判断格式。
- 导入前统计质量指标并输出真实统计结果。
- 判断 spec 完整性。
- 校验 tags 和文档可读性。
- 选择导入项目,不确定时优先创建临时/修正版项目验证。
- 执行导入并检查结果计数,不只依赖命令成功。
- 回读验证并汇报,包含文件路径、质量指标或导出范围、导入项目、导入计数、抽查结果和遗留风险。
原生格式导入策略
apifox import --project <projectId> --format apifox --file ./project.apifox.json
apifox import --project <projectId> --format apifox --file ./project.apifox.json --module-import-mode match-name
apifox import --project <projectId> --format apifox --file ./project.apifox.json --module-import-mode new
apifox import --project <projectId> --format apifox --file ./project.apifox.json \
--module-map "商店 API=8049476" \
--module-map "管理 API=8049482"
默认模块策略为 match-name。--module-map 可重复传,优先级高于 --module-import-mode,写法包括"源模块名=目标模块ID""source:源模块ID=目标模块ID""源模块名=default""源模块名=new"。
原生格式导出策略
apifox export --project <projectId> --format apifox --output ./project.apifox.json
apifox export --project <projectId> --format apifox --scope apis --api-ids 1001,1002 --output ./selected.apifox.json
apifox export --project <projectId> --format apifox --scope folders --folder-ids 2001 --output ./folder.apifox.json
apifox export --project <projectId> --format apifox --scope tags --include-tags pet,store --exclude-tags deprecated --output ./tagged.apifox.json
apifox export --project <projectId> --format apifox --no-include-api-cases --output ./apis-only.apifox.json
具体命令参数以当前 CLI help 为准。
适用场景
- 从代码库、PRD、需求文档、测试文档、讨论记录生成 API spec 并导入 Apifox。
- 导入 OpenAPI、Postman、HAR、Apifox 原生格式等项目数据。
- 迁移、备份或复制 Apifox 项目,尤其是需要控制模块复用或新建时。
- 导出 OpenAPI、Markdown、HTML、Postman 或 Apifox 原生格式。
- 判断生成的 spec 是否只是"路由骨架"。
限制与不应使用的情况
- 把已有 endpoint、test-case 或 test-scenario step 导入/复制到测试场景时,应转 apifox-test-scenario,使用 test-scenario import-steps 或 test-scenario add-ref。
- 精细维护测试场景步骤、变量、断言或处理器时,应转 apifox-test-scenario。
- 不得先手写路由提取脚本、不得把接口数量多等同于 spec 完整、不得跳过导入前质量指标、不得在已有项目上反复试错导入、不得忽略大量 ignoreCount、不得导入 tags 混乱的 spec 作为最终成果、不得把 schema 极少的大项目 spec 当成最终版本。
- 如生成器产物 tags 明显过粗或机械来自技术路径(api、v1、rest、service、controller 等),必须停在导入前询问用户是否允许生成修正版 spec。
常见恢复
- 导入成功但只有路径:回查生成器是否只抽路由,继续找 DTO/handler schema。
- schemas 极少:结合 operations/writes/withBody/emptyObjectBodies 判断是否路由骨架。
- 大量空 body:回查 request DTO 或项目生成器。
- Apifox 目录按 URL 分组:重写 operation tags 后重新导入到干净项目。
- 大量 ignoreCount:判断是否污染已有项目,必要时新建干净项目验证。
- JSON.parse 失败:检查实际是否 YAML,不要信扩展名。
- 原生格式二次导入出现重复模块:检查是否使用默认 match-name、目标同名模块是否唯一,必要时用 --module-map。
- 目标项目有多个同名模块:不要依赖 CLI 自动猜,使用 --module-map "源模块名=目标模块ID"。