大家好，我是Reqable的开发者，给大家分享我在推广 Python 作为程序扩展脚本时遇到的一些问题和思考。如果大家对这个方面有想法和建议也非常欢迎一起讨论，不甚感激。
先说下大体的背景，我的产品 Reqable 是 API 抓包和测试一体化工具。这一类工具基本上都会用到扩展脚本，比如 Fiddler 使用了 FiddlerScript 作为扩展脚本，Postman 和 Proxyman 等使用 Javascript 。用户可以编写扩展脚本来动态地修改请求或者响应数据，相比静态功能来说，提供了更多的可能性。
在设计 Reqable 的时候，我考虑了两种方案：方案 A 是 Javacript ，方案 B 是 Python ，最后定下来方案 B 。谈谈我当初的考虑，Reqable 本身是基于 Flutter 而不是基于 Web 引擎，如果需要支持 Javacript 需要像 React Native 一样额外引入 JSCore 来解释执行 Javacript ，技术实现上来说稍微麻烦点但难度也不大，包体积会大一些但也还好。对于 Python 而言，主流 Windows 和 Mac 上系统默认都已经预安装了，用 Linux 的基本上也会安装，所以可以直接借助用户的 Python 环境来执行脚本，不需要引入额外的库。另外，我考虑到 Python 的在用户宽度可能会更广，比如测试工程师、安全工程师、爬虫工程师等等，而 Javacript 在前端会更加流行。综上原因，最终我选择了 Python 作为扩展脚本语言。
但是想法虽好，用户却不是很买单。有些用户建议我支持 Javacript 脚本，还有一些说 Python 直接劝退。这些反馈让我不得不重新审视之前的想法，考虑是否需要增加 Javascript 作为扩展脚本。当然，维护两套扩展脚本框架我不是很情愿，这个会极大地增加后续维护和迭代的工作量。技术实现难度反而是其次，大佬 Levi 也很贴心地给我提供了他产品目前使用 Javascript 作为扩展脚本的方案： zhuanlan.zhihu.com/p/672772729 。
说回目前的困境，大家不太能接受 Python 的原因，我的个人的反思和调研出来的是以下几点：

Python 作为扩展脚本不多见，或者和用户的技术栈不匹配。
Reqable 内置的代码编辑器功能不完善，无法流畅编写 Python 代码。
生态不佳，大家更喜欢现成拿来就用的而不是自己去编写。

针对这几个原因，我做了一些努力和尝试，希望能再挣扎几下：
第一点：技术栈的问题目前无解，但我还是相信 Python 的用户宽度更广。当然，如果能熟用 GPT ，技术栈也不是什么问题，直接提需求让 GPT 写。
第二点：确实是一个很大的问题，例如代码编辑器缺少代码提示和补全，调试功能不方便。针对这个问题，我完善了代码编辑器，加上了代码提示和补全功能。对于调试，则提供了日志控制台功能，当然断点调试目前还不知道怎么去支持。

第三点：对于拿来主义，我的设想是提供一个开源的公共模板仓库，将一些常用的脚本放进去，用户可以直接在 Reqable 里面 Fork 并使用。例如，我写了个利用 Python 扩展脚本自动生成并添加阿里云 OSS 资源访问的签名头部。

我暂时就想到了这么多，效果好不好目前还不确定，如果大家还有想法和见解，欢迎补充。

