狐友作为搜狐的一款社交产品，在流量传播上有着旺盛的需求点。而在流量传播所需的众多载体之中，海报图片以其简单的分享形式、可定制的视觉体验、自带二维码识别导流等特点，成为了社交产品高频必备的流量载体。

作为狐友的前端开发，生成海报图片就成为了我们工作中持续不断的一个重要需求点。以下是狐友目前的产品前端服务矩阵和海报图片的产品形式。

海报图片实现现状

从上图1可以看到，生成海报图片对于狐友产品矩阵来说是一个高频强需求。海报图片作为分享载体，对于各平台的分享流程对接也非常畅通和直观，例如不同于小程序卡片分享只能拘泥于微信平台，网页分享的链接形式不够直观。

而在海报图片这个重要环节，长期的主要技术手段一直是通过各客户端开发在本地设备上进行绘制，但这种方案存在如下的劣势困扰着我们：

• 各端无法复用：如图2, 如果要全平台都要做图片分享，那么需要各端分别开发，即使生成的图片一模一样，也要开发iOS、Android、H5、小程序一共4遍，整体开发各端无法互相复用。
• 长图大图崩溃：客户端限于设备平台或系统限制，对于长图的生成并不友好，会出现长图因为内存或算力限制无法生成的情况，其中小程序尤为明显，在微信的框架下很容易长图生成造成程序直接崩溃。
• 开发效率较低：客户端本地绘制海报图片，一般需要手写原生代码效率不高。小程序端虽然使用wxml-to-canvas（H5端使用html-to-canvas）来绘制减轻了一些手写命令式绘制代码的负担，但这种标记语言转canvas在实现上也存在缺陷，相比HTML+CSS的表达力还是非常受限。所以，海报图片在代码层面开发效率比较低。

为了解决以上问题，我们开始着手调研并实践落地了一套全新的海报图片统一服务，命名为hy-ssr-img。

海报图片统一服务

海报图片统一服务是一套基于Puppeteer的Node.js后端服务端（SSR）渲染页面并截图生成海报图片的服务，这一服务解决了原有海报图片生成的三大问题：

• 各端无法复用 -> 4端同时复用：iOS、Android、H5、小程序4端只需要开发一遍即可，效率提升400%，如图3
• 长图大图崩溃 -> 无惧长图渲染：不需要再担心长图渲染问题，服务端渲染图片能力理论上可以达到上万长度的渲染，针对不超过5屏的图片需求来说绰绰有余
• 开发效率较低 -> 开发效率最优：使用效率超高、表达力超强的标记语言HTML + CSS渲染，开发效率和表达力都达到最优状态

那么，海报图片统一服务是如何建立起来的呢？下面是从项目立项开始的具体设计方案。

项目选型

首先，我们调研了业界现有的图片渲染方案，如下表。通过下表的调研总结可以看出各个方案各有优劣势。由于复用提效是重要需求点，我们把方案锁定了服务端渲染方向上，即入选方案为：

• Node.js截图方案
• 服务端图层绘画方案

在对比两种方案，以及参考相关业务实践后，我们最终选用了最常见的【Node.js截图方案】。因为服务端图层渲染选用的图形库在排版表达力上远不及HTML+CSS在浏览器上的表达力，而且系统预期的使用对象是前端开发人员，并不是产品和运营，所以服务端图层渲染方案的拖拽方式并不是必选项，反而由于拖拽渲染表达力的限制，对于实现一些排版复杂的图片非常吃力。而Node.js截图方案则没有这方面的问题，前端开发只需要常规开发页面即可，然后交给Puppeteer渲染后进行截图形成最终用户看到的海报图片。

项目架构流程方案

在确定了【Node.js截图方案】之后，我们对项目整体架构流程进行了设计，首先由于我们的应用的后端Java接口服务已经非常成熟，针对参数的合法性校验及加签解签等防护措施都已建立，所以我们在开发Node.js服务时就没有必要再造轮子，那么怎么把这些基础接口功能和Node.js服务联系起来呢？我们决定把Node.js服务放到内网，通过只允许后端服务直接访问的方式来达到这一目的，这样后端接口层就像一个盾牌，挡在用户和Node.js服务之间，而我们就可以专注实现Node.js的截图功能了。整体方案流程如下图4：

仅首屏SSR渲染方案

整体架构流程方案确定后，我们就需要细化截图相关的详细流程方案。在经过调研之后，我们发现常见的截图开源方案在我们的使用场景中还有很多需要优化的点和不满足需求的部分，因此我们决定自研开发【仅首屏 SSR 渲染】方案。针对项目特点，每个海报图片只有一张，所以不存在首屏渲染过后还要渲染第二页的场景，因此该方案只包含首屏字符串渲染即可，不需要带有常见 SSR 的客户端激活渲染的打包构建及执行流程。 去掉常见SSR方案中的非首屏渲染逻辑后，页面就只包含了首屏必要的渲染代码（HTML + CSS），去除一切不需要的环节（JS执行激活），保证页面给到 Puppeteer 渲染时是最简化的状态，尽可能减少网络I/O和本地磁盘I/O，只包含单纯的渲染过程，以加速渲染速度。以下是常见方案和自研方案的对比。

最常见的截图方案是通过请求网页地址，渲染后截图，如图5。

这种方案不管是CSR（客户端渲染）方式，还是SSR（服务端渲染）方式，都还是有优化空间。我们可以发现，Puppeteer请求网页的网络消耗是可以被节省下来的，如果我们直接使用在本地生成好的HTML和CSS，则请求网页并下载所用的时间就可以节省下来，获得更快的截图速度。

另外页面的动态渲染通过SSR来进行，这样完全不需要客户端JS的存在，直接还可以省去加载客户端JS的时间，获得更优的渲染速度，这种优化后的Node.js截图详细流程方案如图6所示。

该方案还有技术细节需要设计，即如何完成SSR渲染首屏的工作，由于我们的技术栈是Vue，所以选用vue-server-renderer为基础库来完成这一过程，如图7。

项目业务技术流程设计

整体架构流程方案确定之后，我们就要进行更细化的业务技术流程设计，这里有很多细节需要考虑：

• 后端接口层如何和Node.js截图服务进行通信？
• 截图服务是一个高耗时服务，如何防止长链接堆积？
• 如何设计海报图片缓存层？如何设计提供海报预渲染？
• 其他流程细节...

