该渲染由 Shiro API 生成，可能存在排版问题，最佳体验请前往：https://linmoe.cn/posts/essay/years_summarize

1. 何为校招

​ 对大厂而言，招聘通常分为校招和社招两条路径。二者最大的差异在于目标群体不同：校招面向应届生，社招面向已有经验的社会人才。因此，考察重点自然也不同。

​ 社招更强调技术能力，因为社招岗位往往是项目紧急、团队缺人，需要找能“即插即用”的人；而校招生普遍缺乏实战经验，面试官默认是一张白纸，因此校招更侧重考察“潜力”。

​ 那么，潜力从哪体现？最重要的筛选工具，就是学历。

​ 在我国，高考是最公平、最规范、官方背书的选拔机制，它在某种意义上代表了一个人在长期学习体系中的执行力、学习能力和稳定性。企业用学历筛选，本质上是为了降低招聘成本——技术可以培养，但学历无法后补。

2. 影响校招的主要因素

​ 从技术岗来讲，无非运气，学历，实习，项目。运气就不谈了，学历整体上可以分为 92 与 双非，不乏有公司/部门会卡双一流（就互联网而言）。如果给这四个因素排序，我的答案是：运气 > 学历 >> 实习 > 项目

​ 有人可能会说，大厂实习的含金量不应该大于学历吗？或许在实习阶段你能拿到很多的offer，但实习和校招是完全不同的，实习做的内容大概都是杂活，一个实习生能待的时间也就是6个月左右，但校招生不同，对于面试官而言，一面面试官是你的同事，他招的是未来一起工作的战友；对你的二面面试官而言，他招的是未来能冲锋陷阵的士兵。或许学历不能代表一切，但至少能代表在高中三年期间你完美的执行了学校老师布置的任务，并在高考中交出一份完美的答卷。所以，大厂实习只能一定程度上去弥补你和 92 之间的差距。更多时候，你的竞争对手是双非。

​ 我见过二本一段大厂拿下阿里淘天（卡学历），美团和腾讯的，也见过双非三段大厂秋招颗粒无收的，更见过九本一段小厂秋招打牌的。但这并非代表你所做的努力是没有意义的，我相信世界上没有白走的路。

3. 校招的变化趋势

​ 就前后端而言，市场变化是很快的，但总体趋势是下降，去年25届前端校招还是可以的，只是一年的时间，26届前端就开始全面崩盘。以今年来看，我总结了几个明显的变化：

3.1 AI的快速发展

​ 25年可以说是 AI 爆发最快的一年，也可以说是 Agent 元年，各种新理念新技术层出不穷，前几年虽然一直在喊前端已死，但只有今年让我切切实实的嗅到了危机感。AI的发展是否会使前端消失？答案是不可能的，十几年前的PHP至今都依然有人在写，不过前端的需求必然是会减少的，中小厂的前端 HC 会进一步减少，甚至小厂会取消前端这个岗位，大厂的前端需求短时间可能会增长停滞，但影响不会太大。不过我觉得大厂业务停滞增长，本身也是一种退后了。

3.2 大厂实习贬值

​ 好像是从24届还是25届开始，我明显感觉市面上的大厂实习岗位开始增多，尤其是字节和美团，日常实习基本上一年四季在招，从今年周围朋友情况来看，2-3段大厂实习的不再少数，所谓物以稀为贵，当人人都有大厂实习的情况下，大厂实习就会贬值没有含金量，我也问过几个27届的学弟，几乎都在大二下就有两段实习，可见卷实习的浪潮只会愈演愈烈，而公司也乐于看到这种结果，一方面实习生的待遇相较于正式来说不算什么，甚至比外包还低，一方面应届生的质量在不断的提高，公司可以得到更优质的应届生资源，对公司来说百利无一害可以说。

3.3 高学历市场下沉