上午起来一看，大家给了很多中肯有价值的回复，我来回认真看了几遍，做个简单总结，就不一一回复了，感谢大家。1. Windows 预安装的问题，确实是调研失误了。Windows 自带的 python3.exe 等是 placeholder ，从命令行跳转应用商店引导安装的，安装完成后链接到真实的 python 可执行文件。有可能我的设备早期按照这个方式安装了 python ，一直以为是预安装的。2. 从大家回复内容来看看，支持 Javascript 的确实远比 Python 要多，明年可能确实要再提供 Javascript 的扩展脚本支持。有回复多次提到市场和用户角度，我补充下我的想法。对于前端工程师，选 JS 毫无疑问；对于测试工程师，选 Python 应该也是毫无疑问；对于后端工程师，到底是会 JS 多还是 Python 多，我确实不清楚，Java 应该是很多的，Java 作为扩展脚本同样不多见，好像 BurpSuite 是 Java 。总的来讲，产品的用户到底是使用哪种语言居多，产品研发前很难去调研，Reqable 现在有一定的用户量，我确实需要做个问卷调研。有回复说 Postman 使用 JS ，那么 JS 一定就是用户的主流语言，这种观点看我其实持怀疑态度的。Postman 选择 JS 不一定是根据市场需求，而是产品自身的技术栈，Postman 是基于 Electron 开发，扩展脚本语言自然是会选择 JS ； BurpSuite 是基于 Java 开发，扩展脚本语言选择了 Java ； MitmProxy 是基于 Python 开发，扩展脚本选择了 Python 。Reqable 基于 Flutter 开发，如果扩展脚本语言使用 Dart ，我也只能加个🐶。从技术实现的难易程度和扩展脚本的生态来讲，JS 无疑是主流。当然，头部产品 Postman 等对用户习惯的培养来说功不可没。JS 是主流，为什么不选择 JS 呢？我当初的想法是，差异化竞争。我认为做个一模一样的产品没有前途，需要一定的差异化。当然，用户量起来了，后面丰富下不同用户的口味是非常有必要的。纠结的点在于，维护和升级成本，按照我的 Roadmap ，扩展脚本除了提供预请求/预响应处理外，还会提供单元测试，自定义 UI 等功能。维护两套语言 API 对于我一个人来讲确实比较吃力，有人建议开源，实际上目前的 Reqable Python API 是开源的，但并没有他人的一点代码贡献。3. 扩展脚本依赖和运行环境的问题。Python 的依赖管理确实比较坑，但是实际上 Python 标准库已经非常完善了，我觉得可以支持 99%以上的扩展编程，不一定需要额外安装依赖。相比，JS 标准的问题则比较多，必须需要额外提供 crypto 等库。另外，就是运行环境。内置 Python Runtime ，通过 FFI 调用技术上没什么问题，但是万一有用户需要用到非标准库的依赖呢，是个很麻烦的问题，这个就和 JS 一样。

另外，关于Python在作为扩展脚本语言方面的实际使用，看回复大多都持有负面的看法。如果有兴趣的，希望能帮我的产品 Reqable 的Python扩展脚本功能做个实际的测评，用户体验、流程、痛点、难受点等角度都可以，非常感谢。
方便测评，我提供一些许可证的免费兑换（90天）：

GT-G6DGA-YBKHL-HHZPL-4VXX8-4VPP8
GT-2X4E6-LL5AZ-9ZY3Y-AUKYD-FMUCP
GT-QKY84-ZU9CX-ENTZY-MTTX5-8PACU
GT-UMHLE-AEGG7-4ACQ5-WE4MR-HYHBJ
GT-5947B-VYNG5-947KF-ULZRH-4Z8Y3
GT-575UX-8UT8D-28HFT-QFSQU-GVGWQ
GT-CWMFU-VU4TB-GDBU3-4WU7Q-GS4U7
GT-VK8BE-CG4AZ-SW2NA-SS6CS-ABQLY
GT-BA5BN-7X44Z-SZQRF-XHDQ5-PGD75
GT-JE3M3-6H2KS-Z8CGL-WP6AC-LDUDM
GT-MFGKB-EQJS8-U8ZBT-GWG6F-WKTVJ
GT-K5VMX-XULS4-9MLSL-FMVMU-QYMHF
GT-SPFDP-Y7A29-H2CBC-9FS24-YQ7P3
GT-ZYH7Y-LBPV7-MEKRE-5ZR3V-8NT35
GT-7GS2W-BN43K-37HK5-9EZVU-YCERN
GT-TD2HZ-UYJGC-VWEG7-E346G-9589E
GT-MA8EC-Q6W8E-XVDZB-Y5QN8-Z6ABS
GT-KLG3Y-Z5YDH-639WX-ERHT4-6DTDN
GT-R2GXS-ASFZE-R4P63-Y52ZE-9M9RZ
GT-68YUK-ESU3Y-6H8PA-JU8DW-KCRPH

兑换处： license.reqable.com/gift

Windows 已经预安装了真的吗？

bullshit ，莫非我安装的假 Windows ，10 和 11 都不预带

提一嘴，windows11 23H2 并没有预安装 python 。

