Document

\n $\"\"$ \n

\n ......省略了19个box\n

\n \n \n\n```\n\n此时的页面:\n\n![image.png](https://p1-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/4948c01e92814e9583a34ea2ce4bbd42~tplv-k3u1fbpfcp-jj-mark:3024:0:0:0:q75.awebp#?w=1928&h=1040&s=1053345&e=png&b=ffffff)\n\n### JavaScript 部分\n\n### 实现原理：\n\n1.使用一个父容器 container 包裹子容器 box\n\n2.图片容器 box-img 包裹在容器 box 中，用来展示\n\n3.通过 js 获取父容器的 DOM 结构，再获取其子元素图片容器 box\n\n4.将其按照瀑布流的规则使用绝对定位放置\n\n5.获取屏幕大小计算该屏幕最多能放下几张图片，将前 n 张图片放在第一行\n\n6.使用一个 heightArr 高度数组,在放置的时候记录每一列图片的高度,后面的图片放置在高度最低的那一列\n\n### 图解:\n\n![image.png](https://p9-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/d2e0b52959ea49df9cb63ab2a5aa9bd2~tplv-k3u1fbpfcp-jj-mark:3024:0:0:0:q75.awebp#?w=905&h=636&s=34819&e=png&b=ffffff)\n\n### js 代码实现:\n\n```javascript\n//获取用户屏幕宽度，决定一行几张图\n//操作下一张图，放到上一行最矮的列下\nimgLocation(\"container\", \"box\");\n\nfunction imgLocation(parent, content) {\n var cparent = document.getElementById(parent);\n var ccontent = getChildElement(cparent, content); //document.querySelectorAll('#container .box')\n // console.log(ccontent)\n var imgWidth = ccontent[0].offsetWidth;\n var num = Math.floor(document.documentElement.clientWidth / imgWidth);\n cparent.style.width = `${imgWidth * num}px`;\n //要操作的是哪张，每一列的高度\n\n var BoxHeightArr = [];\n for (var i = 0; i < ccontent.length; i++) {\n if (i < num) {\n //记录第一行\n BoxHeightArr[i] = ccontent[i].offsetHeight;\n } else {\n //开始操作，找到最矮的高度及列数\n minHeight = Math.min.apply(null, BoxHeightArr);\n var minIndex = BoxHeightArr.indexOf(minHeight);\n\n //摆放图片位置\n ccontent[i].style.position = \"absolute\";\n ccontent[i].style.top = minHeight + \"px\";\n ccontent[i].style.left = ccontent[minIndex].offsetLeft + \"px\";\n //更新这一列图片高度\n BoxHeightArr[minIndex] = BoxHeightArr[minIndex] + ccontent[i].offsetHeight;\n }\n }\n console.log(BoxHeightArr);\n}\n\nfunction getChildElement(parent, child) {\n //获取parent中所有child\n var childArr = [];\n var allChild = parent.getElementsByTagName(\"*\");\n //找出所有box\n for (var i = 0; i < allChild.length; i++) {\n if (allChild[i].className == child) {\n childArr.push(allChild[i]);\n }\n }\n return childArr;\n}\n```\n\n### 最终效果:\n\n![image.png](https://p6-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/19e9ec489a484120b12c43fe87b532e7~tplv-k3u1fbpfcp-jj-mark:3024:0:0:0:q75.awebp#?w=1920&h=911&s=1021235&e=png&b=fefcfc)\n",{"_58":398,"_180":152,"_181":152,"_182":152,"_183":152,"_184":152,"_185":152,"_186":152,"_187":152,"_188":152},"https://api.github.com/repos/pro-collection/interview-question/issues/820/reactions","https://api.github.com/repos/pro-collection/interview-question/issues/820/timeline",{"_58":401,"_60":61,"_62":402,"_64":403,"_66":404,"_68":405,"_70":406,"_72":407,"_74":408,"_76":409,"_78":410,"_111":411,"_131":132,"_133":24,"_134":-5,"_135":414,"_137":415,"_159":152,"_153":417,"_155":418,"_158":-5,"_161":162,"_106":-5,"_163":-5,"_164":419,"_169":420,"_175":421,"_177":422,"_189":424,"_191":-5,"_192":-5,"_193":194},"https://api.github.com/repos/pro-collection/interview-question/issues/808","https://api.github.com/repos/pro-collection/interview-question/issues/808/labels{/name}","https://api.github.com/repos/pro-collection/interview-question/issues/808/comments","https://api.github.com/repos/pro-collection/interview-question/issues/808/events","https://github.com/pro-collection/interview-question/issues/808",2458862560,"I_kwDOJGDC6c6Sj0Pg",808,"日志监控问题：可有办法将请求的调用源码地址包括代码行数也上报上去？【热度: 814】",{"_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},[412,413],{"_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":252,"_68":253,"_62":254,"_70":255,"_72":256,"_74":257,"_76":258,"_122":259,"_147":416,"_149":261,"_151":152,"_131":132,"_153":262,"_155":263,"_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},"2024-08-10T02:43:39Z","2024-08-10T02:43:40Z",{"_166":152,"_167":152,"_168":152},{"_171":152,"_172":152,"_173":152,"_174":152},"**关键词**：日志监控问题\n\n在使用了代码混淆（例如 Webpack 的 mina-hash、chunkhash 或 contenthash）的前端代码中，即使执行了混淆，依然可以通过以下方法在日志监控时提供足够的上下文信息，主要包括被请求的源代码地址以及代码行数：\n\n### 源码映射(Source Maps)\n\n1. **生成 Source Maps:**\n 在构建过程中生成功能强大的源码映射（Source Maps）文件是标准做法。Source Maps 主要用于将混淆、压缩后的 JavaScript 代码映射回到其原始版本，允许在浏览器调试工具中查看原始代码和追踪错误。\n\n - **保存映射文件:** 在生产版本中生成如`.map`的 Source Map 文件，并确保它们正常处理（通常是将它们放置在服务器上的一个公开但安全的位置）。\n - **反映在 Source Maps 中的映射:** Source Maps 文件应将原始的源文件路径和行号映射到构建后的代码中对应的位置。\n\n2. **错误跟踪系统集成:**\n 使用错误跟踪工具（也常被称为 Error Monitoring 平台, 如 Sentry、LogRocket、Bugsnag 等），这些工具通常兼容并支持 Source Maps:\n\n - **自动和源码追踪:**\n 漏洞和崩溃报告将自动包含被未混淆的源码引用，您只需确保生产版本的 Source Maps 配置正确。\n\n - **代码行号报告:**\n 用户报告的堆栈跟踪信息将包括对应底层源文件，而非混淆后的行号。\n\n### 自定义错误日志逻辑\n\n1. **覆盖全局的错误处理器：**\n 对于更高级的错误追踪，你可能需要在前端代码中维护自定义的错误处理逻辑。\n\n - **使用`.Window.onerror`或`try...catch`:**\n 在`Window.onerror`中捕捉到运行时错误时，或者在自定义函数内`try...catch`捕获的错误，你可以从错误的堆栈跟踪中提取当前运行代码的位置，并尝试将符号化的堆栈信息发送到后端服务器。\n\n2. **在后端查阅符号化堆栈:**\n 为了安全和性能的考虑，源码映射通常不包括在客户端的部署中。因此固体堆栈信息需要在服务器端符号化，这是针对转换后的堆栈轨迹进行处理，将反向转换为源代码行。\n\n### 注意:\n\n- 确保 Source Maps 不公开到客户端以避免潜在的安全风险。应该将它们存放于受控的服务器环境，以避免源码泄露或不当使用。\n- 以上方案更适合于开发或测试环境提供详细调试信息，确保在最终部署产品之前只公开给授权的人员。\n",{"_58":423,"_180":152,"_181":152,"_182":152,"_183":152,"_184":152,"_185":152,"_186":152,"_187":152,"_188":152},"https://api.github.com/repos/pro-collection/interview-question/issues/808/reactions","https://api.github.com/repos/pro-collection/interview-question/issues/808/timeline",{"_58":426,"_60":61,"_62":427,"_64":428,"_66":429,"_68":430,"_70":431,"_72":432,"_74":433,"_76":434,"_78":435,"_111":436,"_131":132,"_133":24,"_134":-5,"_135":439,"_137":440,"_159":152,"_153":442,"_155":442,"_158":-5,"_161":162,"_106":-5,"_163":-5,"_164":443,"_169":444,"_175":445,"_177":446,"_189":448,"_191":-5,"_192":-5,"_193":194},"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},[437,438],{"_70":243,"_72":244,"_58":245,"_117":246,"_119":247,"_121":24,"_122":248},{"_70":125,"_72":126,"_58":127,"_117":128,"_119":129,"_121":24,"_122":130},[],{"_58":252,"_68":253,"_62":254,"_70":255,"_72":256,"_74":257,"_76":258,"_122":259,"_147":441,"_149":261,"_151":152,"_131":132,"_153":262,"_155":263,"_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},"2024-07-12T12:01:29Z",{"_166":152,"_167":152,"_168":152},{"_171":152,"_172":152,"_173":152,"_174":152},"**关键词**：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":447,"_180":152,"_181":152,"_182":152,"_183":152,"_184":152,"_185":152,"_186":152,"_187":152,"_188":152},"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":450,"_60":61,"_62":451,"_64":452,"_66":453,"_68":454,"_70":455,"_72":456,"_74":457,"_76":458,"_78":459,"_111":460,"_131":132,"_133":24,"_134":-5,"_135":463,"_137":464,"_159":152,"_153":466,"_155":466,"_158":-5,"_161":162,"_106":-5,"_163":-5,"_164":467,"_169":468,"_175":469,"_177":470,"_189":472,"_191":-5,"_192":-5,"_193":194},"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},[461,462],{"_70":243,"_72":244,"_58":245,"_117":246,"_119":247,"_121":24,"_122":248},{"_70":125,"_72":126,"_58":127,"_117":128,"_119":129,"_121":24,"_122":130},[],{"_58":252,"_68":253,"_62":254,"_70":255,"_72":256,"_74":257,"_76":258,"_122":259,"_147":465,"_149":261,"_151":152,"_131":132,"_153":262,"_155":263,"_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},"2024-07-12T11:59:33Z",{"_166":152,"_167":152,"_168":152},{"_171":152,"_172":152,"_173":152,"_174":152},"**关键词**：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":471,"_180":152,"_181":152,"_182":152,"_183":152,"_184":152,"_185":152,"_186":152,"_187":152,"_188":152},"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":474,"_60":61,"_62":475,"_64":476,"_66":477,"_68":478,"_70":479,"_72":480,"_74":481,"_76":482,"_78":483,"_111":484,"_131":132,"_133":24,"_134":-5,"_135":487,"_137":488,"_159":152,"_153":490,"_155":490,"_158":-5,"_161":162,"_106":-5,"_163":-5,"_164":491,"_169":492,"_175":493,"_177":494,"_189":496,"_191":-5,"_192":-5,"_193":194},"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},[485,486],{"_70":243,"_72":244,"_58":245,"_117":246,"_119":247,"_121":24,"_122":248},{"_70":125,"_72":126,"_58":127,"_117":128,"_119":129,"_121":24,"_122":130},[],{"_58":252,"_68":253,"_62":254,"_70":255,"_72":256,"_74":257,"_76":258,"_122":259,"_147":489,"_149":261,"_151":152,"_131":132,"_153":262,"_155":263,"_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},"2024-07-12T11:57:10Z",{"_166":152,"_167":152,"_168":152},{"_171":152,"_172":152,"_173":152,"_174":152},"**关键词**：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":495,"_180":152,"_181":152,"_182":152,"_183":152,"_184":152,"_185":152,"_186":152,"_187":152,"_188":152},"https://api.github.com/repos/pro-collection/interview-question/issues/780/reactions","https://api.github.com/repos/pro-collection/interview-question/issues/780/timeline",{"_58":498,"_60":61,"_62":499,"_64":500,"_66":501,"_68":502,"_70":503,"_72":504,"_74":505,"_76":506,"_78":507,"_111":508,"_131":132,"_133":24,"_134":-5,"_135":511,"_137":512,"_159":152,"_153":514,"_155":514,"_158":-5,"_161":162,"_106":-5,"_163":-5,"_164":515,"_169":516,"_175":517,"_177":518,"_189":520,"_191":-5,"_192":-5,"_193":194},"https://api.github.com/repos/pro-collection/interview-question/issues/769","https://api.github.com/repos/pro-collection/interview-question/issues/769/labels{/name}","https://api.github.com/repos/pro-collection/interview-question/issues/769/comments","https://api.github.com/repos/pro-collection/interview-question/issues/769/events","https://github.com/pro-collection/interview-question/issues/769",2317410164,"I_kwDOJGDC6c6KIN90",769,"[Webpack] ts 编写的库，在使用 webpack 构建的时候，如何对外提供 d.ts【热度: 224】",{"_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},[509,510],{"_70":243,"_72":244,"_58":245,"_117":246,"_119":247,"_121":24,"_122":248},{"_70":125,"_72":126,"_58":127,"_117":128,"_119":129,"_121":24,"_122":130},[],{"_58":252,"_68":253,"_62":254,"_70":255,"_72":256,"_74":257,"_76":258,"_122":259,"_147":513,"_149":261,"_151":152,"_131":132,"_153":262,"_155":263,"_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},"2024-05-26T03:09:59Z",{"_166":152,"_167":152,"_168":152},{"_171":152,"_172":152,"_173":152,"_174":152},"**关键词**：对外提供 d.ts\n\n在 TypeScript (TS) 中使用 Webpack 构建并为库提供 `.d.ts` 类型声明文件，需要遵循以下步骤：\n\n1. **配置 TypeScript 编译选项**：\n 在库项目的根目录下创建或编辑 `tsconfig.json` 文件，确保编译器配置选项如下：\n\n ```json\n {\n \"compilerOptions\": {\n \"declaration\": true, // 生成对应的 '.d.ts' 文件\n \"declarationDir\": \"types\", // 指定生成的声明文件存放目录\n \"outDir\": \"lib\" // 指定编译后文件的输出目录\n // 其他需要的编译选项\n },\n \"include\": [\"src/**/*\"], // 包含源码的目录\n \"exclude\": [\"node_modules\"] // 排除的目录\n }\n ```\n\n - `declaration`: 这个选项会告诉 TypeScript 编译器为每个 `.ts` 文件生成相应的 `.d.ts` 声明文件。\n - `declarationDir`: 这是指定声明文件的输出目录。\n\n2. **配置 Webpack**：\n 在我们的 Webpack 配置中（通常是 `webpack.config.js`），我们需要设置 `output` 以指向我们的输出目录，同时可能需要使用一些加载器(loader)如 `ts-loader` 或 `babel-loader` 来处理 TypeScript 文件。\n\n 一个简单的 webpack 配置示例可能如下：\n\n ```javascript\n const path = require(\"path\");\n\n module.exports = {\n entry: \"./src/index.ts\", // 入口文件\n module: {\n rules: [\n {\n test: /\\.tsx?$/,\n use: \"ts-loader\",\n exclude: /node_modules/,\n },\n ],\n },\n resolve: {\n extensions: [\".tsx\", \".ts\", \".js\"],\n },\n output: {\n filename: \"your-library.js\", // 输出文件名\n path: path.resolve(__dirname, \"lib\"), // 输出文件夹\n libraryTarget: \"umd\", // 使库支持各种模块系统\n globalObject: \"this\",\n },\n };\n ```\n\n3. **发布包**：\n 当你发布你的库时，你需要确保 `package.json` 文件中包含 `types` 或 `typings` 字段指向入口 `.d.ts` 文件。\n\n 例如：\n\n ```json\n {\n \"name\": \"your-library\",\n \"version\": \"1.0.0\",\n \"main\": \"lib/your-library.js\",\n \"typings\": \"types/index.d.ts\"\n // 其他配置项...\n }\n ```\n\n 这告诉使用你库的 TypeScript 用户，在哪里可以找到类型声明文件。\n\n4. **保证类型声明文件的发布**：\n 如果你的 npm 发布流程排除了 `types` 目录，你需要更新 `.npmignore` 文件来确保 `.d.ts` 文件会被包含在发布的 npm 包中。\n\n完成这些配置后，当你用 webpack 构建并发布你的库时，用户将能够获得与 JavaScript 文件关联的 TypeScript 类型声明，以便在他们的 TypeScript 项目中获得类型检查和智能提示。\n",{"_58":519,"_180":152,"_181":152,"_182":152,"_183":152,"_184":152,"_185":152,"_186":152,"_187":152,"_188":152},"https://api.github.com/repos/pro-collection/interview-question/issues/769/reactions","https://api.github.com/repos/pro-collection/interview-question/issues/769/timeline",{"_58":522,"_60":61,"_62":523,"_64":524,"_66":525,"_68":526,"_70":527,"_72":528,"_74":529,"_76":530,"_78":531,"_111":532,"_131":132,"_133":24,"_134":-5,"_135":535,"_137":536,"_159":152,"_153":538,"_155":539,"_158":-5,"_161":162,"_106":-5,"_163":-5,"_164":540,"_169":541,"_175":542,"_177":543,"_189":545,"_191":-5,"_192":-5,"_193":194},"https://api.github.com/repos/pro-collection/interview-question/issues/768","https://api.github.com/repos/pro-collection/interview-question/issues/768/labels{/name}","https://api.github.com/repos/pro-collection/interview-question/issues/768/comments","https://api.github.com/repos/pro-collection/interview-question/issues/768/events","https://github.com/pro-collection/interview-question/issues/768",2317409849,"I_kwDOJGDC6c6KIN45",768,"测试前端代码覆盖率一般有什么手段？【热度: 550】",{"_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},[533,534],{"_70":243,"_72":244,"_58":245,"_117":246,"_119":247,"_121":24,"_122":248},{"_70":125,"_72":126,"_58":127,"_117":128,"_119":129,"_121":24,"_122":130},[],{"_58":252,"_68":253,"_62":254,"_70":255,"_72":256,"_74":257,"_76":258,"_122":259,"_147":537,"_149":261,"_151":152,"_131":132,"_153":262,"_155":263,"_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},"2024-05-26T03:08:49Z","2024-05-26T03:08:50Z",{"_166":152,"_167":152,"_168":152},{"_171":152,"_172":152,"_173":152,"_174":152},"**关键词**：覆盖率\n\n前端代码的测试覆盖率通常是指衡量在测试过程中有多少代码被执行了的一个指标。测试覆盖率有助于了解测试的全面性，以下是测试前端代码覆盖率常用的手段：\n\n1. **单元测试**：\n\n - 使用测试框架（例如 Jest, Mocha, Jasmine 等）编写单元测试。\n - 利用测试框架或插件生成覆盖率报告（例如 Istanbul/nyc 工具可以与这些框架集成以生成覆盖率数据）。\n\n2. **集成测试**：\n\n - 使用测试工具（比如 Cypress, Selenium 等）编写集成测试来模拟用户操作。\n - 通常这些工具也支持收集代码覆盖率信息。\n -\n\n3. **手动测试与覆盖率工具结合**：\n\n - 在手动测试过程中，可以开启浏览器的覆盖率工具（如 Chrome DevTools 中的 Coverage Tab）记录覆盖率。\n - 可以通过浏览器扩展程序或者自动化脚本来启动这些工具。\n\n4. **测试覆盖率服务**：\n\n - 使用像 Codecov 或 Coveralls 这样的服务，在 CI/CD 流程中集成覆盖率测试和报告。\n",{"_58":544,"_180":152,"_181":152,"_182":152,"_183":152,"_184":152,"_185":152,"_186":152,"_187":152,"_188":152},"https://api.github.com/repos/pro-collection/interview-question/issues/768/reactions","https://api.github.com/repos/pro-collection/interview-question/issues/768/timeline",{"_58":547,"_60":61,"_62":548,"_64":549,"_66":550,"_68":551,"_70":552,"_72":553,"_74":554,"_76":555,"_78":556,"_111":557,"_131":132,"_133":24,"_134":-5,"_135":560,"_137":561,"_159":152,"_153":563,"_155":564,"_158":-5,"_161":162,"_106":-5,"_163":-5,"_164":565,"_169":566,"_175":567,"_177":568,"_189":570,"_191":-5,"_192":-5,"_193":194},"https://api.github.com/repos/pro-collection/interview-question/issues/730","https://api.github.com/repos/pro-collection/interview-question/issues/730/labels{/name}","https://api.github.com/repos/pro-collection/interview-question/issues/730/comments","https://api.github.com/repos/pro-collection/interview-question/issues/730/events","https://github.com/pro-collection/interview-question/issues/730",2279555110,"I_kwDOJGDC6c6H30Am",730,"mouseEnter、mouseLeave、mouseOver、mouseOut 有什么区别？【热度: 266】",{"_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},[558,559],{"_70":383,"_72":384,"_58":385,"_117":386,"_119":387,"_121":24,"_122":388},{"_70":125,"_72":126,"_58":127,"_117":128,"_119":129,"_121":24,"_122":130},[],{"_58":211,"_68":212,"_62":213,"_70":214,"_72":215,"_74":216,"_76":217,"_122":218,"_147":562,"_149":220,"_151":152,"_131":132,"_153":221,"_155":222,"_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},"2024-05-05T14:18:09Z","2024-05-05T14:18:10Z",{"_166":152,"_167":152,"_168":152},{"_171":152,"_172":152,"_173":152,"_174":152},"**关键词**：mouseEnter、mouseLeave、mouseOver、mouseOut 区别\n\n这四个事件都与鼠标指针与元素的交互有关，不过它们之间有一些关键的差异：\n\n1. **mouseEnter 和 mouseLeave**：\n\n - `mouseEnter` 事件当鼠标指针进入元素时触发，但不冒泡，即只有指定的元素可以触发此事件，其子元素不能。\n - `mouseLeave` 事件则是当鼠标指针离开元素时触发，同样也不冒泡。\n\n2. **mouseOver 和 mouseOut**：\n - `mouseOver` 事件当鼠标指针移动到元素或其子元素上时触发，该事件会冒泡，即如果鼠标指针移动到其子元素上，也会触发该元素的`mouseOver`事件。\n - `mouseOut` 事件则是当鼠标指针离开元素或其子元素时触发，也会冒泡。\n\n总结一下它们的区别：\n\n- **冒泡**: `mouseOver` 和 `mouseOut` 事件会冒泡（父元素也会响应这个事件），而 `mouseEnter` 和 `mouseLeave` 不会冒泡。\n- **对子元素的响应**：`mouseOver` 和 `mouseOut` 会在鼠标指针移动到子元素上时也被触发，而 `mouseEnter` 和 `mouseLeave` 在鼠标指针移动到子元素上时不会被触发。\n\n在处理具有嵌套子元素的元素时，使用 `mouseEnter` 和 `mouseLeave` 可以避免多余的事件触发，因为它们不会在鼠标从父元素移动到子元素时触发事件。(即不会对内部子元素的进入和离开反应敏感)。而 `mouseOver` 和 `mouseOut` 更适合需要监测鼠标指针是否有移动到子元素上的情况。\n",{"_58":569,"_180":152,"_181":152,"_182":152,"_183":152,"_184":152,"_185":152,"_186":152,"_187":152,"_188":152},"https://api.github.com/repos/pro-collection/interview-question/issues/730/reactions","https://api.github.com/repos/pro-collection/interview-question/issues/730/timeline",{"_58":572,"_60":61,"_62":573,"_64":574,"_66":575,"_68":576,"_70":577,"_72":578,"_74":579,"_76":580,"_78":581,"_111":582,"_131":132,"_133":24,"_134":-5,"_135":591,"_137":592,"_159":152,"_153":594,"_155":595,"_158":-5,"_161":162,"_106":-5,"_163":-5,"_164":596,"_169":597,"_175":598,"_177":599,"_189":601,"_191":-5,"_192":-5,"_193":194},"https://api.github.com/repos/pro-collection/interview-question/issues/729","https://api.github.com/repos/pro-collection/interview-question/issues/729/labels{/name}","https://api.github.com/repos/pro-collection/interview-question/issues/729/comments","https://api.github.com/repos/pro-collection/interview-question/issues/729/events","https://github.com/pro-collection/interview-question/issues/729",2266881085,"I_kwDOJGDC6c6HHdw9",729,"tsconfig 配置中 types 和 typeRoots 作用是什么，有什么区别？【热度: 378】",{"_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},[583,590],{"_70":584,"_72":585,"_58":586,"_117":587,"_119":588,"_121":24,"_122":589},5232527330,"LA_kwDOJGDC6c8AAAABN-IH4g","https://api.github.com/repos/pro-collection/interview-question/labels/TypeScript","TypeScript","258B51","TypeScript 语法部分",{"_70":125,"_72":126,"_58":127,"_117":128,"_119":129,"_121":24,"_122":130},[],{"_58":252,"_68":253,"_62":254,"_70":255,"_72":256,"_74":257,"_76":258,"_122":259,"_147":593,"_149":261,"_151":152,"_131":132,"_153":262,"_155":263,"_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},"2024-04-27T07:07:19Z","2024-06-05T07:00:57Z",{"_166":152,"_167":152,"_168":152},{"_171":152,"_172":152,"_173":152,"_174":152},"**关键词**：ts 类型配置\n\n> 作者备注\n> 这个问题很冷门，没有价值，当做科普即可\n\n在 TypeScript 的 `tsconfig.json` 配置文件中，`types` 和 `typeRoots` 是两个与类型声明相关的选项，它们用于控制 TypeScript 编译器如何处理类型声明文件。这两个选项的主要区别在于它们控制的范围：\n\n### typeRoots\n\n`typeRoots` 选项指定了包含类型声明文件的目录列表。默认情况下，TypeScript 会查看所有以 `node_modules/@types` 结尾的目录。通过设置 `typeRoots`，你可以直接告诉 TypeScript 编译器去哪查找类型声明：\n\n```json\n{\n \"compilerOptions\": {\n \"typeRoots\": [\"./node_modules/@types\", \"./typings\"]\n }\n}\n```\n\n在这个例子中，我们指定了两个 `typeRoots`：默认的 `node_modules/@types` 和另外一个自定义的类型声明目录 `./typings`。\n\n### types\n\n`types` 选项允许你设置在项目中所使用到的类型声明文件列表。这个列表会限制编译器在 `typeRoots` 下查找的声明文件，意味着 `types` 中列出的类型声明会是项目中唯一可以引用的声明。如果没有设置 `types`，你可以使用存在于 `typeRoots` 下面的任何类型声明：\n\n```json\n{\n \"compilerOptions\": {\n \"types\": [\"my-global-types\"]\n }\n}\n```\n\n在这个例子中，`types` 选项限制了项目只能使用名为 `my-global-types` 的类型声明。即使有其他的 `.d.ts` 文件在 `typeRoots` 指定的目录下，它们也无法在不修改这个列表的情况下被引用。\n\n### 使用场景区别\n\n- 当你有多个 `d.ts` 文件你想指定给 TypeScript 编译器，而不是每一个单独去处理时，使用 `typeRoots` 更为方便。\n- `types` 用于控制引用的类型声明集，如果你是在限制或精心策划的设定下工作，这会很有帮助。\n\n### 结合使用\n\n在许多情况下，`typeRoots` 和 `types` 可以联合使用：\n\n1. `typeRoots` 列表包含了所有声明文件的位置。\n2. `types` 列表限制 TypeScript 可以引用特定集合的声明（其中未列出的声明则不可用）。\n\n通过合理的配置这两个选项，你可以精确控制在 TypeScript 项目中使用的类型声明，帮助你避免类型定义的混乱。\n",{"_58":600,"_180":152,"_181":152,"_182":152,"_183":152,"_184":152,"_185":152,"_186":152,"_187":152,"_188":152},"https://api.github.com/repos/pro-collection/interview-question/issues/729/reactions","https://api.github.com/repos/pro-collection/interview-question/issues/729/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":616,"_137":617,"_159":152,"_153":619,"_155":619,"_158":-5,"_161":162,"_106":-5,"_163":-5,"_164":620,"_169":621,"_175":622,"_177":623,"_189":625,"_191":-5,"_192":-5,"_193":194},"https://api.github.com/repos/pro-collection/interview-question/issues/728","https://api.github.com/repos/pro-collection/interview-question/issues/728/labels{/name}","https://api.github.com/repos/pro-collection/interview-question/issues/728/comments","https://api.github.com/repos/pro-collection/interview-question/issues/728/events","https://github.com/pro-collection/interview-question/issues/728",2266880257,"I_kwDOJGDC6c6HHdkB",728,"ts 项目中，如何使用 node_modules 里面定义的全局类型包到自己项目 src 下面使用？【热度: 377】",{"_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,615],{"_70":584,"_72":585,"_58":586,"_117":587,"_119":588,"_121":24,"_122":589},{"_70":125,"_72":126,"_58":127,"_117":128,"_119":129,"_121":24,"_122":130},[],{"_58":211,"_68":212,"_62":213,"_70":214,"_72":215,"_74":216,"_76":217,"_122":218,"_147":618,"_149":220,"_151":152,"_131":132,"_153":221,"_155":222,"_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},"2024-04-27T07:04:50Z",{"_166":152,"_167":152,"_168":152},{"_171":152,"_172":152,"_173":152,"_174":152},"**关键词**：ts 类型配置\n\n**关键点在 `types` 属性配置**\n\n在 TypeScript 项目中导入 `node_modules` 中定义的全局包，并在你的 `src` 目录下使用它，通常遵循以下步骤：\n\n1. 安装包：\n 使用包管理器如 npm 或 yarn 来安装你需要的全局包。\n\n ```sh\n npm install \n # 或者\n yarn add \n ```\n\n2. 类型声明：\n 确保该全局包具有类型声明。如果该全局包包含自己的类型声明，则 TypeScript 应该能够自动找到它们。如果不包含，则可能需要安装对应的 DefinitelyTyped 声明文件。\n\n ```sh\n npm install @types/\n # 或者，如果它是一个流行的库，一些库可能已经带有自己的类型定义。\n ```\n\n3. 导入包：\n 在 TypeScript 文件中，使用 `import` 语句导入全局包。\n\n ```typescript\n import * as PackageName from \"\";\n // 或者\n import PackageName from \"\";\n ```\n\n4. tsconfig.json 配置：\n 确保你的 `tsconfig.json` 文件配置得当，以便 TypeScript 能够找到 `node_modules` 中的声明文件。\n\n - 如果包是模块形式的，确保 `\"moduleResolution\"` 设置为 `\"node\"`。\n - 确保 `compilerOptions` 中的 `\"types\"` 和 `\"typeRoots\"` 属性没有配置错误。\n\n5. 使用全局包：\n 现在你可以在你的 `src` 目录中的任何文件里使用这个全局包。\n\n记住，最好的做法是不要把包当成全局包来使用，即使它们是全局的。通过显式地导入所需的模块，可以有助于工具如 linters 和 bundlers 更好地追踪依赖关系，并可以在以后的代码分析和维护中发挥重要作用。\n\n此外，全局变量或全局模块通常指的是在项目的多个部分中无需导入就可以直接使用的变量或模块。如果你确实需要将某些模块定义为全局可用，并且无法通过导入来使用，你可能需要更新你的 TypeScript 配置文件（`tsconfig.json`）来包括这些全局声明。但这通常不是一个推荐的做法，因为它可能会导致命名冲突和代码可维护性问题。\n",{"_58":624,"_180":152,"_181":152,"_182":152,"_183":152,"_184":152,"_185":152,"_186":152,"_187":152,"_188":152},"https://api.github.com/repos/pro-collection/interview-question/issues/728/reactions","https://api.github.com/repos/pro-collection/interview-question/issues/728/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":646,"_137":647,"_159":152,"_153":649,"_155":650,"_158":-5,"_161":162,"_106":-5,"_163":-5,"_164":651,"_169":652,"_175":653,"_177":654,"_189":656,"_191":-5,"_192":-5,"_193":194},"https://api.github.com/repos/pro-collection/interview-question/issues/727","https://api.github.com/repos/pro-collection/interview-question/issues/727/labels{/name}","https://api.github.com/repos/pro-collection/interview-question/issues/727/comments","https://api.github.com/repos/pro-collection/interview-question/issues/727/events","https://github.com/pro-collection/interview-question/issues/727",2266075586,"I_kwDOJGDC6c6HEZHC",727,"介绍一下 MutationObserver【热度: 632】",{"_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,645],{"_70":639,"_72":640,"_58":641,"_117":642,"_119":643,"_121":24,"_122":644},5252299764,"LA_kwDOJGDC6c8AAAABOQ-79A","https://api.github.com/repos/pro-collection/interview-question/labels/%E6%B5%8F%E8%A7%88%E5%99%A8","浏览器","f9d0c4","浏览器相关知识点",{"_70":125,"_72":126,"_58":127,"_117":128,"_119":129,"_121":24,"_122":130},[],{"_58":211,"_68":212,"_62":213,"_70":214,"_72":215,"_74":216,"_76":217,"_122":218,"_147":648,"_149":220,"_151":152,"_131":132,"_153":221,"_155":222,"_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},"2024-04-26T15:56:30Z","2024-05-10T14:12:11Z",{"_166":152,"_167":152,"_168":152},{"_171":152,"_172":152,"_173":152,"_174":152},"**关键词**：MutationObserver api\n\n`MutationObserver` 是一种能够响应 DOM 树变动的 Web API，它可以监听几乎所有类型的 DOM 变动，比如元素被添加、删除或修改。你可以通过它执行 callback 来应对这些变化。\n\n下面是 `MutationObserver` 的基本用法：\n\n### 创建 `MutationObserver` 实例\n\n```javascript\nvar observer = new MutationObserver(callback);\n```\n\n### 配置观察者\n\n你可以指定要观察的 DOM 变动的类型和具体的目标节点：\n\n```javascript\nvar config = {\n attributes: true, // 观察属性变动\n childList: true, // 观察子列表变动\n subtree: true, // 观察后代节点\n};\n\nobserver.observe(targetNode, config);\n```\n\n这里的 `callback` 是一个在观察到变动时执行的函数，它有两个参数：`mutationsList` 是一个变动列表，`observer` 是观察者实例。\n\n### 回调函数\n\n`MutationCallback` 函数会被调用，它有两个参数：\n\n1. `mutationsList`：一个 `MutationRecord` 对象的数组，每个对象都描述了一个变动。\n2. `observer`：触发通知的 `MutationObserver` 实例。\n\n```javascript\nfunction callback(mutationsList) {\n for (var mutation of mutationsList) {\n if (mutation.type === \"childList\") {\n console.log(\"A child node has been added or removed.\");\n } else if (mutation.type === \"attributes\") {\n console.log(`The ${mutation.attributeName} attribute was modified.`);\n }\n }\n}\n```\n\n### 停止观察\n\n你可以通过调用 `disconnect` 方法来停止观察：\n\n```javascript\nobserver.disconnect();\n```\n\n这将停止观察并且清除之前的记录。\n\n### 注意\n\n- 使用 `MutationObserver` 应该谨慎，因为它可能对页面性能产生影响，尤其是在观察大型 DOM 树或频繁变动时。\n- 尽量不要过度使用 `MutationObserver` 或过度指定需要它观察的变动种类和节点。\n\n比如，如果你只想监听某个特定属性的变动，那么就不应该打开 `childList` 或者 `attributes`（如果不需要观察它们）。\n\n`MutationObserver` 非常适用于响应 DOM 的动态变动来执行特定的 JavaScript 代码，而且是现代前端开发中的一个重要工具。在使用它时，考虑使用最严格的选项来优化性能并减少不必要的性能损耗。\n",{"_58":655,"_180":152,"_181":152,"_182":152,"_183":152,"_184":152,"_185":152,"_186":152,"_187":152,"_188":152},"https://api.github.com/repos/pro-collection/interview-question/issues/727/reactions","https://api.github.com/repos/pro-collection/interview-question/issues/727/timeline",{"_58":658,"_60":61,"_62":659,"_64":660,"_66":661,"_68":662,"_70":663,"_72":664,"_74":665,"_76":666,"_78":667,"_111":668,"_131":132,"_133":24,"_134":-5,"_135":677,"_137":678,"_159":152,"_153":680,"_155":681,"_158":-5,"_161":162,"_106":-5,"_163":-5,"_164":682,"_169":683,"_175":684,"_177":685,"_189":687,"_191":-5,"_192":-5,"_193":194},"https://api.github.com/repos/pro-collection/interview-question/issues/721","https://api.github.com/repos/pro-collection/interview-question/issues/721/labels{/name}","https://api.github.com/repos/pro-collection/interview-question/issues/721/comments","https://api.github.com/repos/pro-collection/interview-question/issues/721/events","https://github.com/pro-collection/interview-question/issues/721",2254416571,"I_kwDOJGDC6c6GX6q7",721,"前端渲染和后端渲染各有啥优缺点，为何现在技术大方向又逐渐往【后端渲染】方向靠了呢？【热度: 470】",{"_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},[669,676],{"_70":670,"_72":671,"_58":672,"_117":673,"_119":674,"_121":24,"_122":675},5232525911,"LA_kwDOJGDC6c8AAAABN-ICVw","https://api.github.com/repos/pro-collection/interview-question/labels/Nodejs","Nodejs","AC3F88","Nodejs 研究",{"_70":125,"_72":126,"_58":127,"_117":128,"_119":129,"_121":24,"_122":130},[],{"_58":211,"_68":212,"_62":213,"_70":214,"_72":215,"_74":216,"_76":217,"_122":218,"_147":679,"_149":220,"_151":152,"_131":132,"_153":221,"_155":222,"_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},"2024-04-20T06:47:38Z","2024-04-20T06:47:39Z",{"_166":152,"_167":152,"_168":152},{"_171":152,"_172":152,"_173":152,"_174":152},"**关键词**：前端渲染优缺点、后端渲染优缺点\n\n前端渲染（Client-Side Rendering，CSR）和后端渲染（Server-Side Rendering，SSR）是两种不同的网页渲染策略，每种方法都有其固有的优势和劣势。近几年来，后端渲染之所以又开始受到重视，主要是由于它在某些方面更加适应了新的技术需求和趋势。\n\n### 前端渲染 (CSR) 的优缺点：\n\n**优点**：\n\n1. **快速交互**：应用首屏加载后，用户操作通常快速响应，因为交互主要发生在客户端。\n2. **利用缓存**：前端渲染可以更有效地利用浏览器缓存，减轻服务器的负担。\n3. **性能优化**：通过懒加载和代码分割，可以进行更精细的性能优化。\n4. **SEO 优势**：随着 JavaScript 框架对搜索引擎优化的重视，前端渲染页面也能够获得良好的搜索引擎排名。\n\n**缺点**：\n\n1. **SEO 不友好**：对于搜索引擎爬虫来说，JavaScript 生成的内容不容易被抓取，可能影响 SEO。\n2. **首屏加载时间**：页面首次加载时，服务器仅发送 HTML 和 JavaScript，需等待所有脚本下载并执行后才能显示页面。\n3. **服务器端压力**：对于交互式应用，每一种状态都需要请求新的页面或数据，增加服务器端的请求压力。\n\n### 后端渲染 (SSR) 的优缺点：\n\n**优点**：\n\n1. **SEO 友好**：SSR 生成的 HTML 在初始请求时就存在，有利于爬虫索引。\n2. **首屏加载快**：用户可以更快地看到完全渲染的页面，尤其对于移动和低宽带用户有明显优势。\n3. **减轻前端压力**：不需要客户端强大的计算能力，减少了前端资源的限制。\n\n**缺点**：\n\n1. **服务器负载**：每一次页面请求都要通过后端渲染，增加了服务器的负载。\n2. **交互延迟**：交互通常需要进行额外的服务器请求，可能增加等待时间。\n3. **开发复杂性**：SSR 应用需要在服务器和客户端上运行相同的代码库，增加了开发和维护的复杂性。\n\n### 为何技术方向逐渐往后端渲染倾斜：\n\n1. **SEO 重要性**：由于 SEO 对于现代网站至关重要，而 SSR 提供了一种简单直接的方法来改善网页的搜索引擎友好性。\n\n2. **更好的用户体验**：更快的首屏加载时间可以显著提升用户体验，尤其是在网络环境较差的地区。\n\n3. **渐进式增强**：后端渲染的页面即使在 JavaScript 被禁用或浏览器不支持的情况下也能提供有用内容。\n\n4. **同构应用趋势**：随着开发实践的进步，前端框架开始支持同构或通用 JavaScript 应用，开发者可以重用代码同时进行客户端和服务器渲染。\n\n5. **新兴框架的支持**：诸如 Next.js、Nuxt.js、React Server Components 等现代框架和库开始提供内置的 SSR 支持，降低开发复杂性并提高渲染性能。\n\n6. **对抗加载时间问题**：随着网络使用量的增长，尤其是在移动设备上，加载时间对于用户体验的影响变得更加显著。\n\n7. **企业级应用需求**：面对内容量大、结构复杂的企业级应用，SSR 能够更有效地管理和展示数据。\n\n总结来说，虽然前端渲染在交互性能和灵活性方面具有优势，但是后端渲染在 SEO、首屏加载时间和用户体验等方面显示出了其独特价值。随着现代框架的支持和最佳实践的普及，开发人员可以更加容易地实现后端渲染，这使它成为了许多项目的良好选择。\n",{"_58":686,"_180":194,"_181":194,"_182":152,"_183":152,"_184":152,"_185":152,"_186":152,"_187":152,"_188":152},"https://api.github.com/repos/pro-collection/interview-question/issues/721/reactions","https://api.github.com/repos/pro-collection/interview-question/issues/721/timeline",{"_58":689,"_60":61,"_62":690,"_64":691,"_66":692,"_68":693,"_70":694,"_72":695,"_74":696,"_76":697,"_78":698,"_111":699,"_131":132,"_133":24,"_134":-5,"_135":702,"_137":703,"_159":152,"_153":705,"_155":705,"_158":-5,"_161":162,"_106":-5,"_163":-5,"_164":706,"_169":707,"_175":708,"_177":709,"_189":711,"_191":-5,"_192":-5,"_193":194},"https://api.github.com/repos/pro-collection/interview-question/issues/720","https://api.github.com/repos/pro-collection/interview-question/issues/720/labels{/name}","https://api.github.com/repos/pro-collection/interview-question/issues/720/comments","https://api.github.com/repos/pro-collection/interview-question/issues/720/events","https://github.com/pro-collection/interview-question/issues/720",2254415807,"I_kwDOJGDC6c6GX6e_",720,"express 里面的中间件和插件，是一个意思吗？【热度: 469】",{"_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},[700,701],{"_70":670,"_72":671,"_58":672,"_117":673,"_119":674,"_121":24,"_122":675},{"_70":125,"_72":126,"_58":127,"_117":128,"_119":129,"_121":24,"_122":130},[],{"_58":211,"_68":212,"_62":213,"_70":214,"_72":215,"_74":216,"_76":217,"_122":218,"_147":704,"_149":220,"_151":152,"_131":132,"_153":221,"_155":222,"_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},"2024-04-20T06:45:19Z",{"_166":152,"_167":152,"_168":152},{"_171":152,"_172":152,"_173":152,"_174":152},"**关键词**：express 中间件、express 插件\n\n在 Express.js 中，\"中间件\" 和 \"插件\" 这两个术语有时被交替使用，但实际上它们可能指向不同类型的组件，其差异取决于上下文。\n\n### 中间件 (Middleware)\n\n中间件是 Express 架构的核心部分，它是具有访问请求对象（`req`），响应对象（`res`），以及应用请求-响应循环中的下一个中间件的函数。中间件可以执行以下任务：\n\n1. **执行任何代码**。\n2. **对请求和响应对象做出更改**。\n3. **结束请求-响应循环**。\n4. **调用堆栈中的下一个中间件**。\n5. **如果当前是一个错误处理中间件，也可以调用 `next` 函数来跳过执行后续的请求处理中间件**。\n\n中间件可以用来处理日志记录、用户认证、HTTP 方法限定、跨域资源共享（CORS）、请求体解析等。\n\n示例代码：\n\n```javascript\napp.use((req, res, next) => {\n // 这里是中间件逻辑\n next();\n});\n```\n\n### 插件 (Plugins)\n\n在 Node.js 和 Express 生态系统中，\"插件\" 通常指的是：\n\n1. **第三方库**：它们不是 Express 的原生部分，但可以被集成到 Express 应用中来提供额外的功能。例如，`morgan`（日志记录中间件）、`cors`（处理 CORS 请求）等。\n\n2. **Express 框架的扩展**：某些特定的功能或一整套中间件，它们封装了一组特定的行为或应用结构，使之更容易复用于不同的项目中。\n\n3. **框架本身的一部分**：在某些情况下，插件也可以是 Express 框架自身的功能模块或特性。\n\n插件通常是由社区成员创建并维护的，它们可能遵从不同的 API 约定并且提供了比 Express 内置功能更特定的高级功能。\n\n### 主要区别\n\n- **集成方式**：中间件通常是独立功能的函数，可以在应用的任何地方被 `use` 或 `middlewareFunction` 调用。插件则可能是更复杂的库，提供一系列中间件、错误处理或者服务级别的功能。\n\n- **功能范畴**：中间件更侧重于 HTTP 请求的处理，通常与单个请求相关。插件则可能提供包括但不限于 HTTP 请求处理的更广泛的功能集。\n\n- **源码结构**：中间件通常是单一功能的模块，而插件则可能是一个完整的包，包含了一个或多个中间件以及附加功能。\n\n在实践使用中，一般不会严格区分中间件和插件，关键是理解它们提供的功能，以及如何将其集成到你的 Express 应用中。开发者通常根据自己的项目需求选择相应的中间件或插件来扩展 Express 应用的功能。\n",{"_58":710,"_180":152,"_181":152,"_182":152,"_183":152,"_184":152,"_185":152,"_186":152,"_187":152,"_188":152},"https://api.github.com/repos/pro-collection/interview-question/issues/720/reactions","https://api.github.com/repos/pro-collection/interview-question/issues/720/timeline",{"_58":713,"_60":61,"_62":714,"_64":715,"_66":716,"_68":717,"_70":718,"_72":719,"_74":720,"_76":721,"_78":722,"_111":723,"_131":132,"_133":24,"_134":-5,"_135":732,"_137":733,"_159":152,"_153":735,"_155":736,"_158":-5,"_161":162,"_106":-5,"_163":-5,"_164":737,"_169":738,"_175":739,"_177":740,"_189":742,"_191":-5,"_192":-5,"_193":194},"https://api.github.com/repos/pro-collection/interview-question/issues/719","https://api.github.com/repos/pro-collection/interview-question/issues/719/labels{/name}","https://api.github.com/repos/pro-collection/interview-question/issues/719/comments","https://api.github.com/repos/pro-collection/interview-question/issues/719/events","https://github.com/pro-collection/interview-question/issues/719",2254413570,"I_kwDOJGDC6c6GX58C",719,"[Vue] Vue2 中双向绑定是通过 Object.defineProperty() 实现的，那么它是如何监控数组的？【热度: 447】",{"_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},[724,731],{"_70":725,"_72":726,"_58":727,"_117":728,"_119":729,"_121":24,"_122":730},5252532904,"LA_kwDOJGDC6c8AAAABORNKqA","https://api.github.com/repos/pro-collection/interview-question/labels/web%E6%A1%86%E6%9E%B6","web框架","CB446E","web 框架相关知识",{"_70":125,"_72":126,"_58":127,"_117":128,"_119":129,"_121":24,"_122":130},[],{"_58":252,"_68":253,"_62":254,"_70":255,"_72":256,"_74":257,"_76":258,"_122":259,"_147":734,"_149":261,"_151":152,"_131":132,"_153":262,"_155":263,"_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},"2024-04-20T06:37:32Z","2024-04-20T06:37:33Z",{"_166":152,"_167":152,"_168":152},{"_171":152,"_172":152,"_173":152,"_174":152},"**关键词**：Vue2 中双向绑、Vue2 中双向绑监控数组\n\n在 Vue 2 中，双向数据绑定的核心是 `Object.defineProperty()`，它允许 Vue 对每个属性进行 getter 和 setter 的拦截，从而实现响应式系统。对于普通的响应式属性来说，这一切都很简单，因为属性的 getter 和 setter 可以很容易地更改并通知 Vue 更新视图。\n\n但是，由于 JavaScript 的限制，使用 `Object.defineProperty()` 注册响应式属性时并不能完美地跟踪数组索引的变化。而 Vue 需要能够捕捉对数组元素的修改，因此它采用了一种特殊的策略来实现对数组的响应式处理。\n\n### Vue 是如何监控数组的？\n\n1. **拦截数组的变异方法**：Vue 使用一个数组的代理隔着来拦截七个变异数组方法（`push`、`pop`、`shift`、`unshift`、`splice`）和 `sort` 方法以及 `reverse` 方法。对这些方法的调用会被重新定义，以保证当它们被调用时，视图会重新渲染。\n\n2. **Vue.set 和 Vue.delete**：Vue 提供了两个全局函数 `Vue.set` 和 `Vue.delete`，这些函数确保任何对数组进行的直接设置或删除操作都能够触发视图更新。\n\n3. **不直接使用索引赋值**：直接进行索引赋值操作（如 `vm.items[indexOfItem] = newValue`）不会触发视图更新，因为这是一种不能被 `Object.defineProperty` 拦截的操作。为了避免这个陷阱，你应该使用 `Vue.set` 代替索引赋值。\n\n4. **附加属性**：Vue 会为每个项目的数组添加一些附加属性，这些属性可以触发一些视图渲染。\n\n### 使用例子\n\n以下是两个响应式数组操作的示例：\n\n```javascript\n// 展示Vue.set的使用\nVue.set(vm.items, indexOfItem, newValue);\n\n// 展示Vue.delete的使用\nVue.delete(vm.items, indexOfItem);\n```\n\n使用这些方法可以确保 Vue 的观察者模式能够检测到数组的变化，这点对于在循环中使用的内联数组是非常有用的。\n\n### 注意事项\n\n尽管 Vue 2 通过重新定义数组的变异方法和提供 `Vue.set` 和 `Vue.delete` 方法来实现对数组的响应式更新，但刀片开发人员在操作数组时还是需要谨慎以避免那些一开始就不会被 Vue 捕获的数组操作。\n\n总结来说，Vue 对数组的响应式更新比对象要复杂，因为数组需要通过一种特殊的机制来捕获变异操作而不是普通的属性赋值。这是 Vue 响应式系统比较高级的部分，也是为什么在 Vue 2 中推荐使用 Vue 提供的方法来操作数组的核心原因。\n",{"_58":741,"_180":152,"_181":152,"_182":152,"_183":152,"_184":152,"_185":152,"_186":152,"_187":152,"_188":152},"https://api.github.com/repos/pro-collection/interview-question/issues/719/reactions","https://api.github.com/repos/pro-collection/interview-question/issues/719/timeline",{"_58":744,"_60":61,"_62":745,"_64":746,"_66":747,"_68":748,"_70":749,"_72":750,"_74":751,"_76":752,"_78":753,"_111":754,"_131":132,"_133":24,"_134":-5,"_135":757,"_137":758,"_159":152,"_153":760,"_155":761,"_158":-5,"_161":162,"_106":-5,"_163":-5,"_164":762,"_169":763,"_175":764,"_177":765,"_189":767,"_191":-5,"_192":-5,"_193":194},"https://api.github.com/repos/pro-collection/interview-question/issues/718","https://api.github.com/repos/pro-collection/interview-question/issues/718/labels{/name}","https://api.github.com/repos/pro-collection/interview-question/issues/718/comments","https://api.github.com/repos/pro-collection/interview-question/issues/718/events","https://github.com/pro-collection/interview-question/issues/718",2254405580,"I_kwDOJGDC6c6GX3_M",718,"介绍一下 requestIdleCallback api【热度: 290】",{"_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},[755,756],{"_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":252,"_68":253,"_62":254,"_70":255,"_72":256,"_74":257,"_76":258,"_122":259,"_147":759,"_149":261,"_151":152,"_131":132,"_153":262,"_155":263,"_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},"2024-04-20T06:14:10Z","2024-04-20T06:36:22Z",{"_166":152,"_167":152,"_168":152},{"_171":152,"_172":152,"_173":152,"_174":152},"**关键词**：requestIdleCallback api、requestIdleCallback 使用场景\r\n\r\n`requestIdleCallback` 是一个 Web API，它允许开发者请求浏览器在主线程空闲时执行一些低优先级的后台任务，这对于执行如分析、整理状态和数据等不紧急的任务是理想的。这种方法可以提高用户的响应性和页面的整体性能。\r\n\r\n以下是 `requestIdleCallback` API 的一些关键特点：\r\n\r\n### 何时使用 requestIdleCallback\r\n\r\n`requestIdleCallback` 特别适合那些不直接关联用户交互及响应的任务，这些任务可以延后执行而不会明显影响用户体验。例如：\r\n\r\n- 清理工作：如标记的 DOM 节点删除、数据的本地存储同步等。\r\n- 非关键的解析：如解析大量数据。\r\n- 状态更新：如发送不紧急的状态变更。\r\n\r\n### 如何使用 requestIdleCallback\r\n\r\n使用 `requestIdleCallback`，你需要传递一个回调函数给它，此函数会在浏览器的空闲时间调用。你可以指定一个超时参数，它定义了浏览器在“空闲期”最多可以花费的时间来执行你的回调。\r\n\r\n```javascript\r\nrequestIdleCallback(myNonCriticalFunction, { timeout: 5000 });\r\n```\r\n\r\n- **myNonCriticalFunction**: 这是你想要浏览器在空闲时间执行的函数。\r\n- **timeout**: 一个可选的参数，表示回调执行时间的上限（以毫秒为单位）。如果超时，浏览器可能在下次空闲机会进行执行。\r\n\r\n### 回调函数参数\r\n\r\n你的回调函数会接收到一个 `IdleDeadline` 对象作为参数，通常命名为 `deadline`。这个对象包含两个属性：\r\n\r\n- **didTimeout** - 一个布尔值，如果超时已经被触发为 `true`。\r\n- **timeRemaining** - 返回当前空闲阶段剩余时间的函数，单位是毫秒。\r\n\r\n```javascript\r\nfunction myNonCriticalFunction(deadline) {\r\n while ((deadline.timeRemaining() > 0 || deadline.didTimeout) && someCondition()) {\r\n // 执行工作直到时间用完或下次更新不是必要的\r\n }\r\n\r\n // 如果还有未完成的工作，可以请求下一次空闲周期\r\n if (someCondition()) {\r\n requestIdleCallback(myNonCriticalFunction);\r\n }\r\n}\r\n```\r\n\r\n### 注意事项\r\n\r\n- `requestIdleCallback` 不保证你的回调会在一个特定的时刻被调用，它只在浏览器需要的时候调用。\r\n- 执行低优先级任务时，不应该太过频繁或执行时间太长，以免影响页面性能。\r\n- 这个 API 为了最大化性能优化，会强制性地结束你的任务，在不迟于指定的超时时长执行结束。\r\n\r\n### Cross-Browser Compatibility (跨浏览器兼容性)\r\n\r\n你可能需要 polyfills（垫片库）来确保 `requestIdleCallback` 的兼容性，因为它并不是在所有浏览器中都有原生支持。\r\n\r\n使用 `requestIdleCallback`，开发者可以更好地利用浏览器的空闲序列来执行不紧急的任务，同时保持用户交互的流畅度。\r\n\r\n### 参考文档\r\n- https://developer.mozilla.org/zh-CN/docs/Web/API/Background_Tasks_API",{"_58":766,"_180":152,"_181":152,"_182":152,"_183":152,"_184":152,"_185":152,"_186":152,"_187":152,"_188":152},"https://api.github.com/repos/pro-collection/interview-question/issues/718/reactions","https://api.github.com/repos/pro-collection/interview-question/issues/718/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,"_131":132,"_133":24,"_134":-5,"_135":782,"_137":783,"_159":152,"_153":785,"_155":785,"_158":-5,"_161":162,"_106":-5,"_163":-5,"_164":786,"_169":787,"_175":788,"_177":789,"_189":791,"_191":-5,"_192":-5,"_193":194},"https://api.github.com/repos/pro-collection/interview-question/issues/717","https://api.github.com/repos/pro-collection/interview-question/issues/717/labels{/name}","https://api.github.com/repos/pro-collection/interview-question/issues/717/comments","https://api.github.com/repos/pro-collection/interview-question/issues/717/events","https://github.com/pro-collection/interview-question/issues/717",2254404814,"I_kwDOJGDC6c6GX3zO",717,"[React] 为何要自己实现调度器，而不是直接使用 requestIdleCallback ？【热度: 236】",{"_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":725,"_72":726,"_58":727,"_117":728,"_119":729,"_121":24,"_122":730},{"_70":125,"_72":126,"_58":127,"_117":128,"_119":129,"_121":24,"_122":130},[],{"_58":252,"_68":253,"_62":254,"_70":255,"_72":256,"_74":257,"_76":258,"_122":259,"_147":784,"_149":261,"_151":152,"_131":132,"_153":262,"_155":263,"_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},"2024-04-20T06:11:31Z",{"_166":152,"_167":152,"_168":152},{"_171":152,"_172":152,"_173":152,"_174":152},"**关键词**：react 调度器 Scheduler、requestIdleCallback 使用场景\n\nReact 在性能优化方面的一个关键组件是调度器（Scheduler），它负责在渲染的过程中合理安排工作，以减少用户的等待时间以及避免单个任务占用过多的主线程时间，从而提高渲染性能。React 在 18.0 版本后引入了新的调度器机制，提供了更好的性能体验。\n\n那么，为什么 React 不直接使用 `requestIdleCallback` 而要自己实现调度器呢？\n\n1. **控制精细度：** React 需要比 `requestIdleCallback` 更高的控制精细度。`requestIdleCallback` 是基于浏览器的空闲时间进行调度的，而 React 调度器可以根据组件优先级、更新的紧急程度等信息，更精确地安排渲染的工作。\n\n2. **跨浏览器兼容性：** `requestIdleCallback` 直到 2018 年才是浏览器中较普遍支持的 API。React 需要一个能够跨各个版本或框架的解决方案，以实现一致的性能体验。\n\n3. **时间切片：** React 使用一种称为“时间切片”（time slicing）的技术，允许组件分布在多个帧中渲染以维持流畅的 UI。这依赖于 React 自己对任务和帧的精确控制，而不是依赖浏览器的 `requestIdleCallback`。\n\n4. **更丰富的特性：** React 调度器提供了比 `requestIdleCallback` 更丰富的特性和更加详细的调度策略，这包括：\n\n - `Immediate` 模式，用于同步渲染，当它是必需的时候。\n - `User-blocking` 模式，用于任务需要尽快完成，但能够容忍一定延迟，比如交互动画。\n - `Normal` 和 `Low` 模式，用于不同优先级的更新。\n\n5. **复杂功能的实现：** React 使用调度器实现某些特定的特性，比如：\n\n - Fiber 架构，允许 React 在类组件上实现 Concurrent 特性。\n - 在客户端渲染和服务器端渲染之间实现一致性。\n\n6. **优化生态工具：** 对于 React 生态中的其他工具和实现（如 react-native、fast-refresh 等），它们可能需要特定或不同的调度策略。\n\n7. **未来兼容性：** React 团队可以更好地在自己控制的调度器中实现未来的优化和特性，而不受浏览器 API 变更的影响。\n\n最后，调度器是 React 架构中的一个重要部分，它让 React 能够实现更丰富和灵活的用户界面渲染逻辑。尽管 `requestIdleCallback` 可以被用来实现一些调度器的特性，但是完全使用它将限制 React 进一步优化的可能性，并迫使 React 依赖于浏览器的调度行为，这可能不符合 React 的长期发展和技术策略。\n",{"_58":790,"_180":152,"_181":152,"_182":152,"_183":152,"_184":152,"_185":152,"_186":152,"_187":152,"_188":152},"https://api.github.com/repos/pro-collection/interview-question/issues/717/reactions","https://api.github.com/repos/pro-collection/interview-question/issues/717/timeline",{"_58":793,"_60":61,"_62":794,"_64":795,"_66":796,"_68":797,"_70":798,"_72":799,"_74":800,"_76":801,"_78":802,"_111":803,"_131":132,"_133":24,"_134":-5,"_135":806,"_137":807,"_159":152,"_153":809,"_155":810,"_158":-5,"_161":162,"_106":-5,"_163":-5,"_164":811,"_169":812,"_175":813,"_177":814,"_189":816,"_191":-5,"_192":-5,"_193":194},"https://api.github.com/repos/pro-collection/interview-question/issues/699","https://api.github.com/repos/pro-collection/interview-question/issues/699/labels{/name}","https://api.github.com/repos/pro-collection/interview-question/issues/699/comments","https://api.github.com/repos/pro-collection/interview-question/issues/699/events","https://github.com/pro-collection/interview-question/issues/699",2241863787,"I_kwDOJGDC6c6FoCBr",699,"你在开发过程中，使用过哪些 TS 的特性或者能力？【热度: 670】",{"_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},[804,805],{"_70":584,"_72":585,"_58":586,"_117":587,"_119":588,"_121":24,"_122":589},{"_70":125,"_72":126,"_58":127,"_117":128,"_119":129,"_121":24,"_122":130},[],{"_58":252,"_68":253,"_62":254,"_70":255,"_72":256,"_74":257,"_76":258,"_122":259,"_147":808,"_149":261,"_151":152,"_131":132,"_153":262,"_155":263,"_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},"2024-04-14T02:11:46Z","2024-04-14T02:11:47Z",{"_166":152,"_167":152,"_168":152},{"_171":152,"_172":152,"_173":152,"_174":152},"**关键词**：TS 特性和能力\n\n> 这个为何被作者列为了高阶范围的问题 \n> 原因如下：大多数纯写业务的同学，可能就用到了 `interface` 和 `type` 最多加上 `enum` 和 `泛型`； \n> TS 很多牛掰的特性，是伴随做复杂的工具库，或者处理复杂业务场景来的。\n\n这里直接上干货：\n\n1. **Utility Types（工具类型）**：\n\n - **Partial\\**: 将类型 T 的所有属性变为可选。\n - **Required\\**: 将类型 T 的所有属性变为必选。\n - **Readonly\\**: 将类型 T 的所有属性变为只读。\n - **Record\\**: 创建一个具有指定键类型 K 和值类型 T 的新对象类型。\n - **Pick\\**: 从类型 T 中选择指定属性 K 形成新类型。\n - **Omit\\**: 从类型 T 中排除指定属性 K 形成新类型。\n - **Exclude\\**: 从类型 T 中排除可以赋值给类型 U 的类型。\n - **Extract\\**: 从类型 T 中提取可以赋值给类型 U 的类型。\n - **NonNullable\\**: 从类型 T 中排除 null 和 undefined 类型。\n - **ReturnType\\**: 获取函数类型 T 的返回类型。\n - **Parameters\\**: 获取函数类型 T 的参数类型组成的元组类型。\n\n2. **条件判定类型**：\n\n - **Conditional Types（条件类型）**: 根据类型关系进行条件判断生成不同的类型。\n - **Distribute Conditional Types（分布式条件类型）**: 分发条件类型，允许条件类型在联合类型上进行分发。\n\n3. **Mapped Types（映射类型）**：根据已有类型创建新类型，通过映射类型可以生成新的类型结构。\n\n4. **Template Literal Types（模板文字类型）**：使用字符串模板创建新类型。\n\n5. **类型推断关键字**：\n - **keyof 关键字**：关键字允许在泛型条件类型中推断类型变量。\n - **instanceof**：运算符用于检查对象是否是特定类的实例。\n - **in**：用于检查对象是否具有特定属性。\n - **type guards**：类型守卫是自定义的函数或条件语句，用于在代码块内缩小变量的类型范围。\n - **as**：用于类型断言，允许将一个变量断言为特定的类型。\n\n详细内容请参考这个文档： https://github.com/yanlele/node-index/issues/75\n",{"_58":815,"_180":152,"_181":152,"_182":152,"_183":152,"_184":152,"_185":152,"_186":152,"_187":152,"_188":152},"https://api.github.com/repos/pro-collection/interview-question/issues/699/reactions","https://api.github.com/repos/pro-collection/interview-question/issues/699/timeline",{"_58":818,"_60":61,"_62":819,"_64":820,"_66":821,"_68":822,"_70":823,"_72":824,"_74":825,"_76":826,"_78":827,"_111":828,"_131":132,"_133":24,"_134":-5,"_135":831,"_137":832,"_159":152,"_153":834,"_155":834,"_158":-5,"_161":162,"_106":-5,"_163":-5,"_164":835,"_169":836,"_175":837,"_177":838,"_189":840,"_191":-5,"_192":-5,"_193":194},"https://api.github.com/repos/pro-collection/interview-question/issues/698","https://api.github.com/repos/pro-collection/interview-question/issues/698/labels{/name}","https://api.github.com/repos/pro-collection/interview-question/issues/698/comments","https://api.github.com/repos/pro-collection/interview-question/issues/698/events","https://github.com/pro-collection/interview-question/issues/698",2241860649,"I_kwDOJGDC6c6FoBQp",698,"开发过程中为什么会选择使用 ts , 相比于 JS 开发，有哪些优点？【热度: 318】",{"_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},[829,830],{"_70":584,"_72":585,"_58":586,"_117":587,"_119":588,"_121":24,"_122":589},{"_70":125,"_72":126,"_58":127,"_117":128,"_119":129,"_121":24,"_122":130},[],{"_58":211,"_68":212,"_62":213,"_70":214,"_72":215,"_74":216,"_76":217,"_122":218,"_147":833,"_149":220,"_151":152,"_131":132,"_153":221,"_155":222,"_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},"2024-04-14T01:59:50Z",{"_166":152,"_167":152,"_168":152},{"_171":152,"_172":152,"_173":152,"_174":152},"**关键词**：TS 开发优势\n\n使用 TypeScript（简称 TS）而不是纯 JavaScript（JS）进行开发，是因为 TypeScript 提供了一些特性和优势，这些可以帮助开发者提高代码质量、可维护性以及开发效率。以下是使用 TypeScript 的一些主要优点：\n\n1. **静态类型检查**：\n TypeScript 最大的优点是其静态类型系统。静态类型检查意味着错误（如类型错误、未定义的属性或函数）可以在代码运行之前被发现，通常在编写代码的过程中或编译阶段即被 IDE 捕获，这有助于减少运行时错误。\n\n2. **代码智能与自动补全**：\n 由于类型注解，开发者在使用 IDE 或编辑器时可以得到更好的代码智能提示，包括自动补全、函数签名信息、跳转到定义等，从而提高开发效率。\n\n3. **易于重构**：\n 类型安全意味着重构更加安全、更少风险。IDE 可以轻松做到像重命名变量、函数、类的成员等操作，并确保所有的引用都得到更新。\n\n4. **更好的协作**：\n 类型系统可以作为代码中变量、函数和模块的文档说明，这使得团队协作时代码的意图更加清晰，尤其是在大型项目或多人协作环境中。\n\n5. **更丰富的语言特性**：\n TypeScript 支持最新的和即将推出的 ECMAScript 特性，并添加了它自己的额外特性（如类型注解、接口、泛型、枚举等）。\n\n6. **搭配现代框架**：\n 许多现代前端框架对 TypeScript 有良好支持。比如 Angular 是通过 TypeScript 开发的，Vue 和 React 也对 TypeScript 有很好的支持。\n\n7. **避免隐式强制类型转换**：\n JavaScript 由于其动态类型的特性，在进行运算时可能会发生隐式类型转换，导致非预期结果。TypeScript 通过在编译阶段强制类型检查，减少这类问题的发生。\n\n8. **增加大型项目的可管理性**：\n 对于大型、复杂的项目，TypeScript 的类型系统可以帮助代码更好地组织，易于理解和维护。\n\n尽管 TypeScript 带来了许多优点，但它也需要一定的学习投入，并且搭建项目初始化时可能更加复杂。然而，对于需要长期维护和多人协作的项目，以及对类型安全有专门要求的应用，TypeScript 提供的长期益处远大于短期的劣势。\n",{"_58":839,"_180":152,"_181":152,"_182":152,"_183":152,"_184":152,"_185":152,"_186":152,"_187":152,"_188":152},"https://api.github.com/repos/pro-collection/interview-question/issues/698/reactions","https://api.github.com/repos/pro-collection/interview-question/issues/698/timeline",{"_58":842,"_60":61,"_62":843,"_64":844,"_66":845,"_68":846,"_70":847,"_72":848,"_74":849,"_76":850,"_78":851,"_111":852,"_131":132,"_133":24,"_134":-5,"_135":855,"_137":856,"_159":194,"_153":858,"_155":859,"_158":-5,"_161":162,"_106":-5,"_163":-5,"_164":860,"_169":861,"_175":862,"_177":863,"_189":865,"_191":-5,"_192":-5,"_193":194},"https://api.github.com/repos/pro-collection/interview-question/issues/684","https://api.github.com/repos/pro-collection/interview-question/issues/684/labels{/name}","https://api.github.com/repos/pro-collection/interview-question/issues/684/comments","https://api.github.com/repos/pro-collection/interview-question/issues/684/events","https://github.com/pro-collection/interview-question/issues/684",2241462809,"I_kwDOJGDC6c6FmgIZ",684,"Eslint 代码检查的过程是啥？【热度: 111】",{"_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},[853,854],{"_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":252,"_68":253,"_62":254,"_70":255,"_72":256,"_74":257,"_76":258,"_122":259,"_147":857,"_149":261,"_151":152,"_131":132,"_153":262,"_155":263,"_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},"2024-04-13T09:34:59Z","2024-09-17T02:36:13Z",{"_166":152,"_167":152,"_168":152},{"_171":152,"_172":152,"_173":152,"_174":152},"**关键词**：eslint 代码检测、eslint 代码检测执行过程\n\nESLint 是一个插件化的静态代码分析工具，用于识别 JavaScript 代码中的问题。它在代码质量和编码风格方面有助于保持一致性。代码检查的过程通常如下：\n\n1. **配置**：\n 首先需要为 ESLint 提供一套规则，这些规则可以在`.eslintrc`配置文件中定义，或者在项目的`package.json`文件中的`eslintConfig`字段里指定。规则可以继承自一套已有的规则集，如`eslint:recommended`，或者可以是一个流行的样式指南，如`airbnb`。也可以是自定义的规则集。\n\n2. **解析**：\n 当运行 ESLint 时，它会使用一个解析器（如`espree`，默认的解析器）来解析代码，将代码转换成一个抽象语法树（AST）。AST 是代码结构的一个树状表示，能让 ESLint 理解代码的语义结构。\n\n3. **遍历**：\n 一旦代码被转换成 AST，ESLint 则会遍历该树。它会查找树的每个节点，检查是否有任何规则适用于该节点。在遍历过程中，如果发现违反了某项规则，ESLint 将记录一个问题（通常称为“lint 错误”）。\n\n4. **报告**：\n 在遍历完整个 AST 之后，ESLint 会生成一份报告。这份报告详细说明了它在代码中找到的任何问题。这些问题会被分类为错误或警告，根据配置设置的不同，某些问题可能会阻止构建过程或者被忽略。\n\n5. **修复**：\n 对于某些类型的问题，ESLint 提供了自动修复的功能。这意味着你可以让 ESLint 尝试自动修复它所发现的问题，不需人工干预。\n\n6. **集成**：\n ESLint 可以集成到 IDE 中，这样就可以在代码编写过程中即时提供反馈。它也可以被集成到构建工具如 Webpack 或任务运行器 Grunt、Gulp 中，作为构建过程或提交代码到版本控制系统前的一个步骤。\n\n通过以上步骤，ESLint 帮助开发者在编码过程中遵循一致的风格和避免出现潜在的错误。\n",{"_58":864,"_180":152,"_181":152,"_182":152,"_183":152,"_184":152,"_185":152,"_186":152,"_187":152,"_188":152},"https://api.github.com/repos/pro-collection/interview-question/issues/684/reactions","https://api.github.com/repos/pro-collection/interview-question/issues/684/timeline",{"_58":867,"_60":61,"_62":868,"_64":869,"_66":870,"_68":871,"_70":872,"_72":873,"_74":874,"_76":875,"_78":876,"_111":877,"_131":132,"_133":24,"_134":-5,"_135":880,"_137":881,"_159":152,"_153":883,"_155":884,"_158":-5,"_161":162,"_106":-5,"_163":-5,"_164":885,"_169":886,"_175":887,"_177":888,"_189":890,"_191":-5,"_192":-5,"_193":194},"https://api.github.com/repos/pro-collection/interview-question/issues/683","https://api.github.com/repos/pro-collection/interview-question/issues/683/labels{/name}","https://api.github.com/repos/pro-collection/interview-question/issues/683/comments","https://api.github.com/repos/pro-collection/interview-question/issues/683/events","https://github.com/pro-collection/interview-question/issues/683",2241461162,"I_kwDOJGDC6c6Fmfuq",683,"void 和 never 区别【热度: 410】",{"_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},[878,879],{"_70":584,"_72":585,"_58":586,"_117":587,"_119":588,"_121":24,"_122":589},{"_70":125,"_72":126,"_58":127,"_117":128,"_119":129,"_121":24,"_122":130},[],{"_58":211,"_68":212,"_62":213,"_70":214,"_72":215,"_74":216,"_76":217,"_122":218,"_147":882,"_149":220,"_151":152,"_131":132,"_153":221,"_155":222,"_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},"2024-04-13T09:31:27Z","2024-04-13T09:31:28Z",{"_166":152,"_167":152,"_168":152},{"_171":152,"_172":152,"_173":152,"_174":152},"**关键词**：typescript void、typescript never、void 和 never 区别\n\n在 TypeScript 中，`void`和`never`类型都代表没有值，但用途和含义却有所不同。以下是它们之间的主要区别：\n\n1. **void**：\n\n `void`类型用于标记函数没有任何返回值。这意呑着函数可能执行了一些操作但是没有返回任何内容。这不同于返回`undefined`或`null`，尽管在没有明确返回值时，JavaScript 函数默认返回`undefined`。\n\n 如果一个函数的返回类型是`void`，它可能有一个`return`语句，但`return`语句不能返回任何值（或者根本就没有`return`语句）。\n\n 例子：\n\n ```typescript\n function greet(): void {\n console.log(\"Hello, World!\");\n }\n ```\n\n 这个函数打印一个字符串到控制台，但不返回任何值。\n\n2. **never**：\n\n `never`类型表示永远不会返回任何值。它通常用于两种情况：函数总是抛出一个错误，这样就不会有返回值；或者函数有一个无法达到的终点，比如无限循环。\n\n 例子：\n\n ```typescript\n function throwError(errorMsg: string): never {\n throw new Error(errorMsg);\n }\n\n function infiniteLoop(): never {\n while (true) {}\n }\n ```\n\n 这两个函数都不会正常结束：`throwError`函数会抛出异常，而`infiniteLoop`函数会永远循环。在这两种情况中，返回类型`never`正确地表明函数不会有任何返回执行路径。\n\n总结来说，`void`用于没有返回值的函数，这意味着函数的执行结束后不会给调用者任何值；而`never`表示函数永远不会有一个正常的结束，因此不会给调用者任何机会获得它的返回值。它们在类型系统中表达了不同的概念和意图。\n",{"_58":889,"_180":152,"_181":152,"_182":152,"_183":152,"_184":152,"_185":152,"_186":152,"_187":152,"_188":152},"https://api.github.com/repos/pro-collection/interview-question/issues/683/reactions","https://api.github.com/repos/pro-collection/interview-question/issues/683/timeline",{"_58":892,"_60":61,"_62":893,"_64":894,"_66":895,"_68":896,"_70":897,"_72":898,"_74":899,"_76":900,"_78":901,"_111":902,"_131":132,"_133":24,"_134":-5,"_135":905,"_137":906,"_159":152,"_153":918,"_155":919,"_158":-5,"_161":162,"_106":-5,"_163":-5,"_164":920,"_169":921,"_175":922,"_177":923,"_189":925,"_191":-5,"_192":-5,"_193":194},"https://api.github.com/repos/pro-collection/interview-question/issues/677","https://api.github.com/repos/pro-collection/interview-question/issues/677/labels{/name}","https://api.github.com/repos/pro-collection/interview-question/issues/677/comments","https://api.github.com/repos/pro-collection/interview-question/issues/677/events","https://github.com/pro-collection/interview-question/issues/677",2229137016,"I_kwDOJGDC6c6E3e54",677,"JS 放在 head 里和放在 body 里有什么区别？【热度: 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},[903,904],{"_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":907,"_68":908,"_62":909,"_70":910,"_72":911,"_74":194,"_76":912,"_122":913,"_147":914,"_149":915,"_151":152,"_131":132,"_153":916,"_155":917,"_157":-5,"_158":-5},"https://api.github.com/repos/pro-collection/interview-question/milestones/1","https://github.com/pro-collection/interview-question/milestone/1","https://api.github.com/repos/pro-collection/interview-question/milestones/1/labels",9124541,"MI_kwDOJGDC6c4Aizq9","初","初级面试问题",{"_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},79,"2023-03-06T14:59:51Z","2024-11-22T14:22:55Z","2024-04-06T08:14:36Z","2024-04-06T08:15:38Z",{"_166":152,"_167":152,"_168":152},{"_171":152,"_172":152,"_173":152,"_174":152},"将 JavaScript 代码放在 `` 标签内部和放在 `` 标签内部有一些区别：\n1. **加载顺序**：放在 `` 里会在页面加载之前执行 JavaScript 代码，而放在 `` 里会在页面加载后执行。\n2. **页面渲染**：如果 JavaScript 代码影响了页面的布局或样式，放在 `` 里可能会导致页面渲染延迟，而放在 `` 里可以减少这种影响。\n3. **代码依赖**：如果 JavaScript 代码依赖其他元素，放在 `` 里可以确保这些元素已经加载。\n4. **全局变量和函数**：放在 `` 里的 JavaScript 代码中的全局变量和函数在整个页面生命周期内都可用。\n\n以下是一个简单的示例代码，展示了如何在 `` 和 `` 中放置 JavaScript 代码：\n\n```html\n\n\n\n\n \n\n\n\n \n\n\n\n```\n在这个示例中，分别在 `` 和 `` 中放置了简单的 JavaScript 代码，用于在控制台输出信息，以便观察执行顺序。\n",{"_58":924,"_180":152,"_181":152,"_182":152,"_183":152,"_184":152,"_185":152,"_186":152,"_187":152,"_188":152},"https://api.github.com/repos/pro-collection/interview-question/issues/677/reactions","https://api.github.com/repos/pro-collection/interview-question/issues/677/timeline",{"_58":927,"_60":61,"_62":928,"_64":929,"_66":930,"_68":931,"_70":932,"_72":933,"_74":934,"_76":935,"_78":936,"_111":937,"_131":132,"_133":24,"_134":-5,"_135":946,"_137":947,"_159":194,"_153":949,"_155":950,"_158":-5,"_161":162,"_106":-5,"_163":-5,"_164":951,"_169":952,"_175":953,"_177":954,"_189":956,"_191":-5,"_192":-5,"_193":194},"https://api.github.com/repos/pro-collection/interview-question/issues/676","https://api.github.com/repos/pro-collection/interview-question/issues/676/labels{/name}","https://api.github.com/repos/pro-collection/interview-question/issues/676/comments","https://api.github.com/repos/pro-collection/interview-question/issues/676/events","https://github.com/pro-collection/interview-question/issues/676",2229099782,"I_kwDOJGDC6c6E3V0G",676,"列表分页，快速翻页下的竞态问题【热度: 444】",{"_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},[938,945],{"_70":939,"_72":940,"_58":941,"_117":942,"_119":943,"_121":24,"_122":944},5232529101,"LA_kwDOJGDC6c8AAAABN-IOzQ","https://api.github.com/repos/pro-collection/interview-question/labels/%E7%BD%91%E7%BB%9C","网络","1A8829","web 网络相关",{"_70":125,"_72":126,"_58":127,"_117":128,"_119":129,"_121":24,"_122":130},[],{"_58":211,"_68":212,"_62":213,"_70":214,"_72":215,"_74":216,"_76":217,"_122":218,"_147":948,"_149":220,"_151":152,"_131":132,"_153":221,"_155":222,"_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},"2024-04-06T06:14:46Z","2024-08-23T01:28:52Z",{"_166":152,"_167":152,"_168":152},{"_171":152,"_172":152,"_173":152,"_174":152},"**关键词**：翻页场景竞态问题\r\n\r\n**列表分页，快速翻页下的竞态问题**\r\n\r\n> 问题描述：比如在前端分页请求的时候，因为翻页很快，所以请求还没有来得及回来的时候，就发起了下一次请求，且请求返回的时间也是不固定的。 \r\n> 如何保证最后一次请求结果和其请求页码是对应上的。\r\n\r\n在处理这种情况时，一种常见的方法是使用请求标记或唯一标识符来确保请求和结果之间的对应关系。\r\n\r\n以下是一个示例代码片段，展示了一种可能的解决方案：\r\n\r\n```javascript\r\n// 存储请求的标记\r\nlet requestId = 0;\r\n\r\n// 发起请求的函数\r\nfunction sendRequest(page) {\r\n requestId++;\r\n\r\n // 将请求标记与页码一起发送\r\n fetch(`/api?requestId=${requestId}&page=${page}`)\r\n\r\n .then(response => response.json())\r\n\r\n .then(data => {\r\n // 根据请求标记处理返回的数据\r\n handleResponseData(requestId, data);\r\n });\r\n}\r\n\r\n// 处理返回数据的函数\r\nfunction handleResponseData(requestId, data) {\r\n if (requestId === currentRequestId) {\r\n // 在这里处理数据并更新页面\r\n }\r\n}\r\n\r\n// 在翻页时调用 sendRequest 函数\r\n```\r\n\r\n在这个示例中，每次发起请求时都会增加请求标记 `requestId`，并将其与页码一起发送到服务器。在处理返回的数据时，根据请求标记来确保与当前的请求对应。\r\n\r\n另外，还可以考虑以下几点：\r\n- 对快速翻页进行限制或优化，避免过于频繁的请求。\r\n- 在服务器端处理请求时，可以根据请求标记来保证返回的数据与特定的请求相关联。\r\n- 可以使用缓存来存储部分数据，减少不必要的请求。\r\n\r\n**保证唯一性**\r\n\r\n保证请求标记的唯一性可以通过以下几种方式：\r\n1. 使用递增的数字：就像上面示例中的 `requestId` 一样，每次增加 1。\r\n2. 使用随机数：生成一个随机的数字作为请求标记。\r\n3. 使用时间戳：结合当前时间生成唯一的标记。\r\n4. 组合多种因素：例如，将数字、时间戳或其他相关信息组合起来创建唯一标记。\r\n\r\n例如，使用时间戳作为请求标记的示例代码如下：\r\n\r\n```javascript\r\nlet requestId = Date.now();\r\n```\r\n这样每次请求时，`requestId` 都会是一个唯一的时间戳值。\r\n\r\n",{"_58":955,"_180":152,"_181":152,"_182":152,"_183":152,"_184":152,"_185":152,"_186":152,"_187":152,"_188":152},"https://api.github.com/repos/pro-collection/interview-question/issues/676/reactions","https://api.github.com/repos/pro-collection/interview-question/issues/676/timeline",{"_58":958,"_60":61,"_62":959,"_64":960,"_66":961,"_68":962,"_70":963,"_72":964,"_74":965,"_76":966,"_78":967,"_111":968,"_131":132,"_133":24,"_134":-5,"_135":971,"_137":972,"_159":152,"_153":974,"_155":975,"_158":-5,"_161":162,"_106":-5,"_163":-5,"_164":976,"_169":977,"_175":978,"_177":979,"_189":981,"_191":-5,"_192":-5,"_193":194},"https://api.github.com/repos/pro-collection/interview-question/issues/675","https://api.github.com/repos/pro-collection/interview-question/issues/675/labels{/name}","https://api.github.com/repos/pro-collection/interview-question/issues/675/comments","https://api.github.com/repos/pro-collection/interview-question/issues/675/events","https://github.com/pro-collection/interview-question/issues/675",2105867760,"I_kwDOJGDC6c59hP3w",675,"CORS 请求中，是如何触发预检请求【热度: 229】",{"_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},[969,970],{"_70":939,"_72":940,"_58":941,"_117":942,"_119":943,"_121":24,"_122":944},{"_70":125,"_72":126,"_58":127,"_117":128,"_119":129,"_121":24,"_122":130},[],{"_58":252,"_68":253,"_62":254,"_70":255,"_72":256,"_74":257,"_76":258,"_122":259,"_147":973,"_149":261,"_151":152,"_131":132,"_153":262,"_155":263,"_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},"2024-01-29T16:20:56Z","2024-01-29T16:20:57Z",{"_166":152,"_167":152,"_168":152},{"_171":152,"_172":152,"_173":152,"_174":152},"**关键词**：CORS 预检请求条件\n\n其动机是，`HTML 4.0` 中的 `

