[{"_1":2,"_726":-5,"_727":-5},"loaderData",{"_3":4,"_53":54},"root",{"_5":6},"clerkState",{"_7":8},"__internal_clerk_state",{"_9":10,"_25":26,"_27":28,"_29":28,"_30":24,"_31":28,"_32":28,"_33":28,"_34":28,"_35":28,"_36":28,"_37":28,"_38":28,"_39":40,"_49":28,"_50":28,"_51":24,"_52":24},"__clerk_ssr_state",{"_11":12,"_13":-5,"_14":-5,"_15":-5,"_16":-5,"_17":-5,"_18":-5,"_19":-5,"_20":-5,"_21":-5,"_22":-5,"_23":24},"tokenType","session_token","sessionClaims","sessionId","sessionStatus","userId","actor","orgId","orgRole","orgSlug","orgPermissions","factorVerificationAge","isAuthenticated",false,"__publishableKey","pk_live_Y2xlcmsucXVlc3Rpb25zLnZpc3VhbGl6ZWl0LmFwcCQ","__proxyUrl","","__domain","__isSatellite","__signInUrl","__signUpUrl","__afterSignInUrl","__afterSignUpUrl","__signInForceRedirectUrl","__signUpForceRedirectUrl","__signInFallbackRedirectUrl","__signUpFallbackRedirectUrl","__clerk_debug",{"_41":24,"_23":24,"_42":28,"_43":44,"_45":28,"_46":26,"_47":24,"_48":28},"isSignedIn","proxyUrl","reason","session-token-and-uat-missing","message","publishableKey","isSatellite","domain","__clerkJSUrl","__clerkJSVersion","__telemetryDisabled","__telemetryDebug","routes/_index",{"_55":56,"_722":723},"questions",[57,196,221,256,285,324,348,377,402,426,455,479,504,529,554,578,602,626,650,674,698],{"_58":59,"_60":61,"_62":63,"_64":65,"_66":67,"_68":69,"_70":71,"_72":73,"_74":75,"_76":77,"_78":79,"_111":112,"_131":132,"_133":24,"_134":-5,"_135":136,"_137":138,"_159":152,"_153":160,"_155":161,"_158":-5,"_162":163,"_106":-5,"_164":-5,"_165":166,"_170":171,"_176":177,"_178":179,"_190":191,"_192":-5,"_193":-5,"_194":195},"url","https://api.github.com/repos/pro-collection/interview-question/issues/270","repository_url","https://api.github.com/repos/pro-collection/interview-question","labels_url","https://api.github.com/repos/pro-collection/interview-question/issues/270/labels{/name}","comments_url","https://api.github.com/repos/pro-collection/interview-question/issues/270/comments","events_url","https://api.github.com/repos/pro-collection/interview-question/issues/270/events","html_url","https://github.com/pro-collection/interview-question/issues/270","id",1659768390,"node_id","I_kwDOJGDC6c5i7g5G","number",270,"title","小程序的大概原理?","user",{"_80":81,"_70":82,"_72":83,"_84":85,"_86":28,"_58":87,"_68":88,"_89":90,"_91":92,"_93":94,"_95":96,"_97":98,"_99":100,"_101":102,"_66":103,"_104":105,"_106":107,"_108":109,"_110":24},"login","yanlele",22188674,"MDQ6VXNlcjIyMTg4Njc0","avatar_url","https://avatars.githubusercontent.com/u/22188674?v=4","gravatar_id","https://api.github.com/users/yanlele","https://github.com/yanlele","followers_url","https://api.github.com/users/yanlele/followers","following_url","https://api.github.com/users/yanlele/following{/other_user}","gists_url","https://api.github.com/users/yanlele/gists{/gist_id}","starred_url","https://api.github.com/users/yanlele/starred{/owner}{/repo}","subscriptions_url","https://api.github.com/users/yanlele/subscriptions","organizations_url","https://api.github.com/users/yanlele/orgs","repos_url","https://api.github.com/users/yanlele/repos","https://api.github.com/users/yanlele/events{/privacy}","received_events_url","https://api.github.com/users/yanlele/received_events","type","User","user_view_type","public","site_admin","labels",[113,124],{"_70":114,"_72":115,"_58":116,"_117":118,"_119":120,"_121":24,"_122":123},5284642729,"LA_kwDOJGDC6c8AAAABOv0_qQ","https://api.github.com/repos/pro-collection/interview-question/labels/%E5%B7%A5%E7%A8%8B%E5%8C%96","name","工程化","color","1d76db","default","description","web 项目工程化",{"_70":125,"_72":126,"_58":127,"_117":128,"_119":129,"_121":24,"_122":130},5312726360,"LA_kwDOJGDC6c8AAAABPKnFWA","https://api.github.com/repos/pro-collection/interview-question/labels/%E8%85%BE%E8%AE%AF","腾讯","ededed","公司标签","state","open","locked","assignee","assignees",[],"milestone",{"_58":139,"_68":140,"_62":141,"_70":142,"_72":143,"_74":144,"_76":145,"_122":146,"_147":148,"_149":150,"_151":152,"_131":132,"_153":154,"_155":156,"_157":-5,"_158":-5},"https://api.github.com/repos/pro-collection/interview-question/milestones/4","https://github.com/pro-collection/interview-question/milestone/4","https://api.github.com/repos/pro-collection/interview-question/milestones/4/labels",9124550,"MI_kwDOJGDC6c4AizrG",4,"资深","资深级别面试问题","creator",{"_80":81,"_70":82,"_72":83,"_84":85,"_86":28,"_58":87,"_68":88,"_89":90,"_91":92,"_93":94,"_95":96,"_97":98,"_99":100,"_101":102,"_66":103,"_104":105,"_106":107,"_108":109,"_110":24},"open_issues",50,"closed_issues",0,"created_at","2023-03-06T15:00:45Z","updated_at","2025-07-06T12:02:25Z","due_on","closed_at","comments","2023-04-09T06:30:09Z","2023-04-09T06:30:10Z","author_association","MEMBER","active_lock_reason","sub_issues_summary",{"_167":152,"_168":152,"_169":152},"total","completed","percent_completed","issue_dependencies_summary",{"_172":152,"_173":152,"_174":152,"_175":152},"blocked_by","total_blocked_by","blocking","total_blocking","body","具体流程可以看下面这个图：\n![](https://foruda.gitee.com/images/1681021603016376642/cc6178f0_7819612.png)\n\n要了解小程序架构原理，要从以下几个方面入手探索\n- 宿主环境\n- 执行环境\n- 小程序整体架构\n- 运行机制\n- 更新机制\n- 数据通信机制\n- 登录机制\n- 性能方向问题\n- JSCore\n\n具体内容可以参考文档:\n- https://juejin.cn/post/6976805521407868958\n","reactions",{"_58":180,"_181":152,"_182":152,"_183":152,"_184":152,"_185":152,"_186":152,"_187":152,"_188":152,"_189":152},"https://api.github.com/repos/pro-collection/interview-question/issues/270/reactions","total_count","+1","-1","laugh","hooray","confused","heart","rocket","eyes","timeline_url","https://api.github.com/repos/pro-collection/interview-question/issues/270/timeline","performed_via_github_app","state_reason","score",1,{"_58":197,"_60":61,"_62":198,"_64":199,"_66":200,"_68":201,"_70":202,"_72":203,"_74":204,"_76":205,"_78":206,"_111":207,"_131":132,"_133":24,"_134":-5,"_135":209,"_137":210,"_159":212,"_153":213,"_155":214,"_158":-5,"_162":163,"_106":-5,"_164":-5,"_165":215,"_170":216,"_176":217,"_178":218,"_190":220,"_192":-5,"_193":-5,"_194":195},"https://api.github.com/repos/pro-collection/interview-question/issues/267","https://api.github.com/repos/pro-collection/interview-question/issues/267/labels{/name}","https://api.github.com/repos/pro-collection/interview-question/issues/267/comments","https://api.github.com/repos/pro-collection/interview-question/issues/267/events","https://github.com/pro-collection/interview-question/issues/267",1659746104,"I_kwDOJGDC6c5i7bc4",267,"[Webpack] webpack热更新原理是什么？",{"_80":81,"_70":82,"_72":83,"_84":85,"_86":28,"_58":87,"_68":88,"_89":90,"_91":92,"_93":94,"_95":96,"_97":98,"_99":100,"_101":102,"_66":103,"_104":105,"_106":107,"_108":109,"_110":24},[208],{"_70":114,"_72":115,"_58":116,"_117":118,"_119":120,"_121":24,"_122":123},[],{"_58":139,"_68":140,"_62":141,"_70":142,"_72":143,"_74":144,"_76":145,"_122":146,"_147":211,"_149":150,"_151":152,"_131":132,"_153":154,"_155":156,"_157":-5,"_158":-5},{"_80":81,"_70":82,"_72":83,"_84":85,"_86":28,"_58":87,"_68":88,"_89":90,"_91":92,"_93":94,"_95":96,"_97":98,"_99":100,"_101":102,"_66":103,"_104":105,"_106":107,"_108":109,"_110":24},2,"2023-04-09T04:38:38Z","2024-05-26T06:11:01Z",{"_167":152,"_168":152,"_169":152},{"_172":152,"_173":152,"_174":152,"_175":152},"> `Hot Module Replacement`，简称`HMR`，无需完全刷新整个页面的同时，更新模块。`HMR`的好处，在日常开发工作中体会颇深：**节省宝贵的开发时间、提升开发体验**。\r\n\r\n刷新我们一般分为两种：\r\n\r\n* 一种是页面刷新，不保留页面状态，就是简单粗暴，直接`window.location.reload()`。\r\n* 另一种是基于`WDS (Webpack-dev-server)`的模块热替换，只需要局部刷新页面上发生变化的模块，同时可以保留当前的页面状态，比如复选框的选中状态、输入框的输入等。\r\n\r\n`HMR`作为一个`Webpack`内置的功能，可以通过`HotModuleReplacementPlugin`或`--hot`开启。那么，`HMR`到底是怎么实现热更新的呢？下面让我们来了解一下吧！\r\n\r\n\r\n### 1. webpack-dev-server启动本地服务\r\n\r\n我们根据`webpack-dev-server`的`package.json`中的`bin`命令，可以找到命令的入口文件`bin/webpack-dev-server.js`。\r\n\r\n```pgsql\r\n// node_modules/webpack-dev-server/bin/webpack-dev-server.js\r\n\r\n// 生成webpack编译主引擎 compiler\r\nlet compiler = webpack(config);\r\n\r\n// 启动本地服务\r\nlet server = new Server(compiler, options, log);\r\nserver.listen(options.port, options.host, (err) => {\r\n if (err) {throw err};\r\n});\r\n```\r\n\r\n本地服务代码：\r\n\r\n```javascript\r\n// node_modules/webpack-dev-server/lib/Server.js\r\nclass Server {\r\n constructor() {\r\n this.setupApp();\r\n this.createServer();\r\n }\r\n\r\n setupApp() {\r\n // 依赖了express\r\n \tthis.app = new express();\r\n }\r\n\r\n createServer() {\r\n this.listeningApp = http.createServer(this.app);\r\n }\r\n listen(port, hostname, fn) {\r\n return this.listeningApp.listen(port, hostname, (err) => {\r\n // 启动express服务后，启动websocket服务\r\n this.createSocketServer();\r\n }\r\n }\r\n}\r\n```\r\n\r\n这一小节代码主要做了三件事：\r\n\r\n* 启动`webpack`，生成`compiler`实例。`compiler`上有很多方法，比如可以启动 `webpack` 所有**编译**工作，以及**监听**本地文件的变化。\r\n* 使用`express`框架启动本地`server`，让浏览器可以请求本地的**静态资源**。\r\n* 本地`server`启动之后，再去启动`websocket`服务，如果不了解`websocket`，建议简单了解一下[websocket速成](https://link.juejin.cn?target=https%3A%2F%2Fwww.ruanyifeng.com%2Fblog%2F2017%2F05%2Fwebsocket.html \"https://www.ruanyifeng.com/blog/2017/05/websocket.html\")。通过`websocket`，可以建立本地服务和浏览器的双向通信。这样就可以实现当本地文件发生变化，立马告知浏览器可以热更新代码啦！\r\n\r\n上述代码主要干了三件事，但是源码在启动服务前又做了很多事，接下来便看看`webpack-dev-server/lib/Server.js`还做了哪些事？\r\n\r\n### 2. 修改webpack.config.js的entry配置\r\n\r\n启动本地服务前，调用了`updateCompiler(this.compiler)`方法。这个方法中有 2 段关键性代码。一个是获取`websocket`客户端代码路径，另一个是根据配置获取`webpack`热更新代码路径。\r\n\r\n```javascript\r\n// 获取websocket客户端代码\r\nconst clientEntry = `${require.resolve(\r\n '../../client/'\r\n)}?${domain}${sockHost}${sockPath}${sockPort}`;\r\n\r\n// 根据配置获取热更新代码\r\nlet hotEntry;\r\nif (options.hotOnly) {\r\n hotEntry = require.resolve('webpack/hot/only-dev-server');\r\n} else if (options.hot) {\r\n hotEntry = require.resolve('webpack/hot/dev-server');\r\n}\r\n```\r\n\r\n修改后的`webpack`入口配置如下：\r\n\r\n```awk\r\n// 修改后的entry入口\r\n{ entry:\r\n { index:\r\n [\r\n // 上面获取的clientEntry\r\n 'xxx/node_modules/webpack-dev-server/client/index.js?http://localhost:8080',\r\n // 上面获取的hotEntry\r\n 'xxx/node_modules/webpack/hot/dev-server.js',\r\n // 开发配置的入口\r\n './src/index.js'\r\n \t],\r\n },\r\n} \r\n```\r\n\r\n为什么要新增了 2 个文件？在入口默默增加了 2 个文件，那就意味会一同打包到`bundle`文件中去，也就是线上运行时。\r\n\r\n**（1）webpack-dev-server/client/index.js**\r\n\r\n首先这个文件用于`websocket`的，因为`websoket`是双向通信，如果不了解`websocket`，建议简单了解一下[websocket速成](https://link.juejin.cn?target=https%3A%2F%2Fwww.ruanyifeng.com%2Fblog%2F2017%2F05%2Fwebsocket.html \"https://www.ruanyifeng.com/blog/2017/05/websocket.html\")。我们在第 1 步 `webpack-dev-server`初始化的过程中，启动的是本地服务端的`websocket`。那客户端也就是我们的浏览器，浏览器还没有和服务端通信的代码呢？总不能让开发者去写吧hhhhhh。因此我们需要把`websocket`客户端通信代码偷偷塞到我们的代码中。客户端具体的代码后面会在合适的时机细讲哦。\r\n\r\n**（2）webpack/hot/dev-server.js**\r\n\r\n这个文件主要是用于检查更新逻辑的，这里大家知道就好，代码后面会在合适的时机（**第5步**）细讲。\r\n\r\n### 3. 监听webpack编译结束\r\n\r\n修改好入口配置后，又调用了`setupHooks`方法。这个方法是用来注册监听事件的，监听每次`webpack`编译完成。\r\n\r\n```javascript\r\n// node_modules/webpack-dev-server/lib/Server.js\r\n// 绑定监听事件\r\nsetupHooks() {\r\n const {done} = compiler.hooks;\r\n // 监听webpack的done钩子，tapable提供的监听方法\r\n done.tap('webpack-dev-server', (stats) => {\r\n this._sendStats(this.sockets, this.getStats(stats));\r\n this._stats = stats;\r\n });\r\n};\r\n```\r\n\r\n当监听到一次`webpack`编译结束，就会调用`_sendStats`方法通过`websocket`给浏览器发送通知，`ok`和`hash`事件，这样浏览器就可以拿到最新的`hash`值了，做检查更新逻辑。\r\n\r\n```reasonml\r\n// 通过websoket给客户端发消息\r\n_sendStats() {\r\n this.sockWrite(sockets, 'hash', stats.hash);\r\n this.sockWrite(sockets, 'ok');\r\n}\r\n```\r\n\r\n### 4. webpack监听文件变化\r\n\r\n每次修改代码，就会触发编译。说明我们还需要监听本地代码的变化，主要是通过`setupDevMiddleware`方法实现的。\r\n\r\n这个方法主要执行了`webpack-dev-middleware`库。很多人分不清`webpack-dev-middleware`和`webpack-dev-server`的区别。其实就是因为`webpack-dev-server`只负责启动服务和前置准备工作，所有文件相关的操作都抽离到`webpack-dev-middleware`库了，主要是本地文件的**编译**和**输出**以及**监听**，无非就是职责的划分更清晰了。\r\n\r\n那我们来看下`webpack-dev-middleware`源码里做了什么事:\r\n\r\n```awk\r\n// node_modules/webpack-dev-middleware/index.js\r\ncompiler.watch(options.watchOptions, (err) => {\r\n if (err) { /*错误处理*/ }\r\n});\r\n\r\n// 通过“memory-fs”库将打包后的文件写入内存\r\nsetFs(context, compiler); \r\n```\r\n\r\n（1）调用了`compiler.watch`方法，在第 1 步中也提到过，`compiler`的强大。这个方法主要就做了 2 件事：\r\n\r\n* 首先对本地文件代码进行编译打包，也就是`webpack`的一系列编译流程。\r\n* 其次编译结束后，开启对本地文件的监听，当文件发生变化，重新编译，编译完成之后继续监听。\r\n\r\n为什么代码的改动保存会自动编译，重新打包？这一系列的重新检测编译就归功于`compiler.watch`这个方法了。监听本地文件的变化主要是通过**文件的生成时间**是否有变化，这里就不细讲了。\r\n\r\n（2）执行`setFs`方法，这个方法主要目的就是将编译后的文件打包到内存。这就是为什么在开发的过程中，你会发现`dist`目录没有打包后的代码，因为都在内存中。原因就在于访问内存中的代码比访问文件系统中的文件更快，而且也减少了代码写入文件的开销，这一切都归功于`memory-fs`。\r\n\r\n### 5. 浏览器接收到热更新的通知\r\n\r\n我们已经可以监听到文件的变化了，当文件发生变化，就触发重新编译。同时还监听了每次编译结束的事件。当监听到一次`webpack`编译结束，`_sendStats`方法就通过`websoket`给浏览器发送通知，检查下是否需要热更新。下面重点讲的就是`_sendStats`方法中的`ok`和`hash`事件都做了什么。\r\n\r\n那浏览器是如何接收到`websocket`的消息呢？回忆下第 2 步骤增加的入口文件，也就是`websocket`客户端代码。\r\n\r\n```\r\n'xxx/node_modules/webpack-dev-server/client/index.js?http://localhost:8080'\r\n```\r\n\r\n这个文件的代码会被打包到`bundle.js`中，运行在浏览器中。来看下这个文件的核心代码吧。\r\n\r\n```js\r\n// webpack-dev-server/client/index.js\r\nvar socket = require('./socket');\r\nvar onSocketMessage = {\r\n hash: function hash(_hash) {\r\n // 更新currentHash值\r\n status.currentHash = _hash;\r\n },\r\n ok: function ok() {\r\n sendMessage('Ok');\r\n // 进行更新检查等操作\r\n reloadApp(options, status);\r\n },\r\n};\r\n// 连接服务地址socketUrl，?http://localhost:8080，本地服务地址\r\nsocket(socketUrl, onSocketMessage);\r\n\r\nfunction reloadApp() {\r\n\tif (hot) {\r\n log.info('[WDS] App hot update...');\r\n\r\n // hotEmitter其实就是EventEmitter的实例\r\n var hotEmitter = require('webpack/hot/emitter');\r\n hotEmitter.emit('webpackHotUpdate', currentHash);\r\n }\r\n}\r\n```\r\n\r\n`socket`方法建立了`websocket`和服务端的连接，并注册了 2 个监听事件。\r\n\r\n* `hash`事件，更新最新一次打包后的`hash`值。\r\n* `ok`事件，进行热更新检查。\r\n\r\n热更新检查事件是调用`reloadApp`方法。比较奇怪的是，这个方法又利用`node.js`的`EventEmitter`，发出`webpackHotUpdate`消息。这是为什么？为什么不直接进行检查更新呢？\r\n\r\n个人理解就是为了更好的维护代码，以及职责划分的更明确。`websocket`仅仅用于客户端（浏览器）和服务端进行通信。而真正做事情的活还是交回给了`webpack`。\r\n\r\n那`webpack`怎么做的呢？再来回忆下第 2 步。入口文件还有一个文件没有讲到，就是：\r\n\r\n```\r\n'xxx/node_modules/webpack/hot/dev-server.js'\r\n```\r\n\r\n这个文件的代码同样会被打包到`bundle.js`中，运行在浏览器中。这个文件做了什么就显而易见了吧！先瞄一眼代码：\r\n\r\n```javascript\r\n// node_modules/webpack/hot/dev-server.js\r\nvar check = function check() {\r\n module.hot.check(true)\r\n .then(function(updatedModules) {\r\n // 容错，直接刷新页面\r\n if (!updatedModules) {\r\n window.location.reload();\r\n return;\r\n }\r\n\r\n // 热更新结束，打印信息\r\n if (upToDate()) {\r\n log(\"info\", \"[HMR] App is up to date.\");\r\n }\r\n })\r\n .catch(function(err) {\r\n window.location.reload();\r\n });\r\n};\r\n\r\nvar hotEmitter = require(\"./emitter\");\r\nhotEmitter.on(\"webpackHotUpdate\", function(currentHash) {\r\n lastHash = currentHash;\r\n check();\r\n});\r\n```\r\n\r\n这里`webpack`监听到了`webpackHotUpdate`事件，并获取最新了最新的`hash`值，然后终于进行检查更新了。检查更新呢调用的是`module.hot.check`方法。那么问题又来了，`module.hot.check`又是哪里冒出来了的！答案是`HotModuleReplacementPlugin`搞得鬼。这里留个疑问，继续往下看。\r\n\r\n### 6. HotModuleReplacementPlugin\r\n\r\n前面好像一直是`webpack-dev-server`做的事，那`HotModuleReplacementPlugin`在热更新过程中又做了什么伟大的事业呢？\r\n\r\n首先你可以对比下，配置热更新和不配置时`bundle.js`的区别。内存中看不到？直接执行`webpack`命令就可以看到生成的`bundle.js`文件啦。不要用`webpack-dev-server`启动就好了。\r\n\r\n（1）没有配置的。\r\n\r\n![](https://p1-jj.byteimg.com/tos-cn-i-t2oaga2asx/gold-user-assets/2019/12/1/16ec0c9e8fd12349~tplv-t2oaga2asx-zoom-in-crop-mark:3024:0:0:0.awebp)\r\n（2）配置了`HotModuleReplacementPlugin`或`--hot`的。\r\n\r\n![](https://p1-jj.byteimg.com/tos-cn-i-t2oaga2asx/gold-user-assets/2019/12/1/16ec0c90092fa0ac~tplv-t2oaga2asx-zoom-in-crop-mark:3024:0:0:0.awebp)\r\n哦~ 我们发现`moudle`新增了一个属性为`hot`，再看`hotCreateModule`方法。这不就找到`module.hot.check`是哪里冒出来的。\r\n\r\n![](https://p1-jj.byteimg.com/tos-cn-i-t2oaga2asx/gold-user-assets/2019/12/1/16ec0dc36018973f~tplv-t2oaga2asx-zoom-in-crop-mark:3024:0:0:0.awebp)\r\n\r\n经过对比打包后的文件，`__webpack_require__`中的`moudle`以及代码行数的不同。我们都可以发现`HotModuleReplacementPlugin`原来也是默默的塞了很多代码到`bundle.js`中呀。这和第 2 步骤很是相似哦！为什么，因为检查更新是在浏览器中操作呀。这些代码必须在运行时的环境。\r\n\r\n你也可以直接看浏览器`Sources`下的代码，会发现`webpack`和`plugin`偷偷加的代码都在哦。在这里调试也很方便。\r\n\r\n![](https://p1-jj.byteimg.com/tos-cn-i-t2oaga2asx/gold-user-assets/2019/12/1/16ec0d4634af2b3c~tplv-t2oaga2asx-zoom-in-crop-mark:3024:0:0:0.awebp)\r\n`HotModuleReplacementPlugin`如何做到的？这里我就不讲了，因为这需要你对`tapable`以及`plugin`机制有一定了解，可以看下我写的文章[Webpack插件机制之Tapable-源码解析](https://juejin.cn/post/6844904004435050503)。当然你也可以选择跳过，只关心热更新机制即可，毕竟信息量太大。\r\n\r\n### 7. moudle.hot.check 开始热更新\r\n\r\n通过第 6 步，我们就可以知道`moudle.hot.check`方法是如何来的啦。那都做了什么？之后的源码都是`HotModuleReplacementPlugin`塞入到`bundle.js`中的哦，我就不写文件路径了。\r\n\r\n* 利用上一次保存的`hash`值，调用`hotDownloadManifest`发送`xxx/hash.hot-update.json`的`ajax`请求；\r\n* 请求结果获取热更新模块，以及下次热更新的`Hash` 标识，并进入热更新准备阶段。\r\n\r\n```abnf\r\nhotAvailableFilesMap = update.c; // 需要更新的文件\r\nhotUpdateNewHash = update.h; // 更新下次热更新hash值\r\nhotSetStatus(\"prepare\"); // 进入热更新准备状态\r\n```\r\n\r\n* 调用`hotDownloadUpdateChunk`发送`xxx/hash.hot-update.js` 请求，通过`JSONP`方式。\r\n\r\n```javascript\r\nfunction hotDownloadUpdateChunk(chunkId) {\r\n var script = document.createElement(\"script\");\r\n script.charset = \"utf-8\";\r\n script.src = __webpack_require__.p + \"\" + chunkId + \".\" + hotCurrentHash + \".hot-update.js\";\r\n if (null) script.crossOrigin = null;\r\n document.head.appendChild(script);\r\n }\r\n```\r\n\r\n这个函数体为什么要单独拿出来，因为这里要解释下为什么使用`JSONP`获取最新代码？主要是因为`JSONP`获取的代码可以直接执行。为什么要直接执行？我们来回忆下`/hash.hot-update.js`的代码格式是怎么样的。\r\n\r\n![](https://p1-jj.byteimg.com/tos-cn-i-t2oaga2asx/gold-user-assets/2019/12/1/16ec04316d6ac5e3~tplv-t2oaga2asx-zoom-in-crop-mark:3024:0:0:0.awebp)\r\n\r\n可以发现，新编译后的代码是在一个`webpackHotUpdate`函数体内部的。也就是要立即执行`webpackHotUpdate`这个方法。\r\n\r\n再看下`webpackHotUpdate`这个方法。\r\n\r\n```ada\r\nwindow[\"webpackHotUpdate\"] = function (chunkId, moreModules) {\r\n hotAddUpdateChunk(chunkId, moreModules);\r\n} ;\r\n```\r\n\r\n* `hotAddUpdateChunk`方法会把更新的模块`moreModules`赋值给全局全量`hotUpdate`。\r\n* `hotUpdateDownloaded`方法会调用`hotApply`进行代码的替换。\r\n\r\n```reasonml\r\nfunction hotAddUpdateChunk(chunkId, moreModules) {\r\n // 更新的模块moreModules赋值给全局全量hotUpdate\r\n for (var moduleId in moreModules) {\r\n if (Object.prototype.hasOwnProperty.call(moreModules, moduleId)) {\r\n\t hotUpdate[moduleId] = moreModules[moduleId];\r\n }\r\n }\r\n // 调用hotApply进行模块的替换\r\n hotUpdateDownloaded();\r\n}\r\n```\r\n\r\n### 8. hotApply 热更新模块替换\r\n\r\n热更新的核心逻辑就在`hotApply`方法了。 `hotApply`代码有将近 400 行，还是挑重点讲了，看哭😭\r\n\r\n#### ①删除过期的模块，就是需要替换的模块\r\n\r\n通过`hotUpdate`可以找到旧模块\r\n\r\n```cpp\r\nvar queue = outdatedModules.slice();\r\nwhile (queue.length > 0) {\r\n moduleId = queue.pop();\r\n // 从缓存中删除过期的模块\r\n module = installedModules[moduleId];\r\n // 删除过期的依赖\r\n delete outdatedDependencies[moduleId];\r\n\r\n // 存储了被删掉的模块id，便于更新代码\r\n outdatedSelfAcceptedModules.push({\r\n module: moduleId\r\n });\r\n}\r\n```\r\n\r\n#### ②将新的模块添加到 modules 中\r\n\r\n```inform7\r\nappliedUpdate[moduleId] = hotUpdate[moduleId];\r\nfor (moduleId in appliedUpdate) {\r\n if (Object.prototype.hasOwnProperty.call(appliedUpdate, moduleId)) {\r\n modules[moduleId] = appliedUpdate[moduleId];\r\n }\r\n}\r\n```\r\n\r\n#### ③通过\\_\\_webpack\\_require\\_\\_执行相关模块的代码\r\n\r\n```abnf\r\nfor (i = 0; i < outdatedSelfAcceptedModules.length; i++) {\r\n var item = outdatedSelfAcceptedModules[i];\r\n moduleId = item.module;\r\n try {\r\n // 执行最新的代码\r\n __webpack_require__(moduleId);\r\n } catch (err) {\r\n // ...容错处理\r\n }\r\n}\r\n\r\n```\r\n\r\n`hotApply`的确比较复杂，知道大概流程就好了，这一小节，要求你对webpack打包后的文件如何执行的有一些了解，大家可以自去看下。\r\n\r\n### 总结\r\n还是以阅读源码的形式画的图，①-④的小标记，是文件发生变化的一个流程。\r\n\r\n![](https://foruda.gitee.com/images/1681014860649655814/ea9d055f_7819612.png)\r\n\r\n### 参考文档\r\n- [轻松理解webpack热更新原理](https://juejin.cn/post/6844904008432222215)\r\n- [websocket基础知识了解](https://www.ruanyifeng.com/blog/2017/05/websocket.html)\r\n- [tapable: Webpack插件机制之Tapable-源码解析](https://juejin.cn/post/6844904004435050503)\r\n* [Webpack Hot Module Replacement 的原理解析](https://github.com/Jocs/jocs.github.io/issues/15)\r\n* [看完这篇，面试再也不怕被问 Webpack 热更新](https://juejin.cn/post/6844903953092591630)\r\n- [Webpack HMR 原理解析](https://zhuanlan.zhihu.com/p/30669007)\r\n\r\n",{"_58":219,"_181":152,"_182":152,"_183":152,"_184":152,"_185":152,"_186":152,"_187":152,"_188":152,"_189":152},"https://api.github.com/repos/pro-collection/interview-question/issues/267/reactions","https://api.github.com/repos/pro-collection/interview-question/issues/267/timeline",{"_58":222,"_60":61,"_62":223,"_64":224,"_66":225,"_68":226,"_70":227,"_72":228,"_74":229,"_76":230,"_78":231,"_111":232,"_131":132,"_133":24,"_134":-5,"_135":234,"_137":235,"_159":152,"_153":248,"_155":249,"_158":-5,"_162":163,"_106":-5,"_164":-5,"_165":250,"_170":251,"_176":252,"_178":253,"_190":255,"_192":-5,"_193":-5,"_194":195},"https://api.github.com/repos/pro-collection/interview-question/issues/253","https://api.github.com/repos/pro-collection/interview-question/issues/253/labels{/name}","https://api.github.com/repos/pro-collection/interview-question/issues/253/comments","https://api.github.com/repos/pro-collection/interview-question/issues/253/events","https://github.com/pro-collection/interview-question/issues/253",1655615141,"I_kwDOJGDC6c5irq6l",253,"如果用户说 web 应用感觉很反应慢或者卡顿，该如何排查？",{"_80":81,"_70":82,"_72":83,"_84":85,"_86":28,"_58":87,"_68":88,"_89":90,"_91":92,"_93":94,"_95":96,"_97":98,"_99":100,"_101":102,"_66":103,"_104":105,"_106":107,"_108":109,"_110":24},[233],{"_70":114,"_72":115,"_58":116,"_117":118,"_119":120,"_121":24,"_122":123},[],{"_58":236,"_68":237,"_62":238,"_70":239,"_72":240,"_74":241,"_76":242,"_122":243,"_147":244,"_149":245,"_151":152,"_131":132,"_153":246,"_155":247,"_157":-5,"_158":-5},"https://api.github.com/repos/pro-collection/interview-question/milestones/3","https://github.com/pro-collection/interview-question/milestone/3","https://api.github.com/repos/pro-collection/interview-question/milestones/3/labels",9124547,"MI_kwDOJGDC6c4AizrD",3,"高","高级别面试问题",{"_80":81,"_70":82,"_72":83,"_84":85,"_86":28,"_58":87,"_68":88,"_89":90,"_91":92,"_93":94,"_95":96,"_97":98,"_99":100,"_101":102,"_66":103,"_104":105,"_106":107,"_108":109,"_110":24},454,"2023-03-06T15:00:27Z","2025-09-07T06:21:17Z","2023-04-05T13:23:29Z","2023-09-09T06:18:59Z",{"_167":152,"_168":152,"_169":152},{"_172":152,"_173":152,"_174":152,"_175":152},"### 如果用户觉得 web 应用反应卡顿，主要从哪几个方面来排查？\r\n\r\n- 加载慢\r\n - 资源下载慢\r\n - 首屏并发请求资源过多\r\n - 首屏接口慢\r\n - 首屏对应的 JS 执行慢\r\n - 首屏渲染慢\r\n - 首屏加载静态资源过大\r\n - .......\r\n- 执行过程慢\r\n - 接口慢\r\n - long tasks 太多, 阻塞 JS 执行\r\n - 内存泄漏\r\n - 重绘重排过多\r\n - 关键节点没有加节流防抖\r\n - .......\r\n\r\n\r\n### 主要排查手段有哪些\r\n- **通过建立性能监控指标**: 通过真实用户数据反馈，来判断用户是否卡顿，包含网络监控、运行时性能监控\r\n\r\n- **Chrome devtools: NetWork** 主要排查网络问题\r\n $\"image\"$ \r\n\r\n- **Chrome devtools: Performance** 主要细查性能运行时性能，包含了 long tasks、render 次数、重排重绘、执行时间线、阻塞场景\r\n $\"image\"$ \r\n\r\n- **Chrome devtools: Performance monitor** 主要监控用户运行时性能，看看是否有内存泄露\r\n $\"image\"$ \r\n\r\n- **React Developer Tools**: 可以用于追踪 react 应用性能、渲染次数、重排重绘\r\n![image](https://user-images.githubusercontent.com/22188674/229801498-3cc4fc25-64a5-4b9e-ace8-5ed7b96e4ac2.png)\r\n \r\n- **Lighthouse**: 全面分析网页性能的一个工具、支持浏览器插件 \r\n![image](https://user-images.githubusercontent.com/22188674/229803209-505d01da-d780-4a3e-abe7-e56cd942a64b.png)\r\n\r\n- **webpack-bundle-analyzer**: 进行产物依赖分析、包大小分析\r\n\r\n- **抓包**: 通过抓包的方式，看看线上请求分析、请求模拟、网络劫持之后仅仅看 JS 执行时间\r\n\r\n- **E2E测试**: 通过 E2E 进行性能预检，每次上线前进行一系列系统操作，看看时间耗时和线上耗时波动\r\n\r\n\r\n### 主要解决办法和思路\r\n\r\n**首屏加载慢的方向** \r\n- 资源加载方向\r\n - 使用 `tree shaking` 减少包体积\r\n - 代码压缩和混淆\r\n - 对于高版本浏览器，直接使用 ES6 语法，低版本浏览器再使用 ES5（es6 语法代码量会比编译成 es5 代码量小很多，且执行速度也快）\r\n - 使用 `split chunks` 进行大包拆分、小包复用\r\n - 使用 `gzip` \r\n - 使用图片压缩\r\n - 使用雪碧图\r\n - 图标使用 `iconfont` 加载\r\n - 懒加载，仅加载首屏必要资源\r\n - 使用 `tailwindcss` 等技术，复用 css \r\n - 使用 `微前端` 技术，首屏仅加载当前子应用页面，可以做到只加载整站很少的一部分代码\r\n - 首屏非必要依赖尽量延后到 FMP 或者 TTI 之后再加载\r\n - 组件微前端化\r\n \r\n- 渲染方向\r\n - 尽量减少重排重绘\r\n - 减少重复渲染（useMemo、useCallback、memo 等）\r\n - 减少 setState 次数（多次 setState 可以合并为一次）\r\n - 尽量减少 dom 节点深度\r\n \r\n- 网络方向\r\n - 使用流式服务端渲染，可以查看文档：https://juejin.cn/post/6953819275941380109\r\n - 使用服务端渲染，减少首屏请求\r\n - 使用 SSG 静态站点生成\r\n - 首屏必要数据，不作客户端请求，用后端模板注入\r\n - 使用 BFF 进行请求聚合\r\n - 使用 CDN 进行网络请求分发\r\n - DNS Prefetch \r\n - 资源预加载（在闲暇时间加载后续页面所需要的资源和接口，例如：link rel preload）\r\n - 启用 HTTP2 多路复用\r\n - 在业务逻辑上，首屏必要接口提前（例如在 html 加载的那一瞬间，利用一个非常小的 js 文件将首屏需要的请求发送出去, 然后缓存下来，到业务使用的时候直接就使用即可）\r\n - 使用缓存技术缓存资源与请求：强缓存、协商缓存、离线缓存、Service Worker 缓存、后端业务缓存\r\n \r\n**运行时卡顿方向**\r\n- 查看是否存在有有 `long tasks`，有计划的拆解 `long tasks`\r\n- 解决项目中复杂度问题： https://www.jianshu.com/p/ffbb25380904\r\n- 排查项目是否有内存泄露\r\n- 排查特定业务流程是否有慢接口\r\n- 高复杂计算逻辑放在 service worker 处理\r\n\r\n\r\n\r\n### 参考文档\r\n- https://juejin.cn/post/7096144248713510943\r\n- https://juejin.cn/post/6882936217609732110\r\n- https://juejin.cn/post/7119074496610304031\r\n- https://juejin.cn/post/7159807927908302884\r\n",{"_58":254,"_181":152,"_182":152,"_183":152,"_184":152,"_185":152,"_186":152,"_187":152,"_188":152,"_189":152},"https://api.github.com/repos/pro-collection/interview-question/issues/253/reactions","https://api.github.com/repos/pro-collection/interview-question/issues/253/timeline",{"_58":257,"_60":61,"_62":258,"_64":259,"_66":260,"_68":261,"_70":262,"_72":263,"_74":264,"_76":265,"_78":266,"_111":267,"_131":132,"_133":24,"_134":-5,"_135":274,"_137":275,"_159":195,"_153":277,"_155":278,"_158":-5,"_162":163,"_106":-5,"_164":-5,"_165":279,"_170":280,"_176":281,"_178":282,"_190":284,"_192":-5,"_193":-5,"_194":195},"https://api.github.com/repos/pro-collection/interview-question/issues/249","https://api.github.com/repos/pro-collection/interview-question/issues/249/labels{/name}","https://api.github.com/repos/pro-collection/interview-question/issues/249/comments","https://api.github.com/repos/pro-collection/interview-question/issues/249/events","https://github.com/pro-collection/interview-question/issues/249",1651174324,"I_kwDOJGDC6c5iauu0",249,"[webpack] 如果解决重复引用 node_modules 里面的不同版本的包(包重复问题)",{"_80":81,"_70":82,"_72":83,"_84":85,"_86":28,"_58":87,"_68":88,"_89":90,"_91":92,"_93":94,"_95":96,"_97":98,"_99":100,"_101":102,"_66":103,"_104":105,"_106":107,"_108":109,"_110":24},[268,269],{"_70":114,"_72":115,"_58":116,"_117":118,"_119":120,"_121":24,"_122":123},{"_70":270,"_72":271,"_58":272,"_117":273,"_119":129,"_121":24,"_122":130},5342931240,"LA_kwDOJGDC6c8AAAABPnapKA","https://api.github.com/repos/pro-collection/interview-question/labels/%E7%BE%8E%E5%9B%A2","美团",[],{"_58":236,"_68":237,"_62":238,"_70":239,"_72":240,"_74":241,"_76":242,"_122":243,"_147":276,"_149":245,"_151":152,"_131":132,"_153":246,"_155":247,"_157":-5,"_158":-5},{"_80":81,"_70":82,"_72":83,"_84":85,"_86":28,"_58":87,"_68":88,"_89":90,"_91":92,"_93":94,"_95":96,"_97":98,"_99":100,"_101":102,"_66":103,"_104":105,"_106":107,"_108":109,"_110":24},"2023-04-03T01:18:02Z","2023-04-26T15:20:48Z",{"_167":152,"_168":152,"_169":152},{"_172":152,"_173":152,"_174":152,"_175":152},"解决重复引用 `node_modules` 中不同版本的包的问题，可以通过以下几种方式：\n\n**1.使用 npm 或者 yarn 的工具进行依赖的版本控制，尽量避免引用不同版本的同一个依赖库**。在 package.json 文件中使用 \"^\"、\"~\"、\">=\" 等方式指定依赖版本，可以有效减少不同版本的包冲突问题。\n\n**2.使用 webpack 的 resolve.alias 配置选项**，将需要共享的模块指定到一个目录下，然后在其它模块中使用别名引用该模块。例如，将需要共享的模块指定到 src/shared 目录下，然后在其它模块中使用别名 @shared 引用该模块，这样就可以保证在不同模块中引用相同的依赖库。\n假设我们在项目中同时依赖了两个库：`lodash` 和 `lodash-es`，并且它们分别被安装在了不同的目录下，如下所示：\n\n```\nCopy codenode_modules/\n├── lodash/\n└── lodash-es/\n```\n\n我们需要在项目中同时引用这两个库，但是如果我们在代码中分别使用 `import _ from 'lodash'` 和 `import _ from 'lodash-es'`，那么 webpack 会将它们打包成两个独立的模块，导致代码体积变大。\n\n为了解决这个问题，我们可以通过 `resolve.alias` 配置项将它们指向同一个模块。具体做法是在 webpack 配置文件中添加以下内容：\n\n```js\nmodule.exports = {\n // ...\n resolve: {\n alias: {\n 'lodash-es': 'lodash'\n }\n }\n}\n```\n\n这样一来，当我们在代码中使用 `import _ from 'lodash-es'` 时，webpack 会自动将它解析成对 `lodash` 的引用，从而避免了重复打包的问题。\n\n**3.使用 webpack 的 ProvidePlugin 插件**，将需要共享的模块注入到全局作用域中，这样就可以在不同模块中共享相同的依赖库。例如，在 webpack 配置文件中添加以下代码：\n\n```javascript\nconst webpack = require('webpack');\n\nmodule.exports = {\n // ...\n plugins: [\n new webpack.ProvidePlugin({\n $: 'jquery',\n jQuery: 'jquery',\n 'window.jQuery': 'jquery',\n }),\n ],\n};\n```\n\n这样在不同模块中就可以使用 $、jQuery、window.jQuery 全局变量引用 jquery 依赖库，避免了重复引用不同版本的 jquery 包的问题。\n\n**4.使用 webpack 的 resolve.modules 配置选项**，将 node\\_modules 目录移动到项目根目录之外，然后在 resolve.modules 中添加该目录的绝对路径，这样就可以解决不同模块中引用相同依赖库不同版本的问题。例如，在 webpack 配置文件中添加以下代码：\n\n```javascript\nconst path = require('path');\n\nmodule.exports = {\n // ...\n resolve: {\n modules: [\n path.resolve(__dirname, 'src'),\n 'node_modules',\n ],\n },\n};\n```\n\n这样 webpack 在查找依赖库的时候，会先在项目根目录下的 src 目录中查找，如果没有找到再去 node\\_modules 目录中查找，避免了不同模块中引用相同依赖库不同版本的问题。\n",{"_58":283,"_181":152,"_182":152,"_183":152,"_184":152,"_185":152,"_186":152,"_187":152,"_188":152,"_189":152},"https://api.github.com/repos/pro-collection/interview-question/issues/249/reactions","https://api.github.com/repos/pro-collection/interview-question/issues/249/timeline",{"_58":286,"_60":61,"_62":287,"_64":288,"_66":289,"_68":290,"_70":291,"_72":292,"_74":293,"_76":294,"_78":295,"_111":296,"_131":132,"_133":24,"_134":-5,"_135":303,"_137":304,"_159":152,"_153":316,"_155":317,"_158":-5,"_162":163,"_106":-5,"_164":-5,"_165":318,"_170":319,"_176":320,"_178":321,"_190":323,"_192":-5,"_193":-5,"_194":195},"https://api.github.com/repos/pro-collection/interview-question/issues/247","https://api.github.com/repos/pro-collection/interview-question/issues/247/labels{/name}","https://api.github.com/repos/pro-collection/interview-question/issues/247/comments","https://api.github.com/repos/pro-collection/interview-question/issues/247/events","https://github.com/pro-collection/interview-question/issues/247",1651170765,"I_kwDOJGDC6c5iat3N",247,"[webpack] 是如何实现 treeShaking 的",{"_80":81,"_70":82,"_72":83,"_84":85,"_86":28,"_58":87,"_68":88,"_89":90,"_91":92,"_93":94,"_95":96,"_97":98,"_99":100,"_101":102,"_66":103,"_104":105,"_106":107,"_108":109,"_110":24},[297,298],{"_70":114,"_72":115,"_58":116,"_117":118,"_119":120,"_121":24,"_122":123},{"_70":299,"_72":300,"_58":301,"_117":302,"_119":129,"_121":24,"_122":130},5312231007,"LA_kwDOJGDC6c8AAAABPKI2Xw","https://api.github.com/repos/pro-collection/interview-question/labels/%E9%98%BF%E9%87%8C%E5%B7%B4%E5%B7%B4","阿里巴巴",[],{"_58":305,"_68":306,"_62":307,"_70":308,"_72":309,"_74":212,"_76":310,"_122":311,"_147":312,"_149":313,"_151":152,"_131":132,"_153":314,"_155":315,"_157":-5,"_158":-5},"https://api.github.com/repos/pro-collection/interview-question/milestones/2","https://github.com/pro-collection/interview-question/milestone/2","https://api.github.com/repos/pro-collection/interview-question/milestones/2/labels",9124545,"MI_kwDOJGDC6c4AizrB","中","中级程序面试问题",{"_80":81,"_70":82,"_72":83,"_84":85,"_86":28,"_58":87,"_68":88,"_89":90,"_91":92,"_93":94,"_95":96,"_97":98,"_99":100,"_101":102,"_66":103,"_104":105,"_106":107,"_108":109,"_110":24},510,"2023-03-06T15:00:15Z","2025-09-07T06:08:31Z","2023-04-03T01:10:58Z","2023-04-03T01:10:59Z",{"_167":152,"_168":152,"_169":152},{"_172":152,"_173":152,"_174":152,"_175":152},"webpack实现tree shaking的原理是基于ES6模块化语法的静态特性。\n\n在编译阶段，Webpack会根据模块的依赖关系，通过AST（抽象语法树）进行静态分析，识别出那些代码块（函数、变量、对象等）被引用并且使用了。然后将这些代码块打包输出到最终的打包文件中。在这个过程中，Webpack会自动将未被引用的代码块进行剔除，这个过程就是tree shaking。\n\n具体来说，当Webpack在打包时遇到一个ES6模块导入语句（import），它会自动去加载这个模块并分析其导出对象。然后它会分析项目中哪些导出对象被引用了。如果一个导出对象没有被引用，那么Webpack会直接把它从最终的代码中剔除掉。\n\n需要注意的是，tree shaking只对ES6模块生效，对于CommonJS等其他模块化规范，由于其动态加载特性，无法在静态分析阶段确定哪些代码块被引用，因此无法进行tree shaking。\n\n另外，为了使Webpack能够正确识别和剔除未引用的代码块，开发者也需要做出一定的努力，例如将代码编写为纯函数的形式，避免使用全局变量等副作用等。\n\n具体哪些会导致 tree shaking 失效，可以看这个文章：https://github.com/pro-collection/interview-question/issues/235\n",{"_58":322,"_181":152,"_182":152,"_183":152,"_184":152,"_185":152,"_186":152,"_187":152,"_188":152,"_189":152},"https://api.github.com/repos/pro-collection/interview-question/issues/247/reactions","https://api.github.com/repos/pro-collection/interview-question/issues/247/timeline",{"_58":325,"_60":61,"_62":326,"_64":327,"_66":328,"_68":329,"_70":330,"_72":331,"_74":332,"_76":333,"_78":334,"_111":335,"_131":132,"_133":24,"_134":-5,"_135":338,"_137":339,"_159":152,"_153":341,"_155":341,"_158":-5,"_162":163,"_106":-5,"_164":-5,"_165":342,"_170":343,"_176":344,"_178":345,"_190":347,"_192":-5,"_193":-5,"_194":195},"https://api.github.com/repos/pro-collection/interview-question/issues/246","https://api.github.com/repos/pro-collection/interview-question/issues/246/labels{/name}","https://api.github.com/repos/pro-collection/interview-question/issues/246/comments","https://api.github.com/repos/pro-collection/interview-question/issues/246/events","https://github.com/pro-collection/interview-question/issues/246",1651163110,"I_kwDOJGDC6c5iar_m",246,"[webpack] loader 和 plugin 有啥区别",{"_80":81,"_70":82,"_72":83,"_84":85,"_86":28,"_58":87,"_68":88,"_89":90,"_91":92,"_93":94,"_95":96,"_97":98,"_99":100,"_101":102,"_66":103,"_104":105,"_106":107,"_108":109,"_110":24},[336,337],{"_70":114,"_72":115,"_58":116,"_117":118,"_119":120,"_121":24,"_122":123},{"_70":299,"_72":300,"_58":301,"_117":302,"_119":129,"_121":24,"_122":130},[],{"_58":305,"_68":306,"_62":307,"_70":308,"_72":309,"_74":212,"_76":310,"_122":311,"_147":340,"_149":313,"_151":152,"_131":132,"_153":314,"_155":315,"_157":-5,"_158":-5},{"_80":81,"_70":82,"_72":83,"_84":85,"_86":28,"_58":87,"_68":88,"_89":90,"_91":92,"_93":94,"_95":96,"_97":98,"_99":100,"_101":102,"_66":103,"_104":105,"_106":107,"_108":109,"_110":24},"2023-04-03T00:55:06Z",{"_167":152,"_168":152,"_169":152},{"_172":152,"_173":152,"_174":152,"_175":152},"在Webpack中，Loader和Plugin是两个不同的概念，它们的作用和使用方式也有所不同。\n\nLoader用于对源代码文件进行转换和处理，而Plugin用于对Webpack的编译过程进行扩展和增强。\n\n* **Loader**\n\nLoader是Webpack中的一个核心概念，它用于处理源代码文件，将它们转换成Webpack可处理的模块。Webpack在处理代码模块的过程中，会根据模块的类型来选择相应的Loader进行处理，例如，处理CSS文件需要使用css-loader，处理图片需要使用file-loader等。使用Loader可以实现代码转换、文件处理、代码压缩等功能。\n\nLoader的使用方式是在Webpack的配置文件中定义module.rules属性，它是一个数组，每个元素是一个对象，用于描述如何处理特定类型的文件。一个Loader对象通常包括以下几个属性：\n\n* test：用于匹配需要处理的文件类型，通常是一个正则表达式。\n* use：指定需要使用的Loader，可以是一个字符串或一个数组，数组中的每个元素都是一个Loader。\n* exclude/include：指定需要排除/包含的文件夹。\n\n例如，处理CSS文件需要使用css-loader和style-loader，可以在Webpack配置文件中添加如下配置：\n\n```javascript\nmodule: {\n rules: [\n {\n test: /\\.css$/,\n use: [\"style-loader\", \"css-loader\"]\n }\n ]\n}\n```\n\n* **Plugin**\n\nPlugin是Webpack中的另一个核心概念，它用于扩展Webpack的功能。Plugin可以用于执行任意类型的任务，例如，生成HTML文件、压缩代码、提取公共代码等。使用Plugin可以实现Webpack无法处理的复杂任务。\n\nPlugin的使用方式是在Webpack的配置文件中定义plugins属性，它是一个数组，每个元素是一个Plugin实例。Plugin通常包括以下几个方法：\n\n* apply：用于安装插件，接收一个compiler对象作为参数。\n* 一些Webpack钩子函数的实现。\n\n例如，生成HTML文件需要使用HtmlWebpackPlugin，可以在Webpack配置文件中添加如下配置：\n\n```javascript\nconst HtmlWebpackPlugin = require('html-webpack-plugin');\nmodule.exports = {\n // ...\n plugins: [\n new HtmlWebpackPlugin({\n title: 'My App',\n template: './src/index.html'\n })\n ]\n};\n```\n\n\n**表格对比他们之间的差异和适用范围**\n\n|区别|Loader|Plugin|\n|---|---|---|\n|输入/输出|输入文件，输出处理后的文件|可以在Webpack构建过程中处理输出结果或做额外处理|\n|使用方式|在模块加载时直接调用|在Webpack配置中进行配置|\n|功能|用于处理某些类型的文件|可以处理打包过程的各个环节|\n|实现方式|导出一个函数|导出一个类|\n|配置方式|在Webpack配置中使用|在Webpack配置中使用|\n|作用|转换文件或模块|对整个构建过程进行自定义操作|\n|适用场景|处理各种类型的文件，如css、图片等|执行比较复杂的操作，如代码压缩、代码分割等|\n|使用方式|需要在Webpack中明确的指定|无法单独使用，必须在Webpack中明确的指定使用|\n|作用对象|针对每一个文件进行处理|针对整个构建过程进行处理|\n\n\n总体而言，Loader主要用于针对单个文件进行处理，可以根据不同文件类型来选择对应的Loader；Plugin则是针对整个构建过程进行自定义操作，比如代码压缩、分离CSS文件、创建HTML文件等。\n",{"_58":346,"_181":152,"_182":152,"_183":152,"_184":152,"_185":152,"_186":152,"_187":152,"_188":152,"_189":152},"https://api.github.com/repos/pro-collection/interview-question/issues/246/reactions","https://api.github.com/repos/pro-collection/interview-question/issues/246/timeline",{"_58":349,"_60":61,"_62":350,"_64":351,"_66":352,"_68":353,"_70":354,"_72":355,"_74":356,"_76":357,"_78":358,"_111":359,"_131":132,"_133":24,"_134":-5,"_135":366,"_137":367,"_159":152,"_153":369,"_155":370,"_158":-5,"_162":163,"_106":-5,"_164":-5,"_165":371,"_170":372,"_176":373,"_178":374,"_190":376,"_192":-5,"_193":-5,"_194":195},"https://api.github.com/repos/pro-collection/interview-question/issues/243","https://api.github.com/repos/pro-collection/interview-question/issues/243/labels{/name}","https://api.github.com/repos/pro-collection/interview-question/issues/243/comments","https://api.github.com/repos/pro-collection/interview-question/issues/243/events","https://github.com/pro-collection/interview-question/issues/243",1650984812,"I_kwDOJGDC6c5iaAds",243,"[webpack] webpack 是如何给 web 应用注入环境变量的，原理是啥",{"_80":81,"_70":82,"_72":83,"_84":85,"_86":28,"_58":87,"_68":88,"_89":90,"_91":92,"_93":94,"_95":96,"_97":98,"_99":100,"_101":102,"_66":103,"_104":105,"_106":107,"_108":109,"_110":24},[360,361],{"_70":114,"_72":115,"_58":116,"_117":118,"_119":120,"_121":24,"_122":123},{"_70":362,"_72":363,"_58":364,"_117":365,"_119":129,"_121":24,"_122":130},5312738037,"LA_kwDOJGDC6c8AAAABPKny9Q","https://api.github.com/repos/pro-collection/interview-question/labels/%E7%99%BE%E5%BA%A6","百度",[],{"_58":236,"_68":237,"_62":238,"_70":239,"_72":240,"_74":241,"_76":242,"_122":243,"_147":368,"_149":245,"_151":152,"_131":132,"_153":246,"_155":247,"_157":-5,"_158":-5},{"_80":81,"_70":82,"_72":83,"_84":85,"_86":28,"_58":87,"_68":88,"_89":90,"_91":92,"_93":94,"_95":96,"_97":98,"_99":100,"_101":102,"_66":103,"_104":105,"_106":107,"_108":109,"_110":24},"2023-04-02T15:11:38Z","2023-04-02T15:11:39Z",{"_167":152,"_168":152,"_169":152},{"_172":152,"_173":152,"_174":152,"_175":152},"Webpack 可以通过 DefinePlugin 插件给 web 应用注入环境变量。该插件会在编译过程中替换掉代码中指定的变量，以实现在运行时替换成环境变量的值。\n\n在 webpack 的配置文件中，需要先引入该插件，然后将需要注入的环境变量通过该插件进行配置。例如：\n\n```javascript\nconst webpack = require('webpack');\n\nmodule.exports = {\n // 其他配置\n plugins: [\n new webpack.DefinePlugin({\n 'process.env': {\n NODE_ENV: JSON.stringify('production')\n },\n API_URL: JSON.stringify('http://api.example.com')\n })\n ]\n};\n```\n\n上述配置中，定义了两个需要注入的变量，分别是 `process.env.NODE_ENV` 和 `API_URL`。其中，`process.env.NODE_ENV` 是一个常用的环境变量，用来标识当前是开发环境还是生产环境；`API_URL` 是一个自定义的环境变量，用来存储 API 的地址。\n\n在代码中使用这些环境变量时，只需要直接引用即可：\n\n```javascript\nif (process.env.NODE_ENV === 'production') {\n console.log('当前为生产环境');\n}\n\nfetch(API_URL + '/users')\n .then(response => response.json())\n .then(data => console.log(data));\n```\n\nWebpack 在编译时会将这些变量替换成对应的值，例如：\n\n```javascript\nif ('production' === 'production') {\n console.log('当前为生产环境');\n}\n\nfetch('http://api.example.com' + '/users')\n .then(response => response.json())\n .then(data => console.log(data));\n```\n\n通过这种方式，我们就可以在代码中方便地使用环境变量，同时保证了在不同环境下都能正确地使用相应的变量值。",{"_58":375,"_181":152,"_182":152,"_183":152,"_184":152,"_185":152,"_186":152,"_187":152,"_188":152,"_189":152},"https://api.github.com/repos/pro-collection/interview-question/issues/243/reactions","https://api.github.com/repos/pro-collection/interview-question/issues/243/timeline",{"_58":378,"_60":61,"_62":379,"_64":380,"_66":381,"_68":382,"_70":383,"_72":384,"_74":385,"_76":386,"_78":387,"_111":388,"_131":132,"_133":24,"_134":-5,"_135":391,"_137":392,"_159":152,"_153":394,"_155":395,"_158":-5,"_162":163,"_106":-5,"_164":-5,"_165":396,"_170":397,"_176":398,"_178":399,"_190":401,"_192":-5,"_193":-5,"_194":195},"https://api.github.com/repos/pro-collection/interview-question/issues/239","https://api.github.com/repos/pro-collection/interview-question/issues/239/labels{/name}","https://api.github.com/repos/pro-collection/interview-question/issues/239/comments","https://api.github.com/repos/pro-collection/interview-question/issues/239/events","https://github.com/pro-collection/interview-question/issues/239",1648001921,"I_kwDOJGDC6c5iOoOB",239,"如何在前端团队快速落地代码规范",{"_80":81,"_70":82,"_72":83,"_84":85,"_86":28,"_58":87,"_68":88,"_89":90,"_91":92,"_93":94,"_95":96,"_97":98,"_99":100,"_101":102,"_66":103,"_104":105,"_106":107,"_108":109,"_110":24},[389,390],{"_70":114,"_72":115,"_58":116,"_117":118,"_119":120,"_121":24,"_122":123},{"_70":125,"_72":126,"_58":127,"_117":128,"_119":129,"_121":24,"_122":130},[],{"_58":236,"_68":237,"_62":238,"_70":239,"_72":240,"_74":241,"_76":242,"_122":243,"_147":393,"_149":245,"_151":152,"_131":132,"_153":246,"_155":247,"_157":-5,"_158":-5},{"_80":81,"_70":82,"_72":83,"_84":85,"_86":28,"_58":87,"_68":88,"_89":90,"_91":92,"_93":94,"_95":96,"_97":98,"_99":100,"_101":102,"_66":103,"_104":105,"_106":107,"_108":109,"_110":24},"2023-03-30T17:10:42Z","2023-03-31T01:22:24Z",{"_167":152,"_168":152,"_169":152},{"_172":152,"_173":152,"_174":152,"_175":152},"// todo 待整理\r\n\r\n- https://juejin.cn/post/7033210664844066853\r\n- https://juejin.cn/post/7007419705543622669\r\n- https://juejin.cn/post/7167707693333872647\r\n- https://juejin.cn/post/6844904142289240071\r\n",{"_58":400,"_181":152,"_182":152,"_183":152,"_184":152,"_185":152,"_186":152,"_187":152,"_188":152,"_189":152},"https://api.github.com/repos/pro-collection/interview-question/issues/239/reactions","https://api.github.com/repos/pro-collection/interview-question/issues/239/timeline",{"_58":403,"_60":61,"_62":404,"_64":405,"_66":406,"_68":407,"_70":408,"_72":409,"_74":410,"_76":411,"_78":412,"_111":413,"_131":132,"_133":24,"_134":-5,"_135":415,"_137":416,"_159":152,"_153":418,"_155":419,"_158":-5,"_162":163,"_106":-5,"_164":-5,"_165":420,"_170":421,"_176":422,"_178":423,"_190":425,"_192":-5,"_193":-5,"_194":195},"https://api.github.com/repos/pro-collection/interview-question/issues/236","https://api.github.com/repos/pro-collection/interview-question/issues/236/labels{/name}","https://api.github.com/repos/pro-collection/interview-question/issues/236/comments","https://api.github.com/repos/pro-collection/interview-question/issues/236/events","https://github.com/pro-collection/interview-question/issues/236",1646069439,"I_kwDOJGDC6c5iHQa_",236,"babel 的工作流程是如何的？",{"_80":81,"_70":82,"_72":83,"_84":85,"_86":28,"_58":87,"_68":88,"_89":90,"_91":92,"_93":94,"_95":96,"_97":98,"_99":100,"_101":102,"_66":103,"_104":105,"_106":107,"_108":109,"_110":24},[414],{"_70":114,"_72":115,"_58":116,"_117":118,"_119":120,"_121":24,"_122":123},[],{"_58":236,"_68":237,"_62":238,"_70":239,"_72":240,"_74":241,"_76":242,"_122":243,"_147":417,"_149":245,"_151":152,"_131":132,"_153":246,"_155":247,"_157":-5,"_158":-5},{"_80":81,"_70":82,"_72":83,"_84":85,"_86":28,"_58":87,"_68":88,"_89":90,"_91":92,"_93":94,"_95":96,"_97":98,"_99":100,"_101":102,"_66":103,"_104":105,"_106":107,"_108":109,"_110":24},"2023-03-29T15:37:34Z","2023-03-29T15:37:35Z",{"_167":152,"_168":152,"_169":152},{"_172":152,"_173":152,"_174":152,"_175":152},"Babel 是一个 JavaScript 编译器，它的主要功能是将新版本的 JavaScript 代码转换成向后兼容的代码。Babel 的工作流程可以简单概括为以下几个步骤：\n\n1. 解析：将 JavaScript 代码解析成 AST（抽象语法树）。\n\n2. 转换：对 AST 进行遍历，进行代码转换。\n\n3. 生成：将转换后的 AST 生成 JavaScript 代码。\n\n具体来说，Babel 的工作流程如下：\n\n1. Babel 使用 babylon 解析器将 JavaScript 代码解析成 AST，babylon 是一个基于 AST 的 JavaScript 解析器。\n\n2. Babel 使用 babel-traverse 遍历器对 AST 进行遍历，找到需要转换的节点，进行转换。\n\n3. Babel 使用 babel-core 转换器将 AST 转换成 JavaScript 代码。babel-core 是 babel 的核心模块，它包含了所有的转换器和插件。\n\n4. Babel 使用 babel-generator 生成器将转换后的 AST 生成 JavaScript 代码。babel-generator 是一个将 AST 转换成 JavaScript 代码的工具。\n\n在整个流程中，Babel 还会使用 babel-preset-env、babel-plugin-transform-runtime、babel-polyfill 等插件和工具来完成更加复杂的任务，如将 ES6 模块转换成 CommonJS 模块，使用 Polyfill 来实现一些新的 API 等。\n\n需要注意的是，Babel 的转换过程是有损的，转换后的代码不一定与原始代码完全相同，也可能存在性能问题。因此，在使用 Babel 进行转换时，需要谨慎选择转换的规则和插件，以确保转换后的代码正确、高效。",{"_58":424,"_181":152,"_182":152,"_183":152,"_184":152,"_185":152,"_186":152,"_187":152,"_188":152,"_189":152},"https://api.github.com/repos/pro-collection/interview-question/issues/236/reactions","https://api.github.com/repos/pro-collection/interview-question/issues/236/timeline",{"_58":427,"_60":61,"_62":428,"_64":429,"_66":430,"_68":431,"_70":432,"_72":433,"_74":434,"_76":435,"_78":436,"_111":437,"_131":132,"_133":24,"_134":-5,"_135":444,"_137":445,"_159":152,"_153":447,"_155":448,"_158":-5,"_162":163,"_106":-5,"_164":-5,"_165":449,"_170":450,"_176":451,"_178":452,"_190":454,"_192":-5,"_193":-5,"_194":195},"https://api.github.com/repos/pro-collection/interview-question/issues/235","https://api.github.com/repos/pro-collection/interview-question/issues/235/labels{/name}","https://api.github.com/repos/pro-collection/interview-question/issues/235/comments","https://api.github.com/repos/pro-collection/interview-question/issues/235/events","https://github.com/pro-collection/interview-question/issues/235",1646064267,"I_kwDOJGDC6c5iHPKL",235,"[webpack] 什么情况下 webpack treeShaking 会失效？",{"_80":81,"_70":82,"_72":83,"_84":85,"_86":28,"_58":87,"_68":88,"_89":90,"_91":92,"_93":94,"_95":96,"_97":98,"_99":100,"_101":102,"_66":103,"_104":105,"_106":107,"_108":109,"_110":24},[438,439],{"_70":114,"_72":115,"_58":116,"_117":118,"_119":120,"_121":24,"_122":123},{"_70":440,"_72":441,"_58":442,"_117":443,"_119":129,"_121":24,"_122":130},5326133419,"LA_kwDOJGDC6c8AAAABPXZYqw","https://api.github.com/repos/pro-collection/interview-question/labels/%E5%B0%8F%E7%B1%B3","小米",[],{"_58":236,"_68":237,"_62":238,"_70":239,"_72":240,"_74":241,"_76":242,"_122":243,"_147":446,"_149":245,"_151":152,"_131":132,"_153":246,"_155":247,"_157":-5,"_158":-5},{"_80":81,"_70":82,"_72":83,"_84":85,"_86":28,"_58":87,"_68":88,"_89":90,"_91":92,"_93":94,"_95":96,"_97":98,"_99":100,"_101":102,"_66":103,"_104":105,"_106":107,"_108":109,"_110":24},"2023-03-29T15:34:25Z","2023-03-29T15:34:26Z",{"_167":152,"_168":152,"_169":152},{"_172":152,"_173":152,"_174":152,"_175":152},"### 以下是一些可能导致 webpack tree shaking 失效的情况\n\n1. 代码中使用了动态引入（Dynamic Imports）的语法，这种情况下，webpack 无法确定哪些代码会被使用，因此不会进行 tree shaking。\n\n2. 代码使用了函数式编程的方式，比如使用了 map、filter、reduce 等高阶函数，而这些函数很难通过静态分析确定代码的执行路径，所以可能会导致 tree shaking 失效。\n\n3. 代码中使用了 webpack 无法识别的模块系统，比如使用了 AMD 或者 CommonJS 的语法，这种情况下 webpack 也无法进行 tree shaking。\n\n4. 代码使用了 side effect，比如改变全局变量或者函数的参数，这种情况下 webpack 也无法进行 tree shaking。\n\n### 函数式编程的方式 filter 为何会导致无法 tree shaking\n\n函数式编程中常常使用高阶函数来组合函数，这种组合方式常常需要使用传递函数作为参数的方式，例如 map、filter 等高阶函数。这种情况下，如果参数传递的是一个函数表达式或者函数声明，那么无法进行 treeshaking。\n\n举个例子：\n\n```js\n// 代码中定义了一个 sum 函数\nfunction sum(a, b) {\n return a + b;\n}\n\n// 调用了 lodash 库的 filter 函数，传递一个匿名函数表达式作为参数\nimport { filter } from 'lodash';\n\nconst arr = [1, 2, 3, 4, 5];\nconst result = filter(arr, item => {\n if (item > 10) return sum(item, 1)\n else return item;\n});\n```\n上述代码中，使用了 lodash 库的 filter 函数，并且传递了一个匿名函数表达式作为参数。由于函数表达式无法被静态分析，不知道 sum 是否会被调用，因此无法进行 treeshaking，最终导致整个 sum 函数也被打包进了最终的代码中。\n\n### 为什么 commonjs 模块化会导致无法 tree shaking\n\nCommonJS 模块化语法是 Node.js 中的模块化规范，其使用了 `require()` 导入模块，使用 `module.exports` 或 `exports` 导出模块。它采用的是动态导入（require()）和同步加载的方式，这种导入方式无法在编译时确定所依赖的模块，因此在 Webpack 进行 Tree Shaking 时，这种导入方式的模块会被认为无法被静态分析，因而会被排除掉。\n\n相反，ES6 模块化语法采用的是静态导入的方式，例如 `import foo from './foo.js'`，可以在编译时分析出所依赖的模块，因此支持 Tree Shaking。\n\n因此，如果要使用 Tree Shaking，建议采用 ES6 模块化语法。如果必须使用 CommonJS 模块化规范，可以尝试使用动态导入`（import()）`语法，或者采用其他工具或手动实现 Tree Shaking。\n\n\n### side effect 是什么，为何会导致无法 tree shaking\n\n在编写 JavaScript 代码时，如果一个函数除了返回值外，还对外部的变量产生了其他的影响，比如修改了全局变量、读写了文件等操作，那么这个函数就被称为有“副作用”（side effect）。因为这种函数并不是纯函数，它可能会影响其他部分的代码执行结果，不便于优化和调试。\n\n在 Tree Shaking 的过程中，webpack 将模块打包成单独的 JavaScript 文件，它会从模块中找出哪些代码没有被使用到，并删除这些代码。但是，如果模块中存在带有副作用的代码，这些代码虽然没有被使用到，但它们仍然会被保留下来，因为这些代码可能会对其他部分的代码产生影响，因此不能简单地删除。这也是为什么带有副作用的代码会导致无法 Tree Shaking 的原因。\n\n",{"_58":453,"_181":152,"_182":152,"_183":152,"_184":152,"_185":152,"_186":152,"_187":152,"_188":152,"_189":152},"https://api.github.com/repos/pro-collection/interview-question/issues/235/reactions","https://api.github.com/repos/pro-collection/interview-question/issues/235/timeline",{"_58":456,"_60":61,"_62":457,"_64":458,"_66":459,"_68":460,"_70":461,"_72":462,"_74":463,"_76":464,"_78":465,"_111":466,"_131":132,"_133":24,"_134":-5,"_135":468,"_137":469,"_159":152,"_153":471,"_155":472,"_158":-5,"_162":163,"_106":-5,"_164":-5,"_165":473,"_170":474,"_176":475,"_178":476,"_190":478,"_192":-5,"_193":-5,"_194":195},"https://api.github.com/repos/pro-collection/interview-question/issues/231","https://api.github.com/repos/pro-collection/interview-question/issues/231/labels{/name}","https://api.github.com/repos/pro-collection/interview-question/issues/231/comments","https://api.github.com/repos/pro-collection/interview-question/issues/231/events","https://github.com/pro-collection/interview-question/issues/231",1646026621,"I_kwDOJGDC6c5iHF99",231,"不用使用 vue-cli ，如何创建一个完整的 vue 工程？",{"_80":81,"_70":82,"_72":83,"_84":85,"_86":28,"_58":87,"_68":88,"_89":90,"_91":92,"_93":94,"_95":96,"_97":98,"_99":100,"_101":102,"_66":103,"_104":105,"_106":107,"_108":109,"_110":24},[467],{"_70":114,"_72":115,"_58":116,"_117":118,"_119":120,"_121":24,"_122":123},[],{"_58":139,"_68":140,"_62":141,"_70":142,"_72":143,"_74":144,"_76":145,"_122":146,"_147":470,"_149":150,"_151":152,"_131":132,"_153":154,"_155":156,"_157":-5,"_158":-5},{"_80":81,"_70":82,"_72":83,"_84":85,"_86":28,"_58":87,"_68":88,"_89":90,"_91":92,"_93":94,"_95":96,"_97":98,"_99":100,"_101":102,"_66":103,"_104":105,"_106":107,"_108":109,"_110":24},"2023-03-29T15:13:13Z","2023-03-29T15:13:14Z",{"_167":152,"_168":152,"_169":152},{"_172":152,"_173":152,"_174":152,"_175":152},"这个一个较为复杂和庞大的话题，不能称之为问题，只能说它是一个话题。 \n\n主要涉及到的话题如下：\n\n1. vue 工程初始化\n2. 测试集成 \n3. UI 库绑定、基础组件使用\n4. 开发流程\n5. 代码规范（甚至包含 commit 规范）\n6. 多人协作与工作流\n7. 构建问题\n8. 上线流程\n9. 线上日志与用户反馈问题排查\n10. 性能保证\n",{"_58":477,"_181":152,"_182":152,"_183":152,"_184":152,"_185":152,"_186":152,"_187":152,"_188":152,"_189":152},"https://api.github.com/repos/pro-collection/interview-question/issues/231/reactions","https://api.github.com/repos/pro-collection/interview-question/issues/231/timeline",{"_58":480,"_60":61,"_62":481,"_64":482,"_66":483,"_68":484,"_70":485,"_72":486,"_74":487,"_76":488,"_78":489,"_111":490,"_131":132,"_133":24,"_134":-5,"_135":493,"_137":494,"_159":152,"_153":496,"_155":497,"_158":-5,"_162":163,"_106":-5,"_164":-5,"_165":498,"_170":499,"_176":500,"_178":501,"_190":503,"_192":-5,"_193":-5,"_194":195},"https://api.github.com/repos/pro-collection/interview-question/issues/207","https://api.github.com/repos/pro-collection/interview-question/issues/207/labels{/name}","https://api.github.com/repos/pro-collection/interview-question/issues/207/comments","https://api.github.com/repos/pro-collection/interview-question/issues/207/events","https://github.com/pro-collection/interview-question/issues/207",1642269410,"I_kwDOJGDC6c5h4wri",207,"使用虚拟DOM 一定会比直接操作真实 DOM 快吗？",{"_80":81,"_70":82,"_72":83,"_84":85,"_86":28,"_58":87,"_68":88,"_89":90,"_91":92,"_93":94,"_95":96,"_97":98,"_99":100,"_101":102,"_66":103,"_104":105,"_106":107,"_108":109,"_110":24},[491,492],{"_70":114,"_72":115,"_58":116,"_117":118,"_119":120,"_121":24,"_122":123},{"_70":362,"_72":363,"_58":364,"_117":365,"_119":129,"_121":24,"_122":130},[],{"_58":236,"_68":237,"_62":238,"_70":239,"_72":240,"_74":241,"_76":242,"_122":243,"_147":495,"_149":245,"_151":152,"_131":132,"_153":246,"_155":247,"_157":-5,"_158":-5},{"_80":81,"_70":82,"_72":83,"_84":85,"_86":28,"_58":87,"_68":88,"_89":90,"_91":92,"_93":94,"_95":96,"_97":98,"_99":100,"_101":102,"_66":103,"_104":105,"_106":107,"_108":109,"_110":24},"2023-03-27T14:59:24Z","2023-03-27T14:59:28Z",{"_167":152,"_168":152,"_169":152},{"_172":152,"_173":152,"_174":152,"_175":152},"大家惯有的思维模式下，我们普遍的认为，虚拟DOM一定会比原生DOM要快的多。\n\n但实际上并不是这样。\n\n**仅从React的角度来说 : React的官网可从来都没有说过虚拟DOM会比原生操作DOM更快。**\n\n虚拟DOM和原生操作DOM谁更快这个问题。如果要我来回答的话，**一定是原生DOM比虚拟DOM更快性能更好。**\n\n值得注意的是，**虚拟DOM并不是比原生DOM快，更确切的来说，虚拟DOM是比操作不当的原生DOM快**。实际上，如果对原生DOM的操作得当的话，原生DOM的性能一定优于虚拟DOM。\n\n我们来剖析一下。\n\n### 虚拟DOM为什么而存在\n\n**其最核心的思想是提升开发效率而非提升性能**\n\n使用 React/Vue 这些框架的时候，我们不需要去考虑对DOM的操作，只需要关心数据的改变。我们以前还在使用JQ的时候，数据改变之后我们需要调用`$(\"#id\").append(node)`等操作去手动追加DOM。而在使用React/Vue之后，我们只需要关心数据的改变。至于对DOM的一系列动作，在我们的数据改变之后，React/Vue会为我们代劳。这极大程度的提升了我们的开发效率。也是React/Vue的核心思想和初衷。\n\n至于很多人都说，虚拟DOM会比操作原生DOM更快，这个说法并不全面。比如，**首次渲染或者所有节点都需要进行更新的时候。这个时候采用虚拟DOM会比直接操作原生DOM多一重构建虚拟DOM树的操作。这会更大的占用内存和延长渲染时间。**\n\n#### 举个例子\n\n**首次渲染👇不采用虚拟DOM的步骤**\n\n1. 浏览器接受绘制指令\n2. 创建所有节点\n\n**首次渲染👇采用虚拟DOM的步骤**\n\n1. 浏览器接受绘制指令\n2. 创建虚拟DOM\n3. 创建所有节点\n\n不难发现，在首次渲染的时候，采用虚拟DOM会比不采用虚拟DOM要多一个**创建虚拟DOM**的步骤。\n\n> 注意:虚拟DOM的存在，并不是免费的，比对新旧虚拟DOM树的差异会带来一定的性能开销。\n\n**虚拟DOM的优势在于我们更新节点时候。它会检查哪些节点需要更新。尽量复用已有DOM，减少DOM的删除和重新创建。并且这些操作我们是可以通过自己手动操作javascript底层api实现的。只是我们手动操作会非常耗费我们的时间和精力。这个工作由虚拟DOM代劳，会让我们开发更快速便捷。**\n\n#### 举个例子👇\n\n在采用虚拟DOM的前提下\n\n假设我们有节点A，下辖两个子节点B/C.\n\n然后我们删除了节点C\n\n这个时候会有两棵虚拟DOM树，\n\n一颗是修改前的，A->B/C。\n\n另一颗是修改后的A->B。\n\n`diff算法会去比对两颗树的差异`，然后发现A->B没有更改，那么A->B节点保留，C节点执行删除动作。\n\n那么，A->B两个节点的删除和创建渲染操作就被省略了。\n\n如果不采用虚拟DOM的话。使用JQ那时候的模板.\n\n我们可能会把A->B/C三个节点全部删除.\n\n再全都重新创建。而A->B是完全没有改动的。\n\n他们的删除和创建则完全不必要。\n\n### 框架的意义\n\n我们需要知道:不论是React还是Vue或者是Angular。这些框架本身，都是基于原生的基础上创造的。它们，底层依赖的还是javascript，并不是一门新的语言。在他们的底层逻辑下。我们使用框架所做出的一切行为，都会被框架转化为对原生DOM的操作。**框架，只是一个转化语法的工具。**\n\n既然原生DOM可以创造出这些框架。当然我们使用原生DOM自然是可以写出比这些框架更好的性能。\n\n但是:为什么对原生DOM进行操作的性能明明可以比使用框架更好。为什么大家都在使用框架，而没有人去直接对原生DOM进行操作。\n\n这背后涉及`成本`和`普适性`。\n\n如果我们直接去操作真实DOM,当然，我们可以做到在性能上比虚拟DOM更快。但问题是，技术水准能做到这个地步的人，又有多少人呢。不说比虚拟DOM快。即使是做到和虚拟DOM不分上下的性能，拥有这种水平的前端玩家，也是寥寥无几。**基于这样的客观情况下，框架的出现解决了这个问题。**\n\n框架存在的意义 : 在为我们提供只需要关注数据的前提下。框架本身已经做好了底层原理上的性能优化（包括但不限于,对DOM的调用,算法上的优化）已经是高度封装。这样就可以让我们使用一些简单的较为容易理解的技术去做我们原本做不到的事情。这其实就像调用网上的第三方包，某一个功能，自己写是写不出来，写出来性能也不会很好。但是同样的功能，我们去网上引入其他大神已经封装完成的第三方包。我们就会用，功能就可以实现并且性能上也过得去。\n\n如果让大家直接对DOM进行操作完成比框架更优秀的性能。这绝不是大多数人可以做到的。让大多数可以接受，框架需要做的，就是让大多数人使用尽量使用简单的技术，完成相对困难的操作。这是`普适性`。\n\n并且，如果完成同一个性能效果，需要我们去*精通原生javascript*和*学习框架上的一些简单的API和结构*。明显后者的学习成本更低。如果说使用框架我们所能完成的某一阶段的性能所需要的学习成本是2个月的话。那么学习javascript完成同一阶段的性能可能需要一年。\n\n框架的初衷就是让用户使用尽量简单的技术，完成相对复杂的工作并提升一定的性能 *（这其中包括但不限于:可维护性，可复用性，渲染效率等）* 。这样，即使我们的水平不是很高，使用框架以后。项目在性能上也能过得去。\n\n# 总结\n\n1. 虚拟DOM不一定会比操作原生DOM更快。\n2. 虚拟DOM的优势在于节点进行改动的时候尽量减少开销\n3. React从来没说过虚拟DOM会比原生更快。\n4. 框架的本质是提升开发效率，让我们的注意力更集中于数据\n",{"_58":502,"_181":152,"_182":152,"_183":152,"_184":152,"_185":152,"_186":152,"_187":152,"_188":152,"_189":152},"https://api.github.com/repos/pro-collection/interview-question/issues/207/reactions","https://api.github.com/repos/pro-collection/interview-question/issues/207/timeline",{"_58":505,"_60":61,"_62":506,"_64":507,"_66":508,"_68":509,"_70":510,"_72":511,"_74":512,"_76":513,"_78":514,"_111":515,"_131":132,"_133":24,"_134":-5,"_135":518,"_137":519,"_159":152,"_153":521,"_155":522,"_158":-5,"_162":163,"_106":-5,"_164":-5,"_165":523,"_170":524,"_176":525,"_178":526,"_190":528,"_192":-5,"_193":-5,"_194":195},"https://api.github.com/repos/pro-collection/interview-question/issues/204","https://api.github.com/repos/pro-collection/interview-question/issues/204/labels{/name}","https://api.github.com/repos/pro-collection/interview-question/issues/204/comments","https://api.github.com/repos/pro-collection/interview-question/issues/204/events","https://github.com/pro-collection/interview-question/issues/204",1640927038,"I_kwDOJGDC6c5hzo8-",204,"AMD 和 CMD 模块化有和区别？",{"_80":81,"_70":82,"_72":83,"_84":85,"_86":28,"_58":87,"_68":88,"_89":90,"_91":92,"_93":94,"_95":96,"_97":98,"_99":100,"_101":102,"_66":103,"_104":105,"_106":107,"_108":109,"_110":24},[516,517],{"_70":114,"_72":115,"_58":116,"_117":118,"_119":120,"_121":24,"_122":123},{"_70":125,"_72":126,"_58":127,"_117":128,"_119":129,"_121":24,"_122":130},[],{"_58":236,"_68":237,"_62":238,"_70":239,"_72":240,"_74":241,"_76":242,"_122":243,"_147":520,"_149":245,"_151":152,"_131":132,"_153":246,"_155":247,"_157":-5,"_158":-5},{"_80":81,"_70":82,"_72":83,"_84":85,"_86":28,"_58":87,"_68":88,"_89":90,"_91":92,"_93":94,"_95":96,"_97":98,"_99":100,"_101":102,"_66":103,"_104":105,"_106":107,"_108":109,"_110":24},"2023-03-26T14:08:39Z","2023-03-26T14:11:05Z",{"_167":152,"_168":152,"_169":152},{"_172":152,"_173":152,"_174":152,"_175":152},"AMD（Asynchronous Module Definition）和CMD（Common Module Definition）都是JavaScript模块化方案。它们的主要区别在于对依赖的处理方式上不同。\n\nAMD是在require.js推广过程中诞生的，它的特点是提前执行，强调依赖前置。也就是说，在定义模块时就需要声明其所有依赖的模块。它的语法如下：\n\n```javascript\ndefine(['dependency1', 'dependency2'], function(dependency1, dependency2) {\n // 模块的定义\n});\n```\n\nCMD是在Sea.js推广过程中诞生的，它和AMD非常相似，但是更加懒惰，是依赖就近，延迟执行。也就是说，在模块中需要用到依赖时，才去引入依赖。它的语法如下：\n\n```javascript\ndefine(function(require, exports, module) {\n var dependency1 = require('dependency1');\n var dependency2 = require('dependency2');\n // 模块的定义\n});\n```\n\n简单来说，AMD是提前执行、依赖前置，CMD是延迟执行、依赖就近。两种模块化方案各有优缺点，选择哪种模块化方案需要根据实际情况和个人偏好进行考虑。",{"_58":527,"_181":152,"_182":152,"_183":152,"_184":152,"_185":152,"_186":152,"_187":152,"_188":152,"_189":152},"https://api.github.com/repos/pro-collection/interview-question/issues/204/reactions","https://api.github.com/repos/pro-collection/interview-question/issues/204/timeline",{"_58":530,"_60":61,"_62":531,"_64":532,"_66":533,"_68":534,"_70":535,"_72":536,"_74":537,"_76":538,"_78":539,"_111":540,"_131":132,"_133":24,"_134":-5,"_135":543,"_137":544,"_159":152,"_153":546,"_155":547,"_158":-5,"_162":163,"_106":-5,"_164":-5,"_165":548,"_170":549,"_176":550,"_178":551,"_190":553,"_192":-5,"_193":-5,"_194":195},"https://api.github.com/repos/pro-collection/interview-question/issues/203","https://api.github.com/repos/pro-collection/interview-question/issues/203/labels{/name}","https://api.github.com/repos/pro-collection/interview-question/issues/203/comments","https://api.github.com/repos/pro-collection/interview-question/issues/203/events","https://github.com/pro-collection/interview-question/issues/203",1640925937,"I_kwDOJGDC6c5hzorx",203,"前端模块化发展历程？",{"_80":81,"_70":82,"_72":83,"_84":85,"_86":28,"_58":87,"_68":88,"_89":90,"_91":92,"_93":94,"_95":96,"_97":98,"_99":100,"_101":102,"_66":103,"_104":105,"_106":107,"_108":109,"_110":24},[541,542],{"_70":114,"_72":115,"_58":116,"_117":118,"_119":120,"_121":24,"_122":123},{"_70":125,"_72":126,"_58":127,"_117":128,"_119":129,"_121":24,"_122":130},[],{"_58":236,"_68":237,"_62":238,"_70":239,"_72":240,"_74":241,"_76":242,"_122":243,"_147":545,"_149":245,"_151":152,"_131":132,"_153":246,"_155":247,"_157":-5,"_158":-5},{"_80":81,"_70":82,"_72":83,"_84":85,"_86":28,"_58":87,"_68":88,"_89":90,"_91":92,"_93":94,"_95":96,"_97":98,"_99":100,"_101":102,"_66":103,"_104":105,"_106":107,"_108":109,"_110":24},"2023-03-26T14:06:45Z","2023-08-20T14:51:20Z",{"_167":152,"_168":152,"_169":152},{"_172":152,"_173":152,"_174":152,"_175":152},"前端模块化是指在前端开发中，通过模块化的方式组织代码，将代码按照一定规则分割成不同的模块，便于管理和维护。\r\n\r\n前端模块化的发展历程如下：\r\n\r\n1. 早期，前端开发采用的是全局变量的方式进行开发，即将所有代码都放在一个文件中，通过全局变量进行交互。这种方式的问题在于，代码量较大，代码耦合度高，不易维护。\r\n\r\n2. 后来，前端开发采用了命名空间的方式进行组织代码，即将代码放在一个命名空间下，通过命名空间进行交互。这种方式解决了全局变量带来的问题，但是在开发大型应用时，仍然存在代码耦合度高、依赖管理不便等问题。\r\n\r\n3. 2009年，CommonJS提出了一种新的模块化规范，即将每个模块封装在一个独立的文件中，通过require和exports进行模块之间的依赖管理和导出。这种方式解决了前两种方式带来的问题，但是由于该规范是同步加载模块，不适用于浏览器环境。\r\n\r\n4. 2011年，AMD规范提出，即异步模块定义规范，采用异步的方式加载模块，可以在浏览器环境下使用。该规范主要是通过require和define方法进行模块之间的依赖管理和导出。\r\n\r\n5. 2013年，CommonJS和AMD的创始人合并了两种规范，提出了新的规范——CommonJS 2.0规范。该规范在CommonJS 1.0的基础上，增加了异步加载的功能，使其可以在浏览器环境下使用。\r\n\r\n6. 2014年，ES6（即ECMAScript 2015）正式发布，引入了模块化的支持，即通过import和export语句进行模块之间的依赖管理和导出。ES6的模块化规范具有更好的可读性、可维护性和性能优势，已成为前端开发的主流方式。\r\n\r\n7. 同时，还有一些第三方库，如RequireJS、SeaJS等，提供了更加灵活和可扩展的模块化方式，使得前端开发的模块化更加便捷和高效。\r\n\r\n\r\n-----------------------\r\n### 1 函数作为块\r\n\r\n最开始的时候，是以函数为块来编程，因为函数有自己的作用域，相对比较独立\r\n\r\n```js\r\nfunction add(a,b){...}\r\nfunction add1(a,b,c){...}\r\n```\r\n\r\n这种形式中，add和add1都是定义在全局作用域中的，会造成很多问题：\r\n\r\n1. 污染全局作用域，容易造成命名冲突\r\n2. 定义在全局作用域，数据不安全\r\n\r\n### 2 namespace模式\r\n\r\n使用对象作为独立块编程\r\n\r\n```js\r\nvar myModule={\r\n a:1,\r\n b:2,\r\n add:function(m,n){...}\r\n}\r\n```\r\n\r\n优点：减少了全局变量，有效解决了命名冲突\r\n\r\n缺点：\r\n\r\n1. 没有私有变量，使用起来很繁琐\r\n2. 数据不安全，模块外面可以随意修改内部的数据\r\n\r\n### 3 IIFE模式\r\n\r\n**使用立即执行函数来创建块，可以形成独立的作用域，外面无法访问，借助window对象来向外暴露接口**\r\n\r\n```js\r\n(function($){\r\n var a=1;\r\n var b=2;\r\n function add(m,n){\r\n ...\r\n }\r\n $('#id').addClass('.hehe');\r\n window.myModule={\r\n a:a,\r\n b:b,\r\n add:add\r\n }\r\n})()\r\n```\r\n\r\n优点：\r\n\r\n1. 减少了全局变量，解决了命名冲突\r\n2. 创建了独立的作用域，外部无法轻易修改内部数据\r\n\r\n缺点：\r\n\r\n**如果多个模块分布在多个js文件中，那么在html文件中就需要引入多个js文件**\r\n\r\n1. 会增加多个http请求，增加首屏的时候，降低用户体验\r\n2. **模块之间的引用关系很不明显，难以维护**\r\n\r\n\r\n### 4 CommonJS\r\n\r\n最开始出现的模块化方案是在node.js中实现的。node中的模块化方案是根据CommonJS规范实现的。\r\n\r\n**CommonJS规定每个文件就是一个模块，以同步的方式引入其他模块**\r\n\r\n```js\r\n//a.js\r\nfunction add(m,n){\r\n return m+n;\r\n}\r\nmodule.exports={add:add}\r\n\r\n\r\n//b.js\r\nconst {add} = require('./a.js');\r\nconsole.log(add(1,2)); // 3\r\n```\r\n\r\n这种方式是node端独有的，浏览器端如果想要使用，需要使用 **Browserify** 工具来解析。\r\n\r\n\r\n\r\n### 5 AMD和Require.js\r\n\r\nCommonJS模块之前是同步引入的，这在服务端是没有什么问题的，因为**文件都是保存在硬盘中，读取文件的速度是非常快的，同步加载带来的阻塞基本可以忽略不计。**\r\n\r\n但是如果在浏览器中使用CommonJS的话，因为**js文件是存在服务端需要请求获取，所以同步的方式加载会极大的阻塞页面**，显然是不可取的。\r\n\r\n于是诞生了AMD（Asynchronous Module Definition）规范，**一种异步加载的模块方案，使用回调函数来实现**。require.js实现了AMD的规范。\r\n\r\n```js\r\n//定义没有依赖的模块\r\n//a.js\r\ndefine(function(){\r\n function add(m,n){\r\n return m+n;\r\n }\r\n return {add:add}\r\n})\r\n\r\n//定义有依赖的模块\r\n//b.js\r\ndefine(['a'], function(a){\r\n const sum = a.add(1,2);\r\n return {sum:sum}\r\n})\r\n\r\n//引用模块\r\nrequire(['b'],function(b){\r\n console.log(b.sum); //3\r\n})\r\n```\r\n\r\n由上面代码分析Require.js的特点\r\n\r\n1. 依赖模块的代码都是放在回调函数中，等待模块都加载完成才执行这个回调函数，执行顺序可以保证\r\n2. **内部加载其他模块的时候，使用的是动态添加script标签的方式来实现动态加载**\r\n3. 内部需要缓存模块暴露出来的接口，避免多次执行\r\n\r\n**AMD推崇的是依赖前置，提前执行。**\r\n\r\n从上面代码可以看出，**在声明一个模块的时候，会在第一时间就将其依赖模块的内部代码执行完毕。而不是在真正使用的地方再去执行。**因此会带来一些资源浪费\r\n\r\n```js\r\ndefine(['a','b'],function(a,b){\r\n let sum = a.add(1,2);\r\n if(false){\r\n sum = b.add(1,2); //b模块是没有被使用的，应该是不需要执行模块内部代码的\r\n }\r\n return sum;\r\n})\r\n```\r\n\r\n\r\n\r\n### 6 CMD和Sea.js\r\n\r\n由于require.js自身的一些问题存在，所以后来在国内（玉伯）诞生了CMD（Common Module Definition）和Sea.js。\r\n\r\nCMD结合了CommonJS和AMD的特点，也是一种**异步**模块的方案，**提倡就近依赖，延迟执行。**\r\n\r\n**需要用到某个模块的时候，才用require引入，模块内部的代码也是在被引入的时候才会执行，声明的时候并没有执行。**\r\n\r\n语法设计上比较像CommonJS\r\n\r\n```js\r\n//定义模块 math.js\r\ndefine(function(require,exports,module){\r\n var a = require('./a.js'); // 引入模块\r\n function add(m,n){\r\n return m+n;\r\n }\r\n module.exports={\r\n add:add\r\n }\r\n});\r\n\r\n//加载模块\r\nseajs.use(['math.js'],function(math){\r\n var sum = math.add(1,2);\r\n})\r\n```\r\n\r\n看上面的代码可能会有疑问，模块是异步加载的，但是使用的时候require是同步使用的，没有回调函数，如何能够保证执行的顺序呢？这就不得不提sea.js中的静态依赖分析机制了。\r\n\r\n#### 6.1 Sea.js中的静态依赖分析机制\r\n\r\nSea.js中**模块加载的入口方法是use()方法，执行这个方法会开始加载所有的依赖模块**。然后sea.js中是就近依赖的，它是如何获取依赖模块的呢？\r\n\r\n**在define的方法中，如果传入的参数factory是一个函数，内部会执行函数的toString方法，转化成字符串，然后通过正则表达式分析字符串，获取require方法中的参数，通过路径分析去加载依赖的模块**。以此链式分析下去，边分析边加载模块，等待所有的依赖都加载完成之后，才开始调用use的回调函数，正式执行模块内代码。\r\n\r\n所以在require方法执行之前，对应的模块已经加载完成了，所以可以直接传入参数，执行模块函数体。\r\n\r\n#### 6.2 Sea.js的特点\r\n\r\n1. **就近依赖，延时执行**\r\n2. 内部拥有静态依赖分析机制，保证require之前，模块已经加载完毕，但是函数还没有执行\r\n3. 也是一种异步的模块化方案\r\n4. 内部也有缓存机制，缓存模块暴露的接口\r\n5. 内部加载模块的时候，和require.js一样，也是通过**动态增加script标签**来完成的\r\n\r\n\r\n\r\n### 7 ES Module\r\n\r\nES6开始，在语法标准上实现了模块化功能。简称ES Module\r\n\r\n**ES Module是一种静态依赖的模块化方案，模块与模块之间的依赖关系是在编译期完成连接的。**\r\n\r\n**前面所说的三种方案都是动态模块化方案，依赖模块都是动态引入的，而且模块都是一个对象。而ES Module中，模块不是一个对象，模块与模块之间也不是动态引入的，而且编译期间静态引入的，所以无法实现条件加载**\r\n\r\n```js\r\n//a.js\r\nfunction add(m,n){\r\n return m+n;\r\n}\r\nexport {add};\r\n\r\n// b.js\r\nimport {add} from './a.js';\r\nconsole.log(add(1,2)); //3\r\n```",{"_58":552,"_181":152,"_182":152,"_183":152,"_184":152,"_185":152,"_186":152,"_187":152,"_188":152,"_189":152},"https://api.github.com/repos/pro-collection/interview-question/issues/203/reactions","https://api.github.com/repos/pro-collection/interview-question/issues/203/timeline",{"_58":555,"_60":61,"_62":556,"_64":557,"_66":558,"_68":559,"_70":560,"_72":561,"_74":562,"_76":563,"_78":564,"_111":565,"_131":132,"_133":24,"_134":-5,"_135":567,"_137":568,"_159":195,"_153":570,"_155":571,"_158":-5,"_162":163,"_106":-5,"_164":-5,"_165":572,"_170":573,"_176":574,"_178":575,"_190":577,"_192":-5,"_193":-5,"_194":195},"https://api.github.com/repos/pro-collection/interview-question/issues/187","https://api.github.com/repos/pro-collection/interview-question/issues/187/labels{/name}","https://api.github.com/repos/pro-collection/interview-question/issues/187/comments","https://api.github.com/repos/pro-collection/interview-question/issues/187/events","https://github.com/pro-collection/interview-question/issues/187",1640837439,"I_kwDOJGDC6c5hzTE_",187,"前端单页应用 History 路由模式，需要如何配置 nginx？",{"_80":81,"_70":82,"_72":83,"_84":85,"_86":28,"_58":87,"_68":88,"_89":90,"_91":92,"_93":94,"_95":96,"_97":98,"_99":100,"_101":102,"_66":103,"_104":105,"_106":107,"_108":109,"_110":24},[566],{"_70":114,"_72":115,"_58":116,"_117":118,"_119":120,"_121":24,"_122":123},[],{"_58":236,"_68":237,"_62":238,"_70":239,"_72":240,"_74":241,"_76":242,"_122":243,"_147":569,"_149":245,"_151":152,"_131":132,"_153":246,"_155":247,"_157":-5,"_158":-5},{"_80":81,"_70":82,"_72":83,"_84":85,"_86":28,"_58":87,"_68":88,"_89":90,"_91":92,"_93":94,"_95":96,"_97":98,"_99":100,"_101":102,"_66":103,"_104":105,"_106":107,"_108":109,"_110":24},"2023-03-26T09:30:59Z","2023-04-03T01:27:28Z",{"_167":152,"_168":152,"_169":152},{"_172":152,"_173":152,"_174":152,"_175":152},"前端单页应用使用 History 路由模式，需要将路由的控制交给前端，而不是后端处理，因此需要配置 nginx 让其将所有请求都指向 index.html 页面，让前端来处理路由。\n\n具体配置可以参考以下 nginx 配置：\n\n```bash\nbashCopy codeserver {\n listen 80;\n server_name example.com; # 域名或 IP 地址\n\n location / {\n root /path/to/your/app; # 项目根目录\n index index.html;\n try_files $uri $uri/ /index.html; # 将所有请求都指向 index.html 页面\n }\n}\n```\n\n以上配置中，`try_files` 指令会尝试将请求映射到对应的文件，如果找不到，则会将请求转发到 `/index.html` 页面，由前端来处理路由。同时，`root` 指令需要指向前端应用的根目录。",{"_58":576,"_181":152,"_182":152,"_183":152,"_184":152,"_185":152,"_186":152,"_187":152,"_188":152,"_189":152},"https://api.github.com/repos/pro-collection/interview-question/issues/187/reactions","https://api.github.com/repos/pro-collection/interview-question/issues/187/timeline",{"_58":579,"_60":61,"_62":580,"_64":581,"_66":582,"_68":583,"_70":584,"_72":585,"_74":586,"_76":587,"_78":588,"_111":589,"_131":132,"_133":24,"_134":-5,"_135":591,"_137":592,"_159":152,"_153":594,"_155":595,"_158":-5,"_162":163,"_106":-5,"_164":-5,"_165":596,"_170":597,"_176":598,"_178":599,"_190":601,"_192":-5,"_193":-5,"_194":195},"https://api.github.com/repos/pro-collection/interview-question/issues/145","https://api.github.com/repos/pro-collection/interview-question/issues/145/labels{/name}","https://api.github.com/repos/pro-collection/interview-question/issues/145/comments","https://api.github.com/repos/pro-collection/interview-question/issues/145/events","https://github.com/pro-collection/interview-question/issues/145",1637895822,"I_kwDOJGDC6c5hoE6O",145,"实现 JS 沙盒的方式有哪些？",{"_80":81,"_70":82,"_72":83,"_84":85,"_86":28,"_58":87,"_68":88,"_89":90,"_91":92,"_93":94,"_95":96,"_97":98,"_99":100,"_101":102,"_66":103,"_104":105,"_106":107,"_108":109,"_110":24},[590],{"_70":114,"_72":115,"_58":116,"_117":118,"_119":120,"_121":24,"_122":123},[],{"_58":139,"_68":140,"_62":141,"_70":142,"_72":143,"_74":144,"_76":145,"_122":146,"_147":593,"_149":150,"_151":152,"_131":132,"_153":154,"_155":156,"_157":-5,"_158":-5},{"_80":81,"_70":82,"_72":83,"_84":85,"_86":28,"_58":87,"_68":88,"_89":90,"_91":92,"_93":94,"_95":96,"_97":98,"_99":100,"_101":102,"_66":103,"_104":105,"_106":107,"_108":109,"_110":24},"2023-03-23T16:44:40Z","2023-03-23T16:45:35Z",{"_167":152,"_168":152,"_169":152},{"_172":152,"_173":152,"_174":152,"_175":152},"微前端已经成为前端领域比较火爆的话题，在技术方面，微前端有一个始终绕不过去的话题就是前端沙箱\r\n\r\n### 什么是沙箱\r\n\r\n> Sandboxie(又叫沙箱、沙盘)即是一个虚拟系统程序，允许你在沙盘环境中运行浏览器或其他程序，因此运行所产生的变化可以随后删除。它创造了一个类似沙盒的独立作业环境，在其内部运行的程序并不能对硬盘产生永久性的影响。在网络安全中，沙箱指在隔离环境中，用以测试不受信任的文件或应用程序等行为的工具\r\n\r\n简单来说沙箱（sandbox）就是与外界隔绝的一个环境，内外环境互不影响，外界无法修改该环境内任何信息，沙箱内的东西单独属于一个世界。\r\n\r\n### JavaScript 的沙箱\r\n\r\n对于 JavaScript 来说，沙箱并非传统意义上的沙箱，它只是一种语法上的 Hack 写法，沙箱是一种安全机制，把一些不信任的代码运行在沙箱之内，使其不能访问沙箱之外的代码。当需要解析或着执行不可信的 JavaScript 的时候，需要隔离被执行代码的执行环境的时候，需要对执行代码中可访问对象进行限制，通常开始可以把 JavaScript 中处理模块依赖关系的闭包称之为沙箱。\r\n\r\n### JavaScript 沙箱实现\r\n\r\n我们大致可以把沙箱的实现总体分为两个部分：\r\n\r\n* 构建一个闭包环境\r\n* 模拟原生浏览器对象\r\n\r\n### 构建闭包环境\r\n\r\n我们知道 JavaScript 中，关于作用域（scope）,只有全局作用域（global scope）、函数作用域（function scope）以及从 ES6 开始才有的块级作用域（block scope）。如果要将一段代码中的变量、函数等的定义隔离出来，受限于 JavaScript 对作用域的控制，只能将这段代码封装到一个 Function 中，通过使用 function scope 来达到作用域隔离的目的。也因为需要这种使用函数来达到作用域隔离的目的方式，于是就有 IIFE（立即调用函数表达式）,这是一个被称为自执行匿名函数的设计模式\r\n\r\n```javascript\r\n (function foo(){\r\n var a = 1;\r\n console.log(a);\r\n })();\r\n // 无法从外部访问变量 name\r\nconsole.log(a) // 抛出错误：\"Uncaught ReferenceError: a is not defined\"\r\n\r\n```\r\n\r\n当函数变成立即执行的函数表达式时，表达式中的变量不能从外部访问，它拥有独立的词法作用域。不仅避免了外界访问 IIFE 中的变量，而且又不会污染全局作用域，弥补了 JavaScript 在 scope 方面的缺陷。一般常见于写插件和类库时，如 JQuery 当中的沙箱模式\r\n\r\n```javascript\r\n(function (window) {\r\n var jQuery = function (selector, context) {\r\n return new jQuery.fn.init(selector, context);\r\n }\r\n jQuery.fn = jQuery.prototype = function () {\r\n //原型上的方法，即所有jQuery对象都可以共享的方法和属性\r\n }\r\n jQuery.fn.init.prototype = jQuery.fn;\r\n window.jQeury = window.$ = jQuery; //如果需要在外界暴露一些属性或者方法，可以将这些属性和方法加到window全局对象上去\r\n})(window);\r\n\r\n```\r\n\r\n当将 IIFE 分配给一个变量，不是存储 IIFE 本身，而是存储 IIFE 执行后返回的结果。\r\n\r\n```ini\r\nvar result = (function () {\r\n var name = \"张三\";\r\n return name;\r\n})();\r\nconsole.log(result); // \"张三\"\r\n\r\n```\r\n\r\n### 原生浏览器对象的模拟\r\n\r\n模拟原生浏览器对象的目的是为了，防止闭包环境，操作原生对象。篡改污染原生环境；完成模拟浏览器对象之前我们需要先关注几个不常用的 API。\r\n\r\n#### eval\r\n\r\neval 函数可将字符串转换为代码执行，并返回一个或多个值\r\n\r\n```css\r\n var b = eval(\"({name:'张三'})\")\r\n console.log(b.name);\r\n\r\n```\r\n\r\n由于 eval 执行的代码可以访问闭包和全局范围，因此就导致了代码注入的安全问题，因为代码内部可以沿着作用域链往上找，篡改全局变量，这是我们不希望的\r\n\r\n#### new Function\r\n\r\nFunction 构造函数创建一个新的 Function 对象。直接调用这个构造函数可用动态创建函数\r\n\r\n> 语法\r\n\r\n`new Function ([arg1[, arg2[, ...argN]],] functionBody)`\r\n\r\n**arg1, arg2, ... argN** 被函数使用的参数的名称必须是合法命名的。参数名称是一个有效的 JavaScript 标识符的字符串，或者一个用逗号分隔的有效字符串的列表;例如“×”，“theValue”，或“a,b”。\r\n\r\n**functionBody** 一个含有包括函数定义的 JavaScript 语句的字符串。\r\n\r\n```javascript\r\nconst sum = new Function('a', 'b', 'return a + b');\r\n\r\nconsole.log(sum(1, 2));//3\r\n\r\n```\r\n\r\n同样也会遇到和 eval 类似的的安全问题和相对较小的性能问题。\r\n\r\n```javascript\r\nvar a = 1;\r\n\r\nfunction sandbox() {\r\n var a = 2;\r\n return new Function('return a;'); // 这里的 a 指向最上面全局作用域内的 1\r\n}\r\nvar f = sandbox();\r\nconsole.log(f())\r\n\r\n```\r\n\r\n与 eval 不同的是 Function 创建的函数只能在全局作用域中运行。它无法访问局部闭包变量，它们总是被创建于全局环境，因此在运行时它们只能访问全局变量和自己的局部变量，不能访问它们被 Function 构造器创建时所在的作用域的变量；但是，它仍然可以访问全局范围。new Function()是 eval()更好替代方案。它具有卓越的性能和安全性，但仍没有解决访问全局的问题。\r\n\r\n### with\r\n\r\nwith 是 JavaScript 中一个关键字,扩展一个语句的作用域链。它允许半沙盒执行。那什么叫半沙盒？语句将某个对象添加到作用域链的顶部，如果在沙盒中有某个未使用命名空间的变量，跟作用域链中的某个属性同名，则这个变量将指向这个属性值。如果沒有同名的属性，则将拋出 ReferenceError。\r\n\r\n```javascript\r\nfunction sandbox(o) {\r\n with (o){\r\n //a=5; \r\n c=2;\r\n d=3;\r\n console.log(a,b,c,d); // 0,1,2,3 //每个变量首先被认为是一个局部变量，如果局部变量与 obj 对象的某个属性同名，则这个局部变量会指向 obj 对象属性。\r\n }\r\n\r\n}\r\nvar f = {\r\n a:0,\r\n b:1\r\n}\r\nsandbox(f);\r\nconsole.log(f);\r\nconsole.log(c,d); // 2,3 c、d被泄露到window对象上\r\n\r\n```\r\n\r\n究其原理，`with`在内部使用`in`运算符。对于块内的每个变量访问，它都在沙盒条件下计算变量。如果条件是 true，它将从沙盒中检索变量。否则，就在全局范围内查找变量。但是 with 语句使程序在查找变量值时，都是先在指定的对象中查找。所以对于那些本来不是这个对象的属性的变量，查找起来会很慢，对于有性能要求的程序不适合（JavaScript 引擎会在编译阶段进行数项的性能优化。其中有些优化依赖于能够根据代码的词法进行静态分析，并预先确定所有变量和函数的定义位置，才能在执行过程中快速找到标识符。）。with 也会导致数据泄漏(在非严格模式下，会自动在全局作用域创建一个全局变量)\r\n\r\n### in 运算符\r\n\r\n> in 运算符能够检测左侧操作数是否为右侧操作数的成员。其中，左侧操作数是一个字符串，或者可以转换为字符串的表达式，右侧操作数是一个对象或数组。\r\n\r\n```javascript\r\nvar o = {\r\n a : 1,\r\n b : function() {}\r\n}\r\nconsole.log(\"a\" in o); //true\r\nconsole.log(\"b\" in o); //true\r\nconsole.log(\"c\" in o); //false\r\nconsole.log(\"valueOf\" in o); //返回true，继承Object的原型方法\r\nconsole.log(\"constructor\" in o); //返回true，继承Object的原型属性\r\n\r\n```\r\n\r\n### with + new Function\r\n\r\n配合 with 用法可以稍微限制沙盒作用域，先从当前的 with 提供对象查找，但是如果查找不到依然还能从上获取，污染或篡改全局环境。\r\n\r\n```javascript\r\nfunction sandbox (src) {\r\n src = 'with (sandbox) {' + src + '}'\r\n return new Function('sandbox', src)\r\n}\r\nvar str = 'let a = 1;window.name=\"张三\";console.log(a);console.log(b)'\r\nvar b = 2\r\nsandbox(str)({});\r\nconsole.log(window.name);//'张三'\r\n\r\n```\r\n\r\n### 基于 Proxy 实现的沙箱(ProxySandbox)\r\n\r\n由上部分内容思考,假如可以做到在使用`with`对于块内的每个变量访问都限制在沙盒条件下计算变量，从沙盒中检索变量。那么是否可以完美的解决JavaScript沙箱机制。\r\n\r\n使用 with 再加上 proxy 实现 JavaScript 沙箱\r\n\r\n> ES6 Proxy 用于修改某些操作的默认行为，等同于在语言层面做出修改，属于一种“元编程”（meta programming）\r\n\r\n```javascript\r\nfunction sandbox(code) {\r\n code = 'with (sandbox) {' + code + '}'\r\n const fn = new Function('sandbox', code)\r\n\r\n return function (sandbox) {\r\n const sandboxProxy = new Proxy(sandbox, {\r\n has(target, key) {\r\n return true\r\n }\r\n })\r\n return fn(sandboxProxy)\r\n }\r\n}\r\nvar a = 1;\r\nvar code = 'console.log(a)' // TypeError: Cannot read property 'log' of undefined\r\nsandbox(code)({})\r\n\r\n```\r\n\r\n我们前面提到`with`在内部使用`in`运算符来计算变量，如果条件是 true，它将从沙盒中检索变量。理想状态下没有问题，但也总有些特例独行的存在，比如 Symbol.unscopables。\r\n\r\n**Symbol.unscopables**\r\n\r\n> Symbol.unscopables 对象的 Symbol.unscopables 属性，指向一个对象。该对象指定了使用 with 关键字时，哪些属性会被 with 环境排除。\r\n\r\n```javascript\r\nArray.prototype[Symbol.unscopables]\r\n// {\r\n// copyWithin: true,\r\n// entries: true,\r\n// fill: true,\r\n// find: true,\r\n// findIndex: true,\r\n// keys: true\r\n// }\r\n\r\nObject.keys(Array.prototype[Symbol.unscopables])\r\n// ['copyWithin', 'entries', 'fill', 'find', 'findIndex', 'keys']\r\n\r\n```\r\n\r\n\r\n由此我们的代码还需要修改如下：\r\n\r\n```javascript\r\nfunction sandbox(code) {\r\n code = 'with (sandbox) {' + code + '}'\r\n const fn = new Function('sandbox', code)\r\n\r\n return function (sandbox) {\r\n const sandboxProxy = new Proxy(sandbox, {\r\n has(target, key) {\r\n return true\r\n },\r\n get(target, key) {\r\n if (key === Symbol.unscopables) return undefined\r\n return target[key]\r\n }\r\n })\r\n return fn(sandboxProxy)\r\n }\r\n}\r\nvar test = {\r\n a: 1,\r\n log(){\r\n console.log('11111')\r\n }\r\n}\r\nvar code = 'log();console.log(a)' // 1111,TypeError: Cannot read property 'log' of undefined\r\nsandbox(code)(test)\r\n\r\n```\r\n\r\nSymbol.unscopables 定义对象的不可作用属性。Unscopeable 属性永远不会从 with 语句中的沙箱对象中检索，而是直接从闭包或全局范围中检索。\r\n\r\n### 快照沙箱(SnapshotSandbox)\r\n\r\n以下是 qiankun 的 snapshotSandbox 的源码，这里为了帮助理解做部分精简及注释。\r\n\r\n```javascript\r\nfunction iter(obj, callbackFn) {\r\n for (const prop in obj) {\r\n if (obj.hasOwnProperty(prop)) {\r\n callbackFn(prop);\r\n }\r\n }\r\n}\r\n\r\n/**\r\n * 基于 diff 方式实现的沙箱，用于不支持 Proxy 的低版本浏览器\r\n */\r\nclass SnapshotSandbox {\r\n constructor(name) {\r\n this.name = name;\r\n this.proxy = window;\r\n this.type = 'Snapshot';\r\n this.sandboxRunning = true;\r\n this.windowSnapshot = {};\r\n this.modifyPropsMap = {};\r\n this.active();\r\n }\r\n //激活\r\n active() {\r\n // 记录当前快照\r\n this.windowSnapshot = {};\r\n iter(window, (prop) => {\r\n this.windowSnapshot[prop] = window[prop];\r\n });\r\n\r\n // 恢复之前的变更\r\n Object.keys(this.modifyPropsMap).forEach((p) => {\r\n window[p] = this.modifyPropsMap[p];\r\n });\r\n\r\n this.sandboxRunning = true;\r\n }\r\n //还原\r\n inactive() {\r\n this.modifyPropsMap = {};\r\n\r\n iter(window, (prop) => {\r\n if (window[prop] !== this.windowSnapshot[prop]) {\r\n // 记录变更，恢复环境\r\n this.modifyPropsMap[prop] = window[prop];\r\n\r\n window[prop] = this.windowSnapshot[prop];\r\n }\r\n });\r\n this.sandboxRunning = false;\r\n }\r\n}\r\nlet sandbox = new SnapshotSandbox();\r\n//test\r\n((window) => {\r\n window.name = '张三'\r\n window.age = 18\r\n console.log(window.name, window.age) //\t张三,18\r\n sandbox.inactive() //\t还原\r\n console.log(window.name, window.age) //\tundefined,undefined\r\n sandbox.active() //\t激活\r\n console.log(window.name, window.age) //\t张三,18\r\n})(sandbox.proxy);\r\n\r\n```\r\n\r\n快照沙箱实现来说比较简单，主要用于不支持 Proxy 的低版本浏览器，原理是基于`diff`来实现的,在子应用激活或者卸载时分别去通过快照的形式记录或还原状态来实现沙箱，snapshotSandbox 会污染全局 window。\r\n\r\n### legacySandBox\r\n\r\nqiankun 框架 singular 模式下 proxy 沙箱实现，为了便于理解，这里做了部分代码的精简和注释。\r\n\r\n```javascript\r\n//legacySandBox\r\nconst callableFnCacheMap = new WeakMap();\r\n\r\nfunction isCallable(fn) {\r\n if (callableFnCacheMap.has(fn)) {\r\n return true;\r\n }\r\n const naughtySafari = typeof document.all === 'function' && typeof document.all === 'undefined';\r\n const callable = naughtySafari ? typeof fn === 'function' && typeof fn !== 'undefined' : typeof fn ===\r\n 'function';\r\n if (callable) {\r\n callableFnCacheMap.set(fn, callable);\r\n }\r\n return callable;\r\n};\r\n\r\nfunction isPropConfigurable(target, prop) {\r\n const descriptor = Object.getOwnPropertyDescriptor(target, prop);\r\n return descriptor ? descriptor.configurable : true;\r\n}\r\n\r\nfunction setWindowProp(prop, value, toDelete) {\r\n if (value === undefined && toDelete) {\r\n delete window[prop];\r\n } else if (isPropConfigurable(window, prop) && typeof prop !== 'symbol') {\r\n Object.defineProperty(window, prop, {\r\n writable: true,\r\n configurable: true\r\n });\r\n window[prop] = value;\r\n }\r\n}\r\n\r\n\r\nfunction getTargetValue(target, value) {\r\n /*\r\n 仅绑定 isCallable && !isBoundedFunction && !isConstructable 的函数对象，如 window.console、window.atob 这类。目前没有完美的检测方式，这里通过 prototype 中是否还有可枚举的拓展方法的方式来判断\r\n @warning 这里不要随意替换成别的判断方式，因为可能触发一些 edge case（比如在 lodash.isFunction 在 iframe 上下文中可能由于调用了 top window 对象触发的安全异常）\r\n */\r\n if (isCallable(value) && !isBoundedFunction(value) && !isConstructable(value)) {\r\n const boundValue = Function.prototype.bind.call(value, target);\r\n for (const key in value) {\r\n boundValue[key] = value[key];\r\n }\r\n if (value.hasOwnProperty('prototype') && !boundValue.hasOwnProperty('prototype')) {\r\n Object.defineProperty(boundValue, 'prototype', {\r\n value: value.prototype,\r\n enumerable: false,\r\n writable: true\r\n });\r\n }\r\n\r\n return boundValue;\r\n }\r\n\r\n return value;\r\n}\r\n\r\n/**\r\n * 基于 Proxy 实现的沙箱\r\n */\r\nclass SingularProxySandbox {\r\n /** 沙箱期间新增的全局变量 */\r\n addedPropsMapInSandbox = new Map();\r\n\r\n /** 沙箱期间更新的全局变量 */\r\n modifiedPropsOriginalValueMapInSandbox = new Map();\r\n\r\n /** 持续记录更新的(新增和修改的)全局变量的 map，用于在任意时刻做 snapshot */\r\n currentUpdatedPropsValueMap = new Map();\r\n\r\n name;\r\n\r\n proxy;\r\n\r\n type = 'LegacyProxy';\r\n\r\n sandboxRunning = true;\r\n\r\n latestSetProp = null;\r\n\r\n active() {\r\n if (!this.sandboxRunning) {\r\n this.currentUpdatedPropsValueMap.forEach((v, p) => setWindowProp(p, v));\r\n }\r\n\r\n this.sandboxRunning = true;\r\n }\r\n\r\n inactive() {\r\n // console.log(' this.modifiedPropsOriginalValueMapInSandbox', this.modifiedPropsOriginalValueMapInSandbox)\r\n // console.log(' this.addedPropsMapInSandbox', this.addedPropsMapInSandbox)\r\n //删除添加的属性，修改已有的属性\r\n this.modifiedPropsOriginalValueMapInSandbox.forEach((v, p) => setWindowProp(p, v));\r\n this.addedPropsMapInSandbox.forEach((_, p) => setWindowProp(p, undefined, true));\r\n\r\n this.sandboxRunning = false;\r\n }\r\n\r\n constructor(name) {\r\n this.name = name;\r\n const {\r\n addedPropsMapInSandbox,\r\n modifiedPropsOriginalValueMapInSandbox,\r\n currentUpdatedPropsValueMap\r\n } = this;\r\n\r\n const rawWindow = window;\r\n //Object.create(null)的方式，传入一个不含有原型链的对象\r\n const fakeWindow = Object.create(null);\r\n\r\n const proxy = new Proxy(fakeWindow, {\r\n set: (_, p, value) => {\r\n if (this.sandboxRunning) {\r\n if (!rawWindow.hasOwnProperty(p)) {\r\n addedPropsMapInSandbox.set(p, value);\r\n } else if (!modifiedPropsOriginalValueMapInSandbox.has(p)) {\r\n // 如果当前 window 对象存在该属性，且 record map 中未记录过，则记录该属性初始值\r\n const originalValue = rawWindow[p];\r\n modifiedPropsOriginalValueMapInSandbox.set(p, originalValue);\r\n }\r\n\r\n currentUpdatedPropsValueMap.set(p, value);\r\n // 必须重新设置 window 对象保证下次 get 时能拿到已更新的数据\r\n rawWindow[p] = value;\r\n\r\n this.latestSetProp = p;\r\n\r\n return true;\r\n }\r\n\r\n // 在 strict-mode 下，Proxy 的 handler.set 返回 false 会抛出 TypeError，在沙箱卸载的情况下应该忽略错误\r\n return true;\r\n },\r\n\r\n get(_, p) {\r\n //避免使用 window.window 或者 window.self 逃离沙箱环境，触发到真实环境\r\n if (p === 'top' || p === 'parent' || p === 'window' || p === 'self') {\r\n return proxy;\r\n }\r\n const value = rawWindow[p];\r\n return getTargetValue(rawWindow, value);\r\n },\r\n\r\n has(_, p) { //返回boolean\r\n return p in rawWindow;\r\n },\r\n\r\n getOwnPropertyDescriptor(_, p) {\r\n const descriptor = Object.getOwnPropertyDescriptor(rawWindow, p);\r\n // 如果属性不作为目标对象的自身属性存在，则不能将其设置为不可配置\r\n if (descriptor && !descriptor.configurable) {\r\n descriptor.configurable = true;\r\n }\r\n return descriptor;\r\n },\r\n });\r\n\r\n this.proxy = proxy;\r\n }\r\n}\r\n\r\nlet sandbox = new SingularProxySandbox();\r\n\r\n((window) => {\r\n window.name = '张三';\r\n window.age = 18;\r\n window.sex = '男';\r\n console.log(window.name, window.age,window.sex) //\t张三,18,男\r\n sandbox.inactive() //\t还原\r\n console.log(window.name, window.age,window.sex) //\t张三,undefined,undefined\r\n sandbox.active() //\t激活\r\n console.log(window.name, window.age,window.sex) //\t张三,18,男\r\n})(sandbox.proxy); //test\r\n\r\n```\r\n\r\nlegacySandBox 还是会操作 window 对象，但是他通过激活沙箱时还原子应用的状态，卸载时还原主应用的状态来实现沙箱隔离的，同样会对 window 造成污染，但是性能比快照沙箱好，不用遍历 window 对象。\r\n\r\n### proxySandbox(多例沙箱)\r\n\r\n在 qiankun 的沙箱 proxySandbox 源码里面是对 fakeWindow 这个对象进行了代理，而这个对象是通过 createFakeWindow 方法得到的，这个方法是将 window 的 document、location、top、window 等等属性拷贝一份，给到 fakeWindow。\r\n\r\n源码展示：\r\n\r\n```javascript\r\n\r\nfunction createFakeWindow(global: Window) {\r\n // map always has the fastest performance in has check scenario\r\n // see https://jsperf.com/array-indexof-vs-set-has/23\r\n const propertiesWithGetter = new Map();\r\n const fakeWindow = {} as FakeWindow;\r\n\r\n /*\r\n copy the non-configurable property of global to fakeWindow\r\n see https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Proxy/handler/getOwnPropertyDescriptor\r\n > A property cannot be reported as non-configurable, if it does not exists as an own property of the target object or if it exists as a configurable own property of the target object.\r\n */\r\n Object.getOwnPropertyNames(global)\r\n .filter((p) => {\r\n const descriptor = Object.getOwnPropertyDescriptor(global, p);\r\n return !descriptor?.configurable;\r\n })\r\n .forEach((p) => {\r\n const descriptor = Object.getOwnPropertyDescriptor(global, p);\r\n if (descriptor) {\r\n const hasGetter = Object.prototype.hasOwnProperty.call(descriptor, 'get');\r\n\r\n /*\r\n make top/self/window property configurable and writable, otherwise it will cause TypeError while get trap return.\r\n see https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Proxy/handler/get\r\n > The value reported for a property must be the same as the value of the corresponding target object property if the target object property is a non-writable, non-configurable data property.\r\n */\r\n if (\r\n p === 'top' ||\r\n p === 'parent' ||\r\n p === 'self' ||\r\n p === 'window' ||\r\n (process.env.NODE_ENV === 'test' && (p === 'mockTop' || p === 'mockSafariTop'))\r\n ) {\r\n descriptor.configurable = true;\r\n /*\r\n The descriptor of window.window/window.top/window.self in Safari/FF are accessor descriptors, we need to avoid adding a data descriptor while it was\r\n Example:\r\n Safari/FF: Object.getOwnPropertyDescriptor(window, 'top') -> {get: function, set: undefined, enumerable: true, configurable: false}\r\n Chrome: Object.getOwnPropertyDescriptor(window, 'top') -> {value: Window, writable: false, enumerable: true, configurable: false}\r\n */\r\n if (!hasGetter) {\r\n descriptor.writable = true;\r\n }\r\n }\r\n\r\n if (hasGetter) propertiesWithGetter.set(p, true);\r\n\r\n // freeze the descriptor to avoid being modified by zone.js\r\n // see https://github.com/angular/zone.js/blob/a5fe09b0fac27ac5df1fa746042f96f05ccb6a00/lib/browser/define-property.ts#L71\r\n rawObjectDefineProperty(fakeWindow, p, Object.freeze(descriptor));\r\n }\r\n });\r\n\r\n return {\r\n fakeWindow,\r\n propertiesWithGetter,\r\n };\r\n}\r\n\r\n```\r\n\r\nproxySandbox 由于是拷贝复制了一份 fakeWindow，不会污染全局 window，同时支持多个子应用同时加载。详细源码请查看[：proxySandbox](https://link.juejin.cn?target=https%3A%2F%2Fgithub.com%2Fumijs%2Fqiankun%2Fblob%2Fmaster%2Fsrc%2Fsandbox%2FproxySandbox.ts \"https://github.com/umijs/qiankun/blob/master/src/sandbox/proxySandbox.ts\")\r\n\r\n### 关于 CSS 隔离\r\n\r\n常见的有：\r\n\r\n* CSS Module\r\n* namespace\r\n* Dynamic StyleSheet\r\n* css in js\r\n* Shadow DOM 常见的我们这边不再赘述，这里我们重点提一下Shadow DO。\r\n\r\n### Shadow DOM\r\n\r\nShadow DOM 允许将隐藏的 DOM 树附加到常规的 DOM 树中——它以 shadow root 节点为起始根节点，在这个根节点的下方，可以是任意元素，和普通的 DOM 元素一样。\r\n",{"_58":600,"_181":152,"_182":152,"_183":152,"_184":152,"_185":152,"_186":152,"_187":152,"_188":152,"_189":152},"https://api.github.com/repos/pro-collection/interview-question/issues/145/reactions","https://api.github.com/repos/pro-collection/interview-question/issues/145/timeline",{"_58":603,"_60":61,"_62":604,"_64":605,"_66":606,"_68":607,"_70":608,"_72":609,"_74":610,"_76":611,"_78":612,"_111":613,"_131":132,"_133":24,"_134":-5,"_135":615,"_137":616,"_159":195,"_153":618,"_155":619,"_158":-5,"_162":163,"_106":-5,"_164":-5,"_165":620,"_170":621,"_176":622,"_178":623,"_190":625,"_192":-5,"_193":-5,"_194":195},"https://api.github.com/repos/pro-collection/interview-question/issues/141","https://api.github.com/repos/pro-collection/interview-question/issues/141/labels{/name}","https://api.github.com/repos/pro-collection/interview-question/issues/141/comments","https://api.github.com/repos/pro-collection/interview-question/issues/141/events","https://github.com/pro-collection/interview-question/issues/141",1634270758,"I_kwDOJGDC6c5haP4m",141,"如何组织 monorepo 工程？",{"_80":81,"_70":82,"_72":83,"_84":85,"_86":28,"_58":87,"_68":88,"_89":90,"_91":92,"_93":94,"_95":96,"_97":98,"_99":100,"_101":102,"_66":103,"_104":105,"_106":107,"_108":109,"_110":24},[614],{"_70":114,"_72":115,"_58":116,"_117":118,"_119":120,"_121":24,"_122":123},[],{"_58":236,"_68":237,"_62":238,"_70":239,"_72":240,"_74":241,"_76":242,"_122":243,"_147":617,"_149":245,"_151":152,"_131":132,"_153":246,"_155":247,"_157":-5,"_158":-5},{"_80":81,"_70":82,"_72":83,"_84":85,"_86":28,"_58":87,"_68":88,"_89":90,"_91":92,"_93":94,"_95":96,"_97":98,"_99":100,"_101":102,"_66":103,"_104":105,"_106":107,"_108":109,"_110":24},"2023-03-21T16:16:01Z","2023-03-29T08:24:59Z",{"_167":152,"_168":152,"_169":152},{"_172":152,"_173":152,"_174":152,"_175":152},"参考文档： \n- [pnpm + workspace + changesets 构建你的 monorepo 工程](https://juejin.cn/post/7098609682519949325)\n- [现代 Monorepo 工程技术选型，聊聊我的思考](https://juejin.cn/post/7102452341210611720)\n- [前端工程化之多个项目如何同时高效管理 — monorepo](https://juejin.cn/post/6985336835459252260)\n",{"_58":624,"_181":152,"_182":152,"_183":152,"_184":152,"_185":152,"_186":152,"_187":152,"_188":152,"_189":152},"https://api.github.com/repos/pro-collection/interview-question/issues/141/reactions","https://api.github.com/repos/pro-collection/interview-question/issues/141/timeline",{"_58":627,"_60":61,"_62":628,"_64":629,"_66":630,"_68":631,"_70":632,"_72":633,"_74":634,"_76":635,"_78":636,"_111":637,"_131":132,"_133":24,"_134":-5,"_135":639,"_137":640,"_159":195,"_153":642,"_155":643,"_158":-5,"_162":163,"_106":-5,"_164":-5,"_165":644,"_170":645,"_176":646,"_178":647,"_190":649,"_192":-5,"_193":-5,"_194":195},"https://api.github.com/repos/pro-collection/interview-question/issues/140","https://api.github.com/repos/pro-collection/interview-question/issues/140/labels{/name}","https://api.github.com/repos/pro-collection/interview-question/issues/140/comments","https://api.github.com/repos/pro-collection/interview-question/issues/140/events","https://github.com/pro-collection/interview-question/issues/140",1634236600,"I_kwDOJGDC6c5haHi4",140,"pnpm 了解多少？",{"_80":81,"_70":82,"_72":83,"_84":85,"_86":28,"_58":87,"_68":88,"_89":90,"_91":92,"_93":94,"_95":96,"_97":98,"_99":100,"_101":102,"_66":103,"_104":105,"_106":107,"_108":109,"_110":24},[638],{"_70":114,"_72":115,"_58":116,"_117":118,"_119":120,"_121":24,"_122":123},[],{"_58":236,"_68":237,"_62":238,"_70":239,"_72":240,"_74":241,"_76":242,"_122":243,"_147":641,"_149":245,"_151":152,"_131":132,"_153":246,"_155":247,"_157":-5,"_158":-5},{"_80":81,"_70":82,"_72":83,"_84":85,"_86":28,"_58":87,"_68":88,"_89":90,"_91":92,"_93":94,"_95":96,"_97":98,"_99":100,"_101":102,"_66":103,"_104":105,"_106":107,"_108":109,"_110":24},"2023-03-21T16:03:46Z","2023-03-21T16:07:02Z",{"_167":152,"_168":152,"_169":152},{"_172":152,"_173":152,"_174":152,"_175":152},"pnpm，英文里面的意思叫做 `performant npm` ，意味“高性能的 npm”，官网地址可以参考 [pnpm.io/。](https://link.juejin.cn?target=https%3A%2F%2Fpnpm.io%2F%25E3%2580%2582 \"https://pnpm.io/%E3%80%82\")\r\n\r\npnpm 相比较于 yarn/npm 这两个常用的包管理工具在性能上也有了极大的提升，根据目前官方提供的 [benchmark](https://link.juejin.cn?target=https%3A%2F%2Fpnpm.io%2Fbenchmarks \"https://pnpm.io/benchmarks\") 数据可以看出在一些综合场景下比 npm/yarn 快了大概两倍：\r\n\r\n![](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/aa38fc979f4f4ed6a5ec4af64a73c34e~tplv-k3u1fbpfcp-zoom-in-crop-mark:4536:0:0:0.awebp)\r\n\r\n在这篇文章中，将会介绍一些关于 pnpm 在依赖管理方面的优化，在 monorepo 中相比较于 yarn workspace 的应用，以及也会介绍一些 pnpm 目前存在的一些缺陷，包括讨论一下未来 pnpm 会做的一些事情。\r\n\r\n### 依赖管理\r\n\r\n这节会通过 pnpm 在依赖管理这一块的一些不同于正常包管理工具的一些优化技巧。\r\n\r\n#### hard link 机制\r\n\r\n介绍 pnpm 一定离不开的就是关于 pnpm 在安装依赖方面做的一些优化，根据前面的 benchmark 图可以看到其明显的性能提升。\r\n\r\n那么 pnpm 是怎么做到如此大的提升的呢？是因为计算机里面一个叫做 **[Hard link](https://link.juejin.cn?target=https%3A%2F%2Fen.wikipedia.org%2Fwiki%2FHard_link \"https://en.wikipedia.org/wiki/Hard_link\")** 的机制，`hard link` 使得用户可以通过不同的路径引用方式去找到某个文件。pnpm 会在全局的 store 目录里存储项目 `node_modules` 文件的 `hard links` 。\r\n\r\n举个例子，例如项目里面有个 1MB 的依赖 a，在 pnpm 中，看上去这个 a 依赖同时占用了 1MB 的 node\\_modules 目录以及全局 store 目录 1MB 的空间(加起来是 2MB)，但因为 `hard link` 的机制使得两个目录下相同的 1MB 空间能从两个不同位置进行寻址，因此实际上这个 a 依赖只用占用 1MB 的空间，而不是 2MB。\r\n\r\n#### Store 目录\r\n\r\n上一节提到 store 目录用于存储依赖的 hard links，这一节简单介绍一下这个 store 目录。\r\n\r\n一般 store 目录默认是设置在 `${os.homedir}/.pnpm-store` 这个目录下，具体可以参考 `@pnpm/store-path` 这个 pnpm 子包中的代码:\r\n\r\n```js\r\nconst homedir = os.homedir()\r\nif (await canLinkToSubdir(tempFile, homedir)) {\r\n await fs.unlink(tempFile)\r\n // If the project is on the drive on which the OS home directory\r\n // then the store is placed in the home directory\r\n return path.join(homedir, relStore, STORE_VERSION)\r\n}\r\n\r\n```\r\n\r\n当然用户也可以在 `.npmrc` 设置这个 store 目录位置，不过一般而言 store 目录对于用户来说感知程度是比较小的。\r\n\r\n因为这样一个机制，导致每次安装依赖的时候，如果是个相同的依赖，有好多项目都用到这个依赖，那么这个依赖实际上最优情况(即版本相同)只用安装一次。\r\n\r\n如果是 npm 或 yarn，那么这个依赖在多个项目中使用，在每次安装的时候都会被重新下载一次。\r\n\r\n![03](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/9ba60f4713bc46318ee139d3b8a9bc82~tplv-k3u1fbpfcp-zoom-in-crop-mark:4536:0:0:0.awebp)\r\n\r\n如图可以看到在使用 pnpm 对项目安装依赖的时候，如果某个依赖在 sotre 目录中存在了话，那么就会直接从 store 目录里面去 hard-link，避免了二次安装带来的时间消耗，如果依赖在 store 目录里面不存在的话，就会去下载一次。\r\n\r\n当然这里你可能也会有问题：如果安装了很多很多不同的依赖，那么 store 目录会不会越来越大？\r\n\r\n答案是当然会存在，针对这个问题，pnpm 提供了一个命令来解决这个问题: [pnpm store | pnpm](https://link.juejin.cn?target=https%3A%2F%2Fpnpm.io%2Fcli%2Fstore \"https://pnpm.io/cli/store\")。\r\n\r\n同时该命令提供了一个选项，使用方法为 `pnpm store prune` ，它提供了一种用于删除一些不被全局项目所引用到的 packages 的功能，例如有个包 `axios@1.0.0` 被一个项目所引用了，但是某次修改使得项目里这个包被更新到了 `1.0.1` ，那么 store 里面的 1.0.0 的 axios 就就成了个不被引用的包，执行 `pnpm store prune` 就可以在 store 里面删掉它了。\r\n\r\n该命令推荐偶尔进行使用，但不要频繁使用，因为可能某天这个不被引用的包又突然被哪个项目引用了，这样就可以不用再去重新下载这个包了。\r\n\r\n#### node\\_modules 结构\r\n\r\n在 pnpm 官网有一篇很经典的文章，关于介绍 pnpm 项目的 node\\_modules 结构: [Flat node\\_modules is not the only way | pnpm](https://link.juejin.cn?target=https%3A%2F%2Fpnpm.io%2Fblog%2F2020%2F05%2F27%2Fflat-node-modules-is-not-the-only-way \"https://pnpm.io/blog/2020/05/27/flat-node-modules-is-not-the-only-way\")。\r\n\r\n在这篇文章中介绍了 pnpm 目前的 node\\_modules 的一些文件结构，例如在项目中使用 pnpm 安装了一个叫做 `express` 的依赖，那么最后会在 node\\_modules 中形成这样两个目录结构:\r\n\r\n```bash\r\nnode_modules/express/...\r\nnode_modules/.pnpm/express@4.17.1/node_modules/xxx\r\n\r\n```\r\n\r\n其中第一个路径是 nodejs 正常寻找路径会去找的一个目录，如果去查看这个目录下的内容，会发现里面连个 `node_modules` 文件都没有：\r\n\r\n```bash\r\n▾ express\r\n ▸ lib\r\n History.md\r\n index.js\r\n LICENSE\r\n package.json\r\n Readme.md\r\n\r\n```\r\n\r\n实际上这个文件只是个软连接，它会形成一个到第二个目录的一个软连接(类似于软件的快捷方式)，这样 node 在找路径的时候，最终会找到 .pnpm 这个目录下的内容。\r\n\r\n其中这个 `.pnpm` 是个虚拟磁盘目录，然后 express 这个依赖的一些依赖会被平铺到 `.pnpm/express@4.17.1/node_modules/` 这个目录下面，这样保证了依赖能够 require 到，同时也不会形成很深的依赖层级。\r\n\r\n在保证了 nodejs 能找到依赖路径的基础上，同时也很大程度上保证了依赖能很好的被放在一起。\r\n\r\n`pnpm` 对于不同版本的依赖有着极其严格的区分要求，如果项目中某个依赖实际上依赖的 `peerDeps` 出现了具体版本上的不同，对于这样的依赖会在虚拟磁盘目录 `.pnpm` 有一个比较严格的区分，具体可以参考: [pnpm.io/how-peers-a…](https://link.juejin.cn?target=https%3A%2F%2Fpnpm.io%2Fhow-peers-are-resolved \"https://pnpm.io/how-peers-are-resolved\") 这篇文章。\r\n\r\n综合而言，本质上 pnpm 的 `node_modules` 结构是个网状 + 平铺的目录结构。这种依赖结构主要基于软连接(即 symlink)的方式来完成。\r\n\r\n#### symlink 和 hard link 机制\r\n\r\n在前面知道了 pnpm 是通过 hardlink 在全局里面搞个 store 目录来存储 node\\_modules 依赖里面的 hard link 地址，然后在引用依赖的时候则是通过 symlink 去找到对应虚拟磁盘目录下(.pnpm 目录)的依赖地址。\r\n\r\n这两者结合在一起工作之后，假如有一个项目依赖了 `bar@1.0.0` 和 `foo@1.0.0` ，那么最后的 node\\_modules 结构呈现出来的依赖结构可能会是这样的:\r\n\r\n```bash\r\nnode_modules\r\n└── bar // symlink to .pnpm/bar@1.0.0/node_modules/bar\r\n└── foo // symlink to .pnpm/foo@1.0.0/node_modules/foo\r\n└── .pnpm\r\n ├── bar@1.0.0\r\n │ └── node_modules\r\n │ └── bar -> /bar\r\n │ ├── index.js\r\n │ └── package.json\r\n └── foo@1.0.0\r\n └── node_modules\r\n └── foo -> /foo\r\n ├── index.js\r\n └── package.json\r\n\r\n```\r\n\r\n`node_modules` 中的 bar 和 foo 两个目录会软连接到 .pnpm 这个目录下的真实依赖中，而这些真实依赖则是通过 hard link 存储到全局的 store 目录中。\r\n\r\n#### 兼容问题\r\n\r\n读到这里，可能有用户会好奇: 像 hard link 和 symlink 这种方式在所有的系统上都是兼容的吗？\r\n\r\n实际上 hard link 在主流系统上(`Unix/Win`)使用都是没有问题的，但是 symlink 即软连接的方式可能会在 windows 存在一些兼容的问题，但是针对这个问题，pnpm 也提供了对应的解决方案：\r\n\r\n在 win 系统上使用一个叫做 [junctions](https://link.juejin.cn?target=https%3A%2F%2Fdocs.microsoft.com%2Fen-us%2Fwindows%2Fwin32%2Ffileio%2Fhard-links-and-junctions \"https://docs.microsoft.com/en-us/windows/win32/fileio/hard-links-and-junctions\") 的特性来替代软连接，这个方案在 win 上的兼容性要好于 symlink。\r\n\r\n或许你也会好奇为啥 pnpm 要使用 hard links 而不是全都用 symlink 来去实现。\r\n\r\n实际上存在 store 目录里面的依赖也是可以通过软连接去找到的，nodejs 本身有提供一个叫做 `--preserve-symlinks` 的参数来支持 symlink，但实际上这个参数实际上对于 symlink 的支持并不好导致作者放弃了该方案从而采用 hard links 的方式:\r\n\r\n![](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/90ad9850716547d08bfbfea212d6d653~tplv-k3u1fbpfcp-zoom-in-crop-mark:4536:0:0:0.awebp)\r\n\r\n具体可以参考 [github.com/nodejs/node…](https://link.juejin.cn?target=https%3A%2F%2Fgithub.com%2Fnodejs%2Fnode-eps%2Fissues%2F46 \"https://github.com/nodejs/node-eps/issues/46\") 该issue 讨论。\r\n\r\n### Monorepo 支持\r\n\r\n`pnpm` 在 monorepo 场景可以说算得上是个完美的解决方案了，因为其本身的设计机制，导致很多关键或者说致命的问题都得到了相当有效的解决。\r\n\r\n#### workspace 支持\r\n\r\n对于 monorepo 类型的项目，pnpm 提供了 workspace 来支持，具体可以参考官网文档: [pnpm.io/workspaces/…](https://link.juejin.cn?target=https%3A%2F%2Fpnpm.io%2Fworkspaces%2F%25E3%2580%2582 \"https://pnpm.io/workspaces/%E3%80%82\")\r\n\r\n### 痛点解决\r\n\r\nMonorepo 下被人诟病较多的问题，一般是依赖结构问题。常见的两个问题就是 `Phantom dependencies` 和 `NPM doppelgangers`，用 [rush 官网](https://link.juejin.cn?target=https%3A%2F%2Frushjs.io%2F \"https://rushjs.io/\") 的图片可以很贴切的展示着两个问题:\r\n\r\n![](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/977bd60346d04cc8a4565e3e398bd962~tplv-k3u1fbpfcp-zoom-in-crop-mark:4536:0:0:0.awebp)\r\n\r\n下面会针对两个问题一一介绍。\r\n\r\n#### Phantom dependencies\r\n\r\nPhantom dependencies 被称之为幽灵依赖，解释起来很简单，即某个包没有被安装(`package.json` 中并没有，但是用户却能够引用到这个包)。\r\n\r\n引发这个现象的原因一般是因为 node\\_modules 结构所导致的，例如使用 yarn 对项目安装依赖，依赖里面有个依赖叫做 foo，foo 这个依赖同时依赖了 bar，yarn 会对安装的 node\\_modules 做一个扁平化结构的处理(npm v3 之后也是这么做的)，会把依赖在 node\\_modules 下打平，这样相当于 foo 和 bar 出现在同一层级下面。那么根据 nodejs 的寻径原理，用户能 require 到 foo，同样也能 require 到 bar。\r\n\r\n```bash\r\npackage.json -> foo(bar 为 foo 依赖)\r\n\r\nnode_modules\r\n\r\n /foo\r\n\r\n /bar -> 👻依赖\r\n\r\n```\r\n\r\n那么这里这个 bar 就成了一个幽灵依赖，如果某天某个版本的 foo 依赖不再依赖 bar 或者 foo 的版本发生了变化，那么 require bar 的模块部分就会抛错。\r\n\r\n以上其实只是一个简单的例子，但是根据笔者在字节内部见到的一些 monorepo(主要为 `lerna + yarn` )项目中，这其实是个比较常见的现象，甚至有些包会直接去利用这种残缺的引入方式去减轻包体积。\r\n\r\n还有一种场景就是在 lerna + yarn workspace 的项目里面，因为 yarn 中提供了 hoist 机制(即一些底层子项目的依赖会被提升到顶层的 `node_modules` 中)，这种 phantom dependencies 会更多，一些底层的子项目经常会去 require 一些在自己里面没有引入的依赖，而直接去找顶层 node\\_modules 的依赖(nodejs 这里的寻径是个递归上下的过程)并使用。\r\n\r\n而根据前面提到的 pnpm 的 `node_modules` 依赖结构，这种现象是显然不会发生的，因为被打平的依赖会被放到 `.pnpm` 这个虚拟磁盘目录下面去，用户通过 require 是根本找不到的。\r\n\r\n> 值得一提的是，pnpm 本身其实也提供了将依赖提升并且按照 yarn 那种形式组织的 node\\_modules 结构的 Option，作者将其命名为 `--shamefully-hoist` ，即 \"羞耻的 hoist\".....\r\n\r\n#### NPM doppelgangers\r\n\r\n这个问题其实也可以说是 hoist 导致的，这个问题可能会导致有大量的依赖的被重复安装，举个例子:\r\n\r\n例如有个 package，下面依赖有 lib\\_a、lib\\_b、lib\\_c、lib\\_d，其中 a 和 b 依赖 [util\\_e@1.0.0](https://link.juejin.cn?target=mailto%3Autil_e%401.0.0 \"mailto:util_e@1.0.0\")，而 c 和 d 依赖 [util\\_e@2.0.0](https://link.juejin.cn?target=mailto%3Autil_e%402.0.0 \"mailto:util_e@2.0.0\")。\r\n\r\n那么早期 npm 的依赖结构应该是这样的:\r\n\r\n```bash\r\n- package\r\n- package.json\r\n- node_modules\r\n- lib_a\r\n - node_modules <- util_e@1.0.0\r\n- lib_b\r\n - node_modules <- util_e@1.0.0\r\n_ lib_c\r\n - node_modules <- util_e@2.0.0\r\n- lib_d\r\n - node_modules <- util_e@2.0.0\r\n\r\n```\r\n\r\n这样必然会导致很多依赖被重复安装，于是就有了 hoist 和打平依赖的操作:\r\n\r\n```bash\r\n- package\r\n- package.json\r\n- node_modules\r\n- util_e@1.0.0\r\n- lib_a\r\n- lib_b\r\n_ lib_c\r\n - node_modules <- util_e@2.0.0\r\n- lib_d\r\n - node_modules <- util_e@2.0.0\r\n\r\n```\r\n\r\n但是这样也只能提升一个依赖，如果两个依赖都提升了会导致冲突，这样同样会导致一些不同版本的依赖被重复安装多次，这里就会导致使用 npm 和 yarn 的性能损失。\r\n\r\n如果是 pnpm 的话，这里因为依赖始终都是存在 store 目录下的 hard links ，一份不同的依赖始终都只会被安装一次，因此这个是能够被彻彻底底的消除的。\r\n\r\n### 目前不适用的场景\r\n\r\n前面有提到关于 pnpm 的主要问题在于 symlink(软链接)在一些场景下会存在兼容的问题，可以参考作者在 nodejs 那边开的一个 discussion：[github.com/nodejs/node…](https://link.juejin.cn?target=https%3A%2F%2Fgithub.com%2Fnodejs%2Fnode%2Fdiscussions%2F37509 \"https://github.com/nodejs/node/discussions/37509\")\r\n\r\n![](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/2fb3e4b6b5ef43dc9e8437389d2cb46e~tplv-k3u1fbpfcp-zoom-in-crop-mark:4536:0:0:0.awebp)\r\n\r\n在里面作者提到了目前 nodejs 软连接不能适用的一些场景，希望 nodejs 能提供一种 link 方式而不是使用软连接，同时也提到了 pnpm 目前因为软连接而不能使用的场景:\r\n\r\n* Electron 应用无法使用 pnpm\r\n* 部署在 [lambda](https://link.juejin.cn?target=https%3A%2F%2Fdocs.aws.amazon.com%2Flambda%2Flatest%2Fdg%2Fgettingstarted-package.html \"https://docs.aws.amazon.com/lambda/latest/dg/gettingstarted-package.html\") 上的应用无法使用 pnpm\r\n\r\n笔者在字节内部使用 pnpm 时也遇到过一些 nodejs 基础库不支持 symlink 的情况导致使用 pnpm 无法正常工作，不过这些库在迭代更新之后也会支持这一特性。\r\n\r\n![](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/b702b38ff6704651976c4c3eab540566~tplv-k3u1fbpfcp-zoom-in-crop-mark:4536:0:0:0.awebp)\r\n",{"_58":648,"_181":152,"_182":152,"_183":152,"_184":152,"_185":152,"_186":152,"_187":152,"_188":152,"_189":152},"https://api.github.com/repos/pro-collection/interview-question/issues/140/reactions","https://api.github.com/repos/pro-collection/interview-question/issues/140/timeline",{"_58":651,"_60":61,"_62":652,"_64":653,"_66":654,"_68":655,"_70":656,"_72":657,"_74":658,"_76":659,"_78":660,"_111":661,"_131":132,"_133":24,"_134":-5,"_135":663,"_137":664,"_159":152,"_153":666,"_155":667,"_158":-5,"_162":163,"_106":-5,"_164":-5,"_165":668,"_170":669,"_176":670,"_178":671,"_190":673,"_192":-5,"_193":-5,"_194":195},"https://api.github.com/repos/pro-collection/interview-question/issues/139","https://api.github.com/repos/pro-collection/interview-question/issues/139/labels{/name}","https://api.github.com/repos/pro-collection/interview-question/issues/139/comments","https://api.github.com/repos/pro-collection/interview-question/issues/139/events","https://github.com/pro-collection/interview-question/issues/139",1634219700,"I_kwDOJGDC6c5haDa0",139,"pnpm 和 npm 的区别？",{"_80":81,"_70":82,"_72":83,"_84":85,"_86":28,"_58":87,"_68":88,"_89":90,"_91":92,"_93":94,"_95":96,"_97":98,"_99":100,"_101":102,"_66":103,"_104":105,"_106":107,"_108":109,"_110":24},[662],{"_70":114,"_72":115,"_58":116,"_117":118,"_119":120,"_121":24,"_122":123},[],{"_58":305,"_68":306,"_62":307,"_70":308,"_72":309,"_74":212,"_76":310,"_122":311,"_147":665,"_149":313,"_151":152,"_131":132,"_153":314,"_155":315,"_157":-5,"_158":-5},{"_80":81,"_70":82,"_72":83,"_84":85,"_86":28,"_58":87,"_68":88,"_89":90,"_91":92,"_93":94,"_95":96,"_97":98,"_99":100,"_101":102,"_66":103,"_104":105,"_106":107,"_108":109,"_110":24},"2023-03-21T15:56:45Z","2023-03-21T15:57:18Z",{"_167":152,"_168":152,"_169":152},{"_172":152,"_173":152,"_174":152,"_175":152},"`pnpm` 和 `npm` 是两个不同的 JavaScript 包管理工具，它们有以下区别：\n\n1. **包的存储方式：**`npm` 将每个包都下载到项目的 `node_modules` 目录中，而 `pnpm` 会在全局安装一个存储库，并在项目中创建一个符号链接到该存储库中的每个包。\n\n2. **空间占用：** 由于 `pnpm` 使用符号链接，它的空间占用通常比 `npm` 小，因为它避免了在多个项目中重复存储相同的依赖项。\n\n3. **安装速度：** 由于 `pnpm` 在全局安装中共享依赖项，因此安装速度通常比 `npm` 更快。\n\n4. **命令行接口：**`pnpm` 的命令行接口与 `npm` 不同，但它们都提供了一组相似的命令来管理包。\n\n5. **兼容性：** 由于 `pnpm` 的存储方式不同于 `npm`，因此某些与 `npm` 兼容的工具可能无法与 `pnpm` 一起使用。\n\n总的来说，`pnpm` 与 `npm` 相比具有更小的空间占用和更快的安装速度，但由于其不同的存储方式可能会导致与某些工具的不兼容。",{"_58":672,"_181":152,"_182":152,"_183":152,"_184":152,"_185":152,"_186":152,"_187":152,"_188":152,"_189":152},"https://api.github.com/repos/pro-collection/interview-question/issues/139/reactions","https://api.github.com/repos/pro-collection/interview-question/issues/139/timeline",{"_58":675,"_60":61,"_62":676,"_64":677,"_66":678,"_68":679,"_70":680,"_72":681,"_74":682,"_76":683,"_78":684,"_111":685,"_131":132,"_133":24,"_134":-5,"_135":687,"_137":688,"_159":152,"_153":690,"_155":691,"_158":-5,"_162":163,"_106":-5,"_164":-5,"_165":692,"_170":693,"_176":694,"_178":695,"_190":697,"_192":-5,"_193":-5,"_194":195},"https://api.github.com/repos/pro-collection/interview-question/issues/137","https://api.github.com/repos/pro-collection/interview-question/issues/137/labels{/name}","https://api.github.com/repos/pro-collection/interview-question/issues/137/comments","https://api.github.com/repos/pro-collection/interview-question/issues/137/events","https://github.com/pro-collection/interview-question/issues/137",1632412157,"I_kwDOJGDC6c5hTKH9",137,"【性能】以用户为中心的前端性能指标有哪些？",{"_80":81,"_70":82,"_72":83,"_84":85,"_86":28,"_58":87,"_68":88,"_89":90,"_91":92,"_93":94,"_95":96,"_97":98,"_99":100,"_101":102,"_66":103,"_104":105,"_106":107,"_108":109,"_110":24},[686],{"_70":114,"_72":115,"_58":116,"_117":118,"_119":120,"_121":24,"_122":123},[],{"_58":236,"_68":237,"_62":238,"_70":239,"_72":240,"_74":241,"_76":242,"_122":243,"_147":689,"_149":245,"_151":152,"_131":132,"_153":246,"_155":247,"_157":-5,"_158":-5},{"_80":81,"_70":82,"_72":83,"_84":85,"_86":28,"_58":87,"_68":88,"_89":90,"_91":92,"_93":94,"_95":96,"_97":98,"_99":100,"_101":102,"_66":103,"_104":105,"_106":107,"_108":109,"_110":24},"2023-03-20T15:59:33Z","2023-03-23T16:26:43Z",{"_167":152,"_168":152,"_169":152},{"_172":152,"_173":152,"_174":152,"_175":152},"- [以用户为中心的前端性能指标「译」](https://www.jianshu.com/p/456e6eff59c8)\n",{"_58":696,"_181":152,"_182":152,"_183":152,"_184":152,"_185":152,"_186":152,"_187":152,"_188":152,"_189":152},"https://api.github.com/repos/pro-collection/interview-question/issues/137/reactions","https://api.github.com/repos/pro-collection/interview-question/issues/137/timeline",{"_58":699,"_60":61,"_62":700,"_64":701,"_66":702,"_68":703,"_70":704,"_72":705,"_74":706,"_76":707,"_78":708,"_111":709,"_131":132,"_133":24,"_134":-5,"_135":711,"_137":712,"_159":152,"_153":714,"_155":715,"_158":-5,"_162":163,"_106":-5,"_164":-5,"_165":716,"_170":717,"_176":718,"_178":719,"_190":721,"_192":-5,"_193":-5,"_194":195},"https://api.github.com/repos/pro-collection/interview-question/issues/136","https://api.github.com/repos/pro-collection/interview-question/issues/136/labels{/name}","https://api.github.com/repos/pro-collection/interview-question/issues/136/comments","https://api.github.com/repos/pro-collection/interview-question/issues/136/events","https://github.com/pro-collection/interview-question/issues/136",1630982494,"I_kwDOJGDC6c5hNtFe",136,"如何分析页面加载慢？",{"_80":81,"_70":82,"_72":83,"_84":85,"_86":28,"_58":87,"_68":88,"_89":90,"_91":92,"_93":94,"_95":96,"_97":98,"_99":100,"_101":102,"_66":103,"_104":105,"_106":107,"_108":109,"_110":24},[710],{"_70":114,"_72":115,"_58":116,"_117":118,"_119":120,"_121":24,"_122":123},[],{"_58":236,"_68":237,"_62":238,"_70":239,"_72":240,"_74":241,"_76":242,"_122":243,"_147":713,"_149":245,"_151":152,"_131":132,"_153":246,"_155":247,"_157":-5,"_158":-5},{"_80":81,"_70":82,"_72":83,"_84":85,"_86":28,"_58":87,"_68":88,"_89":90,"_91":92,"_93":94,"_95":96,"_97":98,"_99":100,"_101":102,"_66":103,"_104":105,"_106":107,"_108":109,"_110":24},"2023-03-19T15:11:12Z","2023-03-19T15:11:13Z",{"_167":152,"_168":152,"_169":152},{"_172":152,"_173":152,"_174":152,"_175":152},"- [如何分析页面加载慢](https://www.jianshu.com/p/24b93b13e5a9)\n",{"_58":720,"_181":152,"_182":152,"_183":152,"_184":152,"_185":152,"_186":152,"_187":152,"_188":152,"_189":152},"https://api.github.com/repos/pro-collection/interview-question/issues/136/reactions","https://api.github.com/repos/pro-collection/interview-question/issues/136/timeline","pagination",{"_724":725,"_167":725},"value",6,"actionData","errors"]