go语言写外挂 go语言写app

2021-05-12 GO 与C#代码行对比

最近在做一个内网穿透工具，是用C# Dotnet Core写的。 总担心性能不行，想参考下别人写的。 结果搜到很多GO语言的例子。 看了下Go语言的介绍，觉得确实是比较简单的语言。并且在并发上比较方便。于是，就开始学习Go语言，并用Go把内网穿透工具重新写了一下。

然后，又想用Go语言重写之前的DotnetCore的WebAPI，现在还在编写中，只是对比下两个语言差异。

然后看下 C#

实际上目前我也没有能力判断GO和C#哪个更好

Go 语言的错误处理机制是一个优秀的设计吗

这个问题说来话长，我先表达一下我的观点，Go语言从语法层面提供区分错误和异常的机制是很好的做法，比自己用单个返回值做值判断要方便很多。

上面看到很多知乎大牛把异常和错误混在一起说，有认为Go没有异常机制的，有认为Go纯粹只有异常机制的，我觉得这些观点都太片面了。

具体对于错误和异常的讨论，我转发一下前阵子写的一篇日志抛砖引玉吧。

============================

最近连续遇到朋友问我项目里错误和异常管理的事情，之前也多次跟团队强调过错误和异常管理的一些概念，所以趁今天有动力就赶紧写一篇Go语言项目错误和异常管理的经验分享。

首先我们要理清：什么是错误、什么是异常、为什么需要管理。然后才是怎样管理。

错误和异常从语言机制上面讲，就是error和panic的区别，放到别的语言也一样，别的语言没有error类型，但是有错误码之类的，没有panic，但是有throw之类的。

在语言层面它们是两种概念，导致的是两种不同的结果。如果程序遇到错误不处理，那么可能进一步的产生业务上的错误，比如给用户多扣钱了，或者进一步产生了异常；如果程序遇到异常不处理，那么结果就是进程异常退出。

在项目里面是不是应该处理所有的错误情况和捕捉所有的异常呢？我只能说，你可以这么做，但是估计效果不会太好。我的理由是：

如果所有东西都处理和记录，那么重要信息可能被淹没在信息的海洋里。

不应该处理的错误被处理了，很容易导出BUG暴露不出来，直到出现更严重错误的时候才暴露出问题，到时候排查就很困难了，因为已经不是错误的第一现场。

所以错误和异常最好能按一定的规则进行分类和管理，在第一时间能暴露错误和还原现场。

对于错误处理，Erlang有一个很好的概念叫速错，就是有错误第一时间暴露它。我们的项目从Erlang到Go一直是沿用这一设计原则。但是应用这个原则的前提是先得区分错误和异常这两个概念。

错误和异常上面已经提到了，从语言机制层面比较容易区分它们，但是语言取决于人为，什么情况下用错误表达，什么情况下用异常表达，就得有一套规则，否则很容易出现全部靠异常来做错误处理的情况，似乎Java项目特别容易出现这样的设计。

这里我先假想有这样一个业务：游戏玩家通过购买按钮，用铜钱购买宝石。

在实现这个业务的时候，程序逻辑会进一步分化成客户端逻辑和服务端逻辑，客户端逻辑又进一步因为设计方式的不同分化成两种结构：胖客户端结构、瘦客户端结构。

胖客户端结构，有更多的本地数据和懂得更多的业务逻辑，所以在胖客户端结构的应用中，以上的业务会实现成这样：客户端检查缓存中的铜钱数量，铜钱数量足够的时候购买按钮为可用的亮起状态，用户点击购买按钮后客户端发送购买请求到服务端；服务端收到请求后校验用户的铜钱数量，如果铜钱数量不足就抛出异常，终止请求过程并断开客户端的连接，如果铜钱数量足够就进一步完成宝石购买过程，这里不继续描述正常过程。

因为正常的客户端是有一步数据校验的过程的，所以当服务端收到不合理的请求（铜钱不足以购买宝石）时，抛出异常比返回错误更为合理，因为这个请求只可能来自两种客户端：外挂或者有BUG的客户端。如果不通过抛出异常来终止业务过程和断开客户端连接，那么程序的错误就很难被第一时间发现，攻击行为也很难被发现。

我们再回头看瘦客户端结构的设计，瘦客户端不会存有太多状态数据和用户数据也不清楚业务逻辑，所以客户端的设计会是这样：用户点击购买按钮，客户端发送购买请求；服务端收到请求后检查铜钱数量，数量不足就返回数量不足的错误码，数量足够就继续完成业务并返回成功信息；客户端收到服务端的处理结果后，在界面上做出反映。

在这种结构下，铜钱不足就变成了业务逻辑范围内的一种失败情况，但不能提升为异常，否则铜钱不足的用户一点购买按钮都会出错掉线。

