背景
由于 IOS 审核机制的要求，我们需要对接口的入参、出参和接口路径进行混淆处理。具体来说，混淆的方式是通过替换入参和出参的参数名称以满足审核要求。
然而，这些替换操作往往是重复性的，并且不涉及具体业务逻辑。因此，我们需要一种高效且简单的解决方案来完成这项工作。
方案分析
对于混淆最关键点就是生成控制器接口，以及入参/出参对象，因为这个混淆本来就没有业务逻辑，只是把参数作一些映射而已。
我们考虑了以下两种实现方式：
-
动态替换接口入参/出参 动态替换虽然灵活，但可能会导致性能损耗，并增加技术实现的复杂性，因此被放弃。
-
通过插件生成混淆代码 基于上述原因，我们选择使用第二种方式，通过插件生成混淆代码。这种方式更高效，且便于维护。
解决方案
我们的核心思路是：
- 准备一些代码模板文件，通过 Velocity（ vm ）模板引擎将模板中的关键参数进行替换。
- 使用 Idea 插件生成混淆后的代码文件。
- 对于入参和出参的参数替换，通过调用大模型生成与原始参数含义相近的词汇，确保混淆后的代码语义合理且规整。
此方案在兼顾实现效率的同时，也最大程度减少了人工干预，使代码生成过程更加自动化、智能化。
插件安装
通过本地安装方式，将jar包导入进去
配置插件
这样就配置完成了，插件安装配置之后，最重要的是，模板的维护。
上面配置中，路径配置是生成代码保存的路径。文心一言配置是接入的文心一言大模型配置（主要用户获取参数名称的相近词汇）。本地代码模板配置指生成的代码模板，以及代码模板配置文件，这两种文件不同项目是不同的，但是配置需要按照一定的规则。
安装之后右键，可以看到有 full code（全量）、raised code（增量）生成代码。
全量生成代码
首次打开是没有任何接口的，需要修改配置
接口读取的是全量代码JSON配置文件
全量代码JSON配置文件
配置文件也在模板文件里面，也是需要维护的，配置文件定义了生成哪些类，该如何生成
以cms 服务配置文件为例：
serviceName：表示服务名，也就是插件选择要生成哪些服务的名称来源。
items：具体要生成的内容。
type: 类型，0 控制器，1 入参 2 出参 3 转换器。
Methods: 只有 type 为 0 才会有，表示控制器有哪些方法。
className: 生成的类名后缀（一般与模板名称一致）
loadPath: 加载路径（template 后一个目录即可）
params: 这是需要生成相近词汇的原词汇
这里的接口名称读取的就是 JSON文件中的 serviceName。
生成代码就是通过这个配置文件的 系统配置的路径 + loadPath 找到对应的模板来动态生成代码。
增量生成代码
增量生成代码的需求是在已经生成过这个控制器了，然后需要在该控制器下新增一些方法，我们知道全量生成方式是会把整个控制器生成出来，但是如果想只加某一个方法就不行了。
增量是以 url 来识别生成哪个方法的，因此增量的配置文件也是围绕这 方法级别配置的。
增量代码JSON配置文件
Url: 指接口路径，IOS客户端一般都是给我们要混淆的接口路径，通过这个找到对应的接口方法。
Item 里面的和全量的类似了，唯一区别是 type 没有0，而是增加了一个 type = 4,表示生成的控制器接口方法，这个时候 params 不是表示参数名了，也是表示接口方法名
代码模板
地址：xxxxx
上面的模板配置，就是把这个模板拉取到本地，然后关联上。
模板类型以下代码，
控制器能使用的参数如下：
-
controllerInfo.pck
-
controllerInfo.importPackage
-
controllerInfo.path
-
controllerInfo.classPrefix
入参类：
出参依此类推
值得注意的是，JsonProperty 的值就是需要生成相近词汇的原单词，而这个词汇在 配置文件中体现
注意
去掉转换器，转换代码统一写在入参/出参里面，这样的好处是，考虑增量插件的时候，不需要考虑转化器的生成
问题：
- 貌似接口众多，JSON配置文件越来越大，导致JSON文件臃肿 -------- 方案 拆
- 提示词中已使用的词汇越多，提示词内容越大，不知道会不会有影响。