​ 说到双九（本硕都是985），大家的第一想法肯定是科研，算法。但就今年情况来看，很多双九硕都选择来前端，这其实是一种市场下沉的现象，从最开始的双九硕做算法，到双九硕做后端，最后甚至来做前端，我觉得这是一个很恐怖的现象，进一步证实互联网市场正在饱和。

​ 说到高学历就不得不提一个特别著名的学历厂——比亚迪。在22年以前单2（本科211以上）点击就送，到24年双2（本硕211以上）点击就送，到今年双九（本硕985）点击就送。

​ 这就是当下互联网的真实环境：池子变小了，加入的水却越来越多。

4. 规划与选择

时代的一粒沙，落在普通人身上，就是一座山。 既然无法改变环境，就只能改变自己。 变则生，不变则亡。

​ 互联网的变化速度是传统行业不能比的，在校招中规划和选择变的越来越重要，放在十年前也许你玩三年，最后拼一年就能进入一家不错的公司，但放在今天不行了，如果你的目标是进入一家中大型企业，那么你必须趁早规划并做出努力。

4.1 信息差

​ 计算机永远不是闭门造车。除了增强自己的技术，你还需要收集一些新的“信息”，如果你的学校是 985211 或者就业很强的学校，你的学长前辈们可能已经帮你们走出一条路，但如果你的学校不是很好，没有前人的路可以走，那就只能摸着石头过河，自己走出一条路，而 “信息差” 就是走出这条路的关键。

​ 比如我想从事前后端开发，我需要学习哪些技术栈？如果我想要进入大厂实习，我该怎么写简历？我该在哪投简历？什么时候投？这些都是有技巧的，这也是计算机的一部分。

​ 作为一名刚刚入校的新生我该如何打破信息差？先把眼光放在校内，是否有出名的工作室，工作室里是否有还在大厂的学长，如果没有则把注意力放在校外，我推荐使用牛客，计算机校招生的聚集地，很多人会在牛客交流经验，并且你也可以去加入一些交流群，当然这些信息很驳杂，需要自己有过滤和判断能力。

4.2 执行与驱动力

​ 计算机是一门永远进步的学科。你需要保持永远的学习力，对大部分计算机从业者来说，技术才是核心竞争力，你需要时刻了解行业正在发生的变化，并学习新的技术。

​ 比如我想在大二暑假找到实习，那么我必须在这一个月内去学完相应的技术栈，并做出一个完整的项目，这个计划必须在规定时间内完整的执行下去。

4.3 选择大于努力

​ 有时候错误的选择往往会导致努力白费。如果你在25届学前端，那么恭喜你遇到了前端最好的一年；如果你在26年学前端，那么很遗憾你的对手不是985就是多段大厂实习的双非，但如果今年你学习的是测开/客户端这种市场缺口很大的岗位，那么你上岸的几率将大大提升。

​ 在我的周围就有这样的例子，朋友A双非大二开始学客户端，大三下暑假进入腾讯实习，并成功转正；朋友B双非原本是学后端的，暑假收到一家中厂的后端 offer 和腾讯的客户端 offer，最后选择去腾讯客户端，同样他成功转正。

​ 作为反面教材那就是我和周围认识的十一个腾讯前端，一共十二个人只有两个转正成功。

5. 就业与考研

​ 对本科生来说，毕业后的道路无非两条：直接就业或继续升学。

​ 升学当然是一种选择，但绝不能盲目。我始终认为，做任何决定前，都必须想清楚——你会承担什么代价？你能获得什么收益？

5.1 什么样的人适合升学

​ 只有带着明确目的的人，才适合走升学这条路。

​ 就以我个人为例，很多人不理解——明明本科阶段就能拿到大厂 offer，为什么还要读研？ 这个问题我也反复问过自己。

​ 抛开浮躁和短期收益不谈，计算机行业本质是“青春饭”，是一个永远不缺年轻人的赛道。当我意识到自己学历不占优势时，也开始思考，当职业生涯走到瓶颈，我还能靠什么翻盘？我又能凭什么在 35 岁后依然拥有选择权？