为了解决这些问题，我们设计了如下的流程，如图8。

可以看到整个流程设计由接口同步请求和截图异步任务两大块组成。我们把Node.js截图服务当做一个纯渲染图片的服务，用户发起请求给后端服务时会携带渲染页面所需要的动态参数，后端服务则负责参数校验等工作，并且下发给用户一个异步任务ID。然后后端服务会请求截图服务，截图服务收到请求后并不会立刻截图，而是直接返回后端服务，并开启异步任务去进行耗时的截图服务，这样就可以防止长链接堆积造成服务不可用的情况发生。之前下发给用户侧的异步任务ID就是异步截图任务完成后通知后端服务的凭证，这样当截图服务完成后就可以通知后端服务截图完成状态（截图成功或者失败），而用户侧则可通过轮询后端服务接口得知截图是否完成并使用海报图片了，当然可以设置一个超时时间来完成整个截图服务的交互闭环。

对于海报图片的缓存层也是要考虑的，因为很多场景下用户请求的海报图片是一模一样的，比如我们的热榜海报会在固定时间生成一次，那么缓存层可以有效缓解截图耗时操作，并且为预生成海报图片提供了基础。比如我们会在特定时间通过代码自动预渲染一批海报，当第一个用户来访问时就不需要等待耗时的截图服务，直接返回渲染好的海报图片即可。那么命中缓存的条件是什么呢？对于长的一模一样的海报图片当然希望只生成一次后都走缓存层。我们的设计中决定“图片长相”的因素有两个：

1．海报地址：对应不同的海报样式

2．海报参数：对应同一个海报样式中的不同数据

所以，我们通过hash(“海报地址”+“海报参数”)的方式得到缓存命中的key，以此来控制命中缓存。另外截图服务生成海报图片后会直接上传到CDN进行存储，用户侧加载海报图片的速度和稳定性也得到了相应的保障。

项目技术选型及工程化方案

在业务技术流程方案确定后，就需要为此搭建一套工程化开发环境，来支持项目业务的具体开发。我们基于公司现有基础设施以及技术栈，确定了以下主要技术选型：

• 接口服务框架：Express
• 页面渲染框架：Vue
• 支持SSR渲染：vue-server-renderer
• 支持浏览器截图：Puppeteer
• 支持页面开发环境 ：webpack
• 图片存储：OSS （公司内部对象存储服务）
• 服务端日志：Logstash + Kafka + Elasticsearch + Kibana（公司内部基础日志服务链）
• 部署：DomeOS （公司内部云服务平台）

如图9，展示了通过以上技术栈及基础设施组建的整个工程化方案。

这里需要说明是，一个海报图片对应一个页面，一个页面会有两个入口文件：一个CSR（客户端渲染）用于开发页面时使用，一个SSR（服务端渲染）用于截图时Puppeteer渲染页面使用。这么设计的原因是，CSR渲染使用webpack-dev-server是现成的开源方案，对于开发时热更新等支持不需要自定义开发，开箱即用，如果开发时也使用SSR进行就需要进行针对性的改造，由于开发体验上并没有区别，我们就选用了更高效地搭建方式。而截图时页面渲染方式就是上文提到的【仅首屏 SSR 渲染】。

项目关键优化实践

从用户发起请求到海报图片返回，这整个过程的耗时需要进行“压榨”，以获得更好的用户体验。以下是我们在开发过程中实践和验证的相关重点优化和部分效果收益。从第一版基础开发到最后优化完成的版本，截图服务总用时从1300ms+降低到了600ms+（注：测试数据均取相同开发机10次执行结果的平均值，渲染相同的海报图片，图片为超长图且内容丰富，长宽为：4967×750）。表2为各关键优化点明细。

项目在线文档预览系统

为了方便使用海报图片的开发人员，我们还配套开发了海报生成系统在线文档。开发人员可以通过该系统查看现有的海报图片以及相关参数字段，并可以通过右方的编辑器更改字段的值并实时得到新的渲染图进行预览和下载。如图10，开发人员可以在这个playground里进行所见即所得的预览及操作。

项目日志实践

海报图片服务作为一个后端服务，日志采集分析和监控是必不可少的，我们可以通过日志得到以下信息：

• 海报图片生成的访问情况
• 海报图片生成的性能优劣
• 海报图片生成失败的原因
• 海报图片生成异常的报警

所以，我们封装了3种log日志用于海报图片服务：

• access：记录每次请求的请求日志
• debug：记录生成图片的关键节点信息的日志
• error：记录生成图片失败及原因的错误日志

日志处理完成后，我们接入了公司现有日志基建服务来完成后续的日志采集、存储和分析等功能，如图11所示，通过这一套日志流程，我们就可以更加放心地上线并时刻关注我们服务的运行情况，轻松做到快速排查和分析问题。

项目部署方案

海报生成是一个耗时任务，其绘制速度依赖于服务器的CPU和内存。经过线上数据评估，截图服务qps最大支持60即可，经使用JMeter并发测试：

• 当使用单实例（CPU 1核 + 内存 2G）单进程部署项目时，并发为1时生成5000像素的图片需要耗时约2s，并发数超过1时，后面的请求得等待前面请求生成完图片，才会生成，生成图片时间会随并发数成倍增加。
• 当使用单实例（CPU 1核 + 内存 2G）多进程部署项目时，并发为1时生成5000像素的图片需要耗时约2s，并发数超过1时，当并发数少于进程数时，会同时生成图片，并发为5时，图片返回时间约为9s，此时CPU占用会超过40%，内存占用20%，虽然CPU和内存在并发数量为5的时候占用率不高，但是生成图片的速度会大幅下降，所以需要增大单实例CPU和内存的大小。
• 当使用单实例（CPU 4核 + 内存 6G）多进程部署时，并发为1时生成5000像素的图片耗时约1s，并发数为5的时候，图片返回时间约为3s，当并发为10的时候，图片返回时间约为8s。此时CPU占用会超过20%，内存占用10%。

