怎么联系？

parser 倒不是关键，静态分析写的太简陋了，这里面 corner case 挺多的。java 领域比较成熟的框架 soot 或者 wala

看了下代码，我觉得 coca 的静态分析不太靠谱，不如试试比较成熟的那几个

第二个方案用 antlr 不是个好主意，需求越来越多，搞着搞着最后就变成实现一套语言了。不如直接找个支持自定义 DSL 的语言（例如 groovy），在此基础上去实现会好点

vars.put("data", new String(data));

base64 把 byte 转成 string，然后再转回去

技术路线的测开会发现，纯测试开发技术大部分都服务于 QA 或者小部分人群，这些系统都未经标准化的开发管理，也没有外网的海量验证，技术的深度和广度在上游开发看来，不值一提
喜欢做技术，或者转做更上游的开发岗位或者具备领域门槛的研发岗位，专一纯粹去做技术思考和规划，把核心技术深入理解并向架构等方向纵深。

个人觉得这个理解有点片面了，与运维开发不同的是，貌似因为测试的缘故导致多数人总会把测试开发当做自动化的业务测试去理解。当运维开发搞出来 devops，在从架构层面上去改变开发模式，甚至已经开始用云原生去革开发的命。测试开发不要再想着用一个 ssh+vue，写一个所谓的自动化测试框架就是测开的阶段了。
想想公司里测试基建真的有做起来吗？压测是不是还在用 jmeter，能不能做到全球多节点的分布式压测，能不能做到结合监控数据、结合代码分析，做到自动分析代码问题？
静态代码扫描是不是就还在用 sonar，就找人配了几个规则，搞个 ide 插件就完事了？程序分析作为 PL 领域比较火热的一个大领域，能不能做到工业界的落地？
集成测试是不是还停留在接口测试的阶段？复杂业务的全链路自动化测试，在链路上任何一个节点中断、切入这些都能做到吗？
还有混沌工程、流量录制回放、单测生成、用例生成、精准、程序修复……可以做的东西太多了，总结来说就是测试领域的基建还是太落后了。

思路本质就是做 aop，看在哪里做 aop 去改掉原本业务要请求的地址。

比如代码级别的动态配置下发
编译层面的拦截 c/c++ 插桩 java 的 agent，字节码&源码级别的切面 aspectj ASM 等等
机器级别的 libc 拦截、防火墙拦截
中间件级别的 网关统一拦截，配置中心拦截
路由器级别的拦截，这个类似防火墙

当然每一层做都各有优劣势，可以根据自身情况分析分析再做决定

结构化 diff 一般都是将文本解析到语法树，然后通过一些 tree node diff 算法来实现
然后你可以将语法节点本身作为树节点映射，也可以抽象一套通用的树节点，里面包含语法节点名称与值这两个属性，这样获得的结果就通用了

最适合用来做 java 应用单元测试语言的就是 groovy，里面很多特性感觉都是量身定制。
包括元编程，也能应用到很多场景