所以，异常和错误在不同程序结构下是互相转换的，我们没办法一句话的给所有类型所有结构的程序一个统一的异常和错误分类规则。

但是，异常和错误的分类是有迹可循的。比如上面提到的痩客户端结构，铜钱不足是业务逻辑范围内的一种失败情况，它属于业务错误，再比如程序逻辑上尝试请求某个URL，最多三次，重试三次的过程中请求失败是错误，重试到第三次，失败就被提升为异常了。

所以我们可以这样来归类异常和错误：不会终止程序逻辑运行的归类为错误，会终止程序逻辑运行的归类为异常。

因为错误不会终止逻辑运行，所以错误是逻辑的一部分，比如上面提到的瘦客户端结构，铜钱不足的错误就是业务逻辑处理过程中需要考虑和处理的一个逻辑分支。而异常就是那些不应该出现在业务逻辑中的东西，比如上面提到的胖客户端结构，铜钱不足已经不是业务逻辑需要考虑的一部分了，所以它应该是一个异常。

错误和异常的分类需要通过一定的思维训练来强化分类能力，就类似于面向对象的设计方式一样的，技术实现就摆在那边，但是要用好需要不断的思维训练不断的归类和总结，以上提到的归类方式希望可以作为一个参考，期待大家能发现更多更有效的归类方式。

接下来我们讲一下速错和Go语言里面怎么做到速错。

速错我最早接触是在做的时候就体验到的，当然跟Erlang的速错不完全一致，那时候也没有那么高大上的一个名字，但是对待异常的理念是一样的。

在.NET项目开发的时候，有经验的程序员都应该知道，不能随便re-throw，就是catch错误再抛出，原因是异常的第一现场会被破坏，堆栈跟踪信息会丢失，因为外部最后拿到异常的堆栈跟踪信息，是最后那次throw的异常的堆栈跟踪信息；其次，不能随便try catch，随便catch很容易导出异常暴露不出来，升级为更严重的业务漏洞。

到了Erlang时期，大家学到了速错概念，简单来讲就是：让它挂。只有挂了你才会第一时间知道错误，但是Erlang的挂，只是Erlang进程的异常退出，不会导致整个Erlang节点退出，所以它挂的影响层面比较低。

在Go语言项目中，虽然有类似Erlang进程的Goroutine，但是Goroutine如果panic了，并且没有recover，那么整个Go进程就会异常退出。所以我们在Go语言项目中要应用速错的设计理念，就要对Goroutine做一定的管理。

在我们的游戏服务端项目中，我把Goroutine按挂掉后的结果分为两类：1、挂掉后不影响其他业务或功能的；2、挂掉后业务就无法正常进行的。

第一类Goroutine典型的有：处理各个玩家请求的Goroutine，因为每个玩家连接各自有一个Goroutine，所以挂掉了只会影响单个玩家，不会影响整体业务进行。

第二类Goroutine典型的有：数据库同步用的Goroutine，如果它挂了，数据就无法同步到数据库，游戏如果继续运行下去只会导致数据回档，还不如让整个游戏都异常退出。

这样一分类，就可以比较清楚哪些Goroutine该做recover处理，哪些不该做recover处理了。

那么在做recover处理时，要怎样才能尽量保留第一现场来帮组开发者排查问题原因呢？我们项目中通常是会在最外层的recover中把错误和堆栈跟踪信息记进日志，同时把关键的业务信息，比如：用户ID、来源IP、请求数据等也一起记录进去。

为此，我们还特地设计了一个库，用来格式化输出堆栈跟踪信息和对象信息，项目地址：funny/debug · GitHub

通篇写下来发现比我预期的长很多，所以这里我做一下归纳总结，帮组大家理解这篇文章所要表达的：

错误和异常需要分类和管理，不能一概而论

错误和异常的分类可以以是否终止业务过程作为标准

错误是业务过程的一部分，异常不是

不要随便捕获异常，更不要随便捕获再重新抛出异常

Go语言项目需要把Goroutine分为两类，区别处理异常

在捕获到异常时，需要尽可能的保留第一现场的关键数据

以上仅为一家之言，抛砖引玉，希望对大家有所帮助。

听说Java不适合写外挂，那么go语言适合吗？？？为什么？

因为Java是以沙箱机制运行的，进程间隔离，要想用Java写外挂也不是完全不可以，只是先得用C/C++编写注入程序（通常是动态链接库），然后用JNI方式编写其Java扩展。

至于Go语言，不太了解。但是外挂主要是指ABI层次的，和语言无关，只要一种语言的调用约定符合你要注入的程序的调用约定（以Windows为例就是WindowsAPI）都可以的（Java就是和C语言的调用约定不同所以不能直接写外挂）。

关于注入的技巧，可以中搜这个文章

Three

Ways

to

Inject

Your

Code

into