​ 如果我去读研，我必然会失去三年的工作经验，以及近百万的收入，更要承受三年后市场可能继续收缩的风险。 但升学带来的收益同样清晰：学历提升、专业转向（例如前端转后端）、甚至跳向门槛更高的国企或体制内。

​ 所以适不适合升学，不在于你“能不能考上”，而在于你“为什么要考上”。

5.2 尽量不要并行

​ 人的精力毕竟有限，试图“就业 + 考研”双线推进的人，往往两头都顾不住。尤其是对于大多数身处双非、资源有限的学生来说，不是没有天赋，而是时间与精力根本不允许你无限分散。如果你决定两手抓，那你必须先问自己两个问题：

1. 你能否放弃几乎所有娱乐与社交？
2. 你是否能在长达半年以上的时间里，每一天都严格执行计划，不拖延、不松懈？

​ 不论是校招还是考研，都是极其消耗意志的过程。尤其是从九月到十二月——校招的高峰期、考研的冲刺期、心理的崩溃期。这是最接近黎明的黑暗，也是最容易被击垮的阶段。

​ 如果你无法保证“双线高压”下的执行力，那么最理智的做法就是——专注做一件事，并把它做到极致。

6. 尾声：写在最后

​ 四年前我从高中走进大学的校门，曾几何时觉得自己前途一片渺茫，和周围许多朋友相比我算不上天才，但相较于他们我的优点在于对未来必胜的决心，以及敢于一条路走到底的勇气。

​ 从携程到腾讯，感恩路途中帮助过我的所有人。四年一路走来最大的收获不是拿到过的offer，而是路途中遇到的人与事物，有人令我成长，有人为我指明方向，我想未来不论是成功还是失败，我都已经做好准备去迎接了。

​ 直面自己的失败，并战胜它——大学四年留给我的最后一课

看完了？说点什么呢

​ 若你现在处于低谷中，希望听完我的故事你能振作起来。

​ 小时候我生活在华中地区的一个地级市。由于父母工作的原因，大约六年级时我被接去了省会，那是我第一次离开生活了十多年的故乡。

​ 来到繁华的大城市，因为没有朋友，小学最后一年过得并不如意。小升初时被分配到区里一所较差的初中。初中一个年级只有四个班，我幸运地在分班考试中进入了快班。第一次期末考试我考了年级第23名。

​ 后来在初一下时，我遇到了生命中第一位恩师——她是我数学的启蒙老师。也是在她的教导下，我的数学从短板一跃成为了长处。初二时我常年稳居年级前五。

​ 可到了初三，因为恩师出国留学，我在最后一年没能坚守初心，成绩一落千丈，最终在中考中迎来人生第一次大败。

​ 有人说，从那时起，我的命运被改变了。本能考进省重点的我，最后只进入了一所市重点。

​ 进入高中后，高一的成绩不温不火。高一下学期，疫情全面爆发，我们被迫上网课。那段时间我患上了中度抑郁症，成绩也一落千丈。高中三年，是我最不愿回忆的时光。

​ 如果非要说一段快乐的记忆，那应该是我第一次接触计算机的那段时间吧。高三时我拼了一把，最终考上了一所普通二本。或许，一切都是最好的安排。

​ 八月份，爷爷查出癌症晚期，而我也错过了与他见最后一面的机会，这是我一生的遗憾。

​ 记得小时候在老家，虽然家里清贫，但无论我想要什么，爷爷都会尽力满足。虽然父母常年不在身边，但只要有爷爷奶奶在，我从未觉得自己比别人缺少什么。

​ 对爷爷来说，能看到我考上大学，也许了却了他的一桩心愿。那一晚，跪在爷爷遗体前，我发誓：我一定要尽我所能，去拼一个未来。