额，确认了下，这里表述可能有点问题。部分 linux 是自带的，windows 可以直接命令行跳转应用商店安装： devblogs.microsoft.com/python/python-in-the-windows-10-may-2019-update/ ，不过很奇怪，我记得当初调研过，在 Windows 的 C 盘某个系统目录里找到了 python3 ，找其他人确认也都有。

我印象里 windows 是没有预装，但流行的 linux 发行版都有。但无论有没有预装，我都不建议直接调系统的 python 。一个是版本不统一，一个是装包可能打乱系统。最好还是自带运行时

关于 windows 是否预安装的问题，再次确认了下，标准的 windows 确实没有预安装，但是根据 python 官方的说法，某些 windows 可能还是预先安装了 python 的。参考： docs.python.org/zh-cn/3/faq/installed.html＃why-is-python-installed-on-my-machine

＃2 Windows 11 电竞版 Pro Max Ultra 预装了

• 首选 js ，你的应用可是有手机版，我不觉得在手机上写 py 体验会比写 js 好- win11 应该是没有预装 python ，倒是有两个 python 别名会指向商店- 其实我觉得最好还是都支持，我建议设计成未来可以灵活添加，或许还要考虑到扩展的性能问题- 在不侵权的前提下兼容同类产品的生态- “直接借助用户的 Python 环境来执行脚本”，安全性考虑了吗？

  ＃5 感谢建议。我考虑过内置集成运行时，但是有个问题，不方便使用 pip3 已安装的三方库，需要再安装一遍。这个和 Javascript 作为扩展脚本是类似的一个缺点。另外，我是以 3.6 作为最低版本，版本问题应该不大。关于包管理，一般用户可能会有多个 python 环境切换，防止打乱全局的包管理。应用内是也可以配置指定 python 环境的。

作为 python 为主要语言的码农，我还是比较支持 python 作为扩展脚本的。而且单从我的感觉来说像 reqable 这种侧重于抓包和接口调试的应用的用户群体很大一部分是使用 python 作为主要语言的。 这个世界没有两全其美的方案，你做出任何决定都会有人反对的，说不定你切换到 JS 又有人说直接劝退呢?不如思考一下在如何能正确的获取到大多数用户的选择，比如在更新日志里面放一个调查问卷，甚至如果开发量能接受的话可以暂时先上两套方案后续看哪套方案是被更多用户所有接受的，不被接受的方案可以后续下掉不再维护。当然我没有做过这种面向开发者的程序只是提一些不成熟的建议，希望对于开发者有所帮助。reqable 是一个挺优秀的应用，我从一开始推出就入正了，希望作者继续加油。顺便乘机再提出一个无关的建议，目前 reqable 的激活是支持 windows + Linux + macOS + Android + IOS 以便于拥有多个系统的用户使用。但是对于我这种 windows(公司) + windows(家里) + Android 的人就不是很方便了，因为只能支持激活一台同种系统的 reqable 。所以我在想是否可以这样，用户可以选择将 IOS+MacOS+Linux 这三个激活资格兑换成一台 Windows 的机器的激活资格呢?当然如果不可以的话我接下来也考虑再买一个，毕竟软件还是很优秀的。

＃8 感谢建议。手机版其实没提供脚本功能，我觉得应该也不会有多少用户会拿手机写脚本吧。直接借助用户的 Python 环境来执行脚本，这方面安全性考虑确实没有考虑到，请教下是指哪方面的安全性呢。

＃10 谢谢，很中肯。关于许可证的问题，我也考虑到了。大概在春节之后上线，现有的用户会额外送一个设备位置，不需要再买了： github.com/reqable/reqable-app/issues/436

建议结合原文英文版查看，中文版翻译并不十分准确，原版并没有表达预装的意思

我不知道 Python 有没有实现过 ABI ，或许可以考虑编译一个 libpython （其他主流解释型语言也基本都有 libxxx 二进制版本），然后 Dart 调用 FFI 来实现对接 Python 等其他语言，这样系统不需要安装 Python 了，不过就是需要重新静态编译一遍所有需要的库。但我觉得既然你的产品要集成 python ，安装默认以外的 pip 包本来就是非预期行为我觉得可以不考虑进去，这样或许真的是一种可行的方案，而且不会在系统里拉其他文件。我搞过 libphp ，最后 frankenphp 的出现也证实了这是一种可行的将脚本语言融合到其他语言中的方式。