所以为了保证图片的生成速度和稳定性，使并发量少的时候图片生成速度尽可能快，并发量大的时候图片生成速度在可接受时间内，采用了多实例加多进程的部署方式，如图12，项目部署于DomeOS平台，部署了5台 （CPU 4核 + 内存 6G） 实例，每个实例通过pm2启动4个进程。通过负载均衡可以使请求平均打到每个实例的每个进程上，让并发少的时候最快的生成图片，并发大的时候充分利用所有实例，加快整体生成图片时间。生成5000像素的图片，当并发数小于5时，图片可以在1s左右返回，当并发数为20，图片可以在3s左右返回，当并发数为60时，图片可以在8s之内返回。

项目成果

截止到2023年初，海报图片服务已上线海报5个。每个海报只需开发1遍就可供给H5、小程序、Android和iOS共4端进行使用。每天平均生成海报图片6000+，每张海报图片平均生成时间400ms左右，支持超长图可达10000+像素。

未来展望

随着项目迭代，海报服务未来可能有更大的需求诉求，下面列出海报服务未来进化的一些展望：

1、赋能外部开发人员

目前项目是以普通项目的开发模式进行研发，如果提供给非内部研发人员使用则有很多流程和规范上的问题难以解决。未来可以支持渲染远程组件，通过远程组件的方式下发给外部研发进行开发，以此隔绝海报服务核心逻辑和业务方逻辑，使得业务方只需关心业务，也防止业务方无意间可能影响到海报核心逻辑。此外，在整个过程中还可以增加审核远程组件等项目管理能力。

2、赋能非研发人员

为了海报图片渲染极具灵活性，我们把开发人员作为首要满足对象。未来除了开发人员可以开发海报页面，同时可以支持非研发人员通过拖拽编辑等低代码方式完成海报图片的生产，这样针对简单海报图片的场景，运营、产品等非研发人员也可以进行海报图片的制作，进一步提高生产效能。

背景

应团队同学提议，写了这篇如何写好一篇技术文章的文章。鉴于水平实在有限，亚历山大之余，也很高兴分享一下自己对技术写作的一些思考。

希望大家可以从中得到一些对自己有用的关于写作的启示和方法，就能达到本文的目的了。那么，写好一篇技术文章对我们有什么用呢？我觉得有三点：第一点，可以更好地分享传播技术方案，让读者认同赞赏你的文章；第二点，通过文字表达提升个人的表达能力，在做技术分享和演讲时更具魅力；第三点，通过整理技术文章，主动对技术深入思考剖析，提升个人的技术广度和深度能力。

那么，接下来我重点分享下我实践中的写作流程。

写作流程

写作流程，大体上可以分为：写作前的准备工作、写作中的注意事项和技巧以及写作后的提升工作。通过对这三个阶段的打磨，相信你就可以写出一篇”令人满意“的技术文章。

写作前

所谓万事开头难，所以写作前的充分准备工作，可以帮助你快速进入写作状态，准确明晰写作内容。让我们通过以下手段，告别写作开始时的”提笔皱眉“，体验一把”下笔如有神“。

确定立意标题

当然，立意和标题应该是先确定清楚的，要非常明确地知道自己要写什么内容，这个”什么“其实并没有那么简单，可以参考以下罗列的要素：

• 内容传达的目的是什么？
• 内容关键字是什么？
• 内容触达的范围是什么？
• 内容的重点是什么？

最后，通过对立意的分析思考，形成一个立意明确的标题。不要小看这个标题，这个标题是文章的”门面“，有时候甚至会让读者使用”一票否决权“。所以，标题也应该首先明确下来，在写作中不断围绕立意的标题进行，这样即不会产生跑题的情况，也对内容进行了充分强化。技术文章标题，其实不用起得那么”八卦“来吸引读者，简单直接即可。可以参考以下罗列的要素：

• 紧扣内容立意
• 简短清晰

确认目标读者

确认目标读者是非常重要的，尤其文章需要在一些特殊场合中进行发布和使用。是分享技术到社区？还是给领导汇报技术方案？还是具体下发开发执行方案？不同的场景，写作的侧重点和用语都需要做相应的调整。至于如何调整，这个需要对不同的环境进行判断，并不能一概而论，可以参考不同场景下要考虑的写作要素：

• 文章中的称谓
• 读者最关心的是哪部分？过程？结果？还是数据？
• 是否需要为读者提供某些补充资料？

形成树形提纲

在确认立意和目标读者之后，我们就可以开始”下笔“了，但是我建议不要急于写”文章的主体“部分，而应该先形成纸面的”树形提纲“。当然，如果写作前脑子里的”布局“就已经非常清晰，也可以省略纸面工作。其实，我们写文章，尤其是比较长的文章，是应该有目录索引的，这样非常方便读者检索。而这个步骤正好同时完成了目录整理的过程：只需对树形提纲进行适当提炼，就可以轻松成为我们的目录索引了。可以参看本文的目录索引，其实也就是本文的树形提纲了。

准备周边素材

巧妇难为无米之炊，没错，提纲有了就相当于锅碗瓢勺等吃饭的架子都已准备妥当，就差最重要的”食材“就可以”做饭“（写作）了。因为我们已经有了立意和树形提纲，围绕它们我们就可以明确知道接下来要写什么内容，那么拿什么来支撑内容呢？有以下写作要点可以参考：

• 关键概念
• 关键代码
• 规范要求
• 案例支撑
• 图片解释
• 互动demo

其实周边素材可以有很多，在前期准备的时候可以”贪多“，最后再进行”过滤“即可。而收集素材、审视素材的时候，会促进我们来来回回地进行学习和思考。这个过程对作者来说是十分有益的，不仅能把自己的经验沉淀在纸面上，也同时在这个过程中不断“验证”、“证伪”、甚至“升华”了自己的技术经验，甚至碰撞出一些令人激动的“思维火花”。

调整树形提纲

从树形提纲形成之初，它就可以不断进行调整。不管在准备周边素材还是写作中，写作后，都可以在当下按照自己的理念进行调整，或裁剪或丰满。这有点儿像我们写程序时，不断调整参数以观察不同输出结果。直到结果令人满意，那么树形提纲就“定型”了，与之关联紧密的“目录索引”也可轻松产出。这样我们就可以放心开始写作了，因为我们手里有了“树形提纲”这个写作向导，不用再为不知道写什么，不知道是不是跑题了而烦恼。

写作中

