.webpack 中，module，chunk 和 bundle 的區別是什么？

說實話我剛開始看 webpack 文檔的時候，對這 3 個名詞云里霧里的，感覺他們都在說打包文件，但是一會兒 chunk 一會兒 bundle 的，逐漸就迷失在細節里了，所以我們要跳出來，從宏觀的角度來看這幾個名詞。

webpack 官網對 chunk 和 bundle 做出了解釋[3]，說實話太抽象了，我這里舉個例子，給大家形象化地解釋一下。

首先我們在 src 目錄下寫我們的業務代碼，引入 index.js、utils.js、common.js 和 index.css 這 4 個文件，目錄結構如下：

src/
├── index.css
├── index.html # 這個是 HTML 模板代碼
├── index.js
├── common.js
└── utils.js

index.css 寫一點兒簡單的樣式：

body {
    background-color: red;
}

utils.js 文件寫個求平方的工具函數：

export function square(x) {
    return x * x;
}

common.js 文件寫個 log 工具函數：

module.exports = {
  log: (msg) => {
    console.log('hello ', msg)
  }
}

index.js 文件做一些簡單的修改，引入 css 文件和 common.js：

import './index.css';
const { log } = require('./common');

log('webpack');

webpack 的配置如下：

{
    entry: {
        index: "../src/index.js",
        utils: '../src/utils.js',
    },
    output: {
        filename: "[name].bundle.js", // 輸出 index.js 和 utils.js
    },
    module: {
        rules: [
            {
                test: /\.css$/,
                use: [
                    MiniCssExtractPlugin.loader, // 創建一個 link 標簽
                    'css-loader', // css-loader 負責解析 CSS 代碼, 處理 CSS 中的依賴
                ],
            },
        ]
    }
    plugins: [
        // 用 MiniCssExtractPlugin 抽離出 css 文件，以 link 標簽的形式引入樣式文件
        new MiniCssExtractPlugin({
            filename: 'index.bundle.css' // 輸出的 css 文件名為 index.css
        }),
    ]
}

我們運行一下 webpack，看一下打包的結果：

我們可以看出，index.css 和 common.js 在 index.js 中被引入，打包生成的 index.bundle.css 和 index.bundle.js 都屬于 chunk 0，utils.js 因為是獨立打包的，它生成的 utils.bundle.js 屬于 chunk 1。

感覺還有些繞？我做了一張圖，你肯定一看就懂：

看這個圖就很明白了：

1. 對于一份同邏輯的代碼，當我們手寫下一個一個的文件，它們無論是 ESM 還是 commonJS 或是 AMD，他們都是 module ；
2. 當我們寫的 module 源文件傳到 webpack 進行打包時，webpack 會根據文件引用關系生成 chunk 文件，webpack 會對這個 chunk 文件進行一些操作；
3. webpack 處理好 chunk 文件后，最后會輸出 bundle 文件，這個 bundle 文件包含了經過加載和編譯的最終源文件，所以它可以直接在瀏覽器中運行。

一般來說一個 chunk 對應一個 bundle，比如上圖中的 utils.js -> chunks 1 -> utils.bundle.js；但也有例外，比如說上圖中，我就用 MiniCssExtractPlugin 從 chunks 0 中抽離出了 index.bundle.css 文件。

一句話總結：

module，chunk 和 bundle 其實就是同一份邏輯代碼在不同轉換場景下的取了三個名字：

我們直接寫出來的是 module，webpack 處理時是 chunk，最后生成瀏覽器可以直接運行的 bundle。

2.filename 和 chunkFilename 的區別

filename

filename 是一個很常見的配置，就是對應于 entry 里面的輸入文件，經過webpack 打包后輸出文件的文件名。比如說經過下面的配置，生成出來的文件名為 index.min.js。

{
    entry: {
        index: "../src/index.js"
    },
    output: {
        filename: "[name].min.js", // index.min.js
    }
}

chunkFilename