这个版本是个人封装的吗

可是 Python 不就是缩进版 JavaScript 吗🤔

＃14 我调研过是可以的，android 都能跑 python

＃11 那个是假的🤣，是个 placeholder

当用户在各种平台讨论并贴出一段测试用的脚本时，你无法预估平台会对代码做什么格式化处理，如果是 python 脚本这种强缩进相关的，随便一个缩进错乱就搞得脚本出错了。我已经见过好多例新手因为缩进问题搞出的低级 bug ，你这种半成品编辑面板，就是让用户在外面写好之后再复制进去的，更容易出问题了。

反馈一个问题，上次在论坛看到的时候试着装了下。M3 Pro ，安装证书之后，点开启系统代理，然后自动又停了，开关状态灭了。再点开启，又自动关了。当时有点忙就直接卸了，辛苦楼主可以排查下，或者我过阵子再下载下来试试。

换个思路，写扩展就是写一小段函数，一小段函数在云平台里比较成熟的方案就是 serverless 。那么可以直接定好几个接口格式，用户喜欢用什么语言写就用什么语言写，每个事件前后就是一个 http 请求打过去，根据接口响应来决定后面怎么处理。

我喜欢 Python 啊，VSCode 用的不顺手就是因为不支持 Python 开发插件。

有点无语……> 主流 Windows 和 Mac 上系统默认都已经预安装了，用 Linux 的基本上也会安装，所以可以直接借助用户的 Python 环境来执行脚本这个选型初衷就已经走偏了…… 本来作为一个内嵌 DSL, 你该考虑的重点是语言本身好不好写，容不容易把宿主的能力暴露给 DSL 。巧了，python 恰巧就能归到写起来手感很屎的那一类里。而且 python 最恼人的一点就是 interpreter 的依赖和管理，没有用户会想让系统内置的 python 来对接第三方产品的自动化接口，因为这很可能意味着要往系统 python 库里装一堆平时用不到的依赖，很可能系统升一下级产品不能用了或者产品升一下级突然告知系统里的 runtime 不匹配。python 的多版本虚拟环境解决方案是你能见到的所有现代编程语言里最原始也最冗余的 —— 把一个特定版本的、编译好的、完整的 python 运行时和依赖库复制到工程所在的目录里，这想想都觉得不太高明……另外 python 和 js 的 sense 完全就不一样。python 从很多年前我们学着用开始，直到今天，都一直被宣称成「胶水语言」 —— 也的确如此，它并不擅长嵌入到其它运行环境里；在使用 python 的场合，python 必须 作为宿主 或至少存在一个独立 runtime 「胶合」各层 Application Interface 才比较易用，跟 js 和 lua 这种向宿主中嵌入一种控制器运行时的性质并不一样。你可以把产品的能力导出成 python 的 FFI ，而且这样也还会有一大批运维/开发者会乐于使用，但这与你需要为你的产品指定一种语言来表达程序化的过程是两回事。

用 Lua

其实你这选型说到最后就两点，只会写 python 的出来吹 python ，然后就是只会写 javascript 的出来吹 javascript 了，仅此而已，后者毕竟是设计者本人不止一次承认存在多处设计缺陷的语言，ES6 后开始逐渐找补，你感觉有问题也是正常的。优势在于，简单者简单，让简单大行其道，导致想搞个 js 引擎那是再容易不过，现代电脑里没个十个八个 js 引擎都不好意思出来说话。。如果用 Python 那么好处是可以依托庞大生态，问题上面几层也说了，扩展管理和环境隔离，不用质疑，截至目前全网尚无什么理想方案，因为其应用程序绝大多数不以分发形式存在。虽然你可以尝试额外带一个解释器，但想必细节上需要相当多的额外工作。如果想实现的功能不需要强描述能力，Lua 确实也是可以考虑选项，毕竟是被大量验证的插入方案。

得了吧，只是因为互联网上反对者声音更大而已你要是一开始选择 JS ，那么喜欢 Python 的人也会跳出来各种发泄不满要么你就坚持自己的选择，要么两个都支持，否则你又要严重得罪另一批用户

