不瞒大家，接到这个需求的时候我第一感觉是离谱。
在我的认知里，只有客户端程序需要避免被反编译，重新打包，常见的处理方法是混淆。如果是为了防止软件被破解，可以增加注册码，或者全程联网。
现在接到的这个需求是后端微服务也要考虑安全性、防泄漏。我琢磨着后端程序不都是放在自家机房或者是云服务器上吗？怎么还要考虑泄漏问题？
答曰：需要避免运维人员在发布过程中拷贝……
好吧，就算开发出来的代码被拷贝走了，一般后端微服务部署方案非常复杂，不是单单拷贝了一个部署包或者镜像就能用的啊？
要是说反编译导致商业机密泄漏，好吧，参考这个知乎问题，我觉得没多大反编译的价值： https://www.zhihu.com/question/306333255
所以我现在非常怀疑是不是我出发点就错了，求指点迷津！
参考微信就行了
好调试的地方干脆不服务？指的是什么？
我没写对，就是说把 app 做成严重依赖服务器的那种，本地功能尽可能少，只要在本地的很容易被破解
这么折腾还不满意就没法了，拆分也是可以的，拿到一部分代码跑不起来
客户的这种担心，源自几个原因：
1. 开发成本很大（占比）
2. 主要的 idea 就包含在软件中，copy 走就连同 idea 一起盗取了
3. 部署简单，偷盗者或者购脏者能迅速“华丽转身”变成竞争对手
1/2 都较难解决，建议在第三点下手，将部分核心内容交由客户自己部署（通过密码或 key ），就是拷贝部署后的成品不能用，只能通过掌控密码的人重新部署这部份
注意：说的不是部署后要 key 运行，而是部署本身就需要 key，部署后的模块换设备就不能运行，要重新部署
java 的无非是代码混淆，重写 classloader，jni，c 的部分混淆就多了，问题是混淆加密花指令垃圾代码可能微微影响性能，甚至混淆的不好直接挂了都有可能
如果是不太涉及性能可以用 lua 等动态语言写一部分代码，lua 的解析器可以完全定制，你拿不到映射关系是没法反编译的
然后如果是 web 服务这种可以插暗桩，比如特殊的 header 和输出，记得以前有个 ftp 服务器就用这种起诉别人用盗版
只要你的东西足够诱惑，防是防不住的，律师团队肯定得有
等会, 那开发拷贝源码你们是怎么避免的? 源码不是比包更要紧吗?
听起来像拍脑袋的决定, 运维能碰机器大不了给机器打个镜像在家里倒出来谁防得住?
在调研过程中找到这个,我没试,你可以看看
https://github.com/core-lib/xjar