node.js能像Java一样编译代码么?
发布于 1 个月前 作者 iori2882 1526 次浏览 来自 问答

在网络上大概搜索一下,好像是不能?虽然说Java编译的代码也能反编译(一般人还是反编译不了的)…但是直接把代码裸着部署在客户的服务器上不好吧?随随便便拷贝一下懂一些JS就能直接修改代码了…最重要的是,node.js做出来的产品在客户的服务器上部署并想按年授权收费是不是就没有办法了?还得用Java等语言重做? 代码混淆jshaman挺好的,但是他们的代码混淆竟然不支持ES6语法~~~~~~~~~~~ 大家都是怎么弄得啊?还是大家都没有把服务端部署在客户本地服务器上的需求?

18 回复

用gulp压缩混淆代码

用ts开发Node需要先编译,然后启动,而且语法还能写出java风格!值得你拥有

@151263 感谢 我去查一查这个资料

@tzbcf 代码都写一半了,工具用的IDEA,框架express,现在改来不及了吧?

backpack也可以打包,或者pkg直接打包成执行文件

项目都写一半!就没必要在改ts了!还是用Js好好开发!哈哈!

首先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等编译器,这个提案再要等几年

pkg 自己打包二进制了解下

@HobaiRiku 嗯,只是想混淆一下,不想裸的那么彻底

@libook 我很困惑,项目是部署在客户的服务器上,没有部署在公网上其实也是为了节约自己的成本…但是部署在客户机的服务器上,代码全裸总感觉没安全感

@zuohuadong 谢谢,我去了解一下

@andyhu 谢谢,学习一下

@iori2882 你得先明确这种不安全感究竟是什么。

如果是信息安全的话,有一个说法是硬件屏障为最后屏障,如果不能保证硬件隔离(即任何人都可以进入机房操作或拆开服务器)绝大多数安全策略都是无效的,所以只要客户方保证服务器运维是严格、标准、合理的,杜绝入侵者直接物理接触服务器,那么是不是源代码的形式部署软件就无所谓了。

没有做好硬件隔离的设备无论是源代码部署还是二进制部署都是极其不安全的,即便是二进制部署入侵者也可能使用恶意软件直接替换掉原软件,所以关键点不是用什么形式部署软件,而是是否有可靠的运维管控。

@iori2882 你可以这样想,几十年前就流行的PHP也是源代码形式放在服务器上执行的,PHP的安全性问题也从来不是因为PHP的部署方式是源码部署导致的,PHP遇到的安全性问题比如数据库注入漏洞是SQL本身的硬伤+编码人员经验不足导致的;程序注入漏洞是编码人员经验不足导致的;运行时解析是败在没有严格控制文件管理的逻辑,造成可以随意上传PHP文件让引擎来运行它。即便是JSP这种运行时会被编译成机器码Servlet的也难逃上传Webshell的手段。所以,代码全裸并不会是问题的根本,而妥善解决相关问题的方案也从来不是简单得直接二进制部署就可以的。

回到顶部