在网络上大概搜索一下,好像是不能?虽然说Java编译的代码也能反编译(一般人还是反编译不了的)…但是直接把代码裸着部署在客户的服务器上不好吧?随随便便拷贝一下懂一些JS就能直接修改代码了…最重要的是,node.js做出来的产品在客户的服务器上部署并想按年授权收费是不是就没有办法了?还得用Java等语言重做? 代码混淆jshaman挺好的,但是他们的代码混淆竟然不支持ES6语法~~~~~~~~~~~ 大家都是怎么弄得啊?还是大家都没有把服务端部署在客户本地服务器上的需求?
首先js是解析语言，不需要编译，ts的编译不是真正意义上的编译为字节码命令，pkg,enclose是可以将nodejs程序打包封装成可执行文件的，而且可以指定文件和资源进行打包，但是对于js来说，你想要做这些事情就会有很多坑，比如模块的关系要明确、文件系统等在打包后的区别的这些都需要自己去理解和尝试，如果是整体在pkg，enclose方案下没什么难度，那可以使用这种方式去部署项目，而对于一些“动态的模块关系”，比如loader这些，要使用这种工具是比较难的，回到需求上，对于js，最好还是使用gulp压缩并丑化混淆代码来部署，js天生不适合做类似的事情，所有解析型的语言基本都是如此。
企业级Node.js应用，服务器上就是部署JS源码，五年了，没出过什么问题，所谓问题都是运维管理上的问题，要是运维上不能可靠管控的话你就是用Java也避免不了有人上去替换Jar包和动XML配置文件。
如果你的目的是想闭源，可以用ES6+写源码，然后Babel编译成ES5，再Uglify压缩混淆，或者直接找ES新语法直接Uglify的库，JS技术栈有那么多库，又不是只有jshaman一个能用。
另外说一句，9102年了，是否考虑做SaaS而不是直接提供软件？
其实有一个提案，应该可以解决编码加密问题 https://github.com/tc39/proposal-binary-ast 不过还得借助babel等编译器，这个提案再要等几年
@iori2882 你得先明确这种不安全感究竟是什么。
如果是信息安全的话，有一个说法是硬件屏障为最后屏障，如果不能保证硬件隔离（即任何人都可以进入机房操作或拆开服务器）绝大多数安全策略都是无效的，所以只要客户方保证服务器运维是严格、标准、合理的，杜绝入侵者直接物理接触服务器，那么是不是源代码的形式部署软件就无所谓了。
没有做好硬件隔离的设备无论是源代码部署还是二进制部署都是极其不安全的，即便是二进制部署入侵者也可能使用恶意软件直接替换掉原软件，所以关键点不是用什么形式部署软件，而是是否有可靠的运维管控。