​ 进入大学后，我开始规划自己的四年生涯。学校里的学长大多从事后端方向，即使有少数选择前端，也并未走出理想的道路。或许是因为高中时接触过前端，我在职业发展上毫不犹豫地选择了这一方向。

​ 大一下学期，凭借自己的努力，我在一家小型公司获得了实习机会。那时技术水平还十分稚嫩，但热情却是最为炽烈的。

​ 大二上学期的寒假，我没有选择回老家过年，而是留在家中专心写项目。记得那一年雪下得格外大，也是在那个冬天，我完成了人生中第一个开源项目——如今已收获500余个 stars。本打算今年重构，却始终抽不出时间。

​ 大二上的寒假我没有选择回老家过年，而是选择留在家中写项目，还记得那一年的雪下的格外大，也是在那个冬天我完成了自己的第一个开源项目，目前已经达到500stars，本来想在今年重构来着，却一直找不出时间。

​ 大二时，我机缘巧合地参加了新华三杯，并独自带队进入全国总决赛。第一次来到杭州，我不禁思考：未来的自己，是否也能进入像新华三这样的大厂？虽然最终未能获奖，但那次经历让我大开眼界。

​ 国赛结束后不久，我开始投递简历，着手准备大二下学期的暑期实习。由于学校并不出众，从五月初到中旬，只有蔚来一家给了面试机会。那是我第一次面试大厂，发挥欠佳。

​ 或许真的是命运使然在牛客上我看到那个招聘实习的帖子，正是后来我在携程实习时的 leader 发布的，他没有嫌弃我的学历，认真的看完我的简历后帮我约了面试。那个晚上躺在床上我辗转反侧，我不得不考虑这是否是我此生最后的机会。

​ 幸运的是，这次命运眷顾了我，我成功拿到携程的实习offer。

​ 初入上海，那是我第一次真正感受到一线城市的繁华。对于极少外出旅游的我而言，那份震撼至今难忘。

​ 在携程的四个月里，我学到了许多，也更加坚定了留在互联网行业的信念。或许我们无法预知前路的结果，但持续的坚持，是唯一能做的事。

​九月份回到学校后，我开始筹备第二次实习。得益于携程的实习经历作为背书，到了十一月份，面试机会逐渐增多。可惜在第一次字节跳动的面试中，算法准备仍显不足，最终止步于二面。现在回想，那大概是我离字节最近的一次了吧。此后，我在三天内顺利通过了哔哩哔哩的面试，本以为短时间内不会再回到上海，没想到十二月又踏上了那片熟悉的土地。

相比于携程的实习经历，第二段实习给我留下的最深印象并非工作内容，而是实习中遇到的人。没错，正是在那段时间，我遇见了那个让我至今难以忘怀的女孩。不知她如今的工作是否顺利，我们也已经很久没有再见面了呢。

​ 三月份实习结束后我再次返回学校，这个时间我面临一个重大的抉择——继续准备暑期转正还是梭哈考研？这无疑是一个很艰难的抉择，而也在这个月我的奶奶离开了，一时间无力感充斥着我，一如当年爷爷走的时候我没有办法做任何事，但我知道我必须振作起来。

​ 最终我选择了双向推进，在四月份我迎来大爆发，一连斩获五个大厂offer，最终选择去腾讯，对于一直想去深圳的我来说也算是圆梦吧。

​ 也是在腾讯，我遇到了对于我职业生涯影响第二大的导师——miro哥，可以说他是我实习生涯中最好的导师。遗憾的是由于今年前端需求锐减，我没有转正留下来，不过miro哥也一直在关注我的秋招，给予过我很多帮助。

​ 八九月份无疑是我最痛苦的一段时间，今年的前端由于太多985211涌入一时间强度激增，所幸的是这一次命运认可了我这一路走来的艰辛，在快手的大池子里我率先泡了出来，收到意向书的那一刻，也算是如释重负对这三年有了交代。

​ 回首这一路，既有运气的成分，也有努力的痕迹。倘若当初没有抓住携程的机会，或许一切都不会发生。