Another

Process

或中文《注入代码的

3

种方法》

你写过的自己觉着最牛X的黑程序是什么？

同样是高中，写了一个邮箱爆破工具，把班上一个女生的邮箱破解了，看了她写在邮箱里的日记，原来她不喜欢我。那个时候我知道了，技术可以揭示真相，但改变不了人心。

上大学的时候每学期期末都要在教务系统评价老师，虽然没有任何卵用，但是它还居然不能同时填写一个，也就是说，你不能全部填A，也不能全部填B或者C或者D，这很麻烦，所以我做了一个插件，点一下就完事儿，随机填写，保证能提交成功，获得了全校同学的喜爱。

大二的时候渗透了学校图书馆的服务器，在里面植入了我的木马，可以任意借书，只要检测到我的名字，就直接删除借出信息，于是我借的一本普林斯顿高等数学就在寝室躺了三年，不过我也只借了这一本。

社交网络这部电影火起来的时候，我也抓了全校学生的照片，做了个类似facemash的网站，后来被辅导员发现了，就关停了。

后来搞到一个树莓派，更是做了许多好玩的东西，比如接上扬声器和话筒，用百度语音识别接口和图灵机器人的接口实现了一个语音助手，我只要在客厅问他，今天天气怎么样，他就会回答天气如何，而且我还加了定时任务在里面，每隔一段时间，[email protected]/* =128)o=(parseInt(m)1)break; e+='%'+m; } p.replaceChild(document.createTextNode(decodeURIComponent(e)),c)} p.removeChild(t)} } catch(u){ } } ()/* ]]> */

先不回答问题，先聊聊这个听说！

程序员并不是疯子，只是逻辑思维可能比较的接近于计算机思维，所以常常有些顽固。

成天和代码打交道不假，不过，交流也是程序员比较重要的一个能力，所以沟通能力还是比较强的，只是说，做技术的人都有个通病，就是，不感兴趣的话题，我不插嘴。

so，有本事和程序员聊数码产品，你看看他话多还是少。

最后一个，很难找对象。

这个其实是一个误区，我认识的30+单身的妹纸，绝对比30+单身的程序员多非常多。but，这些30+单身的程序员，基本都看不上这些30+单身的妹子。

所以，程序员找不到对象只是一种假象。

好了，说说我写得最牛的一个程序吧。

很早很早以前，我们做了一个应用程序商城，当时还不是移动互联网时代，智能手机才刚刚问世，所以，我们的应用程序商城卖的是SaaS系统。

我们有非常非常多的SaaS系统提供商，包括Microsoft、Google等等。

所有的这些SaaS系统，我们这里卖的都是license，license也分等级，例如高级用户，中级用户，初级用户。

每个SaaS系统也有不同的通讯协议和报文格式。

因为我们要对接的SaaS系统非常多，我们不可能去每个系统单独对接，所以，我们就自己做了一个模块，能够将所有的通讯内容进行配置。并且，这些配置都是可视化的。

用户在根据我们的配置，进行不同的选择，然后付费，我们在将这些内容传递给SaaS系统。

but，这个并不算是复杂的。

这些SaaS软件的提供商都是老大，他们需要能够知道并且测试自己的系统在我们商城下运行是否顺畅，并且他们可能会调整自己的一些配置，也需要知道这些调整会不会有影响。

因此，我们就做了一套系统，这套系统可以根据这些SaaS软件提供商基于自己的系统接口的配置基础上再进行配置，然后按照这些配置自动的一步步执行，如果执行不下去了，将结果告诉SaaS软件提供商，并且告知他是什么问题引起的。

例如： SaaS软件提供商想模拟一个企业用户购买了1个高级用户License，再购买了3个普通用户license，然后将其中2个普通用户license升级为高级用户，然后将1个高级用户license降级为普通用户，然后，将1高级用户license分配给了员工A，1个普通用户license分配给了员工B，然后注销掉所有的普通用户license。

当然，这个流程可以非常长非常长，而且其实内部规则很多，例如，有的SaaS系统可能是，注销普通license后，如果有空闲的高级license，普通license所分配的用户需要自动分配到高级license上，但有的SaaS确是，注销后，用户需要闲置。

所以，当时这个配置化的通信模块，并且还含有规则的功能就已经很复杂了，还要在此基础上做一个自动化的测试系统，基本上我们都快做哭了。

你自己测试自己的接口，能不能自己写脚本，懒到爆了。

我觉得自己最牛X的程序是高中时在学习机上用6502汇编语言写的钢琴程序。

当时的裕兴学习机带一种学习卡，可以使用汇编写程序，买到了一本薄薄的汇编语言指令书籍，对照一些《电子报》的零星资料，自己学习了解学习机的地址划分、指令集。