写作开始，进入到文章主体部分，我们顺着“树形提纲”有条不紊地进行叙述就可以了。但有的同学依然会困惑，还是不会写怎么办？其实这里我认为涉及到一个写作能力和技巧培养的问题。写作能力的培养绝不是一朝一夕的事情，所以这里简单地抛砖引玉，从写作基本功、技术难点阐述以及提炼方法论这三个方面，简单说下我对技术写作的理解。

写作基本功

写作基本功其实是我们从识字开始就不断练习的一种技能。我们平时读文章，常常会感到有些人的文笔很好，其实好的文笔一定是建立在良好的写作基本功之上的。有很多专门的书籍来讲怎么写作，我们可以专门去学习，这需要多看多练，这里就不再展开这些内容，主要列下注意要点：

• 格式：段落、标点、字体、字号、数字等
• 语法：主谓宾、转折、关联等
• 段落：总分、层次、点题等
• 逻辑：清晰、自洽、完整、无歧义、用词统一等
• 对仗：时间对仗、层次对仗、递进对仗等

技术阐述技巧

这里重点提一下技术方面的阐述技巧，因为我们写的是冷冰冰的代码，它本身没有过多的“人性”，而技术文章的使命就在于此，让读者不必“过深”地阅读代码，就可以从代码那“百折千回”中领悟到“意图”。那么，一篇好的技术文章往往就是在这个环节做得非常出色，总是能让读者轻松领悟到代码意图，如果能让读者发出：”原来是这样！cool！“如此的感叹，那就是好的技术文章所带来的魅力了。技术难点的阐述的难度往往是由技术的难度带来的，因为”晦涩难懂“的代码转化成”通俗易懂“的文字，是需要极强的技术能力和文字表达能力的。那么除了能力的培养之外，有没有什么方法可以让我们在写技术难点时更有方向呢？下面我列举了几种方法，供大家参考。

举例法

常用的手段之一就是举例子，通过通俗的例子来解释逻辑代码。例如数据结构queue和stack，我们就可以生活化地解释它们。queue：就是在排队在”鲍师傅“窗口买蛋糕的队伍，先来的人买完之后先离开，这对应着queue中的值先进先出的特性。而stack：就是”老鹰抓小鸡“中的队伍，老鹰要从队伍的尾巴处把人一个一个抓出去，这对应着stack中的值后进先出的特性。

举例子其实有很多手段，可以举生活的例子，也可以举复杂代码简化后的例子，还可以跨学科举例子。只要有利于读者通俗易懂并准确get到核心的例子都是好例子。

重点突出法

很多时候，技术文章因为技术点很多，而删减技术点又不利于整体阐述，这时候重点突出法非常管用。因为在茫茫的大草原中让别人发现一颗稀有的小草太难了，那我何不为这颗重要而稀有的小草旁边立块牌子，并写上字“嘿！看过来，我在这！“呢。对于文章想要强调的重点，一定要重点突出出来，怎么可以突出呢？可以通过以下手段来突出重点：

• 相关重点给予足够的篇幅
• 提炼小标题
• 单独成段
• 视觉加强：加粗、字体颜色、增加背景色等

图像法

一图胜千言，绝非虚言。读者对图的直接感知度要比干巴巴的文字要强很多。一张好的图可以解释大段文字才能说清楚的东西，甚至文字无法表达的”意境“同样可以使用图来”表意“。但是前提是图是精心设计并准确表意的，如果滥用图或者图使用不得当则会适得其反。即使我们不知道画什么，计算机领域里也依然有迹可循，由于图强大的解释力，软件开发中层出不穷地建立了很多有关图的规范：UML、流程图、实体图、数据流向图、原型图等等，善于利用这些图会使得我们的”技术解释力“更上一个台阶。

交互法

交互法和举例法有些像，但是举例法大多是”静态“的，而交互法则更具生命力，它是可以”动态“交互的。例如我们在阐述多个实体的关联关系的时候，我们可以提供给读者一个交互动画，让读者用连线的方式来理解实体间的关联关系，这种让读者主动参与到技术学习中的方式，往往比干巴巴地告诉他有用得多。交互法虽然制作成本大，但对于教学类的文章是效果非常好的阐述和演示工具。

提炼方法论

当我们写完文章主体部分后，写一个让人印象深刻的总结是非常有必要的。而这个总结得广度和深度是可以发散的，也就是可以从文章的点形成总结的面，从文章的面形成总结的体。从文章本身抽象到某个领域的通用规则，也就是提炼方法论。当然，我非常不建议强行提炼，当这篇文章真的激发了你的深度思考并有所结论时，快，千万别犹豫，把它总结提炼出来，这对于个人和读者都将会大有裨益。

写作后

当文章的主体写作完毕，还是有一些方面需要继续处理，这里重点讨论三个方面。

通读找错

写完文章，需要通读文章，并在通读的过程中寻找错误，例如错误字、不通顺语句等。

查漏补缺

在通读文章的过程中，继续查漏补缺，多余的删除，没阐述完整或清除的则需要增加。另外如果你的文章引用了规范、他人著作等，一定要加上引用指南，一来遵守引用版权，二来为想要深入引用的读者提供便利。

升华立意

升华立意在技术文章中的确不多见，但是在某些场景下可以使得文章更具”饱满感“，例如和公司战略、技术前沿突破等方面结合起来，会使得技术文章同样”发光发彩“。

结束语

其实如何写好一篇技术文章这个问题的答案很简单：技术好 + 写作好。而本篇着重阐述了我对如何”写作好“的看法与总结。而这些大多都是”术“，想要达到更高境界，必须要悟”道“：培养自我独有的感悟能力。那么如何才能”悟道“呢？我也还在悟的路上，这里分享三个个人看法：

• 借他山之石：站在高手的肩膀上，多学习借鉴他人的写作手法和思路，取其精华去其糟粕。
• 行自我之思：勤思考多总结，自我思考得够多够深，才不会”思到用时方恨少“。
• 走勤奋之路：万丈高楼平地起，一点一滴积累，勤耕不辍。

由于本人能力所限，请大家不吝指正，望共同进步。

— 纪念毛星云同学并与君共勉

前端技术新闻

React conf 2021 回顾

