最开始为何选择Go？

最开始选择Go也是做了综合考量的，在大部分的选择上Go都是比较不错的选择：

1. 性能
2. 开发效率
3. 具有一定的元编程能力
4. 可以打包出独立可执行的文件
5. ...

为何又要抛弃Go？而使用C#重写。

Go可能与本地调用相关的开发比较麻烦。考虑到可能要和32位的易语言程序(插件开发中可能会使用到易语言32位DLL)交互，而Go自身与DLL交互就是有些繁琐和不那么自然的，同时还存在一些其他方面的考虑：比如数据交互相对比较麻烦、回调处理也麻烦等等；再其次就是Go对32位程序的调试其实是不支持的，这可能对后期开发会造成一定阻碍。

之前也考虑过使用其他方式完成ebuild主程序和易语言开发插件交互的方式：比如IPC，但是能最大化效率的应该还是传统的插件式开发。所以，如果舍弃与易语言程序交互的能力，Golang还是一个不错的选择。

但是在以后很大可能会将ebuild和易语言程序结合，同时C#+.NET6自身性能也是不错的，对于本地调用相关的处理也是比Go要优秀得多（这也是C#+.NET的一大优势，参见.NET本机互操作性），所以综合之下，还是选择了C#+.NET6。也不必担心运行时问题，.NET6本身就支持将运行时同程序一同发布。

改动

基本上是完全复刻了先前Go版本ebuild的功能，但还是有些微小改动：

1. 完善工程信息展示
2. 不向编译周期脚本转发标准输入（即编译周期脚本无法从标准输入获取用户输入的信息，因为本身构建是应该支持并行，只是目前暂且考虑到并行构建可能会影响ecl所以取消了并行构建，不代表以后都不会引入。那么允许输入的话，就会导致混乱），参见

   // 思考了一下还是决定不允许在构建脚本中接收输入（标准输入），尽管之前golang版本中已实现

大致能想到的有这些，可能会有遗漏。