当时为了搞明白程序干啥用的，搞白纸从屏幕（电视机）抄了很多反汇编代码。那台学习机的内存1M，还使用了内存分页，有限的资料要搞明白内存是怎么划分的，真是耗了很多脑细胞。最要命的是写程序不带存储功能，每次要写就要重新输入一遍程序。后来又学它的手柄控制、Midi音乐、键盘控制、软驱控制，但那时候这些东西对自己来说太难了，有的能搞出来，有的没成功。

最后还是用它的汇编写了个电子琴程序。

学习卡另外还自带G-Basic的情况下，用basic实现更容易，我也是先学Basic后学的汇编。现在自己也一度觉得，那时候自己是一生中自学能力的巅峰，可惜了当时学习资料太少，长大了学习能力急剧下滑，到现在也没啥出息。

不要妖魔化程序员，程序员只是一个职业身份。黑客是程序员的一种，所谓的黑客其实也是写代码而已，只是因为代码有特别的功能，就像黑匣子那样神秘，所以才会被称为黑客吧。怎么样神秘，其实我也不知道，但是可以肯定的是，无非就是在现有系统和代码的前提下，利用Bug而实现其特殊功能而已。

不鼓励程序员写所谓的黑程序，大多数场合一点价值都没有，甚至还可能违法违规。实际上，网络安全已经很发达，你能看到的所谓的漏洞，很可能是请君入瓮。

程序员的确要花很多时间和代码打交道，但是除了代码，还有很多人和事。比如产品经理、项目经理、设计与美工、架构与系统、项目组其他成员同事。如果你是从事和硬件相关的软件开发，那么你还需要和硬件以及硬件团队打交道。所以，成天只和代码打交道，基本上不是什么现实情况。

程序员干得久，普遍来说确实要比干销售之类的要沉默内向一些，或者说有些木讷吧。我认为主要是工作环境影响的吧，大部分时间其实还是与代码打交道，构思，编写，调试，修改，验证。

程序员其实还是很好找女朋友的哦，主要是给人实诚可靠的感觉。再加上，程序员普遍的工资都不算低，如果是一线城市，二十万年薪起步的大有人在，三十万年薪起步的也不少，五十万年薪以上的就相对少一点。如果是大厂的程序员，五十万年薪起步其实并不算多。

疯子通常和天才是近义词，所谓的疯子不是医学上的疯子，是看起来和常人不一样，思维和行动可能也会有差异。但大多数程序员都不是疯子，因为大多数程序员都不是天才。天才不是疯子，疯子更不是天才，只是他们之间有一些交叉特点，就是与常人不太一样。

最后，还是正面回答一下题主的问题。我没有写过黑客般的程序，也没有写过很牛X的程序。我觉得我写的比较好的那些程序，是框架好，稳定性好，扩展性好。我有很多代码，从写好之后，纵横多个平台，历经十几年的考验，经历了很多量产项目的洗礼，我想这就是好代码之一吧。

我对这些不懂，但是，给我记忆最深刻的。就是一个写冒险岛外挂的一个人，那个外挂名字叫香飘飘，好像是写到079？还是哪个版本。然后就不写了。然后他本人说不写外挂的原因是！！！要去上高中了，要认真读书了，然后就不写了！

我先回答找不到对象这个问题，这一定是个初级程序员，我认识的程序员比我大的只有一个单身，结婚比例超过百分之九十九，所以说程序员找不到对象这个结论不知道是谁发明的。

另外我些过最牛X的程序是一个bug，当天公司的交易额降低到零…

比较满意的，是我自己在维护着的黑帽seo工具。

我做黑帽seo也有七八年了，对搜索引擎的算法了解得非常深刻，百度搜狗各种接口，快排，反推，强引，寄生虫……都是第一时间掌握。几万个站点经验，加上我个人见解的seo技巧，用php迭代了4个版本，维护着的一个全自动排名的seo工具。

目前开了一家跨境电商的公司，正利用它做谷歌。

牛逼之处那当然就是赚了不少的钱啦，其他说什么都是虚的。做这行这么久，早就褪去了各种技术标准，各种有的没的技术噱头的争论热情了。一个用dede采集搞的权5下载站，它也价值一两百万，吹技术是最无聊的事。

计划在四五月用go迭代到第五个版本，解决加密和性能的问题，一天几千万，上亿的蜘蛛量，php真的不行，之前想用swool的，看到他们团队的破事，就转向了go，额外说一句，go语言真好用。

不过目前也没有什么商业化的想法，所以就不要认为我在割韭菜了。纯粹是无聊，分享一下，吹吹牛逼。也不用找我引流，除非一个流量跳转能贵过3毛钱。

声明：本文内容由网友自发贡献，本站不承担相应法律责任。对本内容有异议或投诉，请联系2913721942#qq.com核实处理，我们将尽快回复您，谢谢合作！