这个是你选错了赛道，如果是 VFX 领域的软件，Python 是业界标准，所有主流软件都带一套 Python API ，你不带是你的问题（这个大概是十年前开始的趋势？）。ML 领域同理。相似地，在 EDA 领域，Tcl 是标准； Web 前端领域 JavaScript 是标准； Gamedev 的话 C＃ 和 Lua 多一些。所以对于“Python 作为扩展脚本常不常见”的回答，更合适的是“有些地方常见，有些地方不常见”。而正是因为楼主试图用一套解决方案照顾不同群体，那就必然出现这类问题。Python 和 JavaScript 都只能 cover 到一部分人，楼主接收到的反馈可能存在幸存者偏差，也许如果楼主当年用了 JavaScript ，就会有另外一批人出来喊为什么不支持 Python ...至于后面的两条问题，这个就和用哪个语言无关了，工具和生态是所有项目永远的话题。我个人的思路： 扩展 API 不局限于单一语言。这个有三个具体的例子，第一个是很多 C/C++ 项目不会直接提供脚本语言的 binding ，而是直接暴露 C API ，几乎任何地方都可以用 FFI 调用，对于各个语言的 binding 由社区维护单独的项目；第二个是各种 Web 服务同样是只暴露统一的 Web API ，不下沉到具体语言；第三个是 Web 里的 DOM API ，同样并不以语言特定的形式定义，而是使用一套单独定义的 Web IDL 语言定义，这个稍微好一点，因为能直接映射到 OO 语言。 同样地，解决编写体验问题，不局限于传统思路。而是使用可视化编程的方式，这个也是在 VFX 等领域中被广泛推广的。可视化编辑器和传统文本编辑器本来在设计思路上就有根本性的不同，比如可视化编辑器一般天然要求在某一个地方要有一个对所有操作的列表/搜索框，这在传统文本编辑中是不必要的。当然这套东西摆出来，并不是对楼主的建议，它不一定适合一个具体的实际问题。这只是我对一个理想的扩展系统的构想。

我主要语言这俩都不是，写 python 和 js 都用来各种地方写个脚本用一下，这俩现在用 gpt 写起来都挺方便。对比这俩，我的感受是，python 确实通过依赖完成很多功能，看起来更加自由。venv ，单独环境，依赖用户的 py 环境听起来怪怪的。js ，我有个疑问，http 各种标准默认应该是前端范畴吧，我觉得除了看规范原文，然后就是看 mdn 了。js 用于接口调试抓包这种事情再正常不过了吧。python 确实可以完成更多的功能，用户自由度也高。但是，如果用户用这个写 python ，如果用户遇到依赖问题很麻烦，包升级也很费劲，包和包之间的版本依赖也是依赖问题的一部分。本质你做的是一个抓包，代理，接口调试工具，用 python 追求自由度，功能丰富度，我个人觉得没必要。我觉得我这种非前端工程师调试网络接口，学习 js 是必要的，在 mdn 参考 web 规范也都是 js 。另外，在你的软件里跑 python 如果报错，我还得想想是我的 venv 的问题，还是你的软件的问题。总结，个人的感受是，因为你做的本质是接口工具，抓包工具，如果 python 作为扩展脚本，会感觉很怪，没必要追求自由度。还想重复一下，非 js 工程师在这种情况下学习 js 我觉得是必要的，不难。语言只是一种工具，个人觉得没必要刻意迎合语言使用者

大部分搞 web 的人应该都会点 js, 但可能不会 pythonjs 比 python 更适合

python 的脚本写起来方便，但是依赖库是个大麻烦相比之下，js 的 npm 包都显得“眉清目秀”了 =_=

依赖比源码大，扩展得多大啊

因为 electron 套壳更常用，我记得 adobe 的软件脚本就用的 jspython lua js 哪个不能用 还不是看底层啥架构

我是个运营，我来和技术同学说一下我的感受：1. 安装 Python 一般不是问题。2. 使用工作电脑安装各种依赖包和环境很容易报错。3. 有些报错在工作电脑处理不了。4. 企业版 win 10 甚至不带应用商店，一些微软官方的软件包并顺利不能跳转下载。

个人感觉 借助用户的环境实在不是一个好的选择。

如果是当作一项兴趣、爱好来做，，自己喜欢什么就用什么，，别人说什么不用管。。如果是当作一项事业来做，，那建议至少也要同时支持 Py 、JS ，，这两个用户量都很大、很流行，，少了一个就会少一大批用户。。

