- 博客(151)
- 收藏
- 关注
RSS订阅原创 原型与原型链（Prototypes）深度解析：从基础到继承，一篇上手
前面继承的时候，我们用到了 Object.create(Person.prototype)，而 Object.create(null) 是面试常考的知识点，很多人分不清它和普通空对象 {} 的区别，今天就一次性给大家讲明白，大家记下来就好。这个核心优化点很简单：用 Object.create(Person.prototype) 代替 new Person()，只继承父类的方法，不执行父类构造函数，避免了父类构造执行两次，没有多余属性，又保留了组合继承的所有优点。搞懂了前面的基础，就可以上手实战继承了。
2026-03-18 08:00:00
438
原创 吃透JS异步编程：从Promise手写到底层协程，新手也能秒懂
/ 定义三种状态常量，避免魔法值，提升代码可读性// 定义MyPromise类// 构造函数，接收执行器函数（创建时立即执行）try {// 执行器接收resolve（成功回调）和reject（失败回调）// 执行器内部抛错，直接触发失败// 初始状态：等待态// 存储成功结果// 存储失败原因// 缓存成功回调（pending状态时，回调先存起来）// 缓存失败回调// 成功回调：修改状态，保存结果，执行缓存的成功回调。
2026-03-18 08:00:00
590
原创 别再死记硬背变量提升了，带你看看 V8 引擎在内存里玩的“拼图游戏”
写代码这么多年，不知道你有没有过这种经历：明明变量就在那儿定义着，控制台偏偏给你报个 ；或者在循环里写个异步回调，结果拿到的全是最后一个值。那时候咱们可能对着屏幕挠头，心想：“这不科学啊，逻辑明明是对的，JS 到底在搞什么鬼？”其实，这多半是因为咱们还没真正摸透 V8 引擎 的“脾气”。它看代码的视角和我们完全不同，它不是一行行读完就拉倒，更像是一个严谨的“舞台搭建师”。咱们先纠正一个直觉误区：代码并不是从上到下直接跑的。当 V8 准备执行一段代码时，Parser（解析器） 会先把代码转成 AST（抽象语法
2026-03-17 08:00:00
428
原创 闭包（Closures）深度应用：从原理到实战，一篇吃透
从事前端开发这些年，你是否也曾遇到过这样的困境：想封装核心变量防止外部误修改，却始终找不到稳妥方案；编写工具函数时，参数层层传递，代码冗余难维护；定时器、事件监听写多了，页面逐渐卡顿，打开浏览器开发者工具才发现，内存占用一路居高不下。但闭包到底是什么？绝不是背一句“有权访问另一个函数作用域变量的函数”就能真正理解；如何高效运用闭包？怎样规避闭包带来的坑？闭包引发的内存泄露根源在哪？模块化、单例模式、柯里化等高频实战场景，又该如何通过闭包落地？
2026-03-17 08:00:00
472
原创 23 | 别再给你的数据对象乱加“技能”了：请个专业外援——访问者模式
我之前接手过一个老项目，里面的“用户”对象简直是我见过的最臃肿的“巨无霸”。那个User类里塞了快 50 个方法：有算工资的、有生成 PDF 报表的、有校验社保状态的，甚至还有发邮件的。朋友跟我抱怨：每次业务想加个新功能（比如算年终奖），他都得去动这个核心的User类。改着改着，核心代码就变得像个垃圾桶，谁都能往里扔两行逻辑，最后谁也不敢轻易动它。我当时就跟同事复盘：我们不应该把“数据”和“对数据的操作”死死地焊在一起。
2026-03-16 14:55:36
370
原创 从原子化到工程化：Tailwind CSS 的深层价值与实践思考
其最新的 v4.0 版本更是凭借 Rust 引擎的革新，将性能与体验推向新高度，而2026年初 Tailwind 团队遭遇的生存危机，更让我意识到这款开源工具的现实困境——AI 编程工具的普及，让用户不再依赖官方文档，导致团队收入暴降80%，裁掉75%的工程团队，陷入“开源项目火爆但商业难以为继”的尴尬。正是这些免费的开源工具，支撑着前端生态的发展，我们在使用的同时，也可以多关注它们的生存现状——毕竟，一款优秀的开源工具，需要我们共同守护。其实所有争议，本质上都是“效率”和“自由”的选择。
2026-03-16 14:54:32
811
原创 21 | 别再写那堆恶心的 if-else 了：给你的代码装个“插件盒”——策略模式
我之前接手过一个电商项目的促销模块，那段代码现在想起来还觉得头大。当时的需求是：根据用户等级算折扣。普通用户不打折，VIP 打 9 折，超级 VIP 打 8 折。我当时写得特别顺手，直接一个if-else搞定。结果后来业务又加了“节日促销”、“新人专享”、“满减活动”……那个算价函数直接膨胀到了两百行，里面全是嵌套的判断。只要改一个规则，另外五个规则都得跟着测一遍，生怕算错一分钱。我当时就跟同事复盘：我们不应该把所有的“算价逻辑”都塞进一个脑袋里。
2026-03-15 08:00:00
214
原创 22 | 别再复制粘贴那 80% 的代码了：给你的流程装个“标准模具”——模板方法模式
我之前给一个做跨境电商的朋友帮忙，处理过一段让人特别心累的代码。当时系统里有各种各样的“数据导出”功能：导出订单、导出库存、导出用户。我发现代码里全是重复的影子：先查数据库，再格式化数据，最后生成文件。虽然导出的格式不同（有的要 CSV，有的要 Excel），但头尾那 80% 的逻辑几乎一模一样。每次改个数据库连接池的配置，我得把这三个导出函数全翻出来改一遍，漏掉一个就是事故。我当时就跟同事复盘：我们不应该在每个函数里都去重复那套“固定动作”。
2026-03-15 08:00:00
196
原创 19 | 别再写“夺命连环调”了：让你的代码学会“广播”——观察者模式
我之前写过一个电商项目的购物车模块，那段代码现在想起来简直是我的“黑历史”。当时的需求是：用户点一下“加入购物车”，页面顶部的图标要闪一下，右侧的侧边栏要刷新列表，底部的推荐位还得更新数据。我当时的做法特别直接：在“加入购物车”的函数里，挨个去调这些组件的方法。结果后来业务又加了个需求，说点完之后还要弹个优惠券提醒。我只能又苦哈哈地钻进那个函数里，再塞一行代码。最后那个函数变得像个“夺命连环调”，动一下全身都疼。我当时就跟同事复盘：我们不应该让“购物车”去操心别人要干啥。
2026-03-13 08:00:00
337
原创 20 | 别再写满屏的 switch 了：让你的对象自己“变身”——状态模式
我之前参与过一个文件下载器的开发，那个下载按钮的逻辑简直是我职业生涯的“噩梦”。当时按钮有好几种状态：未开始、下载中、暂停、出错、已完成。老板提了个需求：在“下载中”点按钮是暂停，在“暂停”点是继续，在“出错”点是重试。我当时的代码写得特别直接，一个switch里面套了无数个if-else。结果后来又加了个“等待中”和“校验中”的状态，那个switch直接膨胀到了几百行，改一个地方，另外四个状态全乱了。我当时就跟同事复盘：我们不应该把按钮当成一个“判断机器”。
2026-03-13 08:00:00
182
原创 17 | 别让你的组件“私下建群”：请个指挥官来搞定乱麻——中介者模式
我之前参与过一个智能家居 App 的开发，那个控制面板的逻辑简直是我职业生涯的“至暗时刻”。当时面板上有好几个组件：灯光开关、空调调温、窗帘拉伸。老板提了个需求：当用户开启“影院模式”时，灯光要调暗，窗帘要拉上，空调要调到 24 度。我当时的代码写得特别直接：在灯光组件里去调窗帘的方法，在窗帘组件里去调空调的方法。结果后来又加了个“睡眠模式”，逻辑全乱了，组件之间互相调用，像一团解不开的乱麻。我当时就跟同事复盘：我们不应该让这些家具“互相打招呼”。
2026-03-12 08:00:00
450
原创 18 | 给你的代码装个“后悔药”：一键回到过去——备忘录模式
我之前在做一个复杂的个人资料编辑器，那个需求现在想起来还觉得挺“坑”的。当时表单里有几十个字段，头像、简介、各种标签，用户改着改着突然觉得“还是刚才那个版本好”，想一键撤销。我以前的处理方式特别笨：定义一堆临时变量，oldNameoldBiooldTags……结果代码里全是这种搬运工逻辑，只要表单加个字段，我就得去手动同步那堆临时变量，漏掉一个就是 Bug。我当时就跟同事复盘：我们不应该去手动盯着每个字段。我们要给这个对象装个“快照相机”，想存的时候咔嚓一下，想回的时候直接把照片贴回去。
2026-03-12 08:00:00
788
原创 15 | 别再用 eval 乱搞了：给你的业务逻辑配个“翻译官”——解释器模式
我之前给一个做低代码平台的团队做技术顾问，当时他们正为一个需求吵得不可开交。业务方希望能在后台配置一些简单的“逻辑规则”，比如：“如果（用户是VIP 并且 余额大于1000）或者 他是新注册用户，就给他发个红包”。开发同学的第一反应是：这不就是把一段 JS 代码存进数据库吗？用eval()跑一下不就得了？我当时赶紧拦住了：这哪是写代码啊，这是在给自己挖坑。先不说安全风险，万一业务人员写错一个括号，整个页面可能就直接白屏了。我当时跟他们聊：我们其实是在处理一种“小众语言”。
2026-03-11 08:00:00
322
原创 16 | 别再数着 i++ 走路了：给你的数据装个“自动导航”——迭代器模式
我之前重构过一个复杂的菜单系统，那个需求现在想起来还觉得头大。当时数据结构特别乱，有的是普通的数组，有的是嵌套了好几层的树形对象，还有的是从 Map 里取出来的。我写业务逻辑的时候，满屏都是各种各样的循环：一会儿是，一会儿是，还得不停地判断数据到底是什么格式。我当时就跟同事复盘：我们不应该让业务逻辑去操心数据是怎么存的。不管它是数组、链表还是树，我们只需要一个“自动导航仪”，让它一个接一个地把数据吐出来就行。
2026-03-11 08:00:00
419
原创 13 | 别再写嵌套 10 层的 if 了：像接力赛一样处理逻辑——责任链模式
我之前参与过一个电商系统的支付流程重构，当时接手了一段让人头皮发麻的代码。那是一个处理“下单”的函数，里面嵌套了十几层if-else先判断用户登录没，再判断收货地址对不对，接着查库存，然后算优惠券，最后还要看风控系统给不给过。只要其中一个环节要改逻辑，或者想在中间插一个“满减活动”的检查，你就得在那堆乱麻里翻半天，生怕动了哪行导致整个支付崩掉。我当时就跟同事聊：你这哪是在写程序，你这是在玩“叠叠乐”啊，动一下底层，上面全塌了。
2026-03-10 08:00:00
289
原创 14 | 别让你的按钮“管得太宽”：给操作装个“后悔药”——命令模式
我之前带队做一个在线文档编辑器，有个功能特别折磨人：撤销（Undo）和重做（Redo）。当时有个小伙伴写得特别痛苦，他在每个按钮的点击事件里直接写逻辑。比如点击“加粗”，他就直接改样式；点击“删除”，他就直接删数据。结果要做“撤销”的时候，他发现根本无从下手，因为他完全记不住刚才到底发生了什么，更别提倒退回去了。我当时跟他聊：你这是把“发号施令的人”和“干活的人”死死地焊在一起了。就像你进餐厅点菜，如果直接冲进厨房跟厨师说“给我炒个蛋”，厨师炒完了，你连个订单记录都没有，想退菜都找不到凭证。
2026-03-10 08:00:00
186
原创 11 | 内存告急？别再疯狂 new 对象了：用“共享单车”思维拯救你的浏览器——享元模式
我之前参与过一个大型的文件管理系统项目，有个功能是展示成千上万个文件的列表。当时有个小伙伴为了省事，给每个文件都创建了一个完整的 JS 对象，里面包含文件名、大小、后缀名，还有一套“重命名、删除、下载”的方法。结果测试的时候，列表一拉长，浏览器内存直接飙到了 2G，页面卡得像幻灯片。我当时跟他打了个比方：你这就像是给每个骑共享单车的人都配了一辆专属自行车，还得专门盖个车棚。其实大家需要的只是“骑车”这个功能，车子本身是可以共享的，只要骑的时候把自己的“目的地”带上就行。
2026-03-09 08:00:00
464
原创 12 | 别让你的核心代码去当“保安”：给对象请个专业秘书——代理模式
我前段时间帮一个朋友排查 Bug，发现他的业务代码里塞满了各种“杂活儿”。比如一个负责“修改用户信息”的函数，里面居然还写了权限校验、操作日志，甚至还有一段防止重复提交的逻辑。那个函数原本只有 5 行核心代码，结果被这些杂事儿撑到了 50 行。朋友跟我抱怨：每次想改点核心逻辑，都得在一堆“保安代码”里翻半天，生怕改错一个括号。我当时就跟他聊：你这是让“老板”亲自去大门口站岗啊。真正优雅的做法是给老板请个“秘书”或者“保镖”，让老板只管签文件，杂事儿全交给外面的人挡回去。
2026-03-09 08:00:00
299
原创 09 | 给代码穿上“钢铁侠战衣”：不改一行源码，让功能原地起飞——装饰器模式
最近在帮一个朋友做老项目重构，他遇到了一个特别经典的头疼事。老板要求给项目里所有的敏感操作（比如删除、导出、修改权限）都加上“操作日志”和“权限校验”。朋友看着代码里几十个散落在各处的函数，整个人都麻了：“难道我要一个一个去改这些函数的源码，把 console.log 和 if (token) 塞进去吗？我以前也干过这种傻事，最后代码改得像个“缝合怪”，核心业务逻辑被一堆杂活儿包围。
2026-03-06 10:00:00
309
原创 10 | 别让你的业务逻辑变成“套娃”：给复杂系统装个“一键启动”——外观模式
我之前带过一个项目，有个新来的小伙伴负责写“用户下单”的逻辑。过了两天我去 Review 代码，好家伙，他在前端页面组件里直接写了快两百行逻辑：先调接口查库存，再调接口算折扣，接着调支付接口，最后还得调个埋点统计。那个组件变得极其臃肿，只要后端接口稍微动一下字段，前端这个页面就得大改。我当时就跟他聊：你这哪是在写页面，你这是在写“说明书”啊。你让一个只想点“下单”按钮的页面，去操心后台那一堆乱七八糟的工序，这不就是典型的“知道得太多了”吗？
2026-03-06 10:00:00
346
原创 07 | 别让你的类像细菌一样繁殖——桥接模式
这是设计模式里最容易被名字耽误，但实际上最能救命的一个。很多朋友一听到“桥接”，脑子里就开始画图：左边一个岸，右边一个岸，中间一座桥。越想越晕，完全不知道这跟写代码有啥关系。。想象一下，你正在维护一个消息推送系统。一开始只有“短信”和“邮件”两种方式。后来需求变了，消息分成了“普通”和“加急”。再后来，又加了“微信推送”和“特急”……如果你习惯用继承来解决问题，你的代码很快就会变成一场噩梦。
2026-03-05 10:00:00
641
原创 08 | 为什么点一份套餐，比单点三个菜还要麻烦？——组合模式
如果你的数据结构只有一层（比如只是一个简单的列表），千万别硬套组合模式，那只会把简单的循环变成复杂的对象嵌套。因为你的逻辑只支持两层嵌套（单品和套餐），不支持“套餐套套餐”。：哪怕你套了一万层，代码逻辑也是一样的。：一旦嵌套层级变深（套餐套套餐），代码逻辑就会变得极其复杂，甚至写出死循环。我只需要把指令传给最顶层的那个对象，剩下的事，让它们自己去层层传递就好。如果是套餐，还得自己写递归去遍历。我以前写递归的时候，总觉得脑容量不够用，生怕栈溢出。用了组合模式之后，我发现其实不需要我去“管理”递归。
2026-03-05 10:00:00
339
原创 05 | 既然能 Ctrl+C，为什么要从头再敲一遍？——原型模式
这是设计模式里最“接地气”，但也是前端开发者最容易忽略的一个。之所以说它容易被忽略，是因为 JavaScript 这门语言本身就是基于原型的（Prototype-based）。我们每天都在用的或者继承，其实骨子里流的都是这个模式的血。但我发现，很多朋友虽然嘴上说着“JS 万物皆对象”，真到了写业务逻辑的时候，还是习惯老老实实地去new一个新对象。如果你的对象创建成本很低，那没问题。
2026-03-04 10:00:00
610
原创 06 | 接口对不上，难道非要重写代码吗？——适配器模式
咱们做开发的，估计最怕听到的一句话就是：“后端接口改了，字段格式变了，你前端配合改一下。或者：“老板要把地图服务从谷歌换成百度，但这两家的 API 长得完全不一样。遇到这种情况，我以前的第一反应是：叹口气，打开全局搜索，把代码里所有相关的调用逻辑全部翻出来，一个一个手动修改。改到最后，不仅眼睛花了，还经常因为漏改了一个地方，导致线上报错。那时候我就在想，为什么我总是被外部的变化牵着鼻子走？后来我才明白，这就是存在的意义。
2026-03-04 10:00:00
421
原创 03 | 为什么你的界面总是像个“缝合怪”？——抽象工厂模式
先聊聊那个让我掉坑里的项目。当时我们要给 App 做一套“夜间模式”和一套“春节红模式”。Button（按钮）和NavBar（导航栏）。我一开始的做法特别简单粗暴：在渲染按钮的时候，判断一下当前是啥主题；在渲染导航栏的时候，再判断一下。结果上线后出了个大乌龙：因为逻辑分散在各个角落，有个页面的配置没读对，导致用户看到的是“夜间模式”的黑底导航栏，配上了“春节模式”的大红按钮。那画面，简直就是个“缝合怪”，丑得我都不敢看。
2026-03-03 10:00:00
680
原创 04 | 别再写几十个参数的构造函数了——建造者模式
不知道你有没有接手过那种“祖传代码”，里面有一个极其庞大的类，初始化的时候需要传十几个参数。一旦中间少传了一个null，或者把第 5 个参数和第 6 个参数搞反了，整个程序直接报错，查都查不出来。我以前写这种代码的时候，自己都觉得心虚，生怕哪天把自己给坑了。今天咱们聊的这个，就是专门为了解决这种“参数地狱”而生的。
2026-03-03 10:00:00
633
原创 01 | 明明是全家共用的“公章”，你为什么要刻好几个？——单例模式
最近在帮几个朋友看代码，发现大家在处理“全局状态”或者“公共组件”时，经常会遇到一个挺让人头疼的问题。比如你写了一个管理用户登录信息的模块，或者一个全局的配置中心。结果因为代码逻辑在不同的地方被反复实例化，导致 A 页面改了配置，B 页面拿到的还是旧的。这种“数据对不上”的情况，排查起来特别费劲，最后发现其实是内存里跑着好几个长得一模一样的对象。我以前也经常在这上面栽跟头，总觉得多new一个对象没什么大不了。但后来才意识到，很多时候我们需要的不是“一堆长得像的东西”，而是“唯一的那一个”。
2026-03-02 10:00:00
790
原创 02 | 为什么加个新功能，要把旧代码改个底朝天？——工厂方法模式
记得刚入行那会儿，我特别怕碰到一种需求：“小王啊，咱们的消息推送，除了发短信，能不能再加个邮件推送？过两天可能还得加个微信通知。我当时的做法特别直接，在业务代码里写了一堆if-else。只要类型是 SMS，我就；是 Email，我就。结果后来渠道越来越多，那个主函数的代码长得像老太婆的裹脚布。更要命的是，每次加新渠道，我都得颤颤巍巍地去改那段核心逻辑，生怕手一抖，把原来的短信功能给搞挂了。
2026-03-02 10:00:00
512
原创 React 第四十章 completeWork 工作流程
前面所介绍的，是属于“递”的阶段，该阶段的工作处理完成后，就会进入到 completeWork，这个是属于“归”的阶段。
2024-05-17 09:09:13
1192
1
原创 React 第三十九章 beginWork工作流程
beginWork 方法主要是根据传入的 FiberNode 创建下一级的 FiberNode。整个 beginWork 方法的流程如下图所示：首先在 beginWork 中，会判断当前的流程是 mount（初次渲染）还是update（更新），判断的依据就是 currentFiberNode 是否存在无法复用的 update 流程和 mount 流程大体一致，主要区别在于是否会生成带副作用标记 flags 的 FiberNode不同的 FiberNode，会有不同的 tag。
2024-05-17 08:38:53
1189
原创 React 第三十八章 React 中的位运算
位运算是一种计算机编程中常用的操作，它直接对二进制位进行操作。二进制，指的就是以二为底的一种计数方式，常见的还有八进制、十进制、十六进制。我们经常会使用二进制来进行计算，基于二进制的位运算能够很方便的表达“增、删、查、改”。再例如，在 linux 操作系统里面，x 代表可执行权限，w代表可写权限，r 代表可读权限，对应的权限值分别就是1、2、4（2 的幂次方）使用二进制来表示权限，首先速度上面会更快一些，其次在表示多种权限的时候，会更加方便一些。比如，现在有 3 个权限 A、B、C…
2024-05-16 11:04:40
1123
原创 React 第三十七章 Scheduler 最小堆算法
在 Scheduler 中，使用最小堆的数据结构在对任务进行排序。我们在学习 Scheduler 中最小堆算法之前，需要先了解什么是 二叉堆。
2024-05-16 11:04:28
1348
原创 React 第三十六章 Scheduler 任务调度
用于在 React 应用中进行任务调度。它可以帮助开发人员在处理复杂的任务和操作时更好地管理和优化性能。关于 Scheduler 在React 如何渲染的可以参考下面我们根据流程图先简单的了解 Scheduler 的调度过程Scheduler 维护两个队列，分别存放普通任务和延时任务当接收的是普通任务时，会加入普通任务队列，然后执行。根据环境创建宏任务（主要创建的就是），然后执行。该方法实际上主要就是在调用。
2024-05-15 09:50:56
1550
原创 浏览器API Performance
将浏览器的资源 timing 缓冲区的大小设置为 “resource” type performance entry 对象的指定数量。从浏览器的性能数据缓冲区中移除所有 entryType 是 “resource” 的 performance entries。在浏览器的指定 start mark 和 end mark 间的性能输入缓冲区中创建一个指定的 timestamp。基于给定的 name 和 entry type 返回一个 PerformanceEntry 对象的列表。性能条目特定于执行上下文。
2024-05-15 09:50:21
998
原创 DOMHighResTimeStamp double 类型的时间计量类
类型在 JavaScript 中并没有明确的类型声明（因为它是作为 Number 类型传递的），但你可以将其视为一个表示高精度时间戳的数值。在大多数浏览器中，这个时间戳的精度可以达到微秒级，但具体的精度可能因浏览器和硬件而异。是从某个不确定的过去时间点（通常是页面加载或页面导航开始的时间）到当前的时间的差值，以毫秒为单位，并且具有微秒级的精度。类型的时间计量类，它用于存储毫秒级的时间值，并且精确到5微秒（0.005 ms）。方法时，需要传入一个回调函数作为参数，这个回调函数会在浏览器下一次重绘之前执行。
2024-05-14 10:00:47
1307
原创 JavaScript API MessageChannel 多线程异步通信
提供了一种可靠、高效的异步(宏任务)通信方式，可以用于多个线程之间的数据传输和协作，特别适用于复杂的交互和并行处理场景。使用 MessageChannel 可以方便地实现一些功能，例如主线程和 Web Worker 之间的任务分发、主线程和 Service Worker 之间的数据同步等。它允许创建一个双向的通信通道，用于发送和接收消息。，开发者可以创建一个通信端口，通过端口发送消息，并监听来自另一个端口的消息。用来监听，当消息到达时，会进行处理。之间建立通信，也可以在主线程和。
2024-05-14 10:00:27
1530
原创 浏览器 API requestIdleCallback
根据研究报告表明，用户操作之后，100ms以内的响应给用户的感觉都是瞬间发生，也就是说不会感受到延迟感，因此将空闲时间设置为 50，浏览器依然还剩下 50ms 可以处理用户的操作响应，不会让用户感到延迟。
2024-05-13 16:54:30
1797
原创 React 第三十五章 Fiber 双缓冲
Wip Fiber Tree 在内存中完成更新，而 Current Fiber Tree 是最终要渲染的树，两颗树通过 alternate 指针相互指向，这样在下一次渲染的时候，直接复用 Wip Fiber Tree 作为下一次的渲染树，而上一次的渲染树又作为新的 Wip Fiber Tree，这样可以加快 DOM 节点的替换与更新。显卡分为前缓冲区和后缓冲区。点击 p 元素，会触发更新，这一操作就会开启 update 流程，此时就会生成一颗新的 wip Fiber Tree，流程和之前是一样的。
2024-05-13 16:54:22
1102
原创 React 第三十四章 React 渲染流程
注意上面 render 阶段的工作是在内存里面进行的，不会更新宿主环境 UI，因此这个阶段即使工作流程反复被中断，用户也不会看到“更新不完整的UI”。当 Scheduler 调度完成后，将任务交给 Reconciler，Reconciler 就需要计算出新的 UI，最后就由 Renderer进行渲染更新操作。
2024-05-12 09:12:37
1931
原创 React 第三十三章 React架构
标准且浅显的回答Stack 架构在进行虚拟 DOM 树比较的时候，采用的是递归，计算会消耗大量的时间，新的 Fiber 架构采用的是链表，可以实现时间切片，防止 JS 的计算占用过多的时间从而导致浏览器出现丢帧的现象。从 React v16 开始，React 重构了整体的架构，新的架构被称之为 Fiber 架构，之前的架构称之为 Stack 架构。新的架构相比旧架构有一个最大的特点就是能够实现时间切片。新架构的出现必定是为了解决旧架构存在的问题，下面我们来讨论旧架构的问题。
2024-05-12 09:12:00
1407
空空如也
空空如也
TA创建的收藏夹 TA关注的收藏夹
TA关注的人