从一个GitHub上的Issue想到的

最近更新了一下一键脚本，把切换到Vmess协议的功能加上了。想出来了一个几乎不影响原有使用体验，脚本结构足够简单，后续维护和解释的工作量比较小的方案。欢迎有Vmess协议需求的来试用。

bash <(curl -L https://github.com/crazypeace/v2ray_wss/raw/main/install.sh)

我在这里想扯一点别的，关于一个Issue

https://github.com/crazypeace/v2ray_wss/issues/7

这个Issue的原作者向我提了几个问题，一个是怎么在VPS上搭建Subconverter，一个是希望我的脚本支持搭建Vmess协议。我印象中TA的语气还是很客气的。

我回复的内容基本上是拒绝了他，当然我还是解释了几句，表达了我自己对这些需求的想法。

过了几天时间，这个Issue的作者把Issue清空了，标题和内容都改成了“算了”。

我想关于这个清空和“算了”说几句。

首先，我很感谢他给我回应。像这样的“小品”工具，有一些bug，或者改进的缺点，或者新功能的需求，或者实现方案的思路，是需要广大的使用者反馈的。光作者一个人使用常常是遇不到大家这么多种实际使用情况的。闭门造车的效果也很差。我以前只是在博客简单写写，没有在Telegram上大量加入群组，没有把自己作品使劲推广给大家的时候，我是收不到什么反馈的。我也一直自我感觉良好。直到把作品推给大家，为了解释和辅助去写详细的教程，去接触其它人的作品，学习大家的优点，找准自己的定位…… 在这样的过程中，我才觉得很快就有了很多收获。

其次，我想说，在开源的世界里，开发者是有极大的权利的。在这个世界里，就是很直接的靠能力说话，你行你上，摆事实讲道理说明你的观点。如果作者不同意你的想法，你就fork一份，让大家都来喜欢用你的fork, 用事实证明你是对的。

最后，我觉得，当你提出一份Issue时，你是这份Issue的作者。 我印象中当时TA的描述还是比较好的，语气也很客气。我当时回复TA时，我只是考虑到自己开发和维护的工作量而拒绝了他。这确实是我的想法，很长一段时间我觉得如果想用Vmess的话，有八合一等脚本可以搭出来，那就不用我的VLESS脚本。我希望我的脚本足够简单，能成为一个大家学习自己写脚本的原料。我觉得TA在那份Issue中的表达确实是有其自身的价值，清空太可惜了。即使被我第一次拒绝了，TA也可以继续修改和优化他的想法和表达，也许就打动了我呢？即使不修改，如果留在这里，被另一个谁看到，也许就有人心动fork了一份呢？或者谁向我提出一个更靠近具体实践的思路，也许我就像现在这样动手更新了脚本呢？如果你觉得你的观点是对的，大可以留在这里，可以等待其它人的共鸣，可以等待时间来检验你的想法。

最后的最后，我想说一点我对开发和产品的看法。我不是全职开发者，写这个脚本只是个爱好，同时也只是因为开源世界里没有一个我心目中需要的脚本，于是我就在别人的成熟的轮子的基础上，拼拼凑凑，以最小的开发工作量写了一个满足我自己需求的脚本。在此基础上，在我不用付出太多精力来开发和维护的前提下，再稍微多满足一点其它人的需求。

就拿支持Vmess协议这个需求来说吧。首先我对它的想法就不是必需的，具体的可以去看那篇Issue中我的回复。接下来我们来谈一谈开发和维护的代价。

一开始的时候，我的思路是，要支持Vmess协议，那从一开始就要给用户一个VLESS/Vmess协议的选择枝，之后的实现也是两整套，这样的话这个脚本就成了一个二合一脚本。脚本的体量翻倍，开发的工作量还好，但是长期维护的工作量翻倍才是最厉害的，而且长期维护中最担心出错。而且这样的话，原来只需要使用VLESS协议的用户需要在执行脚本的一开头就多做一次无谓的选择，哪怕设计成回车默认VLESS在我看来也是不必要的。这时候我对这个需求的看法是，有Vmess需求的人自己fork一份，稍加修改就可以了。

后来，随着我对整个翻墙服务端认识的深入，我了解到，以我的搭建方式，修改为Vmess协议只要修改V2Ray的配置文件中的一个地方就够了。这个时候，我还没有想好如何设计生成Vmess链接的逻辑流程，我也没有想好要不要支持VLESS和Vmess两协议之间的切换。于是，我只是写了一篇教程讲如何修改配置文件切换为Vmess协议，我也写了一篇教程介绍如何认识翻墙服务端配置文件中的参数，这样在读者手动修改了配置文件以后，可以自己填写到翻墙客户端的节点参数中去。同时，我还有一个想法就是让大家有机会动手稍微深入一点点来看看配置文件，认识一下自己天天用的翻墙服务端到底是哪些参数在起什么样的作用。同时，我还有一个担心就是，目前是只需要修改一个地方，以后会不会出现什么变化，只修改一个地方不够，需要修改比较大，怎么办？那时候还要继续支持Vmess协议吗？

再后来，我没有看到太多自己动手修改配置文件的反馈。我自己也想到，可以利用sed命令进行查找替换，这样的话“懒人小白”连文本编辑器都不需要了，无脑执行sed命令就可以了。但这个时候，还是要打开配置文件内容才知道翻墙客户端的节点参数如何填写。

再就是几天前的事了，我想到了一个比较好的流程，使得原有的VLESS极简爱好者的使用体验几乎没有受到影响，而需要使用Vmess协议的用户也能通过一个Y/N选择切换为Vmess协议并得到节点链接和二维码，方便导入到翻墙客户端中使用。至于这两个协议之间的来回切换，我就不准备在脚本中实现了，稍微学习一下就可以自己动手了，而且对应的节点链接和二维码已经生成放好在文本文件里了。多说一句，我对这个脚本的设计定位并不是一个保姆式的菜单型的脚本，脚本只是稍微帮你省点事，并不是包办一切。所以我的脚本中没有处理太多异常情况，连端口占用我都没有检测。至于以后会不会有变化使得支持Vmess不再只是如此简单的修改的问题，我的答案是，考虑到我的脚本的搭建方案，V2Ray是躲在Caddy后面的，VLESS/Vmess是套在TLS里面的，CDN不是国内的，所以不需要考虑以后协议升级或更新的问题，就像这个方案里的Vmess还是使用最老的没有支持AEAD之前的版本，也不会有安全性问题一样的。

我啰啰嗦嗦讲这么多，是想让没有参与开发的用户看到，一个支持Vmess协议的需求，从用户那里提出来只是几个字而已，而开发者要思考多少；同时，我也想让大家看到，开发是一个非常吸引人而且有乐趣的脑力激荡的过程，如果你动了一下念头，欢迎你鼓励自己动手从修改现有的轮子开始，定制符合自己需求的脚本，也许有一天，你会是开发圈里有力一份子。