​ 三年风雪，我心顽如青山，不曾动摇。

该渲染由 Shiro API 生成，可能存在排版问题，最佳体验请前往：https://linmoe.cn/posts/interview-experience/mhy

看完了？说点什么呢

该渲染由 Shiro API 生成，可能存在排版问题，最佳体验请前往：https://linmoe.cn/posts/essay/d2c_ai

看完了？说点什么呢

该渲染由 Shiro API 生成，可能存在排版问题，最佳体验请前往：https://linmoe.cn/posts/essay/tx_teg

看完了？说点什么呢

前言

​ 不知道咋的最近有点摆，可能是刚刚拿到腾讯的offer让自己觉得安于现状？反省一下自己顺便写一写最近的一些思考感悟。

浅谈考研与就业

​ 作为一个考研就业两手抓的卷王，对于这方面还是有自信可以谈论一二的，目前的进度是五月份结束考研一轮（22408），暑期实习拿到包括腾讯美团在内的五家大厂offer，最近闲下来也开始思考自己的未来该如何选择。

​ 首先是考研，作为大一刚刚进校就开始喊着要考研的选手，我也没有太辜负自己的期望，还是坚持了下来，就是没有考自己专业的研哈哈，可以理解进来的时候就对本专业不感兴趣。我是大三上正式开始备考的，可能和其他选手的备考路线不同我最开始备考的是专业课，大三上加上寒假完成408的一轮复习，三月份返校后用了两个月完成了基础课的一轮（不包括政治），其实主要复习也是在数学上，英语就是背背单词。

​ 其次是就业，相较于考研来说就业我准备的时间就比较早了，大一到大二上一直都在打比赛，可惜自己在这方面确实是没什么天赋，拿到的成绩大多都一般，大二上的寒假果断花了两个月自己all in完成自己的第一个开源项目，并成功在大二下末尾拿到携程的offer，再到今年四月份暑期拿到腾讯的offer，可以说在我们学校也是少有来者了。

​ 虽然是一直在两手抓，但最后肯定是要二选一放一个的，目前对于我来说性价比最高的肯定是报就业了，主要犹豫还是以下几点

1. AI冲击下，前端的生存空间是否会被进一步挤压？
2. 进入公司后续晋升是否会涉及到卡学历/学历高者优先提升？
3. 考研上岸选择读研究生三年后的市场如何？
4. 选择读研我能否在本科基础上延长职业寿命？提高薪资待遇？
5. 读研能否前端转入算法岗？

​ 以上几点无疑最让我关心的就是当前前端形势问题以及后续晋升了，其实我参考了周围大部分研究生朋友的经历得出了几个结论，首先大部分研究生甚至包括92硕在内都走不了算法岗，最多就是AI应用开发，本质上还是走的开发，目前就业市场虽然算法岗位有所增加但整体上还是门槛很高，所以对于我来说读研大概率转不了算法，那么读研对于来说就只有提高学历这一个作用了，但是考虑到读研完后要花三年时间，这三年读研经历和工作经历，毫无疑问肯定是工作经验更有优势，所以目前我得出的结论是在能转正的情况下优先工作，考虑大龄读研刷应届生的身份进国企（可能会卡年龄限制🤔）。

浅谈薪资问题

​ 最近突然想到一个很怪的事情，那就是关于我的薪资问题，其实在互联网薪资问题属于一个红线话题，可以说高度保密的，也许是我还在实习对于这方面没有太过于重视，以至于大部分人问我薪资问题都如实回答了，这个得反省一下......虽然对于实习来说薪资在网上是透明的，但是不养成这种习惯，正式上班哪天嘴欠说出去就完蛋了。

浅谈最近备考以及某些焦虑