Adobe 用 JS 和 Electron 关系可能真不大 ... 我觉得更有可能是 Adobe 本身跟 Web 绑定得更紧，甚至是之前占据现代 Web 生态位的，收购来的 Flash （以及后来的 Air 之类）以前用的也是 JS 变体。SpiderMonkey 引擎用的 nanojit 后端甚至还是 Adobe 从 ActionScript 实现里面抠出来的 ...

使用 Py 、JS 做嵌入脚本的都很多，，举实例没什么意义，，Wireshark 还用 lua 做嵌入脚本呢，，用啥的都有。。

幸存者偏差吧等你从 Python 换成 JS 了，又换成只会 Python 不会 JS 的用户出来反馈了

Windows 里自带的那个 python3.exe 是个占位的假程序，作用就是在你输入 python 命令时跳转到商店。

你把这个事情太想当然了。事实上能用到这种工具的在我看来至少一半以上都是前后端开发，大家都多多少少会一点 js ，python 就不一定了。不太懂 flutter 嵌入 js 有多难，但是 QuickJS 也没多大。我懂你这个功能在做什么，应该就是 Postman 的测试或者预请求脚本？这种需求里，什么依赖管理，包管理，都扯远了，直接内嵌个 QuickJS ，保证可以随便拦截处理下请求就 ok 了，再内置几个 CryptoJS 的库就更好了。不会做的话完全可以去抄一下 Postman 这块怎么设计的。

你的用户是 python 用户居多还是 js 用户居多。面向市场编程。

参考 sublime ，内置 python ，别用系统的。

设计一套 RPC 协议，让用户启动 RPC 服务端，这样只要实现了协议就可以用任何语言，也不用自己实现编辑器的功能

如果你的工具主要用户人群是前端开发者或者 java 后端，那么用 python 自然不会让他们高兴如果目标本身就是 python 开发者，用户肯定高兴

都是惯的，就该直接让用 dart 写脚本🐶

QuickJS 我觉得就挺好的，足够的小，可以去找找其它人维护的版本，官方版暂时不能用 msvc 编译，例如 quickjs-ng/quickjs ，openwebf/quickjs ，也可以参考我自己维护的版本 zeromake/quickjs

建议使用 js ，像 frida 这种 app 都是使用的 js ；Javascript 是世界上最好的语言（不支持反驳）；顺带一提，我的聚合搜索应用：混合盘（ hunhepan.com/），也是使用的 js 引擎；再一提，reqable 好用 ， 无论是抓包，还是导入 curl 发送请求，都不错，如果但见有个终身版，我也就买了；不过，也完全理解没有终身版本的原因；

Python 脚本编辑与运行可以参考下开源的 Auto.js 这种模式，提供一个 VSCode 插件，通过 adb 或者内置 http 连接，在 VSCode 写完 js 脚本就能在手机运行

＃11 - 恶意脚本，我觉得借助外部的 Python 运行环境几乎没有好办法来限制脚本，全靠人工审查？- 性能，抓包工具一定会遇到一些需要性能的场景，我觉得调用外部 Python 环境来执行很容易遇到瓶颈吧？

看來看去好像沒知名的抓包工具用 Python 當 plugin/extension 擴充語言?用 Python 可以進行差異化競爭, 避免和 Postman 與 SoapUI 打對台. 當然我的主力語言是 Java 和 JS, 我會優先選 Java 和 JS.

我觉得还是技术栈的问题，基本每个后端都多多少少会 js 吧，但是不是几乎所有人都会 py 哦，尤其是数量庞大的 Java 开发

直接分开使用 websocket 通信，主流语言自己实现 sdk ，小众语言由社区自己实现 sdk

＃50 burp 与 jython 这种算吗

