Nest.JS项目如何打包为可执行文件 部署时不暴露源码防剽窃

核心要实现的效果是：客户拿到交付物能直接启动服务，但拿不到可读的原始业务源码，提高代码剽窃的逆向成本，按保护强度从低到高可以选下面几类方案，按需组合就行：

基础低成本方案（适合大多数普通商业项目） #

• 第一步先做基础编译：不要直接交付TS源码目录，先在本地执行npm run build把TS代码编译为dist目录下的JS产物，但这一步的产物几乎没有保护能力，格式化后逻辑、变量名都清晰可见，和裸奔差别不大。
• 第二步对编译后的JS做高强度混淆：用javascript-obfuscator工具处理dist目录下的所有JS文件，开启控制流平坦化、RC4编码字符串数组、调试保护、自动禁用开发者工具这类配置，举个常用的处理命令参考：

  javascript-obfuscator dist/ --output dist-obf/ --compact true --control-flow-flattening true --control-flow-flattening-threshold 0.8 --string-array true --string-array-encoding rc4 --debug-protection true --debug-protection-interval 4000
  

  混淆后的代码会被打散逻辑、替换所有可读标识符，普通开发者基本无法直接梳理业务逻辑，逆向成本会提升一个量级。
• 交付时只给三个东西：混淆后的dist-obf目录、仅保留生产依赖的package.json、一行启动命令说明。客户侧只需要执行npm install --production安装依赖，再跑node main.js就能启动服务，全程接触不到原始TS源码和未混淆的JS逻辑。

中高强度方案（适合不想交付零散JS文件的场景） #

• 做完上面的混淆步骤后，用pkg或者nexe这类打包工具，把Node运行时、混淆后的JS代码、所有生产依赖打包成对应客户服务器系统的单个可执行二进制文件：比如客户是Linux x64环境，就指定对应target打包，最终产物是单个无后缀的可执行文件；Windows环境就打包成exe文件。
• 打包后的产物不需要客户提前装Node环境，直接拷到服务器上加执行权限就能跑，所有业务逻辑都封在二进制文件里，不会暴露零散的JS源码，逆向难度比纯混淆JS高很多。
• 注意如果项目里有静态资源、视图模板、配置文件这类非JS资源，打包时要提前在工具配置里声明资源路径，避免打包后找不到文件报错。

高安全增强方案（适合核心逻辑价值高、怕硬破解的场景） #

• 核心逻辑抽离为原生模块：把最核心的计费规则、专利算法、授权校验这类高价值逻辑用C++/Rust编写，编译为.node格式的Node原生扩展，NestJS主服务里直接调用这个扩展模块就行。原生二进制的逆向成本远高于JS，基本可以杜绝普通的代码剽窃。
• 加环境绑定校验：服务启动时先读取所在服务器的CPU序列号、MAC地址、磁盘标识等硬件信息，和提前授权的机器码做校验，非授权环境直接拒绝启动，就算别人把交付物拷走也没法在别的环境跑。
• 加反篡改逻辑：启动时先校验自身二进制文件的哈希值，如果发现文件被调试、被篡改打补丁，就直接退出进程，进一步提高破解成本。

注意：不存在100%无法逆向的保护方案，所有手段本质都是拉高逆向成本，只要逆向需要投入的时间、人力成本远高于剽窃代码能获得的收益，就达到了源码保护的目的。不要信“TS编译成JS就安全”的说法，未混淆的编译产物只要过一遍格式化工具，逻辑和原始源码几乎没有差别。

内容的提问来源于stack exchange，提问作者James Fu