反编译带来的困扰
对于一个开发给自己组织内部用的程序，这么做其实是非常多此一举的，但是对于商业软件来说，这又显得有必要，软件行业现在的竞争非常的激烈，大家可以把竞争对手的程序搞过来反编译一下，轻易的知道对手基于什么软件来做，或者能够比较容易知道实现原理，然后。。抄抄抄，换个名字，完事，一个全新的产品就出来了。对于Java来说这个问题就更加明显了。虽然有类似ZKM这样的商业软件来进行混码，但是混码后只要你有耐心，还是有很大机会能读懂的
在这里不得不吐槽一下，ZKM实在太难用了
怎么保护我们的Jar文件
这里我们只讨论胖胖的Jar包（就是那种全部都打在一起直接java -jar就能跑的包，例如Spring Boot打出来的）。
对于防止反编译来说，Golang这类打包出来就是二进制的方式其实就非常适合，打包成二进制之后的程序反编译难度比起一个普通的Jar来说难度会高很多。那是不是把Jar包放到Go里面打包就可以了呢？恩，是的。我们可以通过Golang的一些静态资源库来进行操作，把Jar包作为静态文件来处理。binary-go就是其中一个合适的选择
go get -u github.com/samuelngs/binary-go
安装完之后，我们执行
binary -dir ./[静态文件位置] -out binary
就会产生出许多的go文件，默认它是以20M为一个进行分拆的。binary也提供了方法帮我们把这个包重新还原回来。不过接下来碰到一个问题，虽然能还原成二进制流，不过java没法从二进制启动啊。所以这里需要用一些小技巧了，每次启动的时候把我们的jar包随机放到一个目录，每次启动的时候这个jar包的名字也随机给。完成启动之后就把这个随机生成的jar包干掉。这样一系列操作之后，一个伪装成Go的胖胖的Jar也就出来了