• React 18介绍和并发新特性：React 18 在没有重大break changes的情况下支持了并发特性，这意味着用户可升级的工作量只是和以往大版本更新相似。
• React 18已经发布RC版本可试用，预计2022年初就会发布正式版本。
• Streaming server rendering with Suspense：使用Suspense控制组价级别的流式渲染，使得用户更快看到内容，更快进行交互。
• 创立第一个React working group：集合各领域专家、开发者、库作者以及教育人员，共同合作逐步改善新的APIs，例如useId, useSyncExternalStore, 和 useInsertionEffect。
• React Developer Tooling：将会推送更易用更多功能的开发工具来帮助开发者debug React应用。
• React without memo：解决React常见痛点，介绍如何通过auto-memoizing compiler来减少模板优化代码，使开发者更加聚焦业务本身。
• React docs keynote：React的新版文档的设计理念。
• 其它React相关专题分享：learning and designing with React，Relay,  React Native,  PyTorch teams

React Conf 2021 Recap – React Blog

Last week we hosted our 6th React Conf. In previous years, we’ve used the React Conf stage to deliver industry changing announcements such as React Native and React Hooks. This year, we shared our multi-platform vision for React, starting with the release of React 18 and gradual adoption of concurr…

React

潮流开源

• React 18 RC版本，快来体验最新最强大的前端UI框架:

更新依赖：

npm install react@rc react-dom@rc

更换新的API createRoot :

// before
const container = document.getElementById('root');
ReactDOM.render(<App />, container);

// after
const container = document.getElementById('root');
const root = ReactDOM.createRoot(container);
root.render(<App/>);

• postcss-rs: Rust版本的postcss，几十倍速于Node.js，这速度相当感人

GitHub - postcss-rs/postcss-rs: 🚀 Fast and 100% API compatible postcss replacer, built in Rust

🚀 Fast and 100% API compatible postcss replacer, built in Rust - GitHub - postcss-rs/postcss-rs: 🚀 Fast and 100% API compatible postcss replacer, built in Rust

GitHubpostcss-rs

• TypeScript / ESNext node runtime powered by esbuild：基于esbuild的TS、ES运行时工具。

GitHub - antfu/esno: TypeScript / ESNext node runtime powered by esbuild

TypeScript / ESNext node runtime powered by esbuild - GitHub - antfu/esno: TypeScript / ESNext node runtime powered by esbuild

GitHubantfu

• pnpm：2022了，是时候选择更强的包管理工具了。

GitHub - pnpm/pnpm: Fast, disk space efficient package manager -- 快速的，节省磁盘空间的包管理工具

Fast, disk space efficient package manager -- 快速的，节省磁盘空间的包管理工具 - GitHub - pnpm/pnpm: Fast, disk space efficient package manager -- 快速的，节省磁盘空间的包管理工具

GitHubpnpm

• mkcert：啥？localhost也想带https的锁标？没问题上菜吧。

GitHub - FiloSottile/mkcert: A simple zero-config tool to make locally trusted development certificates with any names you’d like.

A simple zero-config tool to make locally trusted development certificates with any names you'd like. - GitHub - FiloSottile/mkcert: A simple zero-config tool to make locally trusted developmen...

GitHubFiloSottile

技术文章（深度）

• 跨端框架uni-app是如何构建小程序的？：作者通过对打包器、编译器以及运行时处理的层层源码及原理分析，揭开了Vue写小程序的神秘面纱。

uni-app是如何构建小程序的？ - 掘金

uni-app是一个基于Vue.js语法开发小程序的前端框架，开发者通过编写一套代码，可发布到iOS、Android、Web以及各种小程序平台。今天，我们通过相关案例分析uni-app是怎样把Vue.

掘金luocheng

其他（随便看看）

• 防止直接传递数组回调方法的eslint检查规则，规避参数传递不明确引发的问题。

eslint-plugin-unicorn/no-array-callback-reference.md at main · sindresorhus/eslint-plugin-unicorn

Various awesome ESLint rules. Contribute to sindresorhus/eslint-plugin-unicorn development by creating an account on GitHub.

GitHubsindresorhus

• 元宇宙？和前端有啥关系，看看大家都在扯啥子。。

元宇宙时代的前端开发，会是什么样？ - 知乎

既可以理解为元宇宙产品的开发，也可以理解为元宇宙落地后上层应用的开发。请从产品形态，开发模式，技术…

知乎doodlewind雪碧 | github.com/doodlewind

Githooks easily makes our team's code more robust, example below will records some situations of usage.

standard commit msg

filepath to edit: '.git/hooks/commit-msg'

#!/bin/bash
test "" != "$(grep '[A-Z0-9]\+-[0-9]\+ ' "$1")" || {
        echo >&2 "ERROR: Commit message 的格式为: JIRA任务编号 任务名称"
        exit 1
}

prevent conflicts to be commited

filepath to edit: '.git/hooks/pre-commit'

#!/bin/bash
emsg=$(git diff --check --cached)
if git diff --check --cached | grep -qE 'conflict\smarker';then
    echo -e "请检查有未解决冲突的代码进行提交：\n${emsg}"
    exit 1
fi

using script

as git hook file would not keep track on by git history, you cannot share them between your team members. therefore, I prepared a shell script to do it just by adding this script file into your repository root, and then this file can be shared.

#!/bin/bash
echo "start to create git hooks"

fileCommitMsg=.git/hooks/commit-msg
touch $fileCommitMsg
echo "#!/bin/bash" >$fileCommitMsg
echo "test \"\" != \"\$(grep '[A-Z0-9]\\+-[0-9]\\+ ' \"\$1\")\" || {" >>$fileCommitMsg
echo "    echo >&2 \"ERROR: Commit message 的格式为: JIRA任务编号 任务名称\"" >>$fileCommitMsg 
echo "    exit 1" >>$fileCommitMsg
echo "}" >> $fileCommitMsg
chmod +x $fileCommitMsg
echo "finish commit-msg hook"

filePreCommit=.git/hooks/pre-commit
touch $filePreCommit
echo "#!/bin/bash" >$filePreCommit
echo "emsg=\$(git diff --check --cached)" >>$filePreCommit
echo "if git diff --check --cached | grep -qE 'conflict marker'; then" >>$filePreCommit
echo "   echo -e \"请检查有未解决冲突的代码进行提交：\\n\${emsg}\"" >>$filePreCommit
echo "   exit 1" >>$filePreCommit
echo "fi" >>$filePreCommit
chmod +x $filePreCommit
echo "finish pre-commit hook"

exit 1

to be continue