​ 不知道其他选手备考一天能学多长时间？我最近学习时间只能达到4-5h差不多，而且效率也没有太高，还是没有摆正自己的心态，也可能是没有all in的觉悟哈哈哈，今天看了一下APP的使用频率，在社交app上花的时间还是太长了，得找个办法限制一下，我也纳闷了平时也没啥人找我聊天咋花这么长时间的。

​ 其二是最近看着学弟学妹们在空间发自己的代码截图突然有些羡慕或者说惆怅吧，似乎对于代码没有以前那种激情了，也可能是新鲜感过了...突然明白那句永远不要让你的兴趣成为工作，开源项目也堆积了很多技术债没有时间解决，等明年再找时间解决一下吧。

结语

​ 我发现我是一个很容易焦虑的人，总喜欢想点有的没的哈哈哈。

前端框架原理

现代前端框架几乎都是基于描述自变量和 UI 视图之间的关系建立的，即“数据驱动视图”

$ UI=f(state) $

前端经过长时间的发展，对于 UI 的描述语言逐渐衍生出两种解决方案

• JSX（代表框架:React）:类 XML 语法的 ES 的语法糖
• 模版语法（代表框架:Vue，Svelte）

前端框架分类的依据

对于公式 UI = f(state) 在“自变量与因变量”理论中，state 的本质是自变量，自变量通过直接或者间接（自变量导致因变量变化）的方式来改变 UI。“被改变的 UI”仅仅是”对宿主环境 UI 的描述“，并不是实际宿主环境的 UI。

1. 根据自变量（state）变化来计算出 UI 的变化
2. 根据 UI 的变化执行具体宿主环境的 API

• 元素级：Svelte
• 组件级：Vue
• 应用级：React

细粒度更新

在 React 中定义因变量时候需要显式的指定出依赖项，而 Vue 和 Mobx 不需要

// React
const y = useMemo(() => x * 2 + 1,[x]);
// Vue
const y = computed(() => x.value * 2 + 1);
// Mobx
const y = computed(() => x.data * 2 + 1);

在 Vue 和 Mobx 中使用的“能自动追踪依赖的技术”被称为“细粒度更新”，它同时是许多前端框架剪力“自变量变化到 UI 变化”的底层原理。

实现 React 中的一些 Hooks

此处不管是 effect.deps 还是 state 对应的 subs 都使用了 Set 利用了集合不会重复添加数据的特性,用细粒度更新实现的 hooks 不需要去显式的指出依赖

4.1 useState

function useState(value){
  // 订阅该state变化的effect
  const subs = new Set();

  const getter = () => {
    // 获取当前上下文的effect
    const effect = effectStack[effectStatck.length-1];
    if(effect){
      subscribe(effect,subs);
    }
    return value;
  }

  const setter = (nextValue) => {
    value = nextValue;

    // 通知所有订阅该state变化的effect执行
    for(const effect of [...subs]){
      effect.execute();
    }
  } 
  return [getter,setter];
}

function subscribe(effect,subs){
  subs.add(effect);
  // 依赖关系建立
  effects.deps.add(subs);
}

4.2 useEffect

const [count,setCount] = useState(0);

useEffect(() => {
  console.log('count is:',count());
})
setCount(2);

useEffect 实现的关键在于建立 useState 和 useEffect 之间的订阅关系

1. 在 useEffect 回调中执行 useState 的 getter 时，该 Effect 会订阅该 state 的变化
2. useState 的 setter 在执行时，会向所有订阅了该 state 变化的 effect 发布通知

const effect = {
  // 用于执行useEffect回调函数
  execute，
  // 保存该useEffect依赖的state对应的subs的集合
  deps: new Set()
}

function useEffect(callback){
  const execute = () => {
    // 重置依赖
    cleanup(effect);
    // 将当前effect推入栈顶
    effectStack.push(effect);

    try{
      // 执行回调
      callback();
    }finally{
      // effect出栈
      effectStatck.pop();
    }
  }

  const effect = {
    execute,
    deps: new Set();
  }

  execute(); // 自动收集依赖
}

