cesuproxy

搜索支持正则

> [@cesuproxy](https://github.com/cesuproxy) 文件夹设置的公共参数现在是不显示的，只在实际请求时生效。 编辑请求的请求头和参数也是用空白默认模版显示的

> > > [@cesuproxy](https://github.com/cesuproxy) 文件夹设置的公共参数现在是不显示的，只在实际请求时生效。 > > > > > > 编辑请求的请求头和参数也是用空白默认模版显示的 > > 逻辑上是这样。 这与电脑端不一致，电脑端从API集合点击请求的参数、请求头会显示具体的 手机端默认是空白模版 应当保持与电脑端一致，保持操作习惯

> [@cesuproxy](https://github.com/cesuproxy) 感谢建议，不知道是什么场景，我没能get到这个需求的真正痛点。 @MegatronKing 核心痛点在于分析请求时的重复劳动：每次抓包都必须重新识别和定位特定请求。通过一次性编写规则，系统可实现对已分析请求的持久化、自动化标记。这意味着，无论间隔多久，都无需重复分析请求的实际用途，而是能够将精力直接集中在新的、未知的请求上，实现分析效率的几何级提升。

@MegatronKing 提供了一个“永久记忆”的解决方案。可以在分析完成后，立即编写自动化标注规则。规则一旦建立，形成永久性的知识库，无论是一个月还是一年后再次遇到相同结构、特征的请求，都会按规则自动添加描述，不需要再次动脑回忆或分析，迅速定位和理解请求，彻底杜绝了因为遗忘而产生的重复分析成本。

@MegatronKing 再次建议考虑此需求，时间导致的遗忘是必然的，备注有着无法全局匹配的局限性，无法全局匹配：在 API 集合里给单个接口写了备注，但在抓包列表、导入的 HAR 文件中，仍然无法知晓这个请求的用途，备注也有可能写入了脚本写入的内容，备注是临时的，无法承载接口描述的重任 项目迭代和时间的推移，即使是最详尽的局部备注也会被遗忘，导入一个旧的 HAR 文件或查看早期的抓包记录时，这些数据就成了“黑箱”，必须耗费大量精力重新溯源 每一个接口的用途都应该有一个知识库统一管理，通过用户自定义规则，自动为匹配的请求添加描述，无论在任何地方展示这个请求，抓包列表、导入的HAR文件、接口调试、API集合内等所有展示请求的地方，都可以使用规则匹配请求展示描述，永久性的解决遗忘 一旦规则建立，后续所有请求的描述添加将是完全自动化的，无需用户手动干预。 https://github.com/reqable/reqable-app/issues/728 提到时间久了容易混淆 https://github.com/reqable/reqable-app/issues/1371 提到久了忘了参数是什么 https://github.com/reqable/reqable-app/issues/1925 提到记不住对应的字段状态 https://github.com/reqable/reqable-app/issues/2049 提到接口多了不知道接口的有些作用 https://github.com/reqable/reqable-app/issues/1539 提到需要对接口功能等的一个说明或解释 https://github.com/reqable/reqable-app/issues/216 提到容易忘记是干啥的 以及下方提到的需要对接口增加描述 https://github.com/reqable/reqable-app/issues/1156 https://github.com/reqable/reqable-app/issues/478 https://github.com/reqable/reqable-app/issues/1645 https://github.com/reqable/reqable-app/issues/1143 https://github.com/reqable/reqable-app/issues/1156 https://github.com/reqable/reqable-app/issues/1697

> 你只拦截google.com，说明*.apple.com已经绕行，不需要再配置。 使用绕行模式是必须的，例如Apple的域名，绕行模式会对未绕行的所有域名都进行解密，会产生没有必要的性能占用 合并后按照排序生效，使用-为前缀表示绕行