项目做的这个程度，就不是单纯做着玩了，所以需要从喜好策略模式改为运营策略模式。所以你要意识到，你不是在做一个令自己满意的软件，而是在跟业内其他产品竞争市场。无论你觉得你的选型在技术理论上有多少优势，市场因素往往优先级更高。如果竟品大多使用 JS 作为脚本语言，那么为了从竞品挖用户过来，也应该顺应用户的使用习惯使用 JS ，这样用户就会更多关注你的其他优势，而不是因为 Python 望而却步；特别是如果有一个用户量明显高于你的竞品在使用 JS ，你甚至可以以它为标准进行兼容，这样它的生态就成为了你的生态。后续当你的用户数量达到很大规模了，你可能也成为了这个行业的领跑者了，这时你就可以开始尝试培养用户习惯了，比如引入 Python 并作为默认推荐选项，并独占一些吸引人的特性。这就有点类似于 Android 推 Kotlin ，以及 iOS 推 Swift 。

Burp Suite 支援 Java 開發 extension, 對 Javaer 當然直接寫 Java, 而不是繞路去學 Pyhon / Jython.

抓包这种本来就和前端贴近的工具，嵌入脚本第一选择肯定 JS ，看竞品的选择就知道了。至于楼上有人说什么 Py 换成 JS 同样也有人不满，但是反馈的人肯定比现在少得多。

付费的话，看用户比例，开源看自我喜爱。

你的产品介绍：新一代 API 调试 + API 测试一站化解决方案全平台、免登录、轻量级、高性能、无广告，让 API 更快更简单那你的目标用户是谁？如果说你只想服务 python 用户，那就不用在乎其他声音但如果你没这种想法，就想推广产品，显然在网站前后端这个领域里，用 py 的人远少于 js 、java

纯粹是 js 大家都熟悉，python 还有学习成本吧，vscode 有最好的扩展生态，跟随总没错

我日常写 Python 的，我还是建议你用 js ，原因有三：- JS 有 quickJS 这种轻量级实现- 嵌入式脚本，需要复制粘贴的场景太多了，Python 那个缩进就成了弊端了- Python 太依赖官方库和第三方库了，这在嵌入上也是弊端

libpython 也可以吧。不是必须 python 语言作为宿主吧？

python 主要的问题在于 2/3 不兼容 许多环境不预装或预装版本不一致如果在可确定的环境，我还是很愿意使用 python ，毕竟本来也是定位胶水语言。但是如果环境不可控，那么 bash/powershell 的优先级就很高了。除了 Windows ，bash 基本上都是可用的（虽然不同环境下对于一些语法的支持程度不太统一），而 Windows 下 powershell 是毫无疑问的选择。嵌入式脚本，还是建议考虑 lua/js ，考虑到群众基础，js 依旧是相对较好的选择。

塞个 wasm runtime 进去，用户想写啥写啥

js 操作 json ，合理，门外汉基本都是照着事例抄，js 更符合直觉一些，Python 还有缩进的坑，至于懂语法的，啥语言差别不大。

＃20 Mac 上默认使用 networksetup cli 配置代理，但是有兼容性问题，可以安装下代理辅助工具（代理菜单 - 代理辅助工具 - 安装），Mac 上其他代理类软件好像也都要额外安装。

＃50 差异化竞争这个点确实是，非常大的一个选型因素，我忘记说了。

＃51 每个后端都多多少少会 js 吧，我不是后端开发出身，请问这个是真的吗😂

那还是看领域吧。Blender 用 Python 就好好的，Coral PaintShop Pro 用 Python 也……不对，这软件根本没人用。

不知道，会不会推出买断的版本呀。对于个人感觉年付，这种工具类，有点儿贵

另外如果你要集成脚本语言，不要依赖用户环境里预装或者自装的版本，一定要你自己控制。

不支持 js ，那 postman 的用户咋迁移过来啊，已经写好的 js 如果需要自己转 python ，那不是直接劝退么

＃70 关于用户环境里预装或者自装的版本的坑，我目前还没有收到相关的反馈。脚本运行前，我会做版本检测，另外感觉 Python 的兼容性还是蛮好的。当然，内置的话肯定是更加稳定，也可以考虑。另外，现在不少技术方案都是会依赖系统的组件或者环境，比如 tauri 等。

无关：IDA 和 Ghidra 的用户脚本都是 Python

＃67 我觉得是真的 因为没有学习成本，感觉就是简单版的 java

我找了个群问了下，答案也是肯定，好像以前前后端是不分开的。从学习成本来说，python 应该更低，可能很多人习惯不能接受空格作用域吧。

可能不少用户是前端吧，写 js 属于水到渠成