chunkFilename 指未被列在 entry 中，卻又需要被打包出來的 chunk 文件的名稱。一般來說，這個 chunk 文件指的就是要懶加載的代碼。

比如說我們業務代碼中寫了一份懶加載 lodash 的代碼：

// 文件：index.js

// 創建一個 button
let btn = document.createElement("button");
btn.innerHTML = "click me";
document.body.appendChild(btn);

// 異步加載代碼
async function getAsyncComponent() {
    var element = document.createElement('div');
    const { default: _ } = await import('lodash');

    element.innerHTML = _.join(['Hello!', 'dynamic', 'imports', 'async'], ' ');

    return element;
}

// 點擊 button 時，懶加載 lodash，在網頁上顯示 Hello! dynamic imports async
btn.addEventListener('click', () => {
    getAsyncComponent().then(component => {
        document.body.appendChild(component);
    })
})

我們的 webpack 不做任何配置，還是原來的配置代碼：

{
    entry: {
        index: "../src/index.js"
    },
    output: {
        filename: "[name].min.js", // index.min.js
    }
}

這時候的打包結果如下：

這個 1.min.js 就是異步加載的 chunk 文件。文檔[4]里這么解釋：

“

output.chunkFilename 默認使用 [id].js 或從 output.filename 中推斷出的值（[name] 會被預先替換為 [id] 或 [id].）

文檔寫得太抽象，我們不如結合上面的例子來看：

output.filename 的輸出文件名是 [name].min.js，[name] 根據 entry 的配置推斷為 index，所以輸出為 index.min.js；

由于 output.chunkFilename 沒有顯示指定，就會把 [name] 替換為 chunk 文件的 id號，這里文件的 id 號是 1，所以文件名就是 1.min.js。

如果我們顯式配置 chunkFilename，就會按配置的名字生成文件：

{
    entry: {
        index: "../src/index.js"
    },
    output: {
        filename: "[name].min.js",  // index.min.js
        chunkFilename: 'bundle.js', // bundle.js
    }
}

一句話總結：

filename 指列在 entry 中，打包后輸出的文件的名稱。

chunkFilename 指未列在 entry 中，卻又需要被打包出來的文件的名稱。

3.webpackPrefetch、webpackPreload 和 webpackChunkName 到底是干什么的？

這幾個名詞其實都是 webpack 魔法注釋（magic comments）[5]里的，文檔中說了 6 個配置，配置都可以組合起來用。我們說說最常用的三個配置。

webpackChunkName

前面舉了個異步加載 lodash 的例子，我們最后把 output.chunkFilename 寫死成 bundle.js。在我們的業務代碼中，不可能只異步加載一個文件，所以寫死肯定是不行的，但是寫成 [name].bundle.js 時，打包的文件又是意義不明、辨識度不高的 chunk id。

{
    entry: {
        index: "../src/index.js"
    },
    output: {
        filename: "[name].min.js",  // index.min.js
        chunkFilename: '[name].bundle.js', // 1.bundle.js，chunk id 為 1，辨識度不高
    }
}

這時候 webpackChunkName 就可以派上用場了。我們可以在 import 文件時，在 import里以注釋的形式為 chunk 文件取別名：

async function getAsyncComponent() {
    var element = document.createElement('div');
  
    // 在 import 的括號里 加注釋 /* webpackChunkName: "lodash" */ ，為引入的文件取別名
    const { default: _ } = await import(/* webpackChunkName: "lodash" */ 'lodash');

    element.innerHTML = _.join(['Hello!', 'dynamic', 'imports', 'async'], ' ');

    return element;
}

這時候打包生成的文件是這樣的：

現在問題來了，lodash 是我們取的名字，按道理來說應該生成 lodash.bundle.js 啊，前面的 vendors~ 是什么玩意？

其實 webpack 懶加載是用內置的一個插件 SplitChunksPlugin[6] 實現的，這個插件里面有些默認配置項[7]，比如說 automaticNameDelimiter，默認的分割符就是 ~，所以最后的文件名才會出現這個符號，這塊兒內容我就不引申了，感興趣的同學可以自己研究一下。