注：本文是阅读《深入React技术栈》的一些心得，一部分内容和图片是直接摘抄自此书。

React 组件的生命周期函数是 react 的基础知识，如果有不熟悉的可以看官方文档。简单总结如下。
组件的生命周期函数分为两类：挂载或卸载过程 / 组件更新时。挂载或卸载过程涉及到三个函数：componentWillMount - 组件即将挂载、componentDidMount - 组件挂载完成、componentWillUnmount - 组件即将卸载。这些函数都只会在组件初始化或者卸载时运行一次。
组件更新时涉及到四个函数： shouldComponentUpdate - 判断组件是否需要更新、componentWillUpdate - 组件即将更新、componentDidUpdate - 组件完成更新、componentWillReceiveProps - 组件即将接收新的 props。

生命周期整体流程图 - 图片来自于《深入React技术栈》

setState 更是基础的不能再基础的知识了，用来更新组件的状态。需要注意的是 setState 是一个异步方法，一个生命周期内所有的 setState 方法会合并操作。

但是如果把组件的生命周期和 setState 放在一起看就会有一连串的问题：生命周期函数里可以 setState 吗？什么时候 setState 合适呢？阅读完《深入React技术栈》第一和第三章，得出以下心得：

• 在 componentWillMount 中执行 setState 是**无意义的**，应该将这里的 setState 放到初始化 this.state 的地方去（如 constructor）直接作为 state 的初始值。原因是组件只挂载一次，在 componentWillMount 里 setState 会但是仅会更新 state 一次，而且会和 constructor 里的初始化 state 合并执行，因此这是无意义的 setState。
• 在 componentDidMount 中执行 setState 会导致组件在初始化的时候就触发了更新，渲染了两遍，应该尽量避免。有一些场景，比如在组件 DOM 渲染完成后获得DOM元素位置或者宽高等等设置为 state，会不得在 componentDidMount 之后 setState，但是除了这些必要的时候，都应该尽量避免在 componentDidMount 里 setState。
• 在 componentWillUnmount 中执行 setState 不会更新 state，是**不生效而且无意义**的。
• **禁止**在 shouldComponentUpdate 和 componentWillUpdate 中调用 setState，这会造成循环调用，直至耗光浏览器内存后崩溃。了解了生命周期之后，这条很好理解。在 shouldComponentUpdate 或者 componentWillUpdate 里调用 setState 会再次触发这两个函数，然后在两个函数又触发了 setState，然后再次触发这两个函数…… 这样就进入了一个不停 setState 然后不停触发组件更新的死循环里，会导致浏览器内存耗光然后崩溃。[具体分析可以看书的第3章]
• 在 componentDidUpdate 中执行 setState 同样会导致组件刚刚完成更新又要再更新，进入死循环。但是在某些特殊情况下，比如说 state 或者 props 变化触发了 DOM 变化，需要重新获取 DOM 元素宽高时然后更新某个
  state 的时候，就不得不在这个函数里使用 setState 了。此时一定要给 setState 设置一个前提条件（ if (aaa) { setState(bbb) } ），以避免出现循环渲染的问题。 因此，如非必须，**应该尽量避免**在本函数里 setState。
• 在 componentWillReceiveProps 中**可以** setState，不会造成二次渲染。由于只有 props 的变化才会触发 componentWillReceiveProps 事件，因为在这个事件里 setState 不会造成不停触发组件更新的死循环，可以放心在这个函数里 setState。

生命周期函数里 setState 的时机可以总结为以下表格

正则字符串是什么？

这个词是我自己这么叫的，就是可以用字符串来表示的正则。。。一般我们写正则，直接写在两个斜线中间：/这里是正则表达式/

可是你要想写个动态正则，你就得借助字符串来完成了，因为字符串可以动态生成，并且当做参数去构造出正则的对象。但是这个参数直接加双引号变成："/这里是正则表达式/" 这样就可以了吗？

如果去尝试一下，就知道咿~不对。。。为什么不对呢？先来看看escape这个东西吧。

一直对escape这个词有陌生感，因为他的英文是逃避躲开的意思，而程序中它有另一个名字叫做转义。

其实顾名思义，转义就是转换意义的意思，也算式一种避开本身意义的行为吧。那么什么是转义呢？为什么需要转义呢？

因为在特定环境中，字符串中的【某些字符或者字符组合】有某个意义，而希望它表示其他意义的时候，就需要转义了

感觉说了废话，所以上例子：

"Hello "World.""

由于字符串中的两个双引号，和字符串开头和结尾的双引号引起了歧义，所以程序解释器不知道这个字符串合适结束，而你又想表示确确实实看到的这个由这些字符和四个双引号组成的字符时，就需要转义，让解释器明白我只是想表示双引号这个字符而不是它本来的字符串识别符。所以变成下面就可以了：

"Hello \"World.\""

那么对于普通js字符串，可以进行转义的有哪些呢？

所以你想在字符串里使用' " \ 来表示这些字符本来的意义就需要转义成：' " \\ 来让程序解析器正确理解你的意图，原来你只是想表示这些字符本来的意义，而不是表示字符的开始和结束以及转义符。。。。

好了，再说回来我们的正则字符串, 举个例子：
如下匹配任意一个单字符（除了换行符）

/./
/./.exec('abcd')

如果传字符串呢？你会想怎么传？这样？"."

var reg = new RegExp(".")
reg.exec('abcd')

没错，正如你所想没问题，两种写法都是一样的。

可是如果你只想匹配一个.这个本身字符呢？

/\./.exec('abd.ff.')

没错，是这样写，注意这里的.其实是正则表达的转义，在正则里.表示任意单个字符，当你想表示.字符串本身的时候就需要转义成.了，可是这和上面提到的字符串转义什么关系呢？

没有关系。。。

他们是相互独立的转义体系，没有关系，但是当你想用字符串来表示正则表达式的时候它们就产生了联系而已，这也就是为什么在刚开始写正则字符串的时候会懵逼一下的原因吧。。。。那产生了联系怎么写呢？这样吗？

var reg = new RegExp("\.")

你会发现它和下面的是一样的

var reg = new RegExp(".")

并没有只匹配.字符，这是为什么呢？看图

所以这里进行了两次转义才到达你最终的目的的，所以就应该这么写：

var reg = new RegExp("\\.")

