[{"_1":2,"_1001":-5,"_1002":-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,"_997":998},"questions",[57,189,213,243,266,289,323,346,369,392,415,451,481,510,535,560,584,609,633,669,694,719,744,768,793,822,847,876,901,925,949,973],{"_58":59,"_60":61,"_62":63,"_64":65,"_66":67,"_68":69,"_70":71,"_72":73,"_74":75,"_76":77,"_78":79,"_111":112,"_124":125,"_126":24,"_127":-5,"_128":129,"_130":131,"_152":145,"_146":153,"_148":154,"_151":-5,"_155":156,"_106":-5,"_157":-5,"_158":159,"_163":164,"_169":170,"_171":172,"_183":184,"_185":-5,"_186":-5,"_187":188},"url","https://api.github.com/repos/pro-collection/interview-question/issues/1071","repository_url","https://api.github.com/repos/pro-collection/interview-question","labels_url","https://api.github.com/repos/pro-collection/interview-question/issues/1071/labels{/name}","comments_url","https://api.github.com/repos/pro-collection/interview-question/issues/1071/comments","events_url","https://api.github.com/repos/pro-collection/interview-question/issues/1071/events","html_url","https://github.com/pro-collection/interview-question/issues/1071","id",2685189427,"node_id","I_kwDOJGDC6c6gDL0z","number",1071,"title","Webpack 与 Vite 在产物结果上有何区别【热度: 420】","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],{"_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 项目工程化","state","open","locked","assignee","assignees",[],"milestone",{"_58":132,"_68":133,"_62":134,"_70":135,"_72":136,"_74":137,"_76":138,"_122":139,"_140":141,"_142":143,"_144":145,"_124":125,"_146":147,"_148":149,"_150":-5,"_151":-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,"高","高级别面试问题","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",454,"closed_issues",0,"created_at","2023-03-06T15:00:27Z","updated_at","2025-09-07T06:21:17Z","due_on","closed_at","comments","2024-11-23T03:02:02Z","2024-11-23T03:02:03Z","author_association","MEMBER","active_lock_reason","sub_issues_summary",{"_160":145,"_161":145,"_162":145},"total","completed","percent_completed","issue_dependencies_summary",{"_165":145,"_166":145,"_167":145,"_168":145},"blocked_by","total_blocked_by","blocking","total_blocking","body","**关键词**：Webpack 与 Vite 产物差异\n\n1. **模块格式和加载方式**\n\n - **Webpack**：\n - 在产物中，Webpack 通常会将多个模块打包成一个或多个 bundle 文件。这些 bundle 文件的格式可以是多种形式，如 CommonJS（在 Node.js 环境下常用）或者 IIFE（立即调用函数表达式，用于浏览器环境）。对于浏览器环境，Webpack 会将所有的 JavaScript 模块打包成一个或几个大的文件，并且通过自定义的加载逻辑来加载模块。例如，在一个简单的 Webpack 打包后的 JavaScript 文件中，可能会看到类似`__webpack_require__`这样的函数来实现模块的加载和解析。\n - 这种打包方式会把所有的模块依赖关系都内建在 bundle 文件中，使得浏览器在加载时只需要加载一个或几个文件即可。但如果应用规模较大，bundle 文件可能会变得非常大，导致首次加载时间过长。为了解决这个问题，Webpack 也支持代码分割（Code Splitting），通过动态`import`等方式将代码分割成多个较小的块，在需要的时候再加载。\n - **Vite**：\n - Vite 在产物中更倾向于保留原生 ES 模块（ESM）的格式。在开发阶段，Vite 利用浏览器对 ES 模块的原生支持来加载模块，而在生产阶段，它也会尽量保持这种格式。这意味着浏览器可以利用原生的`\n \n\n```\n\n- 当浏览器加载这个文件时，模块加载函数会开始执行，根据需要动态地加载和执行各个模块。\n",{"_58":413,"_174":145,"_175":145,"_176":145,"_177":145,"_178":145,"_179":145,"_180":145,"_181":145,"_182":145},"https://api.github.com/repos/pro-collection/interview-question/issues/1009/reactions","https://api.github.com/repos/pro-collection/interview-question/issues/1009/timeline",{"_58":416,"_60":61,"_62":417,"_64":418,"_66":419,"_68":420,"_70":421,"_72":422,"_74":423,"_76":424,"_78":425,"_111":426,"_124":125,"_126":24,"_127":-5,"_128":440,"_130":441,"_152":145,"_146":443,"_148":444,"_151":-5,"_155":156,"_106":-5,"_157":-5,"_158":445,"_163":446,"_169":447,"_171":448,"_183":450,"_185":-5,"_186":-5,"_187":188},"https://api.github.com/repos/pro-collection/interview-question/issues/991","https://api.github.com/repos/pro-collection/interview-question/issues/991/labels{/name}","https://api.github.com/repos/pro-collection/interview-question/issues/991/comments","https://api.github.com/repos/pro-collection/interview-question/issues/991/events","https://github.com/pro-collection/interview-question/issues/991",2583573078,"I_kwDOJGDC6c6Z_jJW",991,"部署一个 node 应用要考虑哪些因素【热度: 98】",{"_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},[427,434,435],{"_70":428,"_72":429,"_58":430,"_117":431,"_119":432,"_121":24,"_122":433},5232525911,"LA_kwDOJGDC6c8AAAABN-ICVw","https://api.github.com/repos/pro-collection/interview-question/labels/Nodejs","Nodejs","AC3F88","Nodejs 研究",{"_70":114,"_72":115,"_58":116,"_117":118,"_119":120,"_121":24,"_122":123},{"_70":436,"_72":437,"_58":438,"_117":439,"_119":231,"_121":24,"_122":232},5312726360,"LA_kwDOJGDC6c8AAAABPKnFWA","https://api.github.com/repos/pro-collection/interview-question/labels/%E8%85%BE%E8%AE%AF","腾讯",[],{"_58":132,"_68":133,"_62":134,"_70":135,"_72":136,"_74":137,"_76":138,"_122":139,"_140":442,"_142":143,"_144":145,"_124":125,"_146":147,"_148":149,"_150":-5,"_151":-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},"2024-10-13T02:10:15Z","2024-10-13T02:10:16Z",{"_160":145,"_161":145,"_162":145},{"_165":145,"_166":145,"_167":145,"_168":145},"**关键词**：node 应用部署\n\n**一、选择服务器和环境**\n\n1. **服务器选择**：\n\n - 可以选择云服务器提供商（如阿里云、腾讯云、AWS 等）的虚拟服务器或容器服务。根据应用的需求和预算，确定服务器的配置（CPU、内存、存储等）。\n - 考虑服务器的地理位置和网络连接质量，以确保用户能够快速访问应用。\n\n2. **操作系统**：\n - 常见的选择是 Linux 发行版，如 Ubuntu、CentOS 等。Linux 系统具有稳定性、安全性和资源效率高的特点，适合部署服务器应用。\n\n**二、代码准备和优化**\n\n1. **代码审查和测试**：\n\n - 在部署之前，确保代码经过严格的审查和测试。包括单元测试、集成测试和端到端测试，以确保应用的功能和性能符合要求。\n - 检查代码中的潜在安全漏洞，如 SQL 注入、跨站脚本攻击（XSS）等，并采取相应的防范措施。\n\n2. **性能优化**：\n - 对 Node.js 应用进行性能优化，以提高在生产环境中的响应速度和吞吐量。可以采用以下优化措施：\n - 优化数据库查询，避免不必要的查询和复杂的连接。\n - 使用缓存技术，如内存缓存或分布式缓存，减少重复计算和数据库访问。\n - 压缩和优化静态资源，如 CSS、JavaScript 和图片，减少网络传输时间。\n - 配置适当的日志级别，避免过多的日志输出影响性能。\n\n**三、部署方式**\n\n1. **手动部署**：\n\n - 直接将代码上传到服务器，并手动安装和配置所需的依赖项和运行环境。这种方式适用于小型项目或临时部署，但不够自动化和可重复。\n - 步骤如下：\n - 使用 SSH 连接到服务器。\n - 将代码上传到服务器，可以使用 FTP、SCP 或 Git 等方式。\n - 在服务器上安装 Node.js 和所需的依赖项（使用`npm install`或`yarn install`）。\n - 配置应用的环境变量，如数据库连接字符串、端口号等。\n - 启动应用（使用`node app.js`或通过 PM2 等进程管理工具）。\n\n2. **持续集成/持续部署（CI/CD）**：\n - 使用 CI/CD 工具实现自动化的部署流程。这种方式可以提高部署的效率和可靠性，减少人为错误。\n - 常见的 CI/CD 工具包括 Jenkins、Travis CI、CircleCI 等。以下是一般的部署流程：\n - 将代码托管在版本控制系统（如 Git）中。\n - 配置 CI/CD 工具，设置构建和部署的触发器（如代码提交、定时任务等）。\n - 在 CI/CD 管道中，进行代码构建、测试和打包。\n - 将打包后的应用部署到服务器，可以使用 SSH、Docker 等方式。\n - 进行自动化的测试和验证，确保应用在部署后正常运行。\n\n**四、运行和监控**\n\n1. **进程管理**：\n\n - 使用进程管理工具来确保 Node.js 应用在服务器上持续运行。常见的进程管理工具包括 PM2、Forever 等。\n - 这些工具可以监控应用的运行状态，自动重启应用在崩溃或出现错误时，并提供日志管理和性能监控功能。\n\n2. **监控和日志记录**：\n\n - 配置应用的日志记录，以便在生产环境中跟踪应用的运行状态和错误。可以使用日志管理工具，如 Logstash、ELK Stack 等，集中收集和分析日志。\n - 同时，使用监控工具来实时监测应用的性能指标，如 CPU 使用率、内存占用、响应时间等。常见的监控工具包括 New Relic、Datadog、Prometheus 等。\n\n3. **安全措施**：\n - 采取必要的安全措施来保护生产环境中的 Node.js 应用。包括：\n - 配置防火墙，限制对服务器的访问。\n - 使用 HTTPS 加密通信，保护用户数据的安全。\n - 定期更新服务器和应用的软件包，以修复安全漏洞。\n - 实施访问控制，限制对敏感资源的访问。\n",{"_58":449,"_174":145,"_175":145,"_176":145,"_177":145,"_178":145,"_179":145,"_180":145,"_181":145,"_182":145},"https://api.github.com/repos/pro-collection/interview-question/issues/991/reactions","https://api.github.com/repos/pro-collection/interview-question/issues/991/timeline",{"_58":452,"_60":61,"_62":453,"_64":454,"_66":455,"_68":456,"_70":457,"_72":458,"_74":459,"_76":460,"_78":461,"_111":462,"_124":125,"_126":24,"_127":-5,"_128":471,"_130":472,"_152":145,"_146":474,"_148":474,"_151":-5,"_155":156,"_106":-5,"_157":-5,"_158":475,"_163":476,"_169":477,"_171":478,"_183":480,"_185":-5,"_186":-5,"_187":188},"https://api.github.com/repos/pro-collection/interview-question/issues/976","https://api.github.com/repos/pro-collection/interview-question/issues/976/labels{/name}","https://api.github.com/repos/pro-collection/interview-question/issues/976/comments","https://api.github.com/repos/pro-collection/interview-question/issues/976/events","https://github.com/pro-collection/interview-question/issues/976",2569781246,"I_kwDOJGDC6c6ZK7_-",976,"commonjs 模块化中 module.exports 与 exports 有什么区别，该如何选择【热度: 194】",{"_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},[463,464],{"_70":114,"_72":115,"_58":116,"_117":118,"_119":120,"_121":24,"_122":123},{"_70":465,"_72":466,"_58":467,"_117":468,"_119":469,"_121":24,"_122":470},5312047129,"LA_kwDOJGDC6c8AAAABPJ9oGQ","https://api.github.com/repos/pro-collection/interview-question/labels/web%E5%BA%94%E7%94%A8%E5%9C%BA%E6%99%AF","web应用场景","EA4E1E","应用场景类问题",[],{"_58":132,"_68":133,"_62":134,"_70":135,"_72":136,"_74":137,"_76":138,"_122":139,"_140":473,"_142":143,"_144":145,"_124":125,"_146":147,"_148":149,"_150":-5,"_151":-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},"2024-10-07T08:51:26Z",{"_160":145,"_161":145,"_162":145},{"_165":145,"_166":145,"_167":145,"_168":145},"**关键词**：模块化导出\n\n在 CommonJS 模块化规范中，`module.exports`与`exports`有以下区别：\n\n**一、`module.exports`**\n\n1. **本质**：\n\n - `module.exports`是一个对象，它代表当前模块要导出的内容。可以将任意类型的值（如函数、对象、字符串等）赋值给`module.exports`来决定模块导出的内容。\n\n2. **作用范围和灵活性**：\n - 可以完全覆盖模块的导出内容。例如，可以直接将一个全新的对象赋值给`module.exports`，从而完全替换模块原本可能通过`exports`添加的属性。\n - 适合需要导出复杂数据结构或多个不同类型的值的情况。例如，可以导出一个包含多个函数和变量的对象。\n\n**二、`exports`**\n\n1. **本质**：\n\n - `exports`最初是一个对`module.exports`的引用。这意味着通过`exports`添加的属性实际上是添加到了`module.exports`所代表的对象上。\n\n2. **局限性**：\n - 如果直接将一个值赋值给`exports`，它将不再是对`module.exports`的引用，而是变成一个独立的变量。此时，模块的导出内容将变为这个新的值，而不是原本期望的通过添加属性到`exports`来构建的导出对象。\n - 例如：\n ```javascript\n exports = function () {\n console.log(\"This is a new function.\");\n };\n ```\n - 在这种情况下，模块将不再导出之前可能通过`exports.xxx = yyy`添加的属性，而是只导出这个新的函数。\n\n**三、选择建议\\*\\***：\n\n1. **简单模块导出单个值**：\n\n - 如果模块只需要导出一个简单的值，如一个函数或一个字符串，可以使用`module.exports`直接赋值的方式。例如：\n\n ```javascript\n module.exports = function add(a, b) {\n return a + b;\n };\n ```\n\n2. **复杂模块构建导出对象**：\n\n - 当模块需要导出多个相关的值或功能时，可以先使用`exports`添加属性，最后确保`module.exports`指向一个包含所有需要导出内容的对象。例如：\n\n ```javascript\n exports.foo = function () {\n console.log(\"foo function.\");\n };\n exports.bar = \"bar value\";\n module.exports = exports; // 确保 module.exports 和 exports 指向同一个对象\n ```\n\n3. **避免混淆和错误**：\n - 理解`module.exports`和`exports`的区别非常重要，以避免在导出模块内容时出现意外的结果。尽量明确使用`module.exports`或遵循使用`exports`的正确方式，避免直接赋值给`exports`而导致错误的导出行为。\n",{"_58":479,"_174":145,"_175":145,"_176":145,"_177":145,"_178":145,"_179":145,"_180":145,"_181":145,"_182":145},"https://api.github.com/repos/pro-collection/interview-question/issues/976/reactions","https://api.github.com/repos/pro-collection/interview-question/issues/976/timeline",{"_58":482,"_60":61,"_62":483,"_64":484,"_66":485,"_68":486,"_70":487,"_72":488,"_74":489,"_76":490,"_78":491,"_111":492,"_124":125,"_126":24,"_127":-5,"_128":499,"_130":500,"_152":145,"_146":502,"_148":503,"_151":-5,"_155":156,"_106":-5,"_157":-5,"_158":504,"_163":505,"_169":506,"_171":507,"_183":509,"_185":-5,"_186":-5,"_187":188},"https://api.github.com/repos/pro-collection/interview-question/issues/970","https://api.github.com/repos/pro-collection/interview-question/issues/970/labels{/name}","https://api.github.com/repos/pro-collection/interview-question/issues/970/comments","https://api.github.com/repos/pro-collection/interview-question/issues/970/events","https://github.com/pro-collection/interview-question/issues/970",2569723165,"I_kwDOJGDC6c6ZKt0d",970,"对于已经 import 但未实际使用的模块使用 webpack 还会对它打包吗【热度: 108】",{"_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},[493,494],{"_70":114,"_72":115,"_58":116,"_117":118,"_119":120,"_121":24,"_122":123},{"_70":495,"_72":496,"_58":497,"_117":498,"_119":231,"_121":24,"_122":232},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":304,"_68":305,"_62":306,"_70":307,"_72":308,"_74":309,"_76":310,"_122":311,"_140":501,"_142":313,"_144":145,"_124":125,"_146":314,"_148":315,"_150":-5,"_151":-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},"2024-10-07T08:26:50Z","2024-10-07T08:26:51Z",{"_160":145,"_161":145,"_162":145},{"_165":145,"_166":145,"_167":145,"_168":145},"**关键词**：tree-shaking 使用\n\n在使用 Webpack 进行打包时，对于已经导入（import）但未实际使用的模块，通常情况下不会被打包进去，但这也取决于具体的配置和使用场景。\n\n**一、默认行为**\n\n在默认情况下，Webpack 会进行“树摇”（tree shaking）操作。树摇是一种优化技术，它可以检测和移除未被使用的代码。如果一个模块被导入但在代码中没有被实际使用，Webpack 会尝试识别并排除这个模块，以减小最终打包文件的大小。\n\n例如：\n\n```javascript\nimport { someFunction } from \"moduleA\";\n// 如果 someFunction 在后续代码中没有被调用，Webpack 可能会在打包时排除 moduleA 中未被使用的部分。\n```\n\n**二、特殊情况**\n\n然而，在某些情况下，即使模块未被直接使用，也可能会被打包进去：\n\n1. 副作用：如果导入的模块有副作用（例如修改全局状态、注册事件监听器等），即使模块中的具体函数或变量没有被直接使用，Webpack 也可能不会将其排除。因为这些副作用可能对应用的运行产生影响。\n\n - 例如：\n\n ```javascript\n import \"moduleB\"; // moduleB 可能会在导入时执行一些初始化操作，有副作用。\n ```\n\n2. 动态导入：如果使用动态导入（例如通过 import()函数），Webpack 可能无法在打包时确定哪些模块会被实际使用，因此可能会保留一些未被直接使用的模块，以确保在运行时能够正确加载所需的模块。\n\n - 例如：\n\n ```javascript\n const moduleName = \"moduleC\";\n import(moduleName).then((module) => {\n // 使用动态导入的模块。\n });\n ```\n\n3. 第三方库的依赖：如果导入的模块被其他模块间接依赖，即使在当前模块中没有直接使用，也可能会被打包进去。例如，一个第三方库可能依赖于某个特定的模块，而你的代码只导入了这个第三方库，Webpack 可能会将这个被依赖的模块也打包进来。\n",{"_58":508,"_174":309,"_175":309,"_176":145,"_177":145,"_178":145,"_179":145,"_180":145,"_181":145,"_182":145},"https://api.github.com/repos/pro-collection/interview-question/issues/970/reactions","https://api.github.com/repos/pro-collection/interview-question/issues/970/timeline",{"_58":511,"_60":61,"_62":512,"_64":513,"_66":514,"_68":515,"_70":516,"_72":517,"_74":518,"_76":519,"_78":520,"_111":521,"_124":125,"_126":24,"_127":-5,"_128":524,"_130":525,"_152":145,"_146":527,"_148":528,"_151":-5,"_155":156,"_106":-5,"_157":-5,"_158":529,"_163":530,"_169":531,"_171":532,"_183":534,"_185":-5,"_186":-5,"_187":188},"https://api.github.com/repos/pro-collection/interview-question/issues/957","https://api.github.com/repos/pro-collection/interview-question/issues/957/labels{/name}","https://api.github.com/repos/pro-collection/interview-question/issues/957/comments","https://api.github.com/repos/pro-collection/interview-question/issues/957/events","https://github.com/pro-collection/interview-question/issues/957",2569546626,"I_kwDOJGDC6c6ZKCuC",957,"前端需要加载一个大体积的文件时，一般有哪些优化思路【热度: 594】",{"_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},[522,523],{"_70":114,"_72":115,"_58":116,"_117":118,"_119":120,"_121":24,"_122":123},{"_70":436,"_72":437,"_58":438,"_117":439,"_119":231,"_121":24,"_122":232},[],{"_58":132,"_68":133,"_62":134,"_70":135,"_72":136,"_74":137,"_76":138,"_122":139,"_140":526,"_142":143,"_144":145,"_124":125,"_146":147,"_148":149,"_150":-5,"_151":-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},"2024-10-07T07:09:53Z","2024-10-07T07:09:54Z",{"_160":145,"_161":145,"_162":145},{"_165":145,"_166":145,"_167":145,"_168":145},"**关键词**：前端加载文件过大\n\n当前端需要加载大体积文件时，可以从以下几个方面进行优化：\n\n**一、文件压缩**\n\n1. **服务器端压缩**：\n\n - 在服务器上配置文件压缩功能，如使用 Gzip 或 Brotli 压缩算法对文件进行压缩后再传输。这样可以显著减少文件的大小，降低传输时间。\n - 例如，在 Nginx 服务器中，可以通过配置开启 Gzip 压缩：\n\n ```nginx\n gzip on;\n gzip_comp_level 6;\n gzip_types text/plain text/css application/javascript application/json image/svg+xml;\n ```\n\n2. **客户端解压缩**：\n - 现代浏览器通常支持对 Gzip 和 Brotli 压缩的文件进行自动解压缩。当浏览器接收到压缩后的文件时，会自动解压缩并使用。\n - 无需额外的客户端代码，浏览器会自动处理压缩文件的解压缩过程，提高文件加载速度。\n\n**二、文件分割与懒加载**\n\n1. **文件分割**：\n\n - 将大体积文件分割成多个较小的文件。例如，对于一个大型的 JavaScript 库，可以将其拆分成多个模块，根据需要逐步加载。\n - 这样可以避免一次性加载整个大文件，减少初始加载时间。\n - 例如，使用 Webpack 等构建工具可以将代码分割成多个 chunk，根据路由或特定条件进行加载。\n\n2. **懒加载**：\n - 对于不是立即需要的文件或资源，可以采用懒加载的方式。当用户实际需要使用该资源时，再进行加载。\n - 例如，对于图片、视频等资源，可以在用户滚动到可视区域时再进行加载，避免在页面初始加载时加载所有资源。\n - 对于 JavaScript 模块，可以使用动态导入（dynamic import）的方式实现懒加载：\n ```javascript\n const loadModule = async () => {\n const module = await import(\"./largeModule.js\");\n // 使用加载的模块\n };\n ```\n\n**三、缓存策略**\n\n1. **浏览器缓存**：\n\n - 设置合理的缓存策略，让浏览器缓存已经加载过的文件。这样，当用户再次访问时，可以直接从缓存中读取文件，而无需再次从服务器下载。\n - 可以通过设置 HTTP 响应头来控制缓存，例如：\n\n ```nginx\n location / {\n add_header Cache-Control \"max-age=3600\";\n }\n ```\n\n - 上述配置将设置文件的缓存时间为 1 小时。\n\n2. **缓存更新机制**：\n - 当文件内容发生变化时，需要确保浏览器能够获取到最新的版本。可以通过在文件名中添加版本号或哈希值来实现缓存更新。\n - 例如，将文件名改为`largeFile_v1.2.js`或`largeFile_abc123.js`，当文件内容变化时，更新版本号或哈希值，浏览器会认为这是一个新的文件并进行下载。\n\n**四、优化加载顺序**\n\n1. **关键资源优先加载**：\n\n - 确定哪些资源是页面加载的关键资源，优先加载这些资源。对于大体积文件，如果不是关键资源，可以延迟加载。\n - 例如，对于一个图片库应用，先加载页面的基本结构和导航部分，图片可以在用户交互时再进行加载。\n\n2. **异步加载**：\n - 使用异步加载的方式加载大体积文件。例如，对于 JavaScript 文件，可以使用`\n ```\n - 这样可以避免阻塞页面的渲染，提高用户体验。\n\n**五、CDN 加速**\n\n1. **使用内容分发网络（CDN）**：\n\n - 将大体积文件托管在 CDN 上，利用 CDN 的分布式节点，可以让用户从离自己最近的节点获取文件，减少网络延迟，提高加载速度。\n - 例如，将图片、视频、静态文件等托管在 CDN 上，通过 CDN 的 URL 进行访问。\n\n2. **CDN 缓存**：\n - CDN 通常会对文件进行缓存，进一步提高文件的加载速度。当文件内容发生变化时，需要及时更新 CDN 上的缓存。\n - 可以通过设置 CDN 的缓存策略或使用版本号等方式来管理 CDN 缓存。\n",{"_58":533,"_174":145,"_175":145,"_176":145,"_177":145,"_178":145,"_179":145,"_180":145,"_181":145,"_182":145},"https://api.github.com/repos/pro-collection/interview-question/issues/957/reactions","https://api.github.com/repos/pro-collection/interview-question/issues/957/timeline",{"_58":536,"_60":61,"_62":537,"_64":538,"_66":539,"_68":540,"_70":541,"_72":542,"_74":543,"_76":544,"_78":545,"_111":546,"_124":125,"_126":24,"_127":-5,"_128":549,"_130":550,"_152":145,"_146":552,"_148":553,"_151":-5,"_155":156,"_106":-5,"_157":-5,"_158":554,"_163":555,"_169":556,"_171":557,"_183":559,"_185":-5,"_186":-5,"_187":188},"https://api.github.com/repos/pro-collection/interview-question/issues/956","https://api.github.com/repos/pro-collection/interview-question/issues/956/labels{/name}","https://api.github.com/repos/pro-collection/interview-question/issues/956/comments","https://api.github.com/repos/pro-collection/interview-question/issues/956/events","https://github.com/pro-collection/interview-question/issues/956",2569533728,"I_kwDOJGDC6c6ZJ_kg",956,"前端部署应该要考虑哪些问题【热度: 310】",{"_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},[547,548],{"_70":114,"_72":115,"_58":116,"_117":118,"_119":120,"_121":24,"_122":123},{"_70":436,"_72":437,"_58":438,"_117":439,"_119":231,"_121":24,"_122":232},[],{"_58":132,"_68":133,"_62":134,"_70":135,"_72":136,"_74":137,"_76":138,"_122":139,"_140":551,"_142":143,"_144":145,"_124":125,"_146":147,"_148":149,"_150":-5,"_151":-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},"2024-10-07T07:03:14Z","2024-10-07T07:03:15Z",{"_160":145,"_161":145,"_162":145},{"_165":145,"_166":145,"_167":145,"_168":145},"**关键词**：前端部署\n\n在前端部署到生产环境时，有多个关键问题需要解决：\n\n**一、高可用性与故障应对**\n\n生产环境中，单点故障是必须考虑的问题。若一台物理机突然崩溃，应用需依然能够正常运行。这时可以了解 Kubernetes（k8s）的 Deployment，它能够有效地应对单点故障，确保应用的高可用性。\n\n**二、热更新与用户体验**\n\n热更新也是重要环节。当需要更新应用时，要做到让用户无感知。同样，k8s 的 Deployment 提供了热更新的功能，能够在不影响用户使用的情况下完成应用的更新。\n\n**三、版本回退机制**\n\n如果上线的新版本出现问题，需要有时光回溯的能力，能够快速回退到之前的稳定版本。\n\n**四、负载均衡**\n\n负载均衡能够确保流量均匀分配到各个服务器上，提高系统的性能和稳定性。使用 Nginx 等工具可以实现负载均衡，满足生产环境的需求。\n\n**五、自动扩缩容**\n\n当流量突然增大时，系统需要能够自动扩容以应对压力。反之，流量减少时也应能自动缩容以节省资源。\n\n**六、数据库部署与运维**\n\n数据库部署不建议在 k8s 上进行，可选择本地部署 MySQL 集群或直接上云。同时，还需要具备基本的数据运维能力，如日志收集（ELK 或 EFK）和性能监控等。\n\n**总结**\n要将前端应用成功部署到生产环境，需要解决上述多个问题。自动化 pipeline 也是关键，包括 Jenkins、GitLab、k8s 等工具的组合使用。将这一套组合拳运用好，即使不是非常厉害的高手，达到中级水平，也能在中小型公司中轻松应对各种部署需求，实现高效的生产环境部署和运维。\n",{"_58":558,"_174":145,"_175":145,"_176":145,"_177":145,"_178":145,"_179":145,"_180":145,"_181":145,"_182":145},"https://api.github.com/repos/pro-collection/interview-question/issues/956/reactions","https://api.github.com/repos/pro-collection/interview-question/issues/956/timeline",{"_58":561,"_60":61,"_62":562,"_64":563,"_66":564,"_68":565,"_70":566,"_72":567,"_74":568,"_76":569,"_78":570,"_111":571,"_124":125,"_126":24,"_127":-5,"_128":574,"_130":575,"_152":145,"_146":577,"_148":577,"_151":-5,"_155":156,"_106":-5,"_157":-5,"_158":578,"_163":579,"_169":580,"_171":581,"_183":583,"_185":-5,"_186":-5,"_187":188},"https://api.github.com/repos/pro-collection/interview-question/issues/953","https://api.github.com/repos/pro-collection/interview-question/issues/953/labels{/name}","https://api.github.com/repos/pro-collection/interview-question/issues/953/comments","https://api.github.com/repos/pro-collection/interview-question/issues/953/events","https://github.com/pro-collection/interview-question/issues/953",2553981257,"I_kwDOJGDC6c6YOqlJ",953,"[webpack] tree-shaking 原理【热度: 722】",{"_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},[572,573],{"_70":114,"_72":115,"_58":116,"_117":118,"_119":120,"_121":24,"_122":123},{"_70":436,"_72":437,"_58":438,"_117":439,"_119":231,"_121":24,"_122":232},[],{"_58":132,"_68":133,"_62":134,"_70":135,"_72":136,"_74":137,"_76":138,"_122":139,"_140":576,"_142":143,"_144":145,"_124":125,"_146":147,"_148":149,"_150":-5,"_151":-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},"2024-09-28T03:25:08Z",{"_160":145,"_161":145,"_162":145},{"_165":145,"_166":145,"_167":145,"_168":145},"**关键词**：tree-shaking 原理\n\n> 作者备注\n>\n> webpack 热门问题\n\nWebpack 的 Tree Shaking 主要是用来消除未被使用的代码，以减小最终打包文件的体积。其原理如下：\n\n**一、静态分析**\n\n1. 模块依赖分析：\n\n - Webpack 在构建过程中，会对项目中的模块进行依赖分析。它会解析每个模块的内容，确定模块之间的导入和导出关系。\n - 通过分析，可以构建出一个模块依赖图，展示了各个模块之间的引用关系。\n\n2. 识别未使用的代码：\n - 基于模块依赖图，Webpack 可以确定哪些模块被实际使用，哪些模块未被使用。\n - 对于 JavaScript 模块，它可以识别出未被调用的函数、未被访问的变量等。对于其他资源文件，如 CSS 和图片，也可以根据引用情况判断是否被使用。\n\n**二、代码优化**\n\n1. 消除未使用的代码：\n\n - 一旦识别出未使用的代码，Webpack 会在打包过程中将这些代码从最终的输出文件中移除。\n - 这可以显著减小打包文件的大小，提高应用的加载速度和性能。\n\n2. 作用域分析：\n - 在消除未使用的代码时，Webpack 还会进行作用域分析。它会确保在移除代码的过程中，不会影响到实际使用的代码的正确性。\n - 例如，如果一个函数在一个模块中未被使用，但在另一个模块中被间接引用，Webpack 会谨慎处理，避免错误地移除该函数。\n\n**三、实现条件**\n\n1. ES2015 模块语法：\n\n - Tree Shaking 主要依赖于 ES2015 模块语法（`import`和`export`）。这种模块语法是静态的，使得 Webpack 能够在编译时确定模块的导入和导出关系。\n - 相比之下，CommonJS 模块语法（`require`和`module.exports`）是动态的，难以在编译时进行准确的分析。\n\n2. 支持的模块类型：\n - Webpack 不仅可以对 JavaScript 模块进行 Tree Shaking，还可以对一些其他类型的模块进行处理，如 CSS 模块（通过特定的加载器和插件）。\n - 对于不同类型的模块，Webpack 可能会使用不同的技术和策略来实现 Tree Shaking。\n\n总之，Webpack 的 Tree Shaking 通过静态分析模块依赖关系，识别并消除未使用的代码，从而优化打包文件的大小和性能。它依赖于 ES2015 模块语法和准确的模块依赖分析，同时需要注意一些实现条件和潜在的问题。\n",{"_58":582,"_174":145,"_175":145,"_176":145,"_177":145,"_178":145,"_179":145,"_180":145,"_181":145,"_182":145},"https://api.github.com/repos/pro-collection/interview-question/issues/953/reactions","https://api.github.com/repos/pro-collection/interview-question/issues/953/timeline",{"_58":585,"_60":61,"_62":586,"_64":587,"_66":588,"_68":589,"_70":590,"_72":591,"_74":592,"_76":593,"_78":594,"_111":595,"_124":125,"_126":24,"_127":-5,"_128":598,"_130":599,"_152":145,"_146":601,"_148":602,"_151":-5,"_155":156,"_106":-5,"_157":-5,"_158":603,"_163":604,"_169":605,"_171":606,"_183":608,"_185":-5,"_186":-5,"_187":188},"https://api.github.com/repos/pro-collection/interview-question/issues/944","https://api.github.com/repos/pro-collection/interview-question/issues/944/labels{/name}","https://api.github.com/repos/pro-collection/interview-question/issues/944/comments","https://api.github.com/repos/pro-collection/interview-question/issues/944/events","https://github.com/pro-collection/interview-question/issues/944",2553956271,"I_kwDOJGDC6c6YOkev",944,"[webpack] 发中使用的是 esm 和 webpack, 是否可以直接调用 commonjs 模块化的三方包【热度: 359】",{"_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},[596,597],{"_70":114,"_72":115,"_58":116,"_117":118,"_119":120,"_121":24,"_122":123},{"_70":495,"_72":496,"_58":497,"_117":498,"_119":231,"_121":24,"_122":232},[],{"_58":132,"_68":133,"_62":134,"_70":135,"_72":136,"_74":137,"_76":138,"_122":139,"_140":600,"_142":143,"_144":145,"_124":125,"_146":147,"_148":149,"_150":-5,"_151":-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},"2024-09-28T02:18:10Z","2024-09-28T02:18:11Z",{"_160":145,"_161":145,"_162":145},{"_165":145,"_166":145,"_167":145,"_168":145},"**关键词**：模块化混用\n\n在使用 Webpack 作为构建工具的项目中，ESM (ECMAScript Modules) 和 CommonJS 模块系统可以混用。\n\nWebpack 提供了对两种模块化标准的支持，能够理解和处理它们之间的差异，使得这两种不同类型的模块可以在同一个项目中共存。\n\n### 混用时的考虑因素\n\n虽然 ESM 和 CommonJS 可以混用，但是还需要注意一些关键的点：\n\n- **导入方式**：当你从一个 ESM 模块中导入 CommonJS 模块时，导入的内容会被当成默认导出处理。这意味着，即使 CommonJS 模块导出了多个成员，你也需要以默认导入的方式来获取整个 `exports` 对象。\n\n ```javascript\n // CommonJS 模块\n module.exports = {\n foo: \"bar\",\n baz: \"qux\",\n };\n\n // 在 ESM 中导入 CommonJS 模块\n import cjsModule from \"./cjs-module\";\n console.log(cjsModule.foo); // 输出: 'bar'\n ```\n\n- **导出方式**：在一个 CommonJS 模块中，你可以通过 `require` 导入一个 ESM，但是这通常需要额外配置，因为 ESM 默认是异步加载的。此外，ESM 模块的导出在被 CommonJS 模块通过 `require` 导入时，必须访问它们的 `default` 属性或使用 `import()` 异步导入语句。\n\n- **动态与静态**：ESM 是静态的，这意味着你不能动态地导入或导出模块，所有的导入和导出必须在模块的顶层发生。CommonJS 模块是动态的，允许你将 `require` 语句放在代码的任何位置。由于这种静态与动态的区别，混用时要考虑代码组织和模块加载顺序。\n\n- **构建与树摇（Tree Shaking）**：Webpack 可以对 ESM 进行树摇优化，以去除未使用的导出。这可以减少最终构建包的大小。由于 CommonJS 模块是动态的，它们不完全支持树摇。如果在意最终包的大小，优先使用 ESM 来编写新模块可能会更好。\n\n### 总结\n\n在 Webpack 下，ESM 和 CommonJS 可以混用，但是混用时需要注意导入导出的细微差别，以及可能对构建优化产生的影响。理解这些模块系统之间的差异，并合理组织代码，可以充分利用 Webpack 提供的灵活性和功能，编写高效且可维护的现代 JavaScript 应用。\n",{"_58":607,"_174":145,"_175":145,"_176":145,"_177":145,"_178":145,"_179":145,"_180":145,"_181":145,"_182":145},"https://api.github.com/repos/pro-collection/interview-question/issues/944/reactions","https://api.github.com/repos/pro-collection/interview-question/issues/944/timeline",{"_58":610,"_60":61,"_62":611,"_64":612,"_66":613,"_68":614,"_70":615,"_72":616,"_74":617,"_76":618,"_78":619,"_111":620,"_124":125,"_126":24,"_127":-5,"_128":623,"_130":624,"_152":145,"_146":626,"_148":626,"_151":-5,"_155":156,"_106":-5,"_157":-5,"_158":627,"_163":628,"_169":629,"_171":630,"_183":632,"_185":-5,"_186":-5,"_187":188},"https://api.github.com/repos/pro-collection/interview-question/issues/889","https://api.github.com/repos/pro-collection/interview-question/issues/889/labels{/name}","https://api.github.com/repos/pro-collection/interview-question/issues/889/comments","https://api.github.com/repos/pro-collection/interview-question/issues/889/events","https://github.com/pro-collection/interview-question/issues/889",2529856908,"I_kwDOJGDC6c6Wyo2M",889,"pnpm install 和 npm install 有何区别",{"_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},[621,622],{"_70":114,"_72":115,"_58":116,"_117":118,"_119":120,"_121":24,"_122":123},{"_70":495,"_72":496,"_58":497,"_117":498,"_119":231,"_121":24,"_122":232},[],{"_58":304,"_68":305,"_62":306,"_70":307,"_72":308,"_74":309,"_76":310,"_122":311,"_140":625,"_142":313,"_144":145,"_124":125,"_146":314,"_148":315,"_150":-5,"_151":-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},"2024-09-17T02:42:28Z",{"_160":145,"_161":145,"_162":145},{"_165":145,"_166":145,"_167":145,"_168":145},"`pnpm install` 和 `npm install` 都是用于安装 JavaScript 项目依赖的命令，但它们背后的包管理器（分别是 `pnpm` 和 `npm`）在处理依赖安装、存储和优化方面有一些关键区别。\n\n### 1. **存储方式的区别**\n\n- **npm**：在每个项目的 `node_modules` 文件夹中分别存储其依赖。这意味着如果你有多个项目，它们共享相同的依赖库，这些依赖库的多个副本将在你的文件系统中的每个项目内分别存储。这样做会占用更多的磁盘空间。\n\n- **pnpm**：采用一种称为**内容寻址文件系统**的方式来存储依赖。所有项目的依赖被存储在一个共享的位置，各个项目中的 `node_modules` 目录通过硬链接（hard links）或符号链接（symlinks）指向这个共享位置。该方法有效地减少了磁盘空间的占用，并加快了依赖的安装速度。\n\n### 2. **性能与速度**\n\n- **pnpm**：由于对依赖进行了有效的复用，并且使用硬链接来减少磁盘上的副本数量，通常可以提供比 `npm` 更快的安装速度。\n\n- **npm**：近几个大版本中也进行了许多性能改进，但在多个项目中共享相同依赖时，它可能仍然比 `pnpm` 更慢，尤其是在首次安装依赖时。\n\n### 3. **依赖平面结构 vs. 嵌套结构**\n\n- **npm**：自版本 3 以后，默认创建扁平的 `node_modules` 结构（尽可能），这样做是为了避免 Windows 系统中路径过长的问题。但在必要时， `npm` 仍然会创建嵌套的 `node_modules` 目录结构，以解决依赖冲突。\n\n- **pnpm**：通过使用符号链接，`pnpm` 维护了一个严格的嵌套依赖结构，更接近每个包的 `package.json` 文件所声明的依赖树形态。这提供了更高的一致性和在某些情况下更好的包隔离性。\n\n### 4. **依赖隔离与安全性**\n\n- **pnpm**：更好地隔离了依赖，每个包只能访问其在 `package.json` 中声明的依赖。这一特性增强了项目的安全性，因为它阻止了未声明的依赖被意外引入的情况。\n\n- **npm**：虽然 `npm` 也遵循 `package.json` 中的声明，但其扁平化的 `node_modules` 结构有时可能会容易地让包访问到未明确声明的依赖。\n\n### 5. **命令行界面（CLI）和配置**\n\n- 这两个工具的命令行界面（CLI）和配置都非常直观且类似，但它们的某些命令和选项可能会有细微差别。`pnpm` 为了优化性能和安全性引入了一些特有的命令和配置选项。\n\n总的来说，`pnpm` 在多项目管理、磁盘空间和安装速度方面提供了优于 `npm` 的性能和利益。对于新项目或在寻求性能优化的既存项目，考虑试用 `pnpm` 可能是个不错的选择。\n",{"_58":631,"_174":145,"_175":145,"_176":145,"_177":145,"_178":145,"_179":145,"_180":145,"_181":145,"_182":145},"https://api.github.com/repos/pro-collection/interview-question/issues/889/reactions","https://api.github.com/repos/pro-collection/interview-question/issues/889/timeline",{"_58":634,"_60":61,"_62":635,"_64":636,"_66":637,"_68":638,"_70":639,"_72":640,"_74":641,"_76":642,"_78":643,"_111":644,"_124":125,"_126":24,"_127":-5,"_128":647,"_130":648,"_152":145,"_146":661,"_148":662,"_151":-5,"_155":156,"_106":-5,"_157":-5,"_158":663,"_163":664,"_169":665,"_171":666,"_183":668,"_185":-5,"_186":-5,"_187":188},"https://api.github.com/repos/pro-collection/interview-question/issues/888","https://api.github.com/repos/pro-collection/interview-question/issues/888/labels{/name}","https://api.github.com/repos/pro-collection/interview-question/issues/888/comments","https://api.github.com/repos/pro-collection/interview-question/issues/888/events","https://github.com/pro-collection/interview-question/issues/888",2529844180,"I_kwDOJGDC6c6WylvU",888,"monorepo 工程有哪些工具架构，该如何选型【热度: 450】",{"_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},[645,646],{"_70":114,"_72":115,"_58":116,"_117":118,"_119":120,"_121":24,"_122":123},{"_70":495,"_72":496,"_58":497,"_117":498,"_119":231,"_121":24,"_122":232},[],{"_58":649,"_68":650,"_62":651,"_70":652,"_72":653,"_74":654,"_76":655,"_122":656,"_140":657,"_142":658,"_144":145,"_124":125,"_146":659,"_148":660,"_150":-5,"_151":-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,"资深","资深级别面试问题",{"_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},50,"2023-03-06T15:00:45Z","2025-07-06T12:02:25Z","2024-09-17T02:31:47Z","2024-09-17T02:40:09Z",{"_160":145,"_161":145,"_162":145},{"_165":145,"_166":145,"_167":145,"_168":145},"**关键词**：monorepo 技术选项\n\n### 工具推荐\n\n| 工具 | **Turborepo** | **Rush** | **Nx** | **Lerna** | **Pnpm Workspace** |\n| -------- | ------------- | -------- | ------ | --------- | ------------------ |\n| 依赖管理 | ❌ | ✅ | ❌ | ❌ | ✅ |\n| 版本管理 | ❌ | ✅ | ❌ | ✅ | ❌ |\n| 增量构建 | ✅ | ✅ | ✅ | ❌ | ❌ |\n| 插件扩展 | ✅ | ✅ | ✅ | ❌ | ❌ |\n| 云端缓存 | ✅ | ✅ | ✅ | ❌ | ❌ |\n| Stars | 20.4K | 4.9K | 17K | 34.3K | 22.7K |\n\n![img](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/d85551b9ce50496d8403956b571c4635~tplv-k3u1fbpfcp-jj-mark:3024:0:0:0:q75.awebp#?w=2610&h=1020&s=64366&e=webp&b=fdfdfd)\n\n### 工具选型\n\n选择合适的 Monorepo 管理工具对于确保项目的顺利进行是至关重要的。Monorepo 管理工具可以帮助你高效地管理项目依赖、统一代码风格、简化开发流程等。在进行 Monorepo 工具选型时，需要考虑几个重要的因素：\n\n#### 1. **技术栈的兼容性**\n\n- **Lerna**：与任何技术栈兼容性都很好，特别是与前端项目协同工作时。它对 NPM 和 Yarn 都有良好支持，适用于需要独立版本管理或频繁发布的项目。\n- **Yarn Workspaces**：特别适合使用 Yarn 作为包管理器的 JavaScript 或 TypeScript 项目。它非常适合团队中包之间有很多交叉依赖的情形。\n- **Nx**：支持多种前端和后端框架，如 Angular、React、NestJS 等。如果项目采用多技术栈，Nx 提供了一套完整的解决方案，包含了构建、测试和 linting 等一站式服务。\n- **Rush**：同样适用于大型项目，兼容任何 NPM 包管理器，如 NPM、Yarn、pnpm。Rush 提供了灵活的版本控制策略，非常适合需要精细控制包版本策略的场景。\n- **pnpm Workspaces**：具有高效的节点模块解析机制，非常注重节省磁盘空间及速度优化。如果磁盘空间和安装速度是关键考虑因素，pnpm 会是一个不错的选择。\n\n#### 2. **项目的规模和复杂度**\n\n- 对于大型或复杂项目，**Nx** 和 **Rush** 提供了更多的高级特性，比如增量构建、依赖图可视化等，可以有效提升大团队的开发效率。\n- 对于中小型项目，**Lerna**、**Yarn Workspaces** 或 **pnpm Workspaces** 可能更易上手，配置和管理也较为简单。\n\n#### 3. **构建、测试和部署的需求**\n\n- 如果项目需要复杂的构建、测试流程，**Nx** 提供了一些很好的工具来优化这一过程。Nx 可以智能地只重新构建受影响的项目，节省 CI/CD 的时间和资源。\n- **Rush** 强调在大型仓库中提供稳定而灵活的版本策略和发布管理，对于需要精细控制不同环境部署的项目非常有用。\n\n#### 4. **团队协作和代码共享的便利性**\n\n- 所有这些工具都支持代码共享和重用，但是**Nx** 和 **Rush** 在支持大型团队和多项目协作方面有一些额外的优势，如更智能的依赖管理和版本控制。\n\n#### 5. **社区支持和文档**\n\n- **Nx** 拥有强大的社区支持和丰富的文档、教程，非常适合于新技术栈的团队。\n- **Lerna** 和 **Yarn Workspaces** 受众广泛，网上有很多资源和案例，学习曲线相对平缓。\n\n#### 推荐策略\n\n如果你的项目非常关注于构建效率和对多种技术栈的支持，**Nx** 是非常好的选择。如果你更关心包的独立发布和版本管理，**Lerna** 和 **Rush** 可以满足你的需求。而对于那些偏好 Yarn 并且注重依赖管理的项目来说，**Yarn Workspaces** 提供了一套简单直接的解决方案。如果磁盘空间和安装速度是你的主要考虑，不妨试试 **pnpm Workspaces**。\n",{"_58":667,"_174":145,"_175":145,"_176":145,"_177":145,"_178":145,"_179":145,"_180":145,"_181":145,"_182":145},"https://api.github.com/repos/pro-collection/interview-question/issues/888/reactions","https://api.github.com/repos/pro-collection/interview-question/issues/888/timeline",{"_58":670,"_60":61,"_62":671,"_64":672,"_66":673,"_68":674,"_70":675,"_72":676,"_74":677,"_76":678,"_78":679,"_111":680,"_124":125,"_126":24,"_127":-5,"_128":683,"_130":684,"_152":145,"_146":686,"_148":687,"_151":-5,"_155":156,"_106":-5,"_157":-5,"_158":688,"_163":689,"_169":690,"_171":691,"_183":693,"_185":-5,"_186":-5,"_187":188},"https://api.github.com/repos/pro-collection/interview-question/issues/887","https://api.github.com/repos/pro-collection/interview-question/issues/887/labels{/name}","https://api.github.com/repos/pro-collection/interview-question/issues/887/comments","https://api.github.com/repos/pro-collection/interview-question/issues/887/events","https://github.com/pro-collection/interview-question/issues/887",2526835428,"I_kwDOJGDC6c6WnHLk",887,"[webpack] 如何优化产物大小【热度: 521】",{"_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},[681,682],{"_70":114,"_72":115,"_58":116,"_117":118,"_119":120,"_121":24,"_122":123},{"_70":495,"_72":496,"_58":497,"_117":498,"_119":231,"_121":24,"_122":232},[],{"_58":132,"_68":133,"_62":134,"_70":135,"_72":136,"_74":137,"_76":138,"_122":139,"_140":685,"_142":143,"_144":145,"_124":125,"_146":147,"_148":149,"_150":-5,"_151":-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},"2024-09-15T09:55:41Z","2024-09-17T02:39:57Z",{"_160":145,"_161":145,"_162":145},{"_165":145,"_166":145,"_167":145,"_168":145},"**关键词**：webpack 产物大小优化\n\n在使用 Webpack 进行项目构建时，减少包体积是提升加载速度、改善用户体验的关键措施之一。以下是一些通用的方法和技巧来减小构建结果的包体积：\n\n### 1. **使用 Tree Shaking**\n\nTree Shaking 是一个通过清除未引用代码（dead-code）的过程，可以有效减少最终包的大小。确保你的代码使用 ES6 模块语法（import 和 export），因为这允许 Webpack 更容易地识别并删除未被使用的代码。\n\n在 `webpack.config.js` 中设置 `mode` 为 `production` 可自动启用 Tree Shaking。\n\n### 2. **启用压缩(Uglification)**\n\nWebpack 通过压缩输出文件来减小包大小，如删除未使用的代码、缩短变量名等。确保在生产环境中启用了 UglifyJS 插件或 TerserPlugin。\n\n```javascript\nconst TerserPlugin = require(\"terser-webpack-plugin\");\n\nmodule.exports = {\n optimization: {\n minimize: true,\n minimizer: [\n new TerserPlugin({\n /* 附加选项 */\n }),\n ],\n },\n};\n```\n\n### 3. **代码分割(Code Splitting)**\n\n通过代码分割，你可以把代码分成多个 bundle，然后按需加载，从而减少初始加载时间。Webpack 提供了多种分割代码的方式，最常见的是动态导入（Dynamic Imports）。\n\n```javascript\nimport(/* webpackChunkName: \"my-chunk-name\" */ \"path/to/myModule\").then((module) => {\n // 使用module\n});\n```\n\n### 4. **使用 Externals 减轻体积**\n\n通过配置 externals 选项，可以阻止 Webpack 将某些 import 的包打包到 bundle 中，而是在运行时(runtime)再去从外部获取这些扩展依赖。\n\n```javascript\nmodule.exports = {\n externals: {\n jquery: \"jQuery\",\n },\n};\n```\n\n### 5. **利用缓存(Caching)**\n\n使用 `[contenthash]` 替换 `[hash]` 或 `[chunkhash]` 来为输出文件命名，这确保了只有当文件内容改变时，文件名称才会改变，可以更好地利用浏览器缓存。\n\n```javascript\noutput: {\n filename: '[name].[contenthash].js',\n}\n```\n\n### 6. **移除未使用的 CSS**\n\n使用 PurgeCSS 或`purify-css`等工具检查你的 CSS 文件，自动去除未使用的 CSS，可以极大地压缩 CSS 的体积。\n\n```javascript\nconst PurgecssPlugin = require(\"purgecss-webpack-plugin\");\n```\n\n### 7. **优化图片**\n\n使用`image-webpack-loader`等图片压缩插件，可以减小图片文件的体积。\n\n```javascript\nmodule: {\n rules: [\n {\n test: /\\.(png|svg|jpg|jpeg|gif)$/i,\n use: [\n 'file-loader',\n {\n loader: 'image-webpack-loader',\n options: {\n // 配置选项\n },\n },\n ],\n },\n ],\n}\n```\n\n### 8. **使用动态 Polyfills**\n\n只为那些实际需要它们的浏览器提供 polyfills，而不是所有浏览器都提供。\n\n以上方法和技巧可以根据项目的具体需求和情况灵活使用，有的方法可能会对构建和重构现有代码产生较大影响，因此在采用前应评估其必要性和影响。\n\n### 9. **高版本浏览器直接使用 es6 代码**\n\n将代码编译（或者说不编译）为 ES6（ECMAScript 2015）或更高版本的 JavaScript 代码，确实可以减少产物体积。\n",{"_58":692,"_174":145,"_175":145,"_176":145,"_177":145,"_178":145,"_179":145,"_180":145,"_181":145,"_182":145},"https://api.github.com/repos/pro-collection/interview-question/issues/887/reactions","https://api.github.com/repos/pro-collection/interview-question/issues/887/timeline",{"_58":695,"_60":61,"_62":696,"_64":697,"_66":698,"_68":699,"_70":700,"_72":701,"_74":702,"_76":703,"_78":704,"_111":705,"_124":125,"_126":24,"_127":-5,"_128":708,"_130":709,"_152":145,"_146":711,"_148":712,"_151":-5,"_155":156,"_106":-5,"_157":-5,"_158":713,"_163":714,"_169":715,"_171":716,"_183":718,"_185":-5,"_186":-5,"_187":188},"https://api.github.com/repos/pro-collection/interview-question/issues/886","https://api.github.com/repos/pro-collection/interview-question/issues/886/labels{/name}","https://api.github.com/repos/pro-collection/interview-question/issues/886/comments","https://api.github.com/repos/pro-collection/interview-question/issues/886/events","https://github.com/pro-collection/interview-question/issues/886",2526832828,"I_kwDOJGDC6c6WnGi8",886,"[webpack] 代码分割中，让所有的外部依赖打成一个包，源码 source 打成一个包，该如何配置【热度: 352】",{"_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},[706,707],{"_70":114,"_72":115,"_58":116,"_117":118,"_119":120,"_121":24,"_122":123},{"_70":495,"_72":496,"_58":497,"_117":498,"_119":231,"_121":24,"_122":232},[],{"_58":132,"_68":133,"_62":134,"_70":135,"_72":136,"_74":137,"_76":138,"_122":139,"_140":710,"_142":143,"_144":145,"_124":125,"_146":147,"_148":149,"_150":-5,"_151":-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},"2024-09-15T09:48:05Z","2024-09-17T02:40:21Z",{"_160":145,"_161":145,"_162":145},{"_165":145,"_166":145,"_167":145,"_168":145},"**关键词**：webpack 代码分割\n\n为了实现你的需求，即将所有外部依赖（`node_modules` 中的依赖）打包成一个单独的包，而你自己的源码打包成另一个包，可以通过配置 Webpack 的 `optimization.splitChunks` 选项来实现。下面是具体的实施方案：\n\n### 1. 编辑 `webpack.config.js`\n\n在你的 `webpack.config.js` 配置文件中，找到或添加 `optimization` 部分，并在 `splitChunks` 中配置如下：\n\n```javascript\nmodule.exports = {\n // ...其他配置\n\n optimization: {\n runtimeChunk: \"single\", // 为 webpack 运行时代码创建一个额外的包\n splitChunks: {\n cacheGroups: {\n vendor: {\n // 定义一个缓存组用以分离外部依赖\n test: /[\\\\/]node_modules[\\\\/]/, // 检索 node_modules 目录下的模块\n name: \"vendors\", // 分离后的包名称\n chunks: \"all\", // 对所有模块生效\n },\n source: {\n // 我们可以通过添加另一个缓存组来实现源码的分离（如果需要）\n test: /[\\\\/]src[\\\\/]/, // 检索 src 目录\n name: \"source\",\n chunks: \"all\",\n },\n },\n },\n },\n};\n```\n\n### 解释\n\n- `runtimeChunk: 'single'` 创建一个运行时文件，管理模块化交互，比如加载和解析模块。\n- 在`splitChunks.cacheGroups` 中定义了两个缓存组:\n - `vendor`：这个缓存组的目标是将来自 `node_modules` 目录的所有代码移动到命名为 `vendors` 的包中。它通过 `test` 属性来匹配 `node_modules` 目录下的模块。\n - `source`：这个部分是为了演示如何单独将 `src` 目录下的源代码打包成一个文件。这不是必须的，因为默认情况下，Webpack 会将未被上述规则匹配到的模块（即你的源代码）打包到主包中。\n",{"_58":717,"_174":145,"_175":145,"_176":145,"_177":145,"_178":145,"_179":145,"_180":145,"_181":145,"_182":145},"https://api.github.com/repos/pro-collection/interview-question/issues/886/reactions","https://api.github.com/repos/pro-collection/interview-question/issues/886/timeline",{"_58":720,"_60":61,"_62":721,"_64":722,"_66":723,"_68":724,"_70":725,"_72":726,"_74":727,"_76":728,"_78":729,"_111":730,"_124":125,"_126":24,"_127":-5,"_128":733,"_130":734,"_152":145,"_146":736,"_148":737,"_151":-5,"_155":156,"_106":-5,"_157":-5,"_158":738,"_163":739,"_169":740,"_171":741,"_183":743,"_185":-5,"_186":-5,"_187":188},"https://api.github.com/repos/pro-collection/interview-question/issues/841","https://api.github.com/repos/pro-collection/interview-question/issues/841/labels{/name}","https://api.github.com/repos/pro-collection/interview-question/issues/841/comments","https://api.github.com/repos/pro-collection/interview-question/issues/841/events","https://github.com/pro-collection/interview-question/issues/841",2471819478,"I_kwDOJGDC6c6TVPjW",841,"[webpack] 多个 loader 对同一个资源进行处理，他们之间如何通信？【热度: 134】",{"_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},[731,732],{"_70":114,"_72":115,"_58":116,"_117":118,"_119":120,"_121":24,"_122":123},{"_70":495,"_72":496,"_58":497,"_117":498,"_119":231,"_121":24,"_122":232},[],{"_58":132,"_68":133,"_62":134,"_70":135,"_72":136,"_74":137,"_76":138,"_122":139,"_140":735,"_142":143,"_144":145,"_124":125,"_146":147,"_148":149,"_150":-5,"_151":-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},"2024-08-18T06:40:58Z","2024-08-18T06:40:59Z",{"_160":145,"_161":145,"_162":145},{"_165":145,"_166":145,"_167":145,"_168":145},"**关键词**：webpack loader 通信\n\n在 webpack 中，loader 之间传递数据的常见方式是通过资源文件（即要处理的源文件本身）的内容。每个 loader 接收上一个 loader 的处理结果作为输入，并提供自己的输出给下一个 loader。这种方式适用于大多数使用场景。然而，在某些情况下，loader 需要在它们之间共享额外的状态或数据，而不仅仅是文件内容。对于这种需求，webpack 提供了一种机制，允许 loader 之间共享数据。\n\n### 使用 `this.data`\n\n在 webpack 4 及以后的版本中，一个 loader 可以利用它的 `this.data` 属性来共享会话数据。这个属性是特定于当前 loader 运行实例的，可以在 loader 的 `pitch` 阶段和正常的加载阶段之间共享数据。\n\n```javascript\n// pitch 阶段\nmodule.exports.pitch = function (remainingRequest, precedingRequest, data) {\n data.sharedValue = \"Hello from pitch phase\";\n};\n```\n\n在上面的代码片段中，`pitch` 方法设置了 `data.sharedValue`。这个 `pitch` 方法是可选的，它在 loader 处理资源之前执行。`data` 对象会从 `pitch` 阶段传递到正常的加载阶段，从而可以在后者中访问之前设置的共享值。\n\n```javascript\n// 正常的加载阶段\nmodule.exports = function (content) {\n const callback = this.async();\n const sharedValue = this.data.sharedValue;\n\n // 这里可以根据 sharedValue 来处理 content\n console.log(sharedValue); // 将输出 \"Hello from pitch phase\"\n\n callback(null, content);\n};\n```\n\n### 使用自定义属性\n\n一些特定的 loader 实现可能通过向源文件内容附加额外的信息来实现间接的通信。例如，一个 loader 可以在文件内容的末尾追加一些注释或者特殊标记，然后下一个 loader 可以读取这些注释或标记来获取必要的信息。然而，这种方法是高度依赖上下文且难以维护的，不推荐在实际项目中使用。\n\n### 注意事项\n\n当使用一种方法在 loader 之间共享数据时，请注意数据的共享是在每个模块的构建过程中进行的，这些数据是特定于当前处理中的资源文件的。通过这种方式共享的数据不应该包含敏感信息，也不应该用于在不同模块或不同构建之间共享全局状态。\n\n理解这些机制以及如何在 loader 之间正确共享数据是创建高效可维护 webpack 构建流程的关键。\n",{"_58":742,"_174":145,"_175":145,"_176":145,"_177":145,"_178":145,"_179":145,"_180":145,"_181":145,"_182":145},"https://api.github.com/repos/pro-collection/interview-question/issues/841/reactions","https://api.github.com/repos/pro-collection/interview-question/issues/841/timeline",{"_58":745,"_60":61,"_62":746,"_64":747,"_66":748,"_68":749,"_70":750,"_72":751,"_74":752,"_76":753,"_78":754,"_111":755,"_124":125,"_126":24,"_127":-5,"_128":758,"_130":759,"_152":145,"_146":761,"_148":761,"_151":-5,"_155":156,"_106":-5,"_157":-5,"_158":762,"_163":763,"_169":764,"_171":765,"_183":767,"_185":-5,"_186":-5,"_187":188},"https://api.github.com/repos/pro-collection/interview-question/issues/840","https://api.github.com/repos/pro-collection/interview-question/issues/840/labels{/name}","https://api.github.com/repos/pro-collection/interview-question/issues/840/comments","https://api.github.com/repos/pro-collection/interview-question/issues/840/events","https://github.com/pro-collection/interview-question/issues/840",2471818589,"I_kwDOJGDC6c6TVPVd",840,"[webpack] 手写 webpack loader 有哪些重要 api 与注意事项？【热度: 718】",{"_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},[756,757],{"_70":114,"_72":115,"_58":116,"_117":118,"_119":120,"_121":24,"_122":123},{"_70":495,"_72":496,"_58":497,"_117":498,"_119":231,"_121":24,"_122":232},[],{"_58":132,"_68":133,"_62":134,"_70":135,"_72":136,"_74":137,"_76":138,"_122":139,"_140":760,"_142":143,"_144":145,"_124":125,"_146":147,"_148":149,"_150":-5,"_151":-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},"2024-08-18T06:38:27Z",{"_160":145,"_161":145,"_162":145},{"_165":145,"_166":145,"_167":145,"_168":145},"**关键词**：手写 webpack loader\n\n在开发一个 webpack loader 时，除了理解 loader 的基本概念和功能之外，还有一些重要的 API 和注意事项是必需了解的。这些能够帮助你更高效地编写和调试 loader。\n\n### 重要 API\n\n1. **this.callback**:\n\n - 在 loader 函数内部，`this.callback` 是一个允许 loader 异步返回结果的函数。你可以通过 `this.callback(err, content, sourceMap, meta)` 来传递错误或返回结果。\n\n2. **this.async**:\n\n - 调用 `this.async` 会返回一个 callback 函数，你可以在异步操作完成后通过这个函数返回结果。如果 loader 要进行异步处理，这个方法非常有用。\n\n3. **this.loaders**:\n\n - `this.loaders` 是一个包含所有需要应用到当前处理文件的 loaders 的数组，当前 loader 的信息也包含在内。\n\n4. **this.resourcePath** 和 **this.resourceQuery**:\n\n - 这两个属性提供了当前正在处理的资源文件的路径和查询字符串。\n\n5. **this.data**:\n\n - 在 loader 的 pitch 阶段和普通阶段之间共享数据的自由对象。\n\n6. **Loader Utils (loader-utils)**:\n - `loader-utils` 提供了一些实用的工具函数，比如 `getOptions(this)` 用于获取 loader 配置项。\n\n### 注意事项\n\n1. **使用异步 API 处理异步任务**:\n\n - 对于需要进行异步操作的 loader，应使用 `this.async` 来获取异步 callback 函数，而不是直接返回内容。\n\n2. **保持 loader 的简单**:\n\n - 按照最佳实践，每个 loader 只做一件事情。这让 loader 链更加灵活和可维护。\n\n3. **避免使用箭头函数**:\n\n - 在编写 loader 时，避免使用箭头函数来声明 loader 函数，因为箭头函数会绑定父作用域的 `this`，而你需要访问 webpack 传递给 loader 函数的 `this` 上下文。\n\n4. **处理异常**:\n\n - 在处理资源的过程中，如果遇到错误，应该使用 `this.emitError` 方法或通过 `this.callback` 函数的第一个参数传递错误。\n\n5. **缓存**:\n\n - 除非有特定的理由，否则避免关闭 loader 的缓存。webpack 默认会缓存 loader 的结果，以提升构建性能。\n\n6. **资源映射（Source Maps）**:\n\n - 如果你的 loader 转换源内容，生成新的源内容，应当生成新的 source map。然后，使用 `this.callback` 来返回更新后的代码和对应的 source map。\n\n7. **通信**:\n - 如果有多个 loader 对同一个资源进行处理，它们之间可以通过 `this.data` 来共享数据。\n\n掌握并妥当使用上述 API 和注意事项，将帮助你开发出高效、健壮且易于维护的 webpack loader。\n",{"_58":766,"_174":145,"_175":145,"_176":145,"_177":145,"_178":145,"_179":145,"_180":145,"_181":145,"_182":145},"https://api.github.com/repos/pro-collection/interview-question/issues/840/reactions","https://api.github.com/repos/pro-collection/interview-question/issues/840/timeline",{"_58":769,"_60":61,"_62":770,"_64":771,"_66":772,"_68":773,"_70":774,"_72":775,"_74":776,"_76":777,"_78":778,"_111":779,"_124":125,"_126":24,"_127":-5,"_128":782,"_130":783,"_152":145,"_146":785,"_148":786,"_151":-5,"_155":156,"_106":-5,"_157":-5,"_158":787,"_163":788,"_169":789,"_171":790,"_183":792,"_185":-5,"_186":-5,"_187":188},"https://api.github.com/repos/pro-collection/interview-question/issues/839","https://api.github.com/repos/pro-collection/interview-question/issues/839/labels{/name}","https://api.github.com/repos/pro-collection/interview-question/issues/839/comments","https://api.github.com/repos/pro-collection/interview-question/issues/839/events","https://github.com/pro-collection/interview-question/issues/839",2471817712,"I_kwDOJGDC6c6TVPHw",839,"[webpack] 手写 loader: 我要在方法调用的时候，上报调用源文件地址【热度: 117】",{"_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},[780,781],{"_70":114,"_72":115,"_58":116,"_117":118,"_119":120,"_121":24,"_122":123},{"_70":495,"_72":496,"_58":497,"_117":498,"_119":231,"_121":24,"_122":232},[],{"_58":132,"_68":133,"_62":134,"_70":135,"_72":136,"_74":137,"_76":138,"_122":139,"_140":784,"_142":143,"_144":145,"_124":125,"_146":147,"_148":149,"_150":-5,"_151":-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},"2024-08-18T06:36:13Z","2024-08-18T06:36:14Z",{"_160":145,"_161":145,"_162":145},{"_165":145,"_166":145,"_167":145,"_168":145},"**关键词**：手写 webpack loader\n\n要在方法调用时上报调用源文件的地址，并且希望通过 webpack 编译时来实现，你可以通过编写一个自定义的 webpack loader 来操作源代码，为特定的方法调用插入上报的代码。自定义 loader 本质上是一个函数，该函数接收源码作为输入，对源码进行处理后返回新的源码。\n\n### 步骤 1: 设计你的上报逻辑\n\n首先明确你想要上报的信息和上报的方式。比如，你可能想要在方法调用时，插入一个上报函数调用，该函数包含当前文件的路径和文件名。\n\n### 步骤 2: 创建自定义 Loader\n\n你可以开始编写你的 loader。假设你有一个上报函数 `reportFunction(filePath)`，你希望自动为所有 `targetMethod()` 调用注入这个上报函数。\n\nloader 文件 `report-loader.js` 可能看起来像这样：\n\n```javascript\nmodule.exports = function (source) {\n // 使用此 loader 处理的文件的路径\n const filePath = this.resourcePath;\n\n // 定义一个正则表达式匹配特定的方法调用，比如 targetMethod()\n const methodCallRegex = /targetMethod\\(\\)/g;\n\n // 替换匹配到的方法调用\n const modifiedSource = source.replace(methodCallRegex, function (match) {\n // 插入上报函数调用，传入文件路径\n return `reportFunction('${filePath}'); ${match}`;\n });\n\n return modifiedSource;\n};\n```\n\n这个简单的 loader 使用正则表达式查找文件中所有的 `targetMethod()` 调用，并在每个调用前插入 `reportFunction(filePath)` 的调用。注意，考虑到文件路径可能需要处理才能安全地用作字符串字面量（例如，转义特殊字符），这里的实现做得很简单，可能需要根据你的具体需求调整。\n\n### 步骤 3: 在 webpack 配置中使用你的 Loader\n\n在你的 `webpack.config.js` 文件中，添加一个 `module.rules` 条目，以确定哪些文件应该通过你的 loader 处理：\n\n```javascript\nmodule.exports = {\n module: {\n rules: [\n {\n test: /\\.js$/, // 匹配 JavaScript 文件\n use: [\n {\n loader: \"path/to/your/report-loader.js\", // 使用自定义 loader 的路径\n },\n ],\n },\n ],\n },\n};\n```\n\n确保将 `loader` 属性设置为你自定义 loader 文件的路径。\n\n### 注意事项\n\n1. **正则表达式**: 我在例子中使用的正则表达式非常简单，只匹配特定形式的方法调用。根据你的需要，可能要编写更复杂的正则表达式或使用其他方法（比如抽象语法树解析库，如 Babel）来更准确地识别和修改代码。\n\n2. **安全性**: 自动修改源代码会带来风险，确保你的匹配和替换逻辑不会导致代码中出现意外的改变。\n\n3. **性能**: 增加自定义 loader 可能会影响构建的速度，特别是匹配和修改逻辑比较复杂的时候。\n\n编写和测试好你的 loader 后，就可以集成到你的项目中，通过 webpack 构建过程中自动执行所需的代码注入了。\n",{"_58":791,"_174":145,"_175":145,"_176":145,"_177":145,"_178":145,"_179":145,"_180":145,"_181":145,"_182":145},"https://api.github.com/repos/pro-collection/interview-question/issues/839/reactions","https://api.github.com/repos/pro-collection/interview-question/issues/839/timeline",{"_58":794,"_60":61,"_62":795,"_64":796,"_66":797,"_68":798,"_70":799,"_72":800,"_74":801,"_76":802,"_78":803,"_111":804,"_124":125,"_126":24,"_127":-5,"_128":811,"_130":812,"_152":145,"_146":814,"_148":815,"_151":-5,"_155":156,"_106":-5,"_157":-5,"_158":816,"_163":817,"_169":818,"_171":819,"_183":821,"_185":-5,"_186":-5,"_187":188},"https://api.github.com/repos/pro-collection/interview-question/issues/838","https://api.github.com/repos/pro-collection/interview-question/issues/838/labels{/name}","https://api.github.com/repos/pro-collection/interview-question/issues/838/comments","https://api.github.com/repos/pro-collection/interview-question/issues/838/events","https://github.com/pro-collection/interview-question/issues/838",2471815945,"I_kwDOJGDC6c6TVOsJ",838,"[webpack] 手写 webpack plugin 有那些重要 api 与注意的地方？【热度: 714】",{"_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},[805,806],{"_70":114,"_72":115,"_58":116,"_117":118,"_119":120,"_121":24,"_122":123},{"_70":807,"_72":808,"_58":809,"_117":810,"_119":231,"_121":24,"_122":232},5342931240,"LA_kwDOJGDC6c8AAAABPnapKA","https://api.github.com/repos/pro-collection/interview-question/labels/%E7%BE%8E%E5%9B%A2","美团",[],{"_58":132,"_68":133,"_62":134,"_70":135,"_72":136,"_74":137,"_76":138,"_122":139,"_140":813,"_142":143,"_144":145,"_124":125,"_146":147,"_148":149,"_150":-5,"_151":-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},"2024-08-18T06:31:33Z","2024-08-18T06:37:05Z",{"_160":145,"_161":145,"_162":145},{"_165":145,"_166":145,"_167":145,"_168":145},"**关键词**：手写 webpack plugin\n\n在手写一个 webpack 插件时，理解和使用一些核心的 API 是非常关键的。以下是编写 webpack 插件时需要知道的一些重要的 API 和注意事项。\n\n### 重要的 API\n\n1. **compiler 对象**:\n\n - `compiler.hooks`: 提供了一系列的钩子，用于插件挂载到 webpack 的整个编译过程。这些钩子包括：\n - `compile`、`compilation`：允许你在编译器开始编译以及创建新的编译对象时挂载功能。\n - `emit`、`done`：这些阶段更适合于生成资源、修改输出和记录状态。\n\n2. **compilation 对象**:\n\n - 同样提供了一系列钩子，它们以更细粒度控制编译阶段，比如：\n - `optimize`、`optimizeModules`：用于优化阶段。\n - `buildModule`：在构建模块时触发。\n - `moduleAssets`：处理模块产出的资源。\n\n3. **tapable**:\n - webpack 依赖于 tapable 库来实现钩子系统。使用 `tap()` 或 `tapAsync()` 方法来挂载这些钩子。这些方法通常接受两个参数：插件名称和一个回调函数。\n\n### 注意的地方\n\n1. **异步操作**:\n - 如果你的插件中涉及异步操作，确保正确处理。如果使用异步钩子，可以使用 `tapAsync()` 方法，它提供了一个回调函数来告知 webpack 何时异步操作完成。\n2. **资源操作**:\n\n - 当操作 compilation 中的资源时，务必小心。确保不要删除或覆盖 webpack 或其他插件所需的关键资源。\n\n3. **性能考虑**:\n - 插件的性能影响编译时长。避免在插件中执行过重的操作，尤其是在像 `compiler` 或 `compilation` 这样的生命周期钩子中，它们会影响到整个编译过程。\n4. **webpack 版本兼容性**:\n\n - webpack 的 API 在不同版本间可能会有变动。编写插件时，需要注意兼容性，并明确指出插件支持的 webpack 版本范围。\n\n5. **钩子选择**:\n - 精确选择最适合的钩子对性能和功能都至关重要。了解每个钩子的含义和最佳用途能帮助插件更高效地工作。\n\n### 示例\n\n以下是一个简单的 webpack 插件示例，展示了如何使用上述 API：\n\n```javascript\nclass MyWebpackPlugin {\n apply(compiler) {\n // 监听 emit 钩子\n compiler.hooks.emit.tapAsync(\"MyWebpackPlugin\", (compilation, callback) => {\n // 在这里可以处理 compilation 中的资源、模块等\n console.log(\"This is an example webpack plugin!\");\n\n // 完成插件处理后调用 callback 通知 webpack\n callback();\n });\n }\n}\n```\n\n这个简单的插件打印一条消息，在 `emit` 阶段被触发。尽管这个示例很基础，但是它展示了插件的基本结构和一些重要的 API。记得在编写更复杂的插件时阅读并理解 webpack 的文档，以利用 webpack 提供的完整能力。\n",{"_58":820,"_174":145,"_175":145,"_176":145,"_177":145,"_178":145,"_179":145,"_180":145,"_181":145,"_182":145},"https://api.github.com/repos/pro-collection/interview-question/issues/838/reactions","https://api.github.com/repos/pro-collection/interview-question/issues/838/timeline",{"_58":823,"_60":61,"_62":824,"_64":825,"_66":826,"_68":827,"_70":828,"_72":829,"_74":830,"_76":831,"_78":832,"_111":833,"_124":125,"_126":24,"_127":-5,"_128":836,"_130":837,"_152":145,"_146":839,"_148":840,"_151":-5,"_155":156,"_106":-5,"_157":-5,"_158":841,"_163":842,"_169":843,"_171":844,"_183":846,"_185":-5,"_186":-5,"_187":188},"https://api.github.com/repos/pro-collection/interview-question/issues/837","https://api.github.com/repos/pro-collection/interview-question/issues/837/labels{/name}","https://api.github.com/repos/pro-collection/interview-question/issues/837/comments","https://api.github.com/repos/pro-collection/interview-question/issues/837/events","https://github.com/pro-collection/interview-question/issues/837",2471814773,"I_kwDOJGDC6c6TVOZ1",837,"[webpack] 手写一个 plugin, 统计源码里面的 console.log 调用数量与调用路径【热度: 113】",{"_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},[834,835],{"_70":114,"_72":115,"_58":116,"_117":118,"_119":120,"_121":24,"_122":123},{"_70":807,"_72":808,"_58":809,"_117":810,"_119":231,"_121":24,"_122":232},[],{"_58":132,"_68":133,"_62":134,"_70":135,"_72":136,"_74":137,"_76":138,"_122":139,"_140":838,"_142":143,"_144":145,"_124":125,"_146":147,"_148":149,"_150":-5,"_151":-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},"2024-08-18T06:28:25Z","2024-08-18T06:31:21Z",{"_160":145,"_161":145,"_162":145},{"_165":145,"_166":145,"_167":145,"_168":145},"**关键词**：手写 webpack plugin\n\n创建一个 webpack 插件需要遵循 webpack 插件的基本结构和原则，同时为了实现统计源码里的 `console.log` 调用数量与调用路径的目标，我们可能需要对 webpack 的编译过程有一定的了解，尤其是如何操作 webpack 的模块系统内部的原始源代码。\n\n以下是创建这样一个插件的步骤与代码示例：\n\n### 步骤 1: 定义插件类\n\n首先，你需要定义一个 JavaScript 类。在类的 `apply` 方法中，你将会监听 webpack 的 `compilation` 钩子来访问并处理模块的源代码。\n\n### 步骤 2: 监听适当的 webpack 钩子\n\n针对源代码的处理，我们选择监听 `compilation` 阶段的 `optimizeModules` 钩子。在这个阶段，模块的原始源代码可以被访问和修改。\n\n### 步骤 3: 处理源代码\n\n处理每个模块的源代码，你可以使用简单的正则表达式或更高级的方法（如 AST 解析）来识别 `console.log` 的调用。在这个示例中，我将使用正则表达式来简化处理流程。\n\n### 代码示例\n\n下面是一个插件的基本实现：\n\n```javascript\nclass ConsoleLogStatsPlugin {\n apply(compiler) {\n compiler.hooks.compilation.tap(\"ConsoleLogStatsPlugin\", (compilation) => {\n compilation.moduleTemplates.javascript.hooks.render.tap(\"ConsoleLogStatsPlugin\", (moduleSource, module) => {\n // 计算当前模块的 console.log 调用并记录文件路径\n const source = moduleSource.source();\n const consoleLogMatches = source.match(/console\\.log\\(/g) || [];\n\n if (consoleLogMatches.length > 0) {\n console.log(`模块 ${module.resource} 包含 ${consoleLogMatches.length} 次 console.log 调用。`);\n }\n\n return moduleSource;\n });\n });\n }\n}\n\nmodule.exports = ConsoleLogStatsPlugin;\n```\n\n### 使用该插件\n\n要在你的 webpack 配置中使用这个插件，首先要导入它，然后将它的一个实例添加到配置的 `plugins` 数组中：\n\n```javascript\nconst ConsoleLogStatsPlugin = require(\"./path/to/ConsoleLogStatsPlugin\");\n\nmodule.exports = {\n // ...其他配置...\n plugins: [\n new ConsoleLogStatsPlugin(),\n // ...其他插件...\n ],\n};\n```\n\n### 注意事项\n\n- **性能考虑**：直接操作源码可能对构建性能有一定影响。如果项目较大，可能需要考虑更高效的方式，例如仅在生产构建中运行该插件，或者使用更高效的代码分析方法。\n- **正则表达式的局限性**：简单的正则表达式可能无法准确匹配所有 `console.log` 调用的场景，尤其是当代码中包含多行语句或复杂表达式时。更复杂的场景可能需要使用抽象语法树（AST）解析工具，如 Babel。\n- **webpack 版本兼容性**：webpack 的插件 API 在不同的版本之间可能会有所变化。上述代码示例是基于假定的 API 结构编写的，实际使用时需要根据你的 webpack 版本调整 API 的使用。\n\n此插件可以视为检测源代码中 `console.log` 使用情况的起点，可以根据具体需求进行扩展和优化。\n",{"_58":845,"_174":145,"_175":145,"_176":145,"_177":145,"_178":145,"_179":145,"_180":145,"_181":145,"_182":145},"https://api.github.com/repos/pro-collection/interview-question/issues/837/reactions","https://api.github.com/repos/pro-collection/interview-question/issues/837/timeline",{"_58":848,"_60":61,"_62":849,"_64":850,"_66":851,"_68":852,"_70":853,"_72":854,"_74":855,"_76":856,"_78":857,"_111":858,"_124":125,"_126":24,"_127":-5,"_128":865,"_130":866,"_152":145,"_146":868,"_148":869,"_151":-5,"_155":156,"_106":-5,"_157":-5,"_158":870,"_163":871,"_169":872,"_171":873,"_183":875,"_185":-5,"_186":-5,"_187":188},"https://api.github.com/repos/pro-collection/interview-question/issues/816","https://api.github.com/repos/pro-collection/interview-question/issues/816/labels{/name}","https://api.github.com/repos/pro-collection/interview-question/issues/816/comments","https://api.github.com/repos/pro-collection/interview-question/issues/816/events","https://github.com/pro-collection/interview-question/issues/816",2458887841,"I_kwDOJGDC6c6Sj6ah",816,"[webpack] 构建过程中，是如何将我们 es6 代码编译为 es5【热度: 420】",{"_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},[859,860],{"_70":114,"_72":115,"_58":116,"_117":118,"_119":120,"_121":24,"_122":123},{"_70":861,"_72":862,"_58":863,"_117":864,"_119":231,"_121":24,"_122":232},6294910473,"LA_kwDOJGDC6c8AAAABdzS2CQ","https://api.github.com/repos/pro-collection/interview-question/labels/TOP100%E4%BA%92%E8%81%94%E7%BD%91","TOP100互联网",[],{"_58":304,"_68":305,"_62":306,"_70":307,"_72":308,"_74":309,"_76":310,"_122":311,"_140":867,"_142":313,"_144":145,"_124":125,"_146":314,"_148":315,"_150":-5,"_151":-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},"2024-08-10T04:15:18Z","2024-08-10T04:15:19Z",{"_160":145,"_161":145,"_162":145},{"_165":145,"_166":145,"_167":145,"_168":145},"**关键词**：es6 编译为 es5\n\nWebpack 本身是一个模块打包器（bundler），它并不直接负责将 ES6 代码编译为 ES5 代码。Webpack 的主要功能是将项目中的所有模块（JavaScript、图片、CSS 等）打包成一个或多个 bundle，以供浏览器加载。然而，Webpack 可以通过加载器（loaders）和插件（plugins）来扩展其功能，实现代码的转换和编译。\n\n将 ES6 代码编译为 ES5 的过程通常涉及以下几个步骤：\n\n1. **Babel 转换**：\n Babel 是一个流行的 JavaScript 编译器，可以将 ES6+ 代码转换为向后兼容的 JavaScript 版本，即 ES5。Webpack 可以与 Babel 配合使用，通过 Babel Loader 来实现代码的转换。\n\n2. **Loader 配置**：\n 在 Webpack 配置中，你可以指定使用 Babel Loader 来处理 `.js` 文件。当 Webpack 处理 JavaScript 文件时，Babel Loader 会被调用，并将 ES6 代码转换为 ES5。\n\n ```javascript\n // webpack.config.js\n module.exports = {\n // ...\n module: {\n rules: [\n {\n test: /\\.js$/,\n use: {\n loader: \"babel-loader\",\n options: {\n presets: [\"@babel/preset-env\"],\n },\n },\n },\n ],\n },\n // ...\n };\n ```\n\n3. **Babel 预设**：\n Babel 使用预设（presets）来定义转换规则。`@babel/preset-env` 是一个常用的预设，它会自动配置 Babel 以兼容目标浏览器的版本。\n\n4. **Polyfills**：\n 为了支持旧浏览器，Babel 还可以引入 polyfills，这些是提供现代 JavaScript 特性的第三方代码片段。例如，`core-js` 和 `regenerator-runtime` 是两个常用的 polyfill 库。\n\n5. **转换过程**：\n\n - **解析**：Babel 首先解析 ES6 代码为 AST（抽象语法树）。\n - **转换**：然后，Babel 遍历 AST，将 ES6 语法转换为 ES5 语法。\n - **生成**：最后，Babel 生成新的 ES5 代码。\n\n6. **Tree Shaking**：\n Webpack 支持 Tree Shaking，这是一种去除未使用代码的技术，可以进一步减小最终打包文件的大小。\n\n7. **代码分割**：\n Webpack 还可以进行代码分割，将代码拆分成多个 chunk，按需加载，提高应用的加载性能。\n\n8. **优化**：\n Webpack 还提供了多种优化选项，如压缩代码、合并模块等，以减小最终输出文件的大小。\n\n总结来说，Webpack 本身不直接编译 ES6 代码为 ES5，**而是通过与 Babel 等工具的配合使用，实现代码的转换和编译。Webpack 的主要作用是模块打包，而 Babel 负责将现代 JavaScript 代码转换为广泛兼容的格式。**通过合理配置 Webpack 和 Babel，可以高效地构建和优化前端应用。\n",{"_58":874,"_174":145,"_175":145,"_176":145,"_177":145,"_178":145,"_179":145,"_180":145,"_181":145,"_182":145},"https://api.github.com/repos/pro-collection/interview-question/issues/816/reactions","https://api.github.com/repos/pro-collection/interview-question/issues/816/timeline",{"_58":877,"_60":61,"_62":878,"_64":879,"_66":880,"_68":881,"_70":882,"_72":883,"_74":884,"_76":885,"_78":886,"_111":887,"_124":125,"_126":24,"_127":-5,"_128":890,"_130":891,"_152":145,"_146":893,"_148":894,"_151":-5,"_155":156,"_106":-5,"_157":-5,"_158":895,"_163":896,"_169":897,"_171":898,"_183":900,"_185":-5,"_186":-5,"_187":188},"https://api.github.com/repos/pro-collection/interview-question/issues/805","https://api.github.com/repos/pro-collection/interview-question/issues/805/labels{/name}","https://api.github.com/repos/pro-collection/interview-question/issues/805/comments","https://api.github.com/repos/pro-collection/interview-question/issues/805/events","https://github.com/pro-collection/interview-question/issues/805",2421178435,"I_kwDOJGDC6c6QUEBD",805,"babel-runtime 作用是啥【热度: 200】",{"_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},[888,889],{"_70":114,"_72":115,"_58":116,"_117":118,"_119":120,"_121":24,"_122":123},{"_70":436,"_72":437,"_58":438,"_117":439,"_119":231,"_121":24,"_122":232},[],{"_58":132,"_68":133,"_62":134,"_70":135,"_72":136,"_74":137,"_76":138,"_122":139,"_140":892,"_142":143,"_144":145,"_124":125,"_146":147,"_148":149,"_150":-5,"_151":-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},"2024-07-21T02:25:24Z","2024-07-21T02:25:25Z",{"_160":145,"_161":145,"_162":145},{"_165":145,"_166":145,"_167":145,"_168":145},"**关键词**：babel-runtime 作用\n\n`babel-runtime` 是一个包含 `babel` 模块化运行时助手的库。\n\n在使用 `babel` 进行代码转换时，有时会注入一些在多个文件中相同且可能被重复使用的代码。例如，使用类转换（无松散模式）时，每个包含类的文件都会重复出现类似 `_classcallcheck` 这样的函数。\n\n`babel-runtime` 的主要作用就是将这些可能被重用的代码抽取成单独的模块，以避免在每个文件中重复出现相同的代码。它通过模块导入的方式引入这些功能，从而避免了对全局作用域的修改或污染。\n\n具体来说，`babel-runtime` 包含了诸如 `core-js`（提供 JavaScript 内置库的垫片，如 `array`、`json`、`math`、`promise`、`symbol` 等）、`regenerator-runtime`（实现了 `generator/yield`、`async/await`）以及一些语法转换的辅助函数（如 `es5` 与 `es6` 的继承转换等）。\n\n使用 `babel-runtime` 通常需要配合 `babel-plugin-transform-runtime` 插件一起使用。`babel-plugin-transform-runtime` 插件会进行一些处理，例如自动导入 `babel-runtime/core-js`，并将全局静态方法、全局内置对象映射到对应的模块；将内联的工具函数移除，改成通过 `babel-runtime/helpers` 模块进行导入；如果使用了 `async/generator` 函数，则自动导入 `babel-runtime/regenerator` 模块等。\n\n这样，在代码中如果需要使用特定的功能，只需从 `babel-runtime` 相应的模块中导入即可，而不是直接使用全局的对象或函数。\n\n例如，如果代码中使用了 `promise`，可以这样导入：\n\n```javascript\nimport promise from \"babel-runtime/core-js/promise\";\n```\n\n总的来说，`babel-runtime` 更像是一种按需加载的实现方式，适用于开发库、工具等场景，可避免对全局作用域的污染，同时减少重复代码。\n",{"_58":899,"_174":145,"_175":145,"_176":145,"_177":145,"_178":145,"_179":145,"_180":145,"_181":145,"_182":145},"https://api.github.com/repos/pro-collection/interview-question/issues/805/reactions","https://api.github.com/repos/pro-collection/interview-question/issues/805/timeline",{"_58":902,"_60":61,"_62":903,"_64":904,"_66":905,"_68":906,"_70":907,"_72":908,"_74":909,"_76":910,"_78":911,"_111":912,"_124":125,"_126":24,"_127":-5,"_128":915,"_130":916,"_152":145,"_146":918,"_148":918,"_151":-5,"_155":156,"_106":-5,"_157":-5,"_158":919,"_163":920,"_169":921,"_171":922,"_183":924,"_185":-5,"_186":-5,"_187":188},"https://api.github.com/repos/pro-collection/interview-question/issues/783","https://api.github.com/repos/pro-collection/interview-question/issues/783/labels{/name}","https://api.github.com/repos/pro-collection/interview-question/issues/783/comments","https://api.github.com/repos/pro-collection/interview-question/issues/783/events","https://github.com/pro-collection/interview-question/issues/783",2405419143,"I_kwDOJGDC6c6PX8iH",783,"应用如何做应用灰度发布【热度: 247】",{"_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},[913,914],{"_70":114,"_72":115,"_58":116,"_117":118,"_119":120,"_121":24,"_122":123},{"_70":436,"_72":437,"_58":438,"_117":439,"_119":231,"_121":24,"_122":232},[],{"_58":132,"_68":133,"_62":134,"_70":135,"_72":136,"_74":137,"_76":138,"_122":139,"_140":917,"_142":143,"_144":145,"_124":125,"_146":147,"_148":149,"_150":-5,"_151":-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},"2024-07-12T12:04:10Z",{"_160":145,"_161":145,"_162":145},{"_165":145,"_166":145,"_167":145,"_168":145},"**关键词**：灰度发布\n\n应用的灰度发布是将新版本逐步推出给有限的用户群体，以在完全发布之前监控其性能和搜集用户反馈的过程。这可以确保新版本的稳健性，减少因新版本可能引起的问题对所有用户的影响。以下是实现应用灰度发布的几种常见方法：\n\n### 1. 基于 HTTP 头或 Cookie 的路由\n\n通过识别用户的 HTTP 请求头（如 User-Agent）或特定的 Cookie，决定用户请求被路由到新版本还是旧版本的应用。这种方法通常需要负载均衡器或网关支持特定路由规则。\n\n### 2. 使用服务网格（Service Mesh）\n\n服务网格如 Istio 提供了复杂的流量管理能力，可以在微服务架构中实现灰度发布。通过定义路由规则，Istio 可以将特定比例或特定条件的流量导向新版本服务。\n\n### 3. 功能开关（Feature Toggles）\n\n功能开关允许开发者在代码中嵌入开关，根据配置动态激活或关闭某些功能。这样，新版本的功能可以被隐藏，直到你决定通过更改配置为特定用户群体开放。\n\n### 4. DNS 路由\n\n通过 DNS 管理，将部分用户的请求解析到部署了新版本应用的服务器上。这种方法简单，但切换和回退可能不如其他方法灵活。\n\n### 5. CDN 切换\n\n对于前端应用或静态资源，可以通过 CDN 配置，将部分用户的请求路由到包含新版本资源的 CDN 上。通过调整 CDN 的缓存规则控制版本切换。\n\n### 6. A/B 测试平台\n\n将灰度发布作为 A/B 测试的一部分，使用专门的 A/B 测试平台来控制哪些用户看到新版本。这种方法不仅可以实现灰度发布，还能搜集用户反馈和使用情况数据。\n\n### 7. 容器编排和管理\n\n在支持容器编排（如 Kubernetes）的环境中，可以通过部署新版本的 Pod 副本，并逐步增加新版本副本的数量，同时减少旧版本副本的数量实现灰度发布。\n\n在实施灰度发布时，应该配合监控和日志记录工具，以便快速识别并解决新版本可能引入的问题。同时，在决定完全推出新版本之前，逐渐增加访问新版本的用户比例，确保在所有阶段都能够保持应用的稳定性和高性能。\n",{"_58":923,"_174":145,"_175":145,"_176":145,"_177":145,"_178":145,"_179":145,"_180":145,"_181":145,"_182":145},"https://api.github.com/repos/pro-collection/interview-question/issues/783/reactions","https://api.github.com/repos/pro-collection/interview-question/issues/783/timeline",{"_58":926,"_60":61,"_62":927,"_64":928,"_66":929,"_68":930,"_70":931,"_72":932,"_74":933,"_76":934,"_78":935,"_111":936,"_124":125,"_126":24,"_127":-5,"_128":939,"_130":940,"_152":145,"_146":942,"_148":942,"_151":-5,"_155":156,"_106":-5,"_157":-5,"_158":943,"_163":944,"_169":945,"_171":946,"_183":948,"_185":-5,"_186":-5,"_187":188},"https://api.github.com/repos/pro-collection/interview-question/issues/782","https://api.github.com/repos/pro-collection/interview-question/issues/782/labels{/name}","https://api.github.com/repos/pro-collection/interview-question/issues/782/comments","https://api.github.com/repos/pro-collection/interview-question/issues/782/events","https://github.com/pro-collection/interview-question/issues/782",2405414900,"I_kwDOJGDC6c6PX7f0",782,"[微前端] 为何通常在微前端应用隔离，不选择 iframe 方案【热度: 280】",{"_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},[937,938],{"_70":114,"_72":115,"_58":116,"_117":118,"_119":120,"_121":24,"_122":123},{"_70":495,"_72":496,"_58":497,"_117":498,"_119":231,"_121":24,"_122":232},[],{"_58":132,"_68":133,"_62":134,"_70":135,"_72":136,"_74":137,"_76":138,"_122":139,"_140":941,"_142":143,"_144":145,"_124":125,"_146":147,"_148":149,"_150":-5,"_151":-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},"2024-07-12T12:01:29Z",{"_160":145,"_161":145,"_162":145},{"_165":145,"_166":145,"_167":145,"_168":145},"**关键词**：iframe 隔离方案弊端\n\n在微前端架构中，虽然`iframe`能提供很好的应用隔离（包括 JavaScript 和 CSS 隔离），确保微前端应用之间不会相互干扰，但一般不把它作为首选方案，原因包括：\n\n### 1. 性能开销\n\n`iframe`会创建一个全新的浏览器上下文环境，每个`iframe`都有自己的文档对象模型（DOM）树、全局执行环境等。如果一个页面中嵌入了多个`iframe`，就会导致额外的内存和 CPU 资源消耗，特别是在性能有限的设备上更为显著。\n\n### 2. 应用集成和交互问题\n\n`iframe`自然隔离了父子页面的环境，这虽然提供了隔离，但同时也使得主应用与子应用之间的交云难度增加。虽然可以通过`postMessage`等 API 实现跨`iframe`通信，但这种方式相比于直接 JavaScript 调用来说，更为复杂，交互效率也较低。\n\n### 3. UI 体验一致性\n\n在`iframe`中运行的应用在视觉上可能与主应用难以实现无缝集成。`iframe`内外的样式、字体等一致性需要额外的处理。此外，`iframe`可能带来额外的滚动条，影响用户体验。\n\n### 4. SEO 问题\n\n如果微前端的某些内容是通过`iframe`呈现的，那么这部分内容对于搜索引擎是不可见的，这可能会对应用的 SEO 产生负面影响。\n\n### 5. 安全问题\n\n虽然`iframe`可以提供一定程度的隔离，但它也可能引入点击劫持等安全风险。此外，过多地使用`iframe`也可能增加网站被恶意脚本攻击的表面。\n\n因此，虽然`iframe`是一种可行的应用隔离方法，它的这些局限性使得开发者在选择微前端技术方案时，往往会考虑其他提供更轻量级隔离、更好集成与交互体验的方案，如使用 JavaScript 沙箱、CSS 隔离技术、Web Components 等。这些方法虽然隔离性可能不如`iframe`彻底，但在整体的应用性能、用户体验和开发效率上通常会有更好的表现。\n",{"_58":947,"_174":145,"_175":145,"_176":145,"_177":145,"_178":145,"_179":145,"_180":145,"_181":145,"_182":145},"https://api.github.com/repos/pro-collection/interview-question/issues/782/reactions","https://api.github.com/repos/pro-collection/interview-question/issues/782/timeline",{"_58":950,"_60":61,"_62":951,"_64":952,"_66":953,"_68":954,"_70":955,"_72":956,"_74":957,"_76":958,"_78":959,"_111":960,"_124":125,"_126":24,"_127":-5,"_128":963,"_130":964,"_152":145,"_146":966,"_148":966,"_151":-5,"_155":156,"_106":-5,"_157":-5,"_158":967,"_163":968,"_169":969,"_171":970,"_183":972,"_185":-5,"_186":-5,"_187":188},"https://api.github.com/repos/pro-collection/interview-question/issues/781","https://api.github.com/repos/pro-collection/interview-question/issues/781/labels{/name}","https://api.github.com/repos/pro-collection/interview-question/issues/781/comments","https://api.github.com/repos/pro-collection/interview-question/issues/781/events","https://github.com/pro-collection/interview-question/issues/781",2405411791,"I_kwDOJGDC6c6PX6vP",781,"[微前端] Qiankun 是如何做 JS 隔离的【热度: 228】",{"_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},[961,962],{"_70":114,"_72":115,"_58":116,"_117":118,"_119":120,"_121":24,"_122":123},{"_70":495,"_72":496,"_58":497,"_117":498,"_119":231,"_121":24,"_122":232},[],{"_58":132,"_68":133,"_62":134,"_70":135,"_72":136,"_74":137,"_76":138,"_122":139,"_140":965,"_142":143,"_144":145,"_124":125,"_146":147,"_148":149,"_150":-5,"_151":-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},"2024-07-12T11:59:33Z",{"_160":145,"_161":145,"_162":145},{"_165":145,"_166":145,"_167":145,"_168":145},"**关键词**：JS 隔离\n\nQiankun 是一个基于 Single-SPA 的微前端实现库，它提供了比较完善的 JS 隔离能力，确保微前端应用间的独立运行，避免了全局变量污染、样式冲突等问题。Qiankun 实现 JS 隔离的主要机制包括：\n\n### 1. JS 沙箱\n\nQiankun 使用 JS 沙箱技术为每个子应用创建一个独立的运行环境。沙箱有以下两种类型：\n\n- **快照沙箱（Snapshot Sandbox）**：在子应用启动时，快照并记录当前全局环境的状态，然后在子应用卸载时，恢复全局环境到启动前的状态。这种方式不会对全局对象进行真正的隔离，而是通过记录和恢复的方式避免全局环境被污染。\n\n- **Proxy 沙箱**：通过 `Proxy` 对象创建一个全新的全局对象代理，子应用的所有全局变量修改操作都将在这个代理对象上进行，从而不会影响到真实的全局对象。这种方式提供了更为彻底的隔离效果，是 Qiankun 中推荐的沙箱隔离方式。\n\n### 2. 动态执行 JS 代码\n\nQiankun 通过动态执行 JS 代码的方式加载子应用，避免了脚本直接在全局环境下执行可能导致的变量污染。具体来说，它可以动态获取子应用的 JS 资源，然后在沙箱环境中运行这些代码，确保代码执行的全局变量不会泄露到主应用的全局环境中。\n\n### 3. 生命周期隔离\n\nQiankun 给每个子应用定义了一套生命周期钩子，如 `bootstrap`、`mount`、`unmount` 等，确保在应用加载、激活和卸载的过程中正确管理和隔离资源。通过在 `unmount` 生命周期钩子中正确清理子应用创建的全局监听器、定时器等，进一步保证了不同子应用间的独立性和隔离性。\n\n### 4. 样式隔离\n\n虽然主要针对 JS 隔离，Qiankun 也提供了样式隔离机制，通过动态添加和移除样式标签，保证子应用样式的独立性，避免不同子应用间的样式冲突。\n\n通过以上机制，Qiankun 能够有效实现微前端架构中子应用的 JS 隔离，加强了应用间的独立性和安全性，使得不同子应用可以无缝集成在一起，同时又能够保持各自的运行环境独立不受影响。\n",{"_58":971,"_174":145,"_175":145,"_176":145,"_177":145,"_178":145,"_179":145,"_180":145,"_181":145,"_182":145},"https://api.github.com/repos/pro-collection/interview-question/issues/781/reactions","https://api.github.com/repos/pro-collection/interview-question/issues/781/timeline",{"_58":974,"_60":61,"_62":975,"_64":976,"_66":977,"_68":978,"_70":979,"_72":980,"_74":981,"_76":982,"_78":983,"_111":984,"_124":125,"_126":24,"_127":-5,"_128":987,"_130":988,"_152":145,"_146":990,"_148":990,"_151":-5,"_155":156,"_106":-5,"_157":-5,"_158":991,"_163":992,"_169":993,"_171":994,"_183":996,"_185":-5,"_186":-5,"_187":188},"https://api.github.com/repos/pro-collection/interview-question/issues/780","https://api.github.com/repos/pro-collection/interview-question/issues/780/labels{/name}","https://api.github.com/repos/pro-collection/interview-question/issues/780/comments","https://api.github.com/repos/pro-collection/interview-question/issues/780/events","https://github.com/pro-collection/interview-question/issues/780",2405408021,"I_kwDOJGDC6c6PX50V",780,"[微前端] 微前端架构一般是如何做 JavaScript隔离【热度: 127】",{"_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},[985,986],{"_70":114,"_72":115,"_58":116,"_117":118,"_119":120,"_121":24,"_122":123},{"_70":495,"_72":496,"_58":497,"_117":498,"_119":231,"_121":24,"_122":232},[],{"_58":132,"_68":133,"_62":134,"_70":135,"_72":136,"_74":137,"_76":138,"_122":139,"_140":989,"_142":143,"_144":145,"_124":125,"_146":147,"_148":149,"_150":-5,"_151":-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},"2024-07-12T11:57:10Z",{"_160":145,"_161":145,"_162":145},{"_165":145,"_166":145,"_167":145,"_168":145},"**关键词**：JS 隔离\n\n在微前端架构中，JavaScript 隔离是核心之一，用以确保各个子应用间代码运行时不互相干扰、变量不冲突，以及能够安全地卸载应用。为了实现这一目标，主要采用以下几种方法：\n\n### 1. 使用沙箱技术：\n\n- **`iframe`**：最直接的隔离方式是将子应用运行在`iframe`中。这种方式提供了良好的隔离性，因为`iframe`内部有自己独立的执行环境，包括 JavaScript 运行环境和 DOM 环境。但`iframe`的使用可能会导致性能问题，且父子通信复杂。\n- **JavaScript Sandboxing**：通过创建一个独立的 JavaScript 执行环境，比如使用 Web Workers，或者更高级的沙箱库（如 Google 的 Caja），以在主页环境隔离执行 JavaScript 代码。\n\n### 2. 命名空间和模块化：\n\n- **命名空间**：通过命名空间（Namespace）封装每个子应用的代码，确保全局变量和函数不会与其他应用冲突。\n- **模块化**：利用 ES Modules 或 CommonJS 等模块化标准，使代码封装在模块中运行，通过 import/export 管理依赖，减少全局变量的使用，从而实现隔离。\n\n### 3. 状态管理隔离：\n\n- 虽然主要关注 JavaScript 代码的隔离，但在单页应用中，子应用间状态管理（如使用 Redux、Vuex 等状态管理库）也可能导致隔离问题。可以为每个子应用创建独立的状态树，只通过明确定义的接口来共享必要的状态信息。\n\n### 4. 使用微前端框架或库：\n\n- **模块联邦（Module Federation）**：Webpack 的模块联邦功能允许不同的前端应用共享 JavaScript 模块，同时保持应用间的隔离。它可以动态地加载另一个应用导出的模块，而不需要将它们打包进单个文件里。\n- **专门的微前端框架**：如 Single-SPA、Qiankun 等，这些框架提供了一套完整的解决方案，用于管理微前端应用的加载、卸载以及相互隔离，部分内部采用了类似沙箱的技术实现隔离。\n\n### 5. 服务端渲染（SSR）隔离：\n\n- 通过服务端渲染各个微前端应用，再将渲染好的静态 HTML 集成到主应用中。这样，每个子应用的 JavaScript 在客户端激活（Hydration）之前是隔离的。SSR 可以减少初次加载时间，同时具备部分隔离性，尤其是在初次加载阶段。\n\n实施 JavaScript 隔离时，需要根据具体项目需求、技术栈和团队的熟练度来选取合适的隔离策略，以确保子应用之间的高度独立性和可维护性。\n",{"_58":995,"_174":145,"_175":145,"_176":145,"_177":145,"_178":145,"_179":145,"_180":145,"_181":145,"_182":145},"https://api.github.com/repos/pro-collection/interview-question/issues/780/reactions","https://api.github.com/repos/pro-collection/interview-question/issues/780/timeline","pagination",{"_999":309,"_160":1000},"value",6,"actionData","errors"]