webpackPrefetch 和 webpackPreload

這兩個配置一個叫預拉?。≒refetch），一個叫預加載（Preload），兩者有些細微的不同，我們先說說 webpackPreload。

在上面的懶加載代碼里，我們是點擊按鈕時，才會觸發異步加載 lodash 的動作，這時候會動態的生成一個 script 標簽，加載到 head 頭里：

如果我們 import 的時候添加 webpackPrefetch：

...

const { default: _ } = await import(/* webpackChunkName: "lodash" */ /* webpackPrefetch: true */ 'lodash');

...

就會以 <link rel="prefetch" as="script"> 的形式預拉取 lodash 代碼：

這個異步加載的代碼不需要手動點擊 button 觸發，webpack 會在父 chunk 完成加載后，閑時加載 lodash 文件。

webpackPreload 是預加載當前導航下可能需要資源，他和 webpackPrefetch 的主要區別是：

• preload chunk 會在父 chunk 加載時，以并行方式開始加載。prefetch chunk 會在父 chunk 加載結束后開始加載。
• preload chunk 具有中等優先級，并立即下載。prefetch chunk 在瀏覽器閑置時下載。
• preload chunk 會在父 chunk 中立即請求，用于當下時刻。prefetch chunk 會用于未來的某個時刻

一句話總結：

webpackChunkName 是為預加載的文件取別名，webpackPrefetch 會在瀏覽器閑置下載文件，webpackPreload 會在父 chunk 加載時并行下載文件。

4.hash、chunkhash、contenthash 有什么不同？

首先來個背景介紹，哈希一般是結合 CDN 緩存來使用的。如果文件內容改變的話，那么對應文件哈希值也會改變，對應的 HTML 引用的 URL 地址也會改變，觸發 CDN 服務器從源服務器上拉取對應數據，進而更新本地緩存。

hash

hash 計算是跟整個項目的構建相關，我們做一個簡單的 demo。

沿用案例 1 的 demo 代碼，文件目錄如下：

src/
├── index.css
├── index.html
├── index.js
└── utils.js

webpack 的核心配置如下（省略了一些 module 配置信息）：

{
    entry: {
        index: "../src/index.js",
        utils: '../src/utils.js',
    },
    output: {
        filename: "[name].[hash].js",  // 改為 hash
    },
    
    ......
    
    plugins: [
        new MiniCssExtractPlugin({
            filename: 'index.[hash].css' // 改為 hash
        }),
    ]
}

生成的文件名如下：

我們可以發現，生成文件的 hash 和項目的構建 hash 都是一模一樣的。

chunkhash

因為 hash 是項目構建的哈希值，項目中如果有些變動，hash 一定會變，比如說我改動了 utils.js 的代碼，index.js 里的代碼雖然沒有改變，但是大家都是用的同一份 hash。hash 一變，緩存一定失效了，這樣子是沒辦法實現 CDN 和瀏覽器緩存的。

chunkhash 就是解決這個問題的，它根據不同的入口文件(Entry)進行依賴文件解析、構建對應的 chunk，生成對應的哈希值。

我們再舉個例子，我們對 utils.js 里文件進行改動：

export function square(x) {
    return x * x;
}

// 增加 cube() 求立方函數
export function cube(x) {
    return x * x * x;
}

然后把 webpack 里的所有 hash 改為 chunkhash：

{
    entry: {
        index: "../src/index.js",
        utils: '../src/utils.js',
    },
    output: {
        filename: "[name].[chunkhash].js", // 改為 chunkhash
    },
          
    ......
    
    plugins: [
        new MiniCssExtractPlugin({
            filename: 'index.[chunkhash].css' // // 改為 chunkhash
        }),
    ]
}

構建結果如下：

我們可以看出，chunk 0 的 hash 都是一樣的，chunk 1 的 hash 和上面的不一樣。

假設我又把 utils.js 里的 cube() 函數去掉，再打包：

