正在加载

\n },\n})\n\nclass RouterConfig extends React.Component {\n render() {\n return (\n 加载中 }>\n \n ...\n \n ...\n \n\n \n )\n }\n}\n\nexport default RouterConfig;\n```\n\n### 受控性组件颗粒化，独立请求服务渲染单元\n\n可控性组件颗粒化，独立请求服务渲染单元是笔者在实际工作总结出来的经验。目的就是避免因自身的渲染更新或是副作用带来的全局重新渲染。\n\n大概思路是这样子的：\n![1](https://foruda.gitee.com/images/1682260059688615416/19b33481_7819612.png)\n\n拆分需要单独调用后端接口的细小组件，建立独立的数据请求和渲染，这种依赖数据更新 -> 视图渲染的组件，能从整个体系中抽离出来，好处我总结有以下几个方面。\n\n1. 可以避免父组件的冗余渲染，react的数据驱动，依赖于 state 和 props 的改变，改变state 必然会对组件 render 函数调用，如果父组件中的子组件过于复杂，一个自组件的 state\n 改变，就会牵一发动全身，必然影响性能，所以如果把很多依赖请求的组件抽离出来，可以直接减少渲染次数。\n\n2. 可以优化组件自身性能，无论从class声明的有状态组件还是fun声明的无状态，都有一套自身优化机制，无论是用shouldupdate 还是用 hooks中 useMemo useCallback\n ，都可以根据自身情况，定制符合场景的渲条件，使得依赖数据请求组件形成自己一个小的，适合自身的渲染环境。\n\n3. 能够和redux ,以及redux衍生出来 redux-action , dva,更加契合的工作，用 connect\n 包裹的组件，就能通过制定好的契约，根据所需求的数据更新，而更新自身，而把这种模式用在这种小的，需要数据驱动的组件上，就会起到物尽其用的效果。\n\n### shouldComponentUpdate ,PureComponent 和 React.memo ,immetable.js/immer.js 助力性能调优\n\n#### PureComponent 和 React.memo\n\nReact.PureComponent 通过props和state的浅对比来实现 shouldComponentUpate()。如果对象包含复杂的数据结构(比如对象和数组)\n，他会浅比较，如果深层次的改变，是无法作出判断的，React.PureComponent 认为没有变化，而没有渲染试图。\n\nreact.memo 和 PureComponent 功能类似，react.memo 作为第一个高阶组件，第二个参数可以对props 进行比较，和shouldComponentUpdate不同的, 当第二个参数返回 true\n的时候，证明props没有改变，不渲染组件，反之渲染组件。\n\n#### shouldComponentUpdate\n\n使用 shouldComponentUpdate() 以让React知道当state或props的改变是否影响组件的重新render，默认返回ture，返回false时不会重新渲染更新，而且该方法并不会在初始化渲染或当使用\nforceUpdate() 时被调用。\n\n#### immetable.js/immer.js\n\nimmetable.js 是Facebook 开发的一个js库，可以提高对象的比较性能，像之前所说的pureComponent 只能对对象进行浅比较，,对于对象的数据类型,却束手无策,所以我们可以用 immetable.js 配合\nshouldComponentUpdate 或者 react.memo来使用。immutable 中我们用react-redux来简单举一个例子，如下所示数据都已经被 immetable.js处理。\n\n```jsx\nimport { is } from 'immutable'\n\nconst GoodItems = connect(state =>\n ({ GoodItems: filter(state.getIn(['Items', 'payload', 'list']), state.getIn(['customItems', 'payload', 'list'])) || Immutable.List(), })\n /* 此处省略很多代码～～～～～～ */\n)(memo(({ Items, dispatch, setSeivceId }) => {\n /* */\n}, (pre, next) => is(pre.Items, next.Items)))\n\n```\n\n通过 is 方法来判断，前后Items(对象数据类型)是否发生变化。\n\n**immer** 是 mobx 的作者写的一个 immutable 库，核心实现是利用 ES6 的 proxy，几乎以最小的成本实现了 js 的不可变数据结构，简单易用、体量小巧、设计巧妙，满足了我们对 JS 不可变数据结构的需求。\n\n具体使用可见： https://juejin.cn/post/7157745748832944141\n\n### hooks 组件中，常使用 useMemo、useCallback、useRef 等方式方式重复申明\n\n每次点击button的时候,都会执行Index函数。handerClick1 , handerClick2,handerClick3都会重新声明。这种函数的重复申明，会使得子组件每次都是拿到的新的应用对象，会导致 memo 直接失效。\n\n```jsx\nfunction Index() {\n const [number, setNumber] = useState(0)\n const [handerClick1, handerClick2, handerClick3] = useMemo(() => {\n const fn1 = () => {\n /* 一些操作 */\n }\n const fn2 = () => {\n /* 一些操作 */\n }\n const fn3 = () => {\n /* 一些操作 */\n }\n return [fn1, fn2, fn3]\n }, []) /* 只有当数据里面的依赖项，发生改变的时候，才会重新声明函数。 */\n return

\n 点我有惊喜1\n 点我有惊喜2\n 点我有惊喜3\n \n

\n}\n```\n\n推荐使用 ahooks - usePersistFn、useMemoizedFn 其实现也非常简单，就是将函数的应用绑定在了 ref 上\n\n```jsx\nfunction usePersistFn(fn, deps) {\n const fnRef = useRef();\n\n useEffect(() => {\n fnRef.current = fn;\n }, [fn, ...deps]);\n\n return useCallback(() => {\n return fnRef.current();\n }, [fnRef]);\n}\n```\n\n### 警惕 context 陷阱\n使用Context可以避免的组件的层层props嵌套的问题。但是它使用consumer拿值时,会多一层组件。但得益于 useContext hook 我们可以不使用consumer组件。直接拿到值,直观。一般的使用场景,如那拿全局的class前缀，或者国际化，Ui主题颜色等。\n\n**但是当 Provider 的 value 值发生变化时，它内部的所有消费组件都会重新渲染。Provider 及其内部 consumer 组件都不受制于 shouldComponentUpdate、memo 等函数，因此当 consumer 组件在其祖先组件退出更新的情况下也能更新。**\n\n使用 `createContext 和 useContext` 的时候，尽量从顶层往下传递的数据是不可变的数据，否则会引起整个链路层级的渲染。 \n\n此处推荐使用 `recoil`，由 facebook 官方出品，使用语法非常简单，跟 context 很类似。\n\n",{"_58":428,"_181":152,"_182":152,"_183":152,"_184":152,"_185":152,"_186":152,"_187":152,"_188":152,"_189":152},"https://api.github.com/repos/pro-collection/interview-question/issues/305/reactions","https://api.github.com/repos/pro-collection/interview-question/issues/305/timeline",{"_58":431,"_60":61,"_62":432,"_64":433,"_66":434,"_68":435,"_70":436,"_72":437,"_74":438,"_76":439,"_78":440,"_111":441,"_131":132,"_133":24,"_134":-5,"_135":444,"_137":445,"_159":152,"_153":447,"_155":448,"_158":-5,"_162":163,"_106":-5,"_164":-5,"_165":449,"_170":450,"_176":451,"_178":452,"_190":454,"_192":-5,"_193":-5,"_194":195},"https://api.github.com/repos/pro-collection/interview-question/issues/235","https://api.github.com/repos/pro-collection/interview-question/issues/235/labels{/name}","https://api.github.com/repos/pro-collection/interview-question/issues/235/comments","https://api.github.com/repos/pro-collection/interview-question/issues/235/events","https://github.com/pro-collection/interview-question/issues/235",1646064267,"I_kwDOJGDC6c5iHPKL",235,"[webpack] 什么情况下 webpack treeShaking 会失效？",{"_80":81,"_70":82,"_72":83,"_84":85,"_86":28,"_58":87,"_68":88,"_89":90,"_91":92,"_93":94,"_95":96,"_97":98,"_99":100,"_101":102,"_66":103,"_104":105,"_106":107,"_108":109,"_110":24},[442,443],{"_70":282,"_72":283,"_58":284,"_117":285,"_119":286,"_121":24,"_122":287},{"_70":125,"_72":126,"_58":127,"_117":128,"_119":129,"_121":24,"_122":130},[],{"_58":249,"_68":250,"_62":251,"_70":252,"_72":253,"_74":254,"_76":255,"_122":256,"_147":446,"_149":258,"_151":152,"_131":132,"_153":259,"_155":260,"_157":-5,"_158":-5},{"_80":81,"_70":82,"_72":83,"_84":85,"_86":28,"_58":87,"_68":88,"_89":90,"_91":92,"_93":94,"_95":96,"_97":98,"_99":100,"_101":102,"_66":103,"_104":105,"_106":107,"_108":109,"_110":24},"2023-03-29T15:34:25Z","2023-03-29T15:34:26Z",{"_167":152,"_168":152,"_169":152},{"_172":152,"_173":152,"_174":152,"_175":152},"### 以下是一些可能导致 webpack tree shaking 失效的情况\n\n1. 代码中使用了动态引入（Dynamic Imports）的语法，这种情况下，webpack 无法确定哪些代码会被使用，因此不会进行 tree shaking。\n\n2. 代码使用了函数式编程的方式，比如使用了 map、filter、reduce 等高阶函数，而这些函数很难通过静态分析确定代码的执行路径，所以可能会导致 tree shaking 失效。\n\n3. 代码中使用了 webpack 无法识别的模块系统，比如使用了 AMD 或者 CommonJS 的语法，这种情况下 webpack 也无法进行 tree shaking。\n\n4. 代码使用了 side effect，比如改变全局变量或者函数的参数，这种情况下 webpack 也无法进行 tree shaking。\n\n### 函数式编程的方式 filter 为何会导致无法 tree shaking\n\n函数式编程中常常使用高阶函数来组合函数，这种组合方式常常需要使用传递函数作为参数的方式，例如 map、filter 等高阶函数。这种情况下，如果参数传递的是一个函数表达式或者函数声明，那么无法进行 treeshaking。\n\n举个例子：\n\n```js\n// 代码中定义了一个 sum 函数\nfunction sum(a, b) {\n return a + b;\n}\n\n// 调用了 lodash 库的 filter 函数，传递一个匿名函数表达式作为参数\nimport { filter } from 'lodash';\n\nconst arr = [1, 2, 3, 4, 5];\nconst result = filter(arr, item => {\n if (item > 10) return sum(item, 1)\n else return item;\n});\n```\n上述代码中，使用了 lodash 库的 filter 函数，并且传递了一个匿名函数表达式作为参数。由于函数表达式无法被静态分析，不知道 sum 是否会被调用，因此无法进行 treeshaking，最终导致整个 sum 函数也被打包进了最终的代码中。\n\n### 为什么 commonjs 模块化会导致无法 tree shaking\n\nCommonJS 模块化语法是 Node.js 中的模块化规范，其使用了 `require()` 导入模块，使用 `module.exports` 或 `exports` 导出模块。它采用的是动态导入（require()）和同步加载的方式，这种导入方式无法在编译时确定所依赖的模块，因此在 Webpack 进行 Tree Shaking 时，这种导入方式的模块会被认为无法被静态分析，因而会被排除掉。\n\n相反，ES6 模块化语法采用的是静态导入的方式，例如 `import foo from './foo.js'`，可以在编译时分析出所依赖的模块，因此支持 Tree Shaking。\n\n因此，如果要使用 Tree Shaking，建议采用 ES6 模块化语法。如果必须使用 CommonJS 模块化规范，可以尝试使用动态导入`（import()）`语法，或者采用其他工具或手动实现 Tree Shaking。\n\n\n### side effect 是什么，为何会导致无法 tree shaking\n\n在编写 JavaScript 代码时，如果一个函数除了返回值外，还对外部的变量产生了其他的影响，比如修改了全局变量、读写了文件等操作，那么这个函数就被称为有“副作用”（side effect）。因为这种函数并不是纯函数，它可能会影响其他部分的代码执行结果，不便于优化和调试。\n\n在 Tree Shaking 的过程中，webpack 将模块打包成单独的 JavaScript 文件，它会从模块中找出哪些代码没有被使用到，并删除这些代码。但是，如果模块中存在带有副作用的代码，这些代码虽然没有被使用到，但它们仍然会被保留下来，因为这些代码可能会对其他部分的代码产生影响，因此不能简单地删除。这也是为什么带有副作用的代码会导致无法 Tree Shaking 的原因。\n\n",{"_58":453,"_181":152,"_182":152,"_183":152,"_184":152,"_185":152,"_186":152,"_187":152,"_188":152,"_189":152},"https://api.github.com/repos/pro-collection/interview-question/issues/235/reactions","https://api.github.com/repos/pro-collection/interview-question/issues/235/timeline",{"_58":456,"_60":61,"_62":457,"_64":458,"_66":459,"_68":460,"_70":461,"_72":462,"_74":463,"_76":464,"_78":465,"_111":466,"_131":132,"_133":24,"_134":-5,"_135":469,"_137":470,"_159":152,"_153":483,"_155":484,"_158":-5,"_162":163,"_106":-5,"_164":-5,"_165":485,"_170":486,"_176":487,"_178":488,"_190":490,"_192":-5,"_193":-5,"_194":195},"https://api.github.com/repos/pro-collection/interview-question/issues/232","https://api.github.com/repos/pro-collection/interview-question/issues/232/labels{/name}","https://api.github.com/repos/pro-collection/interview-question/issues/232/comments","https://api.github.com/repos/pro-collection/interview-question/issues/232/events","https://github.com/pro-collection/interview-question/issues/232",1646029883,"I_kwDOJGDC6c5iHGw7",232,"使用同一个链接，如何实现 PC 打开是 web 应用、手机打开是一个 H5 应用？",{"_80":81,"_70":82,"_72":83,"_84":85,"_86":28,"_58":87,"_68":88,"_89":90,"_91":92,"_93":94,"_95":96,"_97":98,"_99":100,"_101":102,"_66":103,"_104":105,"_106":107,"_108":109,"_110":24},[467,468],{"_70":240,"_72":241,"_58":242,"_117":243,"_119":244,"_121":24,"_122":245},{"_70":125,"_72":126,"_58":127,"_117":128,"_119":129,"_121":24,"_122":130},[],{"_58":471,"_68":472,"_62":473,"_70":474,"_72":475,"_74":476,"_76":477,"_122":478,"_147":479,"_149":480,"_151":152,"_131":132,"_153":481,"_155":482,"_157":-5,"_158":-5},"https://api.github.com/repos/pro-collection/interview-question/milestones/4","https://github.com/pro-collection/interview-question/milestone/4","https://api.github.com/repos/pro-collection/interview-question/milestones/4/labels",9124550,"MI_kwDOJGDC6c4AizrG",4,"资深","资深级别面试问题",{"_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","2023-03-29T15:15:05Z","2023-03-29T15:15:06Z",{"_167":152,"_168":152,"_169":152},{"_172":152,"_173":152,"_174":152,"_175":152},"可以通过根据请求来源（User-Agent）来判断访问设备的类型，然后在服务器端进行适配。例如，可以在服务器端使用 Node.js 的 Express 框架，在路由中对不同的 User-Agent 进行判断，返回不同的页面或数据。具体实现可以参考以下步骤：\n\n1. 根据 User-Agent 判断访问设备的类型，例如判断是否为移动设备。可以使用第三方库如 ua-parser-js 进行 User-Agent 的解析。\n\n2. 如果是移动设备，可以返回一个 H5 页面或接口数据。\n\n3. 如果是 PC 设备，可以返回一个 web 应用页面或接口数据。\n\n具体实现方式还取决于应用的具体场景和需求，以上只是一个大致的思路。",{"_58":489,"_181":152,"_182":152,"_183":152,"_184":152,"_185":152,"_186":152,"_187":152,"_188":152,"_189":152},"https://api.github.com/repos/pro-collection/interview-question/issues/232/reactions","https://api.github.com/repos/pro-collection/interview-question/issues/232/timeline",{"_58":492,"_60":61,"_62":493,"_64":494,"_66":495,"_68":496,"_70":497,"_72":498,"_74":499,"_76":500,"_78":501,"_111":502,"_131":132,"_133":24,"_134":-5,"_135":505,"_137":506,"_159":152,"_153":508,"_155":509,"_158":-5,"_162":163,"_106":-5,"_164":-5,"_165":510,"_170":511,"_176":512,"_178":513,"_190":515,"_192":-5,"_193":-5,"_194":195},"https://api.github.com/repos/pro-collection/interview-question/issues/227","https://api.github.com/repos/pro-collection/interview-question/issues/227/labels{/name}","https://api.github.com/repos/pro-collection/interview-question/issues/227/comments","https://api.github.com/repos/pro-collection/interview-question/issues/227/events","https://github.com/pro-collection/interview-question/issues/227",1646006770,"I_kwDOJGDC6c5iHBHy",227,"进程、线程、协程分别是什么概念？",{"_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},[503,504],{"_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":139,"_68":140,"_62":141,"_70":142,"_72":143,"_74":144,"_76":145,"_122":146,"_147":507,"_149":150,"_151":152,"_131":132,"_153":154,"_155":156,"_157":-5,"_158":-5},{"_80":81,"_70":82,"_72":83,"_84":85,"_86":28,"_58":87,"_68":88,"_89":90,"_91":92,"_93":94,"_95":96,"_97":98,"_99":100,"_101":102,"_66":103,"_104":105,"_106":107,"_108":109,"_110":24},"2023-03-29T15:03:05Z","2023-03-29T15:03:06Z",{"_167":152,"_168":152,"_169":152},{"_172":152,"_173":152,"_174":152,"_175":152},"### 进程（Process）和线程（Thread）\n进程（Process）和线程（Thread）是操作系统中的重要概念。\n\n**进程是指计算机中已经运行的程序，它是操作系统资源分配的最小单位**。进程拥有独立的内存空间和系统资源，如打开的文件、网络连接等。在操作系统中，每个进程都拥有一个唯一的标识符，称为进程ID。\n\n**线程是进程中的执行单元**，一个进程可以包含多个线程，它们共享进程的内存空间和系统资源。线程是CPU调度的最小单位，它可以看作是进程中的一个独立执行流程。与进程不同的是，线程没有自己的系统资源，只有一部分与进程共享的资源。在操作系统中，每个线程都拥有一个唯一的标识符，称为线程ID。\n\n可以将进程和线程的关系类比为一家工厂。工厂代表一个进程，工厂中的工人代表线程。每个工人负责自己的一部分工作，但是他们共享工厂的资源，如原材料、设备等。\n\n总的来说，进程和线程都是操作系统资源分配和调度的基本单位，它们之间的关系是多对一的，即多个线程可以属于同一个进程，共享进程的资源。\n\n### 协程（Coroutine）\n协程（Coroutine）是一种用户态的轻量级线程，也称为协作式多任务处理，与传统的抢占式多任务处理方式不同，协程的调度不由系统来控制，而是由程序员自己控制。在协程内部，程序可以自己决定在何处挂起、何时恢复执行。协程可以有效地避免多线程并发操作时出现的死锁、竞争、状态同步等问题，同时协程又可以充分利用 CPU 资源，提高程序执行效率。\n\n在协程中，所有任务共享一个线程，通过在任务之间切换来实现并发，这种方式可以避免线程切换时的性能损耗，也可以避免线程之间的同步问题。协程主要有以下特点：\n\n- 协程是一种轻量级的线程，其切换过程不需要操作系统介入，而是在用户态实现的。\n- 协程是一种非抢占式调度方式，需要程序员显式地让出执行权。\n- 协程可以共享全局变量等状态信息，但是需要程序员自己管理状态同步。\n\n协程在很多语言中都得到了广泛的应用，例如 Python 中的 asyncio、Lua 中的 coroutine 等。在前端领域中，JavaScript 的 Generator 函数就是一种协程实现方式。\n",{"_58":514,"_181":152,"_182":152,"_183":152,"_184":152,"_185":152,"_186":152,"_187":152,"_188":152,"_189":152},"https://api.github.com/repos/pro-collection/interview-question/issues/227/reactions","https://api.github.com/repos/pro-collection/interview-question/issues/227/timeline","pagination",{"_518":144,"_167":144},"value","actionData","errors"]