goto用不好，就说goto有问题，我劝一些程序员认清自身问题先！

公司有个程序员小哥，在使用Modbus RTU做数据通讯，往设备寄存器里面写入数据，因为是半双工，且一个串口上面连了好几个设备，所以Modbus RTU在写入数据时可能会出现超时和写入失败的情况，我就告诉他，在写入数据前面先定一个锚点标签，如果写入失败，则直接goto 回锚点那里再次尝试写入，为了避免死循环，增加一个计数变量，如果连续写入失败10次，才正式返回写入失败的结果给前端。

程序员还知道跟我说goto返回锚点不能乱用，我跟他说，goto本身没什么错，之所以有隐患，是因为用的人不能善用它导致的，只要你控制好出口，那就不会出什么大问题，小哥将信将疑的就去改代码了！

过了一会儿，他跑过来告诉我：“哥，用了goto以后软件直接假死了！”

我听他说这话就来劲了：“什么叫用了goto以后软件假死？”

其实，我听他说软件假死，我就知道肯定是因为他代码写错了，没有控制好goto的出口，所以代码直接死循环了，我也好奇他是怎么把goto给弄成死循环的，所以就来到他的工位上看了下他的代码。

看完给我整笑了，我一眼就看出了问题所在！

他虽然按我说的，对goto次数进行了判断，但是他的计数变量却放在了锚点之后，也就是说每次goto回锚点以后，这个计数变量虽然之前都被赋值了，可是goto之后的新代码空间里，这个计数变量又被重新初始化了！

于是，我就把道理跟他讲，还批评他，这个问题只要稍微下个断点调试下就能发现。而他不光没有反省自身问题，反而又把问题抛给了goto，说goto还是不能乱用！

听到这话，我脑袋都要挠秃噜皮了，我问他，这种情况下，他不用goto用什么？

他回答：“递归、while循环、计时器、线程等待都可以！”

我跟他说，虽然解决方法有很多，但是像递归、while循环监听状态本身隐患就不比goto少，而计时器和线程等待多多少少都会出现阻塞线程或者增加不稳定因素，最重要的是，相比这三种方法，goto的语法更为简洁，理解起来也更加容易。

尽管我这么说，他还是有点不服，不服就不服吧，我最后跟他说：“代码从来都没有固定的书写方法，用什么方法比较好，我觉得看你自己，你如果觉得goto不好用，那你就用你自己的方法去做！但是对于我来说，我觉得goto挺好用的！”