對比可以發現，只有 chunk 1 的 hash 發生變化，chunk 0 的 hash 還是原來的。

contenthash

我們更近一步，index.js 和 index.css 同為一個 chunk，如果 index.js 內容發生變化，但是 index.css 沒有變化，打包后他們的 hash 都發生變化，這對 css 文件來說是一種浪費。如何解決這個問題呢？

contenthash 將根據資源內容創建出唯一 hash，也就是說文件內容不變，hash 就不變。

我們修改一下 webpack 的配置：

{
    entry: {
        index: "../src/index.js",
        utils: '../src/utils.js',
    },
    output: {
        filename: "[name].[chunkhash].js",
    },
      
    ......
    
    plugins: [
        new MiniCssExtractPlugin({
            filename: 'index.[contenthash].css' // 這里改為 contenthash
        }),
    ]
}

我們對 index.js 文件做了 3 次修改（就是改了改 log 函數的輸出內容，過于簡單就先不寫了），然后分別構建，結果截圖如下：

我們可以發現，css 文件的 hash 都沒有發生改變。

一句話總結：

hash 計算與整個項目的構建相關；

chunkhash 計算與同一 chunk 內容相關；

contenthash 計算與文件內容本身相關。

5.sourse-map 中 eval、cheap、inline 和 module 各是什么意思？

sourse-map ，里面都有個 map 了，肯定是映射的意思。sourse-map 就是一份源碼和轉換后代碼的映射文件。具體的原理內容較多，感興趣的同學可以自行搜索，我這里就不多言了。

我們先從官網上看看 sourse-map 有多少種類型：

emmmm，13 種，告辭。

如果再仔細看一下，就發現這 13 種大部分都是 eval、cheap、inline 和 module這 4 個詞排列組合的，我做了個簡單的表格，比官網上直白多了：

參數參數解釋eval打包后的模塊都使用 eval() 執行，行映射可能不準；不產生獨立的 map 文件cheapmap 映射只顯示行不顯示列，忽略源自 loader 的 source mapinline映射文件以 base64 格式編碼，加載 bundle 文件最后，不產生獨立的 map 文件module增加對 loader source map 和第三方模塊的映射

還不明白？可以看看 demo。

我們對 webpack 做一些配置，devtool 是專門配置 source-map 的。

......

{
    devtool: 'source-map',
}

......

index.js 文件為了簡便，我們只寫一行代碼，為了得出報錯信息，我們故意拼錯：

console.lg('hello source-map !') // log 寫成 lg

下面我們試一試常見的幾個配置：

source-map

source-map 是最大而全的，會生成獨立 map 文件：

注意下圖光標的位置，source-map 會顯示報錯的行列信息：

cheap-sourse-map

cheap，就是廉價的意思，它不會產生列映射，相應的體積會小很多，我們和 sourse-map 的打包結果比一下，只有原來的 1/4 。

eval-source-map

eval-source-map 會以 eval() 函數打包運行模塊，不產生獨立的 map 文件，會顯示報錯的行列信息：

// index.bundle.js 文件

!function(e) {
    // ......
    // 省略不重要的代碼
    // ......
}([function(module, exports) {
    eval("console.lg('hello source-map !');//# sourceURL=[module]\n//# sourceMappingURL=data:application/json;charset=utf-8;base64,eyJ2ZXJzaW9uIjozLCJzb3VyY2VzIjpbIndlYnBhY2s6Ly8vLi4vc3JjL2luZGV4Mi5qcz9mNmJjIl0sIm5hbWVzIjpbImNvbnNvbGUiLCJsZyJdLCJtYXBwaW5ncyI6IkFBQUFBLE9BQU8sQ0FBQ0MsRUFBUixDQUFXLG9CQUFYIiwiZmlsZSI6IjAuanMiLCJzb3VyY2VzQ29udGVudCI6WyJjb25zb2xlLmxnKCdoZWxsbyBzb3VyY2UtbWFwICEnKSJdLCJzb3VyY2VSb290IjoiIn0=\n//# sourceURL=webpack-internal:///0\n")
}
]);