2/3 不兼容应该已经不需要考虑了吧现在大部分主流库都已经抛弃了对 2 的兼容，在 2 上已经很难安装出“有生产力”的环境了

问个作者不太相关的问题：比较好奇为什么 Fiddler 、mitmproxy 一直没有支持 socks 上游代理，reqable 的优先级也不高，是需求量比较少吗

如果要支持 python 最好把环境内置了，但是环境内置会有另外一个问题，第三方依赖库的问题，可以参考 mitmproxy 对 python 的支持，他内置的环境用户没有办法调整依赖库，必须要自己配置环境才可以

不过自己做一套独立绿色的 python 环境也不难，我现在就是自己搭了一套，与 mitmproxy 放在一起，启动 mitmproxy 的时候为 mitmproxy 指定使用这个环境，安装依赖直接安装到这个独立环境里就可以，目前这样用着没啥问题

你为何不调研一下？是写 js 的多还是 python 的？这个问题拍脑袋一定是 js 。因为作为这样的功能，使用最多的一定是前端 or 后端，测试有，但测试写代码有几个都要打个问号。绝大多数情况都是前端 or 后端做好扩展直接用。测试没那功夫自己写。这

问下，api 接口什么时候可以加上环境变量支持？

＃78 指定是二级代理吧。技术上来讲，socks 协议需要有个握手过程，稍微麻烦点，http 代理实现就非常简单了；从实际使用场景来讲，一般梯子软件都是提供本地 http 代理端口，所以 http 代理够用了；另外呢，很多用来非翻墙的代理软件，不一定支持 socks 协议，或者开发者自己写了个代理服务器，基本是也是写 http 代理，简单嘛。

＃82 快的话一个月，慢的话三个月，春节后的 Roadmap 具体还没整理。

我也觉得 python 用户宽度大，另外不知道 op 知不知道 yakit ，你这个产品让我想起来了它，也是最近几年一直在开发。

＃81 这看起来不是拍脑袋拍错了嘛😂，我既不是做前端也不是做后端出身的，我是做 Android 出身的。我做移动端的时候，JS 几乎不用，反而 python 常用，可能也和我的行业是 AI 领域有关。

＃85 yakit 这个我知道，对标的是 burpsuit ，算是赛道有重叠吧。

直接上 wasm ，语言 Actionscript/go/rust/c/c++/zig/lua/python/... 就都有了 🐶

libython 是可以，但 libpython 大多还是用封装一个 python 语言的 API ，还是用来扩展 python 的能力你能比较容易做到写一个 「 extensions for python 」/ 「 extension with ES 」，但反过来就不那么容易，这是两个相反方向

你所说的“用 Python 这个方案更好”都是基于你的臆想，没有调研的软件发布后的用户反馈也证明了是这样的至于你说的差异化竞争，那你有看到说“python 方案好”的用户反馈吗？注意是用户反馈不是你自己说的哦。差异化竞争，你关注的是差异，但是实际上他还是竞争。竞争是什么意思？意思就是，想法你可以做，但是最后想法好不好，终究还是要由市场来决定。市场觉得不行的，他差异再大也没用。

＃83 确实，http 代理客户端实现起来比 socks 简单、对于服务端而言则 socks 代理协议更简单

对都会的人感觉用不同语言没啥大差别。个人觉得你就直接让用户投票呗，哪个投的多就先用啥就完事了，其他语言未来慢慢支持

接口的主要用户人群是谁？是前端，不是后端！！！

如楼上所说，看主要用户群体，如果是前端 那就 js ，如果测试 那就 python ，但从功能需求上来说 前端一般没太多痛点，请求 mock 就行，用了下不得不说 一键代理真不错，加油！

我的建议是用 haskell

大佬牛逼，1 个人开发这种软件，原来还是小黄鸟 HttpCanary 的作者

如果实在无法决策，最好都支持，由客户去选择比较好。

感觉 OP 语气里已经有拿着锤子找钉子的感觉了, 而且现在的反馈也是幸存者偏差了,会 js 的会骂,会 python 的不会提

我都会也优先 js ，python 过于“优雅”，js 没负担不需要换行缩进，lambda 表达式满天飞也无所谓。

python 的包管理有很大问题遇到过很多次了 有 requirements.txt但是就是有版本依赖冲突问题很可能出现的情况 脚本头两个月 work过了两个月报错