function cleanup(effect){
  // 从该effect订阅的所有state对应subs移除该effect
  for(const subs of effect.deps){
    subs.delete(effect);
  }
  effect.deps.clear();
}

4.3 useMemo

function useMemo(callback){
  const [s,set] = useState();
  // 首次执行callback后，建立回调中state的订阅发布关系
  useEffect(() => set(callback()));
  return s;
}

AOT 与 JIT

所有现代前端框架都需要 “编译” 这一环节，而 “编译” 可以选择两个时机去执行：

1. AOT（Ahead Of Time，提前编译或预编译），宿主环境获取编译后的代码
2. JIT（Just In Time，即时编译），代码在宿主环境中编译并执行

在 Angular 中同时提供了这两种编译方案：

import {Component} from "@angular/core";

@Component({
  selector: "app-root",
  template: "<h3>{{getTitle()}}</h3>"
})

export class AppComponent {
  public getTitle() {
    return "Hello World";
  }
}

渲染结果：

<app-root>
  <h3>Hello World</h3>
</app-root>

如果将使用的 getTitle 方法换成一个未被定义的函数：

1. AOT：立即报错

ERROR occurs in the template of component AppComponent.

2. JIT：代码在编译时候不会报错，在浏览器运行的时候报错

ERROR TypeError: _co.getTitleXXX is not a function

除此之外还有这些区别：

1. JIT 的应用在首次加载的时候慢于 AOT 的应用，因为其需要先编译代码；而使用 AOT 的应用已经在构建的时候编译完成，可以直接执行代码
2. 使用 JIT 的应用体积可能大于使用 AOT 的应用，因为其在运行时会增加编译器代码

因此 Angular 一般在开发环境下使用 JIT，生产环境下使用 AOT

VirtualDOM（虚拟 DOM）

又称 VDOM 是目前根据自变量变化计算出 UI 变化的一种主流技术

在 Vue 中使用模版语法来描述 UI，模版语法编译为 render 函数：

1. render函数执行后返回“VNode 描述的 UI”，这一步骤中 Vue 中被称为 render
2. 将变化前后“VNode 描述的 UI”进行对比，计算出 UI 中变化的部分，这一部分在 Vue 中被称为 patch

React 使用 JSX 来描述 UI，JSX 编译为 createElement 方法：

1. createElement 方法执行后返回“React Elemet 描述的 UI”
2. “将 React Eleme 描述的 UI”与变化前“Fiber Node 描述的 UI”进行比较，计算出 UI 变化的部分，同时生成本次更新“Fiber Node 描述的 UI”

VDOM 的优点

1. 相较于 DOM 的体积优势：除了“比较 UI 变化需要必要的属性”，DOM 还包含了大量冗余的属性，使用 VDOM 可以减少内存的开销
2. 相较于 AOT 更强大的描述能力：比如要在“使用模版语法的前端框架”中实现 React 的 children 属性，需要实现 Slot Component，对 children 的简单操作也变成了对 Slot Component 的繁琐操作
3. 多平台渲染能力：根据 $ UI=f(state) $中 f 的工作原理可以概括为
   1. 根据自变量变化计算出 UI 变化
   2. 根据 UI 变化执行具体的宿主 API

因此在浏览器，Node 宿主环境下使用 ReactDOM 包，在 Native 宿主环境下使用 ReactNative 包，在 Canvas，SVG 宿主环境下使用 ReactArt 包。

React 实现原理

React 被称为应用级框架的原因在于--其每次更新流程都是从应用的根结点开始，遍历整个应用。同理，Vue 起始于组件，Svelte 起始于元素。

暮色漫上窗棂，收拾好工位告别 mentor。转身时字节跳动大楼的灯火正撞进眼底，千万格数据洪流在玻璃幕墙上蜿蜒流淌，将未说出口的告别冲散在霓虹里。