inline-source-map

映射文件以 base64 格式編碼，加在 bundle 文件最后，不產生獨立的 map 文件。加入 map 文件后，我們可以明顯地看到包體積變大了；

// index.bundle.js 文件

!function(e) {

}([function(e, t) {
    console.lg("hello source-map !")
}
]);
//# sourceMappingURL=data:application/json;charset=utf-8;base64,eyJ2ZXJzaW9uIjozLCJzb3VyY2VzIjpbIndlYnBhY2s6Ly8vd2VicGFjay9ib290c3RyYXAiLCJ3ZWJwYWNrOi8vLy4uL3NyYy9pbmRleDIuanMiXSwibmFtZXMiOlsiaW5zdGFsbGVkTW9kdWxlcyIsIl9fd2VicGFja19yZXF1aXJ......

// base64 太長了，我刪了一部分，領會精神

常用配置：

上面的幾個例子都是演示，結合[官網推薦](https://webpack.docschina.org/configuration/devtool/#%E5%AF%B9%E4%BA%8E%E5%BC%80%E5%8F%91%E7%8E%AF%E5%A2%83[8])和實際經驗，常用的配置其實是這幾個：

1.source-map

大而全，啥都有，就因為啥都有可能會讓 webpack 構建時間變長，看情況使用。

2.cheap-module-eval-source-map

這個一般是開發環境（dev）推薦使用，在構建速度報錯提醒上做了比較好的均衡。

3.cheap-module-source-map

一般來說，生產環境是不配 source-map 的，如果想捕捉線上的代碼報錯，我們可以用這個

<scheme>://<user>:<password>@<host>:<port>/<path>:<params>?<query>#<frag>

http://<host>:<port>/<path>?<query>#<frag>

http://www.hardware.com/index.html
http://www.hardware.com:80/index.html

https://<host>:<port>/<path>?<query>#<frag>

https://www.hardware.com/secure.html

mailto:joe@hardware.com

ftp://<user>:<password>@<host>:<port>/<path>;<params>

ftp://anonymous:joe%40hardware.com@prep.ai.mit.edu:21/pub/gnu/

rtsp://<user>:<password>@<host>:<port>/<path>
rtspu://<user>:<password>@<host>:<port>/<path>

rtsp://www.hardware.com:554/interview/cto_video

file ://<host>/<path>

file://OFFICE-FS/policies/casual-fridays.doc

telnet://<user>:<password>@<host>:<port>/

telnet://slurp:webhound@joes-hardware.com:23/

http://www.hardware.com:80/index.html 
http://161.58.228.45:80/index.html

ftp://ftp.prep.ai.mit.edu/pub/gnu
ftp://anonymous@ftp.prep.ai.mit.edu/pub/gnu
ftp://anonymous:my_passwd@ftp.prep.ai.mit.edu/pub/gnu 
http://joe:joespasswd@www.joes-hardware.com/sales_info.txt

http://www.hardware.com:80/seasonal/index-fall.html 

ftp://prep.ai.mit.edu/pub/gnu;type=d

http://www.hardware.com/hammers;sale=false/index.html;graphics=true

http://www.hardware.com/inventory-check.cgi?item=12731&color=blue&size=large

http://www.hardware.com/tools.html#drills

! # $ & ' ( ) * + , - . / : ;=? @ _ ~ 0-9 a-z A-Z

//'http://www.w3school.com.cn<br />'
console.log(encodeURI("http://www.w3school.com.cn")+ "<br />")
//'http://www.w3school.com.cn/My%20first/'
console.log(encodeURI("http://www.w3school.com.cn/My first/"))
//',/?:@&=+$#'
console.log(encodeURI(",/?:@&=+$#"))

//'%E6%B5%8B%E8%AF%95'
console.log(encodeURI('測試'));

//"http://www.w3school.com.cn/My first/"
console.log(decodeURI("http://www.w3school.com.cn/My%20first/"));

!， '，(，)，*，-，.，_，~，0-9，a-z，A-Z

var uri="http://www.wrox.com/illegal value.htm#start";
//'http%3A%2F%2Fwww.wrox.com%2Fillegal%20value.htm%23start'
console.log(encodeURIComponent(uri));
//'%E6%B5%8B%E8%AF%95'
console.log(encodeURIComponent('測試'));

var uri='http%3A%2F%2Fwww.wrox.com%2Fillegal%20value.htm%23start';
//'http://www.wrox.com/illegal value.htm#start'
console.log(decodeURIComponent(uri));

* + - . / @ _ 0-9 a-z A-Z

var uri="http://www.wrox.com/illegal value.htm#start";
//'http%3A//www.wrox.com/illegal%20value.htm%23start'
console.log(escape(uri));
//%u6D4B%u8BD5
console.log(escape('測試'));

//http://www.wrox.com/illegal value.htm#start
console.log(unescape('http%3A//www.wrox.com/illegal%20value.htm%23start'));
//'測試'
console.log(unescape('%u6D4B%u8BD5'));

JS文件添加右鍵菜單，一鍵完成JS混淆加密
將“JS混淆加密”集成到鼠標右鍵菜單
Windows一鍵JS混淆加密：功能集成到鼠標右鍵菜單

目標：將“JS混淆加密”功能集成到鼠標右鍵菜單，一鍵點擊完成JavaScript代碼混淆加密。

原因：為什么實現這個功能，有什么好處？

答：方便、易用。JavaScript程序員經常需要將代碼進行混淆加密。

操作過程，通常情況下，需要將代碼復制或提交到網站或軟件中，以使用JShaman為例，需要復制代碼到JShaman網站，完成JS混淆加密，再把代碼粘貼回來。

JShaman網站不需要注冊、不需要登錄，打開網站、復制粘貼就可使用。雖然已經很方便，但集成到鼠標右鍵菜單可以更方便。

效果展示：

實現方法：

環境需求：Node.JS

1、NodeJS腳本文件準備

實現此功能，需要用NodeJS運行一個腳本JS文件，以便調用JShaman WebApi接口，進行JavaScript混淆加密。

JS代碼如下，將此文件保存為obfuscate.js，放于任一目錄下：

/**
 * 調用JShaman.com WebAPI接口 實現JavaScript混淆加密
 */
/**
 * 配置部分
 */
//JShaman.com VIP碼，免費使用設為"free"，如已購買VIP碼，在此修改
const vip_code="free";
//混淆加密參數配置，免費使用時無需配置
//參數詳細說明請參見JShaman官網，設為"true"啟用功能、設為"false"不啟用
const config={
    //壓縮代碼
    compact: "true",
    //混淆全局變量名和函數名
    renameGlobalFunctionVariable: "false",
    //平展控制流
    controlFlowFlattening: "true",
    //僵尸代碼植入
    deadCodeInjection: "false",
    //字符串陣列化
    stringArray: "true",
    //陣列字符串加密
    stringArrayEncoding: "false",
    //禁用命令行輸出 
    disableConsoleOutput: "false",
    //反瀏覽器調試
    debugProtection: "false",
    //時間限定
    time_range: "false",
    //時間限定起始時間、結束時間，時間限定啟用時此2參數生效
    time_start: "20240118",
    time_end: "20240118",
    //域名鎖定
    domainLock: [],
    //保留關鍵字
    reservedNames: [],
}
/**
 * 以下代碼實現向JShaman.com WebApi發送請求完成JavaScript混淆加密，無需修改
 */
const fs=require("fs");
const readline=require("readline");  
const request=require("request");
//獲取命令行參數中的文件路徑
//獲取右鍵菜單調用的文件路徑
const filePath=process.argv[2];  
if(!filePath) {  
    console.error("未選中文件");  
    process.exit(1);  
}  
//確保文件存在  
if(!fs.existsSync(filePath)) {  
    console.error(`文件 ${filePath} 不存在`);  
    process.exit(1);  
} 
console.log(`正在處理文件：${filePath}`);  
//從文件中獲取JavaScript代碼
var javascript_code=fs.readFileSync(filePath,"utf8").toString();
//Post請求配置
var options={  
    url: "https://www.jshaman.com:4430/submit_js_code/",  
    method: "POST",  
    json: true,  
    body: {
        //JavaScript代碼
        "js_code": javascript_code,
        //JShaman VIP碼
        "vip_code": vip_code,
    }
};  
//使用free為VIP碼、免費調用JShaman WebAPI接口時，不能配置參數，僅可實現較低強度代碼保護
//如果購買了JShaman的VIP碼，則可啟用配置，實現高強度JavaScript混淆加密
if(options.body.vip_code !="free"){
    //混淆加密參數
    options.body.config=config;
}
console.log("正在向JShaman.com提交混淆加密請求...")
//發送請求到JShaman服務器，進行JavaScript混淆加密
request(options, function(error, response, body) {  
    if (!error && response.statusCode===200) { 
        //輸出返回消息
        console.log(body.message); 
        //返回狀態值為0是成功標識
        if(body.status==0){
            const rl=readline.createInterface({  
                input: process.stdin,  
                output: process.stdout  
            });
            rl.question("是否覆蓋原文件？y為是，n則在同目錄下另存。(y/n) ", (answer)=> {  
                if (answer.toLowerCase()==="y") {  
                    //輸入y，覆蓋原文件  
                    fs.writeFileSync(filePath, body.content.toString());  
                    console.log("文件已覆蓋。");  
                } else {
                    var obfuscated_file=filePath + ".obfuscated.js";
                    fs.writeFileSync(obfuscated_file, body.content.toString());  
                    console.log("混淆加密后的Js文件：", obfuscated_file);  
                }  
                rl.close();  
            });  
        }
    } else {  
        console.error("向JShaman.com發送請求時出現錯誤：", error);  
    }  
});
//按下任意鍵退出程序
process.on("beforeExit", (code)=> {  
    const rl=readline.createInterface({  
      input: process.stdin,  
      output: process.stdout  
    });  
    console.log("按下任意鍵退出程序...");  
    rl.on("line", (input)=> {  
      rl.close();  
      process.exit(0);  
    });
}); 

說明：此JS腳本默認調用JShaman提供的免費Web API接口。JShaman提供有免費、商業兩種接口。如您已獲得JShaman VIP 碼，可修改上述代碼中的VIP碼、使用商業接口，能使配置參數生效、獲得更好的JS混淆加密效果。

2、注冊表修改

修改注冊表是為給JS文件添加右鍵菜單，以便在右鍵點擊.js文件時菜單中顯示“混淆加密”功能。

將下面的代碼保存為right_click_menu.reg：

Windows Registry Editor Version 5.00  
; 為 .js 文件類型定義新的上下文菜單項  
[HKEY_CLASSES_ROOT\SystemFileAssociations\.js\Shell\JavaScript Obfuscate]  
"MuiVerb"="@shell32.dll,-30525"  
"Icon"="imageres.dll,-102"
"Position"="Bottom"  
; 定義點擊菜單項時要執行的命令  
[HKEY_CLASSES_ROOT\SystemFileAssociations\.js\Shell\JavaScript Obfuscate\command]  
@="\"C:\\Program Files\\nodejs12\\node.exe\" \"C:\\Users\\WangLiwen\\Desktop\\JShaman_JavaScript_Obfuscator\\obfuscate.js\" \"%1\""

說明：“JavaScript Obfuscate”是菜單中的顯示的文字內容，可修改。

保存之后，雙擊將內容導入注冊表：

僅此兩步，已經大功告成，可以使用了。

JS文件混淆加密測試：

測試，加密一個JS文件，如上圖所示。

使用感受：

如此進行“JS文件混淆加密”，非常方便、又快又好！