我们为什么开发 ApiCatcher 这个HTTPS抓包工具？

你好，我是ApiCatcher的创造者，我叫吴就业，我的工作经历有做过iOS&Android应用开发、也做过后端开发、中间件研发， 于2024年创作ChatTCP，2025年12月辞职创业， 于2026年1月创作ApiCatcher。今天我将和你分享为什么要开发ApiCatcher这个HTTPS抓包工具。

在我以往的工作经历中，我每次换工作都要面对陌生的项目，而且基本没有技术文档、接口文档。 每次接到新任务要去改一个功能，需要评估此次需求需要改哪些接口时，我都要花很多时间去阅读代码，找到相关的接口。

2025年，我从中间件研发转去做后端开发，开始做业务需求。 我印象比较深刻的一次需求开发，由于我没有权限去看客户端的代码，也不懂客户端是调用了哪些接口，客户端的同事也刚接手项目，不了解项目， 我不得不找新方法能够在没文档、没代码的情况下去找出那些我需要知道的接口。

本来是可以在服务端抓包的，但服务端架构太复杂，都不懂入口是哪个网关， 我只能通过在客户端抓包了，但是客户端发起请求是HTTPS的，于是就想着找一款支持HTTPS抓包的工具。 因为我手机是iPhone, 我因此试用了几款在App Store下载的HTTPS抓包工具，包括Stream、ProxyPin。

我当时想把这些接口导入到Apifox，并且基于当前接口和新的迭代需求在此基础上去修改接口，并在团队中共享这份接口。 开源的工具基本都只有抓包这一个功能，于是我试了一些付费的抓包工具，可都没有能解决我需求的。 当时我只能基于抓取的请求和响应的数据，自己在Apifox里面写接口，这耗费了我整整一天半的时间。

我需要复现多种业务场景，然后抓取多次请求，将多次请求的请求参数、请求Body、响应Body合并到一起得出一个比较完整的接口文档。 这是因为在不同场景下，调用接口传参不同，且响应结果也不同。 例如当一个签收订单的设备类型是摄像头时，接口需要传摄像头相关的参数，而当签收订单的设备类型是电子钥匙时，接口需要传电子钥匙相关的参数。 不同传参对应的响应字段也会有差异，后端代码很多的if-else条件，从代码层面理解非常的痛苦。

经过那次之后，我就想着自己研发一个HTTPS抓包工具，这个HTTPS抓包工具能够自动生成接口文档， 并且多次抓同一接口的请求，能够自动更新文档，补充字段进去， 并且还能自动关联抓包历史记录。最重要的是能够将生成的接口文档导出到Apifox或Postman， 同时带着请求历史作为用例一起导出，这样我就可以在Apifox中基于接口文档和用例去分析和修改迭代接口文档， 并且在团队中共享这份接口文档。

将抓取的HTTPS请求自动生成接口文档、更新接口文档，将不同业务场景下抓取的同一接口的请求历史作为用例，并且将接口文档和用例一起导出到Apifox或Postman，就是这个工具最初想做的核心功能。也是在所有抓包工具中，我们原创的、独有的功能。这也是我们取名为ApiCatcher的原因。

后来在自己做项目，做全栈开发的过程中，我发现对于前端/客户端（包括Web开发，iOS、Android、Windows、macOS应用开发）开发者来说， 抓包工具不仅仅只是抓包，还是接口调试的利器。 以前做后端开发，我们测试接口可以直接用API管理工具，也可以自己写测试用例，只要判断接口响应符合预期就行。 但是客户端开发不一样，客户端开发需要验证UI交互逻辑，这是脚本替代不了的，需要手动去操作看效果。 客户端只能通过代码Mock各种响应，但是这样会导致项目很多的Mock代码，极难维护。 而抓包工具如果能把Mock响应、模拟接口耗时响应等，就能解决客户端开发接口调试的痛点。 另外，前后端接口联调过程中，抓包工具对于问题的排查分析也是非常有帮助的，能极快的定位问题，而不是通过在前后端代码中打印一堆日记判断， 因为中间隔着底层网络框架，实际发出的请求不一定是日记看到的，也因为中间隔着网络传输， 请求耗时不一定发生在客户端代码。所以HTTPS抓包和接口调试的需求一起做是非常有必要的。

在满足接口提取和接口调试需求的基础上，我们还希望创造一款考虑用户使用体验，而不是只有功能堆砌的工具。 因此我们也在设计上考虑了很多细节，例如在编写重写规则的正则替换规则时， 由于正则表达式的语法比较复杂，很多用户不懂怎么写，我们就加入了AI生成表达式的功能，用户只需要描述效果，AI自动生成表达式。 例如在编写定时任务时，Cron表达式可能很多用户也不懂怎么写，我们也加入了AI生成Cron表达式的功能。

在你最想要的时候出现那个恰当的功能，就是我们在细节上做的努力，我们致力于把ApiCatcher做成 一款用户体验极佳的HTTPS抓包工具，以帮助用户提升工作效率。