字符串"\\."先转义成字符串"\."，然后再作为参数传给正则引擎，自然理解你想要匹配的是.这个字符，而不是任意一个字符了。

感受一个长一点的, 我想匹配这个正则/\.\w\\a/ 它的正则字符串是什么呢？如下：

'\\.\\w\\\\a'

现在在看这堆东西是否清晰了一些呢

我时常感到困惑，为什么有些知识我总是觉得模糊，其实就是想的少，总结的少，大多数人也如此，有疑惑不清楚就找出来，想明白或者想不明白都记录下来自己的收获，比扭头忘记还是要好很多吧。。好我觉得js中的正则我不是很清楚，那么来看一下吧。

首先6这个具象的数字可以帮助我们整体记忆了，666哈哈

范围

js中有两个类可以让正则发挥作用

创建

var re = /ab+c/

方式一：正则表达字面量，这种直接是常量的表示用法可以让js解析器提高性能

var re = new RegExp('ab+c')

方式二：构造函数，这种方式可以在runtime的时候动态确定正则是什么，更加灵活

常用特殊字符

来记忆一些常用特殊字符，这个是正则本身的范畴了，是不是总觉得记不住？其实我也记不住，每次都是去搜索和online验证来完成一些任务。我也困恼过，其实最后还是因为自己写的少吧，唯手熟尔。。。下面的总结不写具体内容，只列出具体特殊字符和分类，可以尝试一下说出他们的意义，我觉得比看表格更有利于记忆。。。

• 匹配量的：* + ? {n} {n,} {n,m} .
• 匹配位置的：^ $
• 匹配并且需要支持分组的时候需要括号来包裹：(匹配的模式)
• 匹配条件的：|
• 匹配集合的：[]
• 匹配非集合的：[^]

还有大量的由\和字母组成的特殊含义的匹配模式，这些用到的时候查询就可以了，没有必要记住，其实我是记不住。。。

例子

例子是最好的老师。。。。
例子来源于MDN

• 我想得到匹配后的数组

var myRe = /d(b+)d/g;
myRe.exec('cdbbdbsdbdbz') // ["dbbd", "bb", index: 1, input: "cdbbdbsdbdbz"]
myRe.exec('cdbbdbsdbdbz') // ["dbd", "b", index: 7, input: "cdbbdbsdbdbz"]
myRe.exec('cdbbdbsdbdbz') // null

注意对于每个正则对象的exec每次调用都只返回一个匹配，如果需要拿到全部匹配就需要while循环获取，循环结束标志是返回值为null

'cdbbdbsdbdbz'.match(/d(b+)d/g) // ["dbbd", "dbd"]
'cdbbdbsdbdbz'.match(/d(b+)d/) // ["dbbd", "bb", index: 1, input: "cdbbdbsdbdbz"]

string的match挺奇怪的，如果是global匹配则出所有匹配的数组，如果不是，则出第一个匹配的字符串，以及相应的捕获内容

• 我想得到是否匹配

var str = 'hello world!';
var result = /^hello/.test(str); // true

• 我只想得到第一次匹配的位置

'cdbbdbsdbdbz'.search(/d(b+)d/) // 1
'xxx'.search(/d(b+)d/) // -1 没有匹配

• 我想按照匹配拆分字符串

var names = 'Harry Trump ;Fred Barney; Helen Rigby ; Bill Abel ;Chris Hand ';
var re = /\s*;\s*/;
var nameList = names.split(re);
// [ "Harry Trump", "Fred Barney", "Helen Rigby", "Bill Abel", "Chris Hand " ]

• 我想按照匹配覆盖字符串

var re = /apples/gi;
var str = 'Apples are round, and apples are juicy.';
var newstr = str.replace(re, 'oranges');
// // oranges are round, and oranges are juicy.

这个replace方法的用法着实比较多，只放了最基础用法，当有需求的时候再查就好了，整体有概念了再实践比强行记忆要好吧~

遇到一个需求，需要实现的样式是固定宽度的容器里一排显示若干个标签，数量不定，每个标签的长度也不定。当到了某个标签不能被完全展示下时则不显示。大致效果如下，标签只显示一排，多了放不下了就不显示了。

标签部分 DOM 结构如下

<div class="labels">
	<span class="label">Cooking</span>
	<span class="label">Coding</span>
	<span class="label">Travel</span>
	<span class="label">Photography</span>
	<span class="label">Reading</span>
</div>

乍一看这个问题很简单嘛，本着样式问题尽量不用 js 解决的原则，写了下面这堆样式，完美实现效果。可以看出来最后两个 .label 由于会超出 .labels 的宽度，被折到了下一行，然后又被 .labels 的 overflow: hidden 隐藏。

.label {
	display: block;
	height: 24px;
	line-height: 24px;
	padding: 0 10px;
	background-color: #e1ecf4;
	border-radius: 12px;
	font-size: 14px;
	flex-shrink: 0; // label 不收缩，长度为内容长度

	& + .label {
		margin-left: 5px;
	}
}

.labels {
	height: 24px; // 一行 label 的高度
	overflow: hidden;
	display: flex;
	flex-wrap: wrap;
	justify-content: flex-start;
}

但是刚高兴没多久，突然发现了问题，如果第一个标签的长度就超出了容器的宽度的话，并不会被整个隐藏，只是内容被截断了，像下面这样

这个问题困扰了我好一阵时间，一直在想 css 里有什么属性可以在子元素宽度超过父容器时把它整个隐藏（而非仅仅隐藏超出父容器的部分）。各种思索都没有结果正准备放弃万分纠结到底用不用 js 实现时，突然冒出来一个想法 既然现在被折行的元素可以被隐藏掉，那让第一个标签也折行不就行了嘛。

那么怎么让第一个标签折行呢，想到一个比较 trick 的方法，让它不再是第一个元素就可以利用 flex 的特性把它折行了~ 于是，在所有 .label 元素之前，添加了一个 .placeholder 元素只有 1px 宽，高度为 100%。
Inspect 元素的话可以看到确实 .placeholder 元素占据了第一行的位置，实现了我们想要的效果~

其实利用这个想法，使用 float 也可以实现同样的效果。虽然有点 trick 并且还是借助了一个额外的 DOM 元素，不过效果还是完美实现了的~ 附上 codepen 链接供参考 https://codepen.io/Simona_Deng/pen/dJvvBR