` 元素（早于跨站 `XMLHttpRequest 和 fetch`）可以向任何来源提交简单请求，所以任何编写服务器的人一定已经在保护跨站请求伪造攻击`（CSRF）`。在这个假设下，服务器不必选择加入（通过响应预检请求）来接收任何看起来像表单提交的请求，因为 CSRF 的威胁并不比表单提交的威胁差。然而，服务器仍然必须提供 `Access-Control-Allow-Origin`的选择，以便与脚本共享响应。\n\n若请求满足所有下述条件，则该请求可视为简单请求：\n\n- 使用下列方法之一：\n - `GET`\n - `HEAD`\n - `POST`\n\n- 除了被用户代理自动设置的标头字段（例如 Connection、User-Agent 或其他在 Fetch 规范中定义为禁用标头名称的标头），允许人为设置的字段为 Fetch 规范定义的对 CORS 安全的标头字段集合。该集合为：\n - `Accept`\n - `Accept-Language`\n - `Content-Language`\n - `Content-Type（需要注意额外的限制）`\n - `Range（只允许简单的范围标头值如 bytes=256- 或 bytes=127-255）`\n\n- Content-Type 标头所指定的媒体类型的值仅限于下列三者之一：\n - `text/plain`\n - `multipart/form-data`\n - `application/x-www-form-urlencoded`\n\n- 如果请求是使用 `XMLHttpRequest` 对象发出的，在返回的 `XMLHttpRequest.upload` 对象属性上没有注册任何事件监听器；也就是说，给定一个 `XMLHttpRequest` 实例 `xhr`，没有调用 `xhr.upload.addEventListener()`，以监听该上传请求。\n\n- 请求中没有使用 `ReadableStream` 对象。\n\n比如说，假如站点 https://foo.example 的网页应用想要访问 https://bar.other 的资源。foo.example 的网页中可能包含类似于下面的 JavaScript 代码：\n",{"_58":980,"_180":152,"_181":152,"_182":152,"_183":152,"_184":152,"_185":152,"_186":152,"_187":152,"_188":152},"https://api.github.com/repos/pro-collection/interview-question/issues/675/reactions","https://api.github.com/repos/pro-collection/interview-question/issues/675/timeline",{"_58":983,"_60":61,"_62":984,"_64":985,"_66":986,"_68":987,"_70":988,"_72":989,"_74":990,"_76":991,"_78":992,"_111":993,"_131":132,"_133":24,"_134":-5,"_135":996,"_137":997,"_159":152,"_153":999,"_155":1000,"_158":-5,"_161":162,"_106":-5,"_163":-5,"_164":1001,"_169":1002,"_175":1003,"_177":1004,"_189":1006,"_191":-5,"_192":-5,"_193":194},"https://api.github.com/repos/pro-collection/interview-question/issues/674","https://api.github.com/repos/pro-collection/interview-question/issues/674/labels{/name}","https://api.github.com/repos/pro-collection/interview-question/issues/674/comments","https://api.github.com/repos/pro-collection/interview-question/issues/674/events","https://github.com/pro-collection/interview-question/issues/674",2105712097,"I_kwDOJGDC6c59gp3h",674,"http 中 HSTS 是什么【热度: 374】",{"_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},[994,995],{"_70":939,"_72":940,"_58":941,"_117":942,"_119":943,"_121":24,"_122":944},{"_70":125,"_72":126,"_58":127,"_117":128,"_119":129,"_121":24,"_122":130},[],{"_58":252,"_68":253,"_62":254,"_70":255,"_72":256,"_74":257,"_76":258,"_122":259,"_147":998,"_149":261,"_151":152,"_131":132,"_153":262,"_155":263,"_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},"2024-01-29T15:07:23Z","2024-01-29T15:07:24Z",{"_166":152,"_167":152,"_168":152},{"_171":152,"_172":152,"_173":152,"_174":152},"**关键词**：http HSTS\n\nHTTP `Strict-Transport-Security`（HSTS）是一种安全策略，它通过 HTTP 头部告诉浏览器只能通过安全的 HTTPS 连接访问网站，从而增加网站的安全性。HSTS 有助于防止恶意攻击者通过中间人攻击（如SSL剥离攻击）窃取敏感信息。\n\nHSTS 的主要作用包括：\n\n- **强制使用 HTTPS：** 通过 HSTS，网站可以强制浏览器在一定时间内只能通过 HTTPS 访问，提高数据的安全性。\n\n- **防止 SSL 剥离攻击：** HSTS 通过告知浏览器只能通过安全的连接访问网站，有效地防止了一些中间人攻击，例如 SSL 剥离攻击，其中攻击者试图将 HTTPS 连接降级为不安全的 HTTP 连接。\n\n- **增加网站的安全性：** HSTS 是一种增加网站安全性的简单而有效的手段，尤其是对于那些强调隐私和数据保护的网站。\n\n\nHSTS 的工作原理如下：\n\n1. **首次访问：** 当用户首次通过 HTTPS 访问网站时，服务器可以在响应头中包含 HSTS 头部，指定网站的 HSTS 策略。例如：\n```\nStrict-Transport-Security: max-age=31536000; includeSubDomains; preload\n```\n\n- `max-age=31536000`: 告诉浏览器在接下来的 1 年内，只能通过 HTTPS 访问该网站。\n- `includeSubDomains`: 表示该策略也适用于所有子域名。\n- `preload`: 表示网站希望被添加到浏览器的 HSTS 预加载列表中。\n\n2. **以后的访问：** 一旦浏览器接收到包含 HSTS 头部的响应后，它会记住这个信息。在接下来的一年内，浏览器将强制使用 HTTPS 访问该网站，即使用户尝试通过 HTTP 访问。\n\n一旦网站启用了 `HSTS`，并且用户第一次通过 HTTPS 访问该网站，浏览器将在 `HSTS` 头部指定的时间内（`max-age` 参数指定的时间）记住这个策略，即使用户以后尝试通过 HTTP 访问，浏览器仍然会强制使用 HTTPS。因此，使用 HSTS 需要谨慎，确保网站支持 HTTPS 并且配置正确。\n\n**如何取消 `HSTS`**\n\n> 如果之前的请求设置了 HTTP Strict-Transport-Security 这个 header 了，时间是 max-age=31536000；\n> 之后因为一些原因，取消了 Strict-Transport-Security 这个 header，那么还是不能使用 http 吗?\n\n一旦浏览器接收到包含 HTTP `Strict-Transport-Security`（HSTS）头部的响应，并且在响应中设置了 `max-age` 参数，浏览器会在指定的时间内坚持使用 HTTPS 连接，即使后续的请求中不再包含 HSTS 头部。\n\n如果之前的请求设置了 `max-age=31536000`，那么浏览器将在接下来的一年内坚持使用 HTTPS 连接，即使后续的请求中不再包含 HSTS 头部。即使之后取消了 HSTS 头部，浏览器仍然会在 `max-age` 规定的时间内执行强制使用 HTTPS 的策略。\n\n如果由于一些原因需要取消 HSTS，可以采取以下步骤之一：\n\n1. **在 HTTP 响应中不再包含 HSTS 头部：** 在服务器的 HTTPS 响应中，不再包含 `Strict-Transport-Security` 头部，或者将 `max-age` 设置为较短的时间，以便更快地使浏览器放弃 HSTS 策略。\n\n2. **使用 `includeSubDomains` 指令进行逐步取消：** 如果之前设置了 `includeSubDomains`，并且想逐步取消 HSTS，可以在不同的子域名上逐步取消。例如，可以在某个子域名上不再包含 HSTS 头部，而其他子域名仍然保持 HSTS。\n\n请注意，取消 HSTS 头部可能导致用户在一定时间内无法通过 HTTPS 访问网站，因为浏览器会在 `max-age` 规定的时间内继续强制使用 HTTPS。确保在取消 HSTS 头部之前，确保网站的 HTTPS 配置是正确的，以避免访问问题。\n",{"_58":1005,"_180":152,"_181":152,"_182":152,"_183":152,"_184":152,"_185":152,"_186":152,"_187":152,"_188":152},"https://api.github.com/repos/pro-collection/interview-question/issues/674/reactions","https://api.github.com/repos/pro-collection/interview-question/issues/674/timeline",{"_58":1008,"_60":61,"_62":1009,"_64":1010,"_66":1011,"_68":1012,"_70":1013,"_72":1014,"_74":1015,"_76":1016,"_78":1017,"_111":1018,"_131":132,"_133":24,"_134":-5,"_135":1021,"_137":1022,"_159":152,"_153":1024,"_155":1025,"_158":-5,"_161":162,"_106":-5,"_163":-5,"_164":1026,"_169":1027,"_175":1028,"_177":1029,"_189":1031,"_191":-5,"_192":-5,"_193":194},"https://api.github.com/repos/pro-collection/interview-question/issues/673","https://api.github.com/repos/pro-collection/interview-question/issues/673/labels{/name}","https://api.github.com/repos/pro-collection/interview-question/issues/673/comments","https://api.github.com/repos/pro-collection/interview-question/issues/673/events","https://github.com/pro-collection/interview-question/issues/673",2105665554,"I_kwDOJGDC6c59gegS",673,"http 中 CSP 是什么【热度: 323】",{"_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},[1019,1020],{"_70":939,"_72":940,"_58":941,"_117":942,"_119":943,"_121":24,"_122":944},{"_70":125,"_72":126,"_58":127,"_117":128,"_119":129,"_121":24,"_122":130},[],{"_58":252,"_68":253,"_62":254,"_70":255,"_72":256,"_74":257,"_76":258,"_122":259,"_147":1023,"_149":261,"_151":152,"_131":132,"_153":262,"_155":263,"_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},"2024-01-29T14:46:34Z","2024-01-29T14:46:35Z",{"_166":152,"_167":152,"_168":152},{"_171":152,"_172":152,"_173":152,"_174":152},"**关键词**：http CSP\n\n在 HTTP 协议中，CSP 指的是 \"Content Security Policy\"（内容安全策略）。CSP 是一种用于增强网站安全性的安全策略机制，通过指定浏览器只能加载指定来源的资源，以减少恶意攻击的风险。\n\nCSP 的主要目标是防止和减缓特定类型的攻击，例如跨站脚本攻击 (XSS) 和数据注入攻击。通过配置 CSP，网站管理员可以告诉浏览器哪些资源是被信任的，从而减少恶意代码的执行。\n\nCSP 的一些常见配置项包括：\n\n1. **default-src：** 指定默认情况下可以从哪些来源加载资源。\n2. **script-src：** 指定允许加载脚本的来源。\n3. **style-src：** 指定允许加载样式表的来源。\n4. **img-src：** 指定允许加载图片的来源。\n5. **font-src：** 指定允许加载字体的来源。\n6. **connect-src：** 指定允许进行网络请求的来源（例如 Ajax 请求）。\n7. **frame-src：** 指定允许加载框架的来源。\n8. **media-src：** 指定允许加载媒体资源的来源。\n\n等等。\n\n以下是一个简单的 CSP 示例：\n\n```http\nContent-Security-Policy: default-src 'self'; script-src 'self' example.com; img-src 'self' data:;\n```\n\n上述 CSP 规则的含义是：\n\n- `default-src 'self'`: 允许从同一站点加载默认来源的资源。\n- `script-src 'self' example.com`: 允许从同一站点和 example.com 加载脚本。\n- `img-src 'self' data:`: 允许从同一站点和 data: 协议加载图片。\n\nCSP 可以通过 HTTP 头部来设置，也可以通过 `` 标签嵌入在 HTML 页面中。使用 CSP 可以帮助网站减少受到恶意攻击的风险，提高网站的安全性。\n\n**如何通过 meta 标签设置 CSP**\n\n通过 `` 标签设置 Content Security Policy (CSP) 的方式如下：\n\n```html\n\n\n\n \n \n Your Page Title\n\n\n \n\n\n```\n\n在上面的代码中，`` 标签的 `http-equiv` 属性被设置为 \"Content-Security-Policy\"，而 `content` 属性中则包含了 CSP 指令（directives）。你需要将 \"directives\" 替换为你实际想要设置的 CSP 规则。\n\n以下是一个具体的例子：\n\n```html\n\n```\n\n在这个例子中，CSP 规则指定了默认来源是同一站点，允许加载同一站点和 example.com 的脚本，允许加载同一站点和 data: 协议的图片。\n\n注意：通过 `` 标签设置的 CSP 规则只对当前页面生效，而通过 HTTP 头部设置的 CSP 规则对整个站点生效。因此，如果你希望 CSP 规则对整个站点生效，最好在服务器端通过 HTTP 头部设置 CSP。\n",{"_58":1030,"_180":152,"_181":152,"_182":152,"_183":152,"_184":152,"_185":152,"_186":152,"_187":152,"_188":152},"https://api.github.com/repos/pro-collection/interview-question/issues/673/reactions","https://api.github.com/repos/pro-collection/interview-question/issues/673/timeline","pagination",{"_1034":216,"_166":144},"value","actionData","errors"]