命运总是在制造精密的时间差，我想那些看似错轨的瞬间，实际是上帝在调试名为人生的沙盒——那段我们共同编译的短暂岁月，也许早已成为各自生命进程里不可替代的常量。相遇的意义在于照亮彼此，只要同行时是快乐的，便是最好的相遇。

如果有机会我想带你去看一看苏州河的黄昏，当波光将影子揉碎成十万片金箔，我们将听到这座城市用江水书写出的启示。

十二月的开卷铃声将比外滩跨年钟声更加洪亮，当试卷展开的刹那，洁白的卷面会倒映出我的过往，而所有未尽的遗憾，都将在下一个换乘站了却。

愿每个人的心中都有一座静安寺，在这喧嚣的城市中留存一份安宁。

再见，上海。

1. 使用了 `import` 语法，这是 `ES规范`，而非 Node.js 的 `CommonJS规范`。
2. 我们使用了 `React` 的 `JSX` 语法，`JavaScript` 并不认识，需要用 `Babel` 转译成这样。

修改 `package.json`:

} ```

此时运行 node server.js 可以成功渲染，但是只用 renderToString 将 React组件 转为了 HTML字符串，并没有任何的 Hydrate（水合）事件绑定，只有静态的 HTML。

绑定事件

既然服务端只能渲染 HTML，客户端能渲染事件，那就结合一下，再实现一遍 CSR，让页面插入一个打包后的 bundle，挂载到相同的节点，让客户端将一模一样的内容重新渲染一遍，并绑定上事件（重复渲染后面解决）。

client.js

import React from 'react';
import { createRoot } from 'react-dom/client';
import App from './pages/index';

const root = createRoot(document.getElementById('root'));

root.render(<App />);

修改 server.js

import express from 'express';
import React from 'react';
import { renderToString } from 'react-dom/server';
import App from './pages/index';

const app = express();
app.use(express.static('public'));
const content = renderToString(<App />);

app.get('/', (req, res) => res.send(`
<html>
    <head>
        <title>Tiny React SSR</title>
    </head>
    <body>
        <div id='root'>
            ${content}
        </div>
        <script src='/client.bundle.js'></script>
    </body>
</html>    
`));

app.listen(3000, () => console.log('listening on port 3000'));

打包后的客户端代码被命名为 client.bundle.js，并放入 public 目录。

webpack.client.js

const path = require('path');

module.exports = {
  mode: 'development',
  entry: './client.js',
  output: {
    filename: 'client.bundle.js',
    path: path.resolve(__dirname, 'public'),
  },
  module: {
    rules: [
      {
        test: /\.(js|jsx)$/,
        exclude: /node_modules/,
        use: {
          loader: 'babel-loader',
          options: {
            presets: ['@babel/preset-env', '@babel/preset-react'],
          },
        },
      },
    ],
  },
};

现在的流程是

先打包 客户端 的 JS，将引用 pages/index.js 核心 React 代码的 client.js 打包到 public 下的 client.bundle.js。

然后将同样引用 pages/index.js 核心 React 代码的 server.js 打包到 build 下的 server.bundle.js 中，然后 node 开启 server.bundle.js。

服务端会先渲染一遍组件代码，然后输出到 HTML 中，引用 client.bundle.js，然后用 JS 再渲染一遍，并绑定上事件。

修改 package.json

"scripts": {
  "start": "webpack --config webpack.client.js && webpack --config webpack.server.js && node ./build/server.bundle.js"
}

此时已经能交互，但是有个重复渲染问题需要解决。

HydrateRoot

React 官方提供了 HydrateRoot API，允许你在先前 react-dom/server 生成的 HTML DOM节点 中展示 React组件，简单来说就是复用服务器渲染出来的 DOM 节点。

修改 client.js

import React from 'react';
import { hydrateRoot } from 'react-dom/client';
import App from './pages/index';

const root = hydrateRoot(document.getElementById('root'));

root.render(<App />);

运行 npm start，实现了 SSR + Hydration 的 React 渲染。