webpack

As you've described, Webpack is a module bundler, it bundles various module formats primarily so they can be run in a browser. It offers both a CLI and Node API.

webpack-dev-middleware

Webpack Dev Middleware is middleware which can be mounted in an express server to serve the latest compilation of your bundle during development. This uses webpack's Node API in watch mode and instead of outputting to the file system it outputs to memory.

For comparison, you might use something like express.static instead of this middleware in production.
webpack-dev-server

Webpack Dev Server is itself an express server which uses webpack-dev-middleware to serve the latest bundle and additionally handles hot module replacement (HMR) requests for live module updates in the client.

webpack-hot-middleware

Webpack Hot Middleware is an alternative to webpack-dev-server but instead of starting a server itself it allows you to mount it in an existing / custom express server alongside webpack-dev-middleware.

Also...

webpack-hot-server-middleware

Just to confuse things even more, there's also Webpack Hot Server Middleware which is designed to be used alongside webpack-dev-middleware and webpack-hot-middleware to handle hot module replacement of server rendered apps.

copy form here

• webpack本身只负责打包构建

• webpack-dev-server是一个基于express的并使用了webpack-dev-middleware的开发服务器

• webpack-dev-middleware 是一个用来增强express服务器的功能的中间件，它使得：

  • 每次文件编译后不用写入磁盘，直接写入内存等待请求来取
  • 在监听文件变动时，如果还有文件在编译中，则立即停止当前编译而重新编译，如果此时有请求则延长请求时间直到新的编译完成。

• webpack hot middleware是给webpack-dev-middleware用的，进一步增强服务器功能，使得服务器支持热更新

总结就是：webpack-dev-server包含webpack-dev-middleware和webpack-hot-middleware，是一个可以独立使用的开发服务器；webpack-dev-middleware是一个可以和express配合的开发服务器中间件；express + webpack-dev-middleware+ webpack-hot-middleware （webpack-dev-server就是它们集合实现的一种）可以组成一个支持热更新的静态资源开发服务器。

最近simona在面试，一面动不动就问闭包，这个包子啊，好吃么？哈哈，其实吧，很多时候程序员一直用着闭包，也知道有这么回事儿，可是有时候用语言去表达也是醉醉的。。。。所以，叙述不出来没事儿，也不代表能力，抽个空，总结一下也就完事儿了，是吧？so，让我们来吃掉这个包子~

好的，开始认知:

• 是什么

闭包是指有权访问另一个函数作用域中的变量的函数（红宝书如是说）

• 怎么创建

在一个函数内部创建另一函数 （红宝书如是说）

• 有什么用

函数执行完后，让函数的内部变量不被当做垃圾收回的一种手段 （我自己如是瞎说哈哈）

好了，就这么些东西，好像不是很好吃啊，干巴巴的。。。那我们就深入一些，把包子馅给吃掉吧~

• 函数就是程序执行的一个提前写好的计划清单：plan
• 要开始做这个计划就需要在plan上写上我的计划需要的东西，例如我们要计算今天的花费：
  • 早餐=5元
  • 中餐=15元
  • 晚餐=借的别人的钱
• 由于我要借别人的钱，所以别人的plan要先执行，我才能借
• 但是plan执行有个规则，就是plan执行完之后会把执行的内容所要求准备的钱都清空，为什么呢？钱都花了，当然没了呗。。。如果再执行这个plan就得再准备新的钱了
• 好了，我们来开始这个执行过程：
• A的 plan：早餐=5元；中餐=10元；晚餐=15元；可借别人的钱=10元；
• B的 plan：早餐=5元；中餐=15元；晚餐=A可以借的钱
• 情况1：A plan执行完，A吃饱了，然后A中所有准别的钱都清空了， 然后B plan再执行，发现晚餐的钱被清空了。。。。。哭。。。晚上只能饿肚子了。。
• 情况2：A plan执行完，A吃饱了，然后正当A中所有的钱要被清空的时候，B说等等，让我先拿到你借我的钱你再清空，然后B执行的时候就拿到了A可以借的钱。

这翻译成程序就是：

// 情况1
function Aplan() {
  var 早餐=5；
  var 中餐=10；
  var 晚餐=15；
  var 借钱=10；
}
function Bplan() {
  var 早餐=5；
  var 中餐=15；
  var 晚餐=借钱；
}
Aplan();
Bplan();

Aplan和Bplan现在各自独立，所以B的晚餐是找不到的。

// 情况2
function Aplan() {
  var 早餐=5；
  var 中餐=10；
  var 晚餐=15；
  var 借钱=10；
  function Bplan() {
    var 早餐=5；
    var 中餐=15；
    var 晚餐=借钱；
  }
  Bplan();
}
Aplan();

这次能借到钱了。。。执行完后A和B的plan的钱也就清空了。但是我们如果有这么个需求，就是凭什么A来决定整个计划的实施时间啊，A花钱的时候B并不想花钱啊。。。可是B想借A的钱啊，可是A花完钱就不管不顾的把准备借B的钱也清空了啊。。。怎么办呢？

没错，利用闭包来达到这个目的。

// B的命运自己掌握
function Aplan() {
  var 早餐=5；
  var 中餐=10；
  var 晚餐=15；
  var 借钱=10；
  return function Bplan() {
    var 早餐=5；
    var 中餐=15；
    var 晚餐=借钱；
  }
}
var Bplan = Aplan();
// 好了，B想什么时候执行都行
Bplan();

为什么这个B可以拿到钱了呢，A执行完不是清空了么，是的，A执行完的时候清空了早中晚餐的钱，然后又想清空借的钱，可是它发现你妹的B已经把钱借走了啊，那好吧，钱放在那里等B执行完的时候再清空吧。

简单来说，就是B函数引用了A函数的变量。这个例子可能不太好，但是简单说明了闭包是什么，就是例子中的Bplan啊哈哈。

再学术的总结一下，闭包是指有权访问另一个函数作用域中的变量的函数。利用闭包的特点，我们可以让闭包持有外部作用域的变量而不释放，到达组织垃圾回收或者延迟垃圾回收的目的。所以呢情况2下最好最后加一句：

Bplan = null;

取消对闭包引用，进而取消闭包所引用的它的外部作用域的变量，达到让垃圾回收车主动回收掉不再使用的内存的目的。节约空间呗~