买车已 3 月有余，适逢中秋，天气也算凉爽，于是临时开始做起了自驾游的攻略。
与平时出去玩不同，自驾游更像是一种随性的选择。明天要哪儿、中间时间怎么安排、在哪里吃、住哪里都是浑然没有安排的。
走到哪儿算哪儿，快到地点时找饭店，吃饭时候看攻略，下午五六点才预定酒店也算是这几天的常态了。

出发前

物资

出发的前一天，临时在盒马囤了 300 多的物资和小零食，基本上是感觉啥有用就买啥。

现在来看其实还是买多了，大约有一半都没有用上或者吃掉（特别是自热火锅/米饭，在当地有美食的情况下真的完全不会打开）

如果再来一次，我可能会着重囤一些水果、没有刺激味道且不是汤汤水水的小零食，一次性的内裤、袜子方便换洗等。

补能

我的车子是增程式的混动车，支持 180km 的纯电续航与 800 km 左右的纯油续航。

出发前去了一趟家门口的中石化加油中，加满了油后又去充电站把电池充到了 95%。满油满电折合 1000+km 的续航，安全感满满的。

回来之后重新补满了

路线图

因为之前有买过江浙沪的自驾路书，所以这次也派上了用场，最终选择了环清凉峰的路线。考虑到整体行程 160km 左右（到达龙岗收费站后）。时间也适宜，就出发了。

只是没有想到，最终这种路书地图，我们只用到了半张图。

收费攻略，隐藏了本次无关的路线，有需要请自行购买。

视频攻略

点击查看【bilibili】

Bilibili 图片

Day 1 杭州 - 临安大明山清凉峰

出发

早起，在收拾完行李后，打开导航看了一眼，果不其然路上开始堵车了。中秋的第一天，看起来大家都想出去玩儿。

尽管心里早有准备，但一路上的堵车情况还是超出了我们的预期。原计划 1 小时就能抵达的收费站，最终花费了接近两小时才到达。中间高速有一段路全程都是 20 码的在开。

景观

抵达龙岗收费站后，我们马不停蹄的前往今天的第一个景观：石浪。

石浪景观本身是不收费的，入口也比较隐蔽，如果没有路书提示我们应该会直接错过。

石浪景观

此处风景我觉得一般，可能是对这么多大石头无感吧 XD，也有可能是因为当天下午天气还是比较晒的状态，在山上走着还是挺热的，也缺了观赏风景的心。

站在山上的观景亭，能看到远处的华光潭大桥，桥底的水是碧绿的，反而挺好看。

华光潭大桥

稍作休息后，跨过华光潭大桥后去了兔川悬索桥。在华光潭大桥建起来之前，当地人民都是走兔川悬索桥过河的。

这也是我当天非常满意的景点（未开发，看路书攻略找的），风很大，桥两边的水也很清澈，吹着很舒服但也带着一丝惶恐，生怕掉下去，所以走了一半就回头了。

继续往前开，路边有一条溪流，因为过往天气热的原因，河里水流不多，河床裸露。
女朋友提议下去玩水，考虑了一下不影响今天的行程（虽然那时候我还不知道住哪儿），就下去游玩了。

可惜的是出门匆忙，只准备了一把椅子，我只能在边上的石头上站着。

盘山公路

再往上走，就是一段二十多公里的盘山公路，华浪线。山路比较陡，弯也多，但公路是新修缮的，整体体验非常不错。

自驾时导航的路线图

山顶的风景

观景台

随后顺着盘山公路下山，抵达石长城景区，当时天色已经快黑了所以没有进去游玩，短暂的歇息了一会儿。

歇息的时候，吃了根香蕉，看着对面的人家在处理新鲜摘下来的山核桃，才知道原来核桃剥壳都是机械化的。

不得不说的是，在临安自驾的路上，真的是全员都在搞山核桃，太夸张了。事后也了解到，山核桃的树不是随便采摘的，而是村民自己种的。

前往大明山 & 入住

在歇息的片刻，我们定下了当晚的酒店，大明春天。

这是一个路书视频上推荐的酒店，在携程上预定要 360，电话问老板有没有别的渠道预定时则反馈还有去哪儿，只需要 260，感觉自己省下了一百多。

大明山入口

开车到民宿附近，整个一片都是做民宿相关的，当然家家户户也在搞着山核桃。简单办理了入住，酒店条件一般，但也还行（毕竟景区）。

想着都到山里了，那么去吃点农家乐，结果一连找了几家餐馆，都反应接待不过来。最后找的一家，也是等了一个多小时才上的菜。
问老板，说参观一般都没有厨师，都是夫妻店。加上近期受疫情影响，又是旅游淡季，餐馆一般没有怎么备菜，所以招待不过来。

山里的小河

而后就是简单的休息了，因为是山里，虫子很多，这点体验很糟糕。晚上实在受不了下去找前台要了点蚊香，点起来后又熏得睡不着，属实是进退两难。
最后实在是没有办法了，把酒店的纱窗打开，蚊香移到阳台，静静呆了十几分钟后呼吸到山里的新鲜空气后，才安然睡去。

如果下次出游，还是尽可能选标准的酒店吧，至少能睡个好觉。

旅程轨迹

Day 2 临安 - 婺源晒秋 & 上饶

上午起来，吃了酒店的提供的早餐。虽然就是简单的稀饭 + 玉米、鸡蛋、饼之类的食物，但粥刚好温凉，喝起来格外的惬意。

在昨晚睡前，我们考虑是要去千岛湖还是继续原路线走山路。但女朋友很明确的表达不想再跑山路了，莫得意思。于是我在观察地图后，提出了新的地点：婺源。

洗好水果，备好车车，我们就准备出发了。

婺源

我们选择的是婺源的篁岭景区。从临安大明山出发，单程 2 小时左右。
不知道是线路本身就比较空，还是因为当天是中秋假期第二天的缘故，道路上格外的空，一路上都看不见几辆车。和女朋友两个人换着开，一人一个小时，很快就到了。

中途还下错了服务区，和高速的工作人员说明了情况希望掉头返回，他还给我们指明了路线，让我们原地掉头重新上了高数，没有浪费一分钟的时间。

到达婺源后选了大众点评排名第一的餐馆吃了午餐，价格还是略贵的， ￥198，但是味道也算对得起这个价格，很下饭。

在进景区之前，买了两顶草帽，确认上饶户口优惠政策已经结束了，就买票坐索道上去了。

篁岭是一个很大的景区，这种大并不是来自于平面面积，而是立体的体积。

晒秋

晒秋

回家

在看完篁岭经典的晒秋场景后，我们选择前往上饶的家。

虽说信州区和婺源都同属上饶，但两个地方实际上相隔挺远，开车下来也有一百多公里，接近两小时的车程了。

到上饶市区后，选择去商场买点补给。原本看到楼下停车场有充电桩还挺惊喜的，结果全部都不能用。

结束补给后，找到了一家还在营业的洗车店，惊喜的是洗车店的工作人员里里外外洗的非常干净（应该是我洗这么多次车以来最干净的一次了），可惜没有拍照片。

又是一路狂奔，回老家的路因为修路的原因，导航给我导到了一条从未开过的村道上，一路上开的怀疑人生。而后半段好不容易回到了大路，路边的路灯暗的简直没法看，对向一直有来车也不能一直开远光，胆战心惊的。

到家之后，见过爸妈，苗苗小朋友很是开心，一个劲的在玩滑滑梯，停不下来。

再晚一点，稍作收拾后，我们就继续休息了。天气还是很热，住的三楼没有空调，当晚也是辗转反侧过好久才睡着。

旅程轨迹

Day 3 家 - 千岛湖

第二天一早，回家看望了爷爷奶奶，吃过了午饭后，因为昨晚的闷热，选择午休过后再出发。

出发上高速前，感觉油量可能有不足的风险，所以选择在当地的加油站加满了油，花费 ￥315，我继续出发前往下一个目的地了。

千岛湖

起初我们是准备去横店的。因为恰好顺路，在横店游玩一天后直接返回杭州也不会很累。但在中途一直在搜索横店的攻略和门票，没有找到合适的。

恰好在高速路上，我们路过了一个路口，右转可以去千岛湖。于是我就想着要不去千岛湖吧。虽然女朋友不太理解，但我们依然在下一个路口下了高速，途径龙游出发去了千岛湖。

在服务区时，我想起之前好像囤过一张千岛湖的酒店券，正好这次就用上了。

入住的房间，很大

晚上人有点不舒服，或许是因为昨晚没睡好的缘故有些偏头痛，买了散列痛后吃了一片，感觉好些就出去觅食了。

千岛湖这边是没有什么夜生活的，基本上一到酒店饭店就都关门了，我因为人不舒服，拖到九点半才去找到一家馆子吃的晚饭。

馆子比较小，但胜在味道不错，名字叫“胖子饭馆”，有兴趣的同学下次可以去试试，价格也还算经济实惠。

回酒店后，玩了一会儿水，就稍作休息了。

当日路程

Day 4 千岛湖环湖 - 杭州

一大早起来，房间内设施出了点故障，和相关经理反馈不愉快后，一通沟通之后决定退费一半，想了一下也还行，就决定出发继续自驾游之旅。

当天的安排还是比较明确的，下午出发去环千岛湖自驾游，结束后上高速回杭州，只是当天的天气预报通知我杭州即将有台风，所以我们想加快速度。

千岛湖整个自驾游路线 135km，我们使用的是趣兜风的 App，导航的过程中还附带讲解（收费），旅途过程中也不觉得那么单调。

出发过程中，路过三谭驿站，走过上江埠大桥，我也就抵达到了今天的第一个目的地，下姜村。起初只是想吃顿饭，但最终没有想到是此次环湖自驾游中，呆的最久的地方。

下姜村

餐厅

下姜村不大，但是很漂亮，整个村子的给我的感觉就是非常平和，舒缓，大家都有自己的节奏和自己的生活。而我在过桥后，与茶室里的阿姨一起聊了半个多小时，喝了几杯茶，也感觉到自己确实在放松。

环湖游的其它景点

后面有陆续去了芹川古村与文渊狮城，听着车里 App 的介绍，才知道原来为了建立新安江水库，是淹了上千个村庄的。

在游玩的路上还能看到亚运会的福娃和提示牌。

因为在一些景点上耽搁的有些久，因此我们也加快了脚步，开始往回赶。

返程

返程的前半段还算顺利，路上车不多，天也没有完全黑下来。而到了后半段，天黑 + 台风 + 高速路前方偶发的事故使得开车变得异常艰难。

在和女朋友商量过后，我们决定从最近的出口下高速，走国道回去。国道反而开起来比高速要顺畅许多，车不多，照明条件也好。

折腾了将近两小时后，我也终于开车回到了家，在家门口的加油站补满了油，想看看本次行程的总开销。

一共加了 307 元。

行程总结

这是我第一次出行自驾，出门前没想到会在外面开这么久，这么远。

里程

车辆统计一共行驶了 1169.7km。

能耗

按上图来看，平均能耗 3.2kwh + 5.4L，约等于 6.3L 每百公里。

按实际加油充电情况，整个过程中共加了 622 元的油，中间有补充过一次电，大约 30 元，整体算下来就是 652 元的用车成本。

按 95# 汽油均价 8.92 来算，折合百公里用油 6.2L 左右，一公里 0.55 左右。整体与车载油耗表接近，我个人对这个能耗也表示满意。毕竟中间有山路、高速、国道等复杂的驾驶场景。

结语

穿行于山林之间，感受山谷湿润的空气，享受与家人团聚的时刻，沉浸在下姜“世外桃源”般的场景中。我想，在那一刻，我是放松且自由的。

晚上在看 Deno Deploy 官网介绍时，脑海里突然蹦出了一句话：“Web 框架不是答案”。

我个人目前是 Node.js Web 框架 Midway 的开发者，日常也会造一些小轮子自娱自乐，我很清楚的知道 Web 框架在现代 Web 开发下的不可替代性与企业级应用下所产生的效用。但今天我却想说，Web 框架不是答案。

在恢弘的巨型软件工程中，我可能会惊讶于在框架的约束与规则下，这个项目仍然得以继续开发，而不是凌乱不堪难以维护。但巨石应用终究还是离大部分普通开发者太远了，这时候 Web 框架所设立的一系列有利于后续维护的规则，此时都会变成约束。

“世间安得两全法，不负如来不负卿”。这句话也适用于 Web 框架开发者的我。

从那段代码开始

这是 Deno Deploy 官网上，那段给我带来灵感的代码：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

import { serve } from "https://deno.land/std@0.114.0/http/server.ts";
import { h, ssr, tw } from "https://crux.land/nanossr@0.0.1";

const Hello = (props) => (
  <div class={tw`bg-white flex h-screen`}>
    <h1 class={tw`text-5xl text-gray-600 m-auto mt-20`}>
      Hello {props.name}!
    </h1>
  </div>
);

console.log("Listening on http://localhost:8000");
await serve((req) => {
  const url = new URL(req.url);
  const name = url.searchParams.get("name") ?? "world";
  return ssr(() => <Hello name={name} />);
});

代码很简单，在模块中，我们通过监听 Http 事件，调用 nanossr 渲染出 Html 并返回给客户端。
整个渲染流程看起来非常的清晰且简洁，代码是无状态的，输入输出也很确定，只要有足够多的容器，它在云上也可以以非常快的速度扩容并支撑服务。

而如果使用框架，以 Midway Hooks 为例（伪代码），用户代码是这样的。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22

import { Api, Get, useContext, run } from '@midwayjs/hooks'
import { h, ssr, tw } from "https://crux.land/nanossr@0.0.1";

const Hello = (props) => (
  <div class={tw`bg-white flex h-screen`}>
    <h1 class={tw`text-5xl text-gray-600 m-auto mt-20`}>
      Hello {props.name}!
    </h1>
  </div>
);

const api = Api(
  Get('/'),
  async () => {
    const { query } = useContext()
    const name = query.name ?? "world"; 
    return ssr(() => <Hello name={name} />);
  }
)

await run(api)
console.log("Listening on http://localhost:8000");

在这之前，我会认为上面这种纯函数的代码是简单的，不足以覆盖后续迭代场景的，用哲学一点的说法就是，这种开发方式是不具备发展的眼光的与可持续性的。

但现在我觉得，或许一些简单的 Api 开发，就是应该这么简单的，只是写两行胶水代码，聚合后端 Api，又或者是渲染一段模版，此时框架设计是显得过重的。

此时再来重新思考，之前的我会觉得让每个可能场景都用上我的框架会是正确的答案。但现在我觉得，在简单的场景下，简单的框架或无框架的服务才是正确的。使用复杂的框架容易使用户代码出现过度设计与提早优化，从而适得其反。

自问自答

Q：你是做框架的，为什么突然出来唱反调，说起 “Web 框架不是答案”了？
A：正因为我是做框架的，所以我对框架的适用范围，用户遇到的问题理解的更为深刻一些，但也因为屁股思维，所以做事情都是朝着框架去的。而简单框架和无框架意味着更透明的使用方式，更低的心智负担。且“Web 框架不是答案”是我今晚在读代码时产生的灵感，给我打开了一个新的方向，所以我给它配了一篇文章。这不是唱反调，这是对思路的补充。

Q：简单框架或无框架开发模式下，代码架构、开发范式、可维护性都是问题，你怎么解决？
A：不解决。我认为开发人员在使用 Web 框架时，容易存在两大误区。a. 什么都想用框架实现，过度优化与提前设计 b. 不用框架，后续维护不过来了只能重构。建议开发者在第一时间就想好自己的功能要不要用框架，实在不行就重构吧（毕竟架构师都是一遍一遍的重构出来的）。

Q：后续有什么落地的 Action 吗？
A：会有。后续我将尝试简单框架或无框架的设计，尝试将 Web Api 开发的心智负担下降到尽可能的低。目标不是消灭框架，而是让开发者在使用时觉得简单且可信赖。

Q：这么做的价值在哪里？
A：简单框架和无框架的价值需要通过配套的平台 & 基建体现出来，单独拎出来说事情是不公平的。强大的基建 + 易用的平台 + 低心智负担的开发方式，配合极速启动 + 保存代码即上线等特性，开发者可以放心的开发和部署功能。BTW，我也觉得对一个初生的想法或者灵感询问价值，是会带来非常大压力的。

Q：现阶段有实际的产物吗？
A：就是这篇文章，梳理思路 & 阐述个人观点。

Q：这个过程中你觉得可能会遇到什么问题？
A：克制与做减法。框架设计随着时间迭代与功能完善，总是会做的越来越复杂，最终达到用户难以理解全貌，框架由开发者的工具转变为了开发者心中的黑匣子。所以我觉得在后续过程中，最难的问题不是我要加什么功能，而是知道我不要什么功能，我给用户提供的究竟是什么？能不能用一句话描述并概括出来。

Q：没看懂你想说什么和想做什么
A：正常，深夜灵感 + 随笔，只是描述个人的看法而已。

Midway 3.0

首先将给大家介绍的是 Midway 3.0 的相关内容。
​

3.0 版本发布

去年的秋季发布会时，我们介绍了 Midway 3.X 预览版本中的新功能。
​

而在这几个月中，我们一直在对 Midway 3.X 的功能进行迭代与完善，并且不断有同学通过微信、钉钉、Issue 等渠道来关注我们 3.X 的进度。
​

而在本次冬季直面会中，我们非常高兴的告诉大家，在 2022.01.20 这天，Midway 3.0 正式发布了，相关新功能可以参考：Midway v3 新功能预览。
​

官网支持多版本文档

我们也对 Midway 的官网进行了更新。在新版本中，我们支持了多版本的文档，大家可以在网页右上角切换版本来查阅相关文档。
​

Midway 3.0 发布了，官网文档默认以 3.0 为主。
​

技术栈明确

在 3.0 发布后，Midway 在不同场景的技术栈也愈发明确。
​

第一部分是标准项目，使用 Class + IoC 的技术栈，来承载传统 Node.js Web 项目的开发。
第二部分是 Serverless 项目，我们支持了阿里云 / 腾讯云等云厂商，同时我们也在积极接入 KNative 原生的基建。
第三部分是一体化部分，是从传统的 Node.js Web 工程孵化出的创新模式。它主要支持前后端一体化融合的开发方式，并且在前后端都使用了函数式去进行开发，去给大家带去一个不同的体验。今天也将在后面发布 Midway 一体化 3.0 的相关内容。
​

感谢参与开源

同时在过去的一年中，我们发现有很多的小伙伴给我们提交过 PR，非常感谢这些同学。我们深知，所有的开源项目，不论大小都是从一点一滴开始做起的。
​

为了感谢这些给我们提交 PR 的同学，我们也准备了一些精美礼品，如果大家在 2021.01.01 - 2021.12.31 期间有给 Midway 提交过 PR，欢迎扫码或访问 礼品问卷 提交信息，我们将及时寄出礼品。
​

信息同步

在接下来的一段时间，我们会主要完成以下三件事情：

• 提供 Egg 模版
• 【年后】提供 Open telemetry 的集成方案
• 【年后】阿里内部版本同步

​

一体化 3.0

在本次直面会中，我们也将为大家带来全新的一体化 3.0 内容。
​

Midway 一体化 2.0 于 2021 年的 3 月份发布，截止至发布会当日已经有差不多 9 个月，这段时间我们一方面是在内部做了大规模的落地实践，同时我们也在不断的探索，去研究社区的新方案，思考一体化未来的演讲方向。
​

在经过 9 个月的探索后，我们决定推出全新的一体化 3.0 版本，包含新语法、新路由设计、新全栈套件三部分功能。
​

现状

Midway 一体化方案的想法诞生于 2020 年的 2 月份，并于同年的 4 月份在内部正式发布。
​

截止至发布会当日（2021.01），目前已经有超过 2800 个应用是基于 Midway 一体化方案开发的，目前一体化也已成为了阿里前端的主流研发模式之一。
​

新语法

一体化 3.0 的首要革新在于 API 语法。

上图是 2.X 版本的语法，在 2.X 版本中，我们通过 函数即接口、“零”API 调用、文件系统路由三个理念设计了整套语法。
​

在 2.0 的语法中，我们牺牲一定的功能性，换取接口开发的便利性。以 Http Method 为例，上述的接口实际上只能描述出 Get / Post 两种 Method，对于 Put / Delete 等支持则无能为力。
​

3.0 语法

在 3.0 中，我们则重新设计了整套语法，在保留函数即接口、“零”API 调用的特性之上，全面增强了功能性。

一个 API 接口由以下部分组成：

• Api()：定义接口函数
  • Get(path?: string)：指定 Http 触发器，此处指定请求方法为 GET
  • Query<{ page: string }>()：操作符，声明前端传参或执行自定义逻辑
  • Handler: async (...args: any[]) => { ... }：用户逻辑，处理请求并返回结果

​

同时我们也支持了“零”API 调用的特性，你依然可以在前端直接导入函数并调用，我们的 SDK 会自动将你的请求转换为正确的格式。
​

Http 触发器

得益于新的语法设计，我们支持了全系列的 Http 触发器，同时也支持用户指定路径。

新功能下，对于类似 OAuth2 的场景是非常有用的，你可以非常方便的指定接口地址，并完成认证逻辑的开发。
​

更多触发器的支持

在新语法的加持下，我们也实现了更多触发器的支持，如上图展示的定时器、OSS 回调等，在 3.0 中都可以非常容易的实现。

操作符

操作符（Operator）的设计是一体化 3.0 的核心，我们通过操作符的使用、组合来拓展 Api 的功能。
​

操作符一共支持以下 3 种功能：

• 声明：声明前端传参的类型，如 Query/Params/Header
• 定义：定义函数元信息，如 Middleware
• 执行：控制函数执行流程，如 Validate/HttpCode/Redirect

​

我们在上图中提供了一个复杂的例子，如果在传统的一体化中，要实现上述的功能会将逻辑写的非常复杂，容易出现面条式的代码。而在 3.0 中，你通过操作符的组合就可以实现了。
​

同时，我们依旧保留了简洁的“零”API 调用。
​

Request & Response

我们提供了一系列的内置操作符，来帮助开发者快速完成常见功能的开发。
​

以 Request 操作符为例，你可以通过 Query / Params / Headers 操作符来声明前端需要传入的类型，在使用“零”API 调用时，我们会将其转换为正确的结构体。
​

我们也提供了 Response 相关的操作符。
​

Middleware

我们也支持使用 Middleware 操作符来定义中间件。

Validate & ValidateHttp

参数校验是我们在 3.0 中着重实现的功能，其中一体化默认使用 Zod 作为校验库。你可以通过 Validate(...schemas) 来校验用户入参，如上图所示。

这是一种非常自由的用法，当你不使用 Validate 校验器时，你实现了静态类型安全，前后端基于 TypeScript 的类型系统，确保安全性。
​

而当你使用 Validate 校验器时，你实现了运行时安全，在不损失前后端调用体验的同时，校验器会校验用户入参是否正确。
​

如上图所示，同时我们也支持了 Http 结构的校验，
​

基于 Zod 对 TypeScript 的良好支持，你可以在编写 Schema 时直接获得推导的类型。
​

Prisma ORM

Prisma 是为 Node.js & TypeScript 而生的 ORM。简单来说就是，你可以通过编写数据库的 Schema（也可以基于当前数据库结构自动生成），来自动生成 ORM Client。
​

因为 ORM 是生成的，因此无需用户手动定义 Model，并可以获得完善的 TypeScript 支持。
​

基于 Prisma 的特性与 Validate 校验器，我们可以实现类型安全 + 运行时安全的方案。
​

这个方案成本足够的低，不仅在编程时通过静态的类型信息确保安全性，也通过校验器在运行时保障安全性，并且带来了极其流畅的开发体验，前后端全链路紧密的联系在一起。

新路由

在 3.0 中，我们也设计了全新的路由机制。
​

2.X - 文件路由机制

在 2.X 版本中，我们使用文件路由来作为默认的路由机制，文件系统路由是基于约定的，易于理解，但也存在强依赖于文件系统、规则较多的问题。

API 路由

在 3.0 中，我们极大的简化了整体的路由机制，分为以下两种策略：

• 不指定路径：使用函数名 / 文件名（默认导出的情况下）来生成路由
• 指定路径：使用指定的路径，支持动态传入 Params 的情况

  新全栈套件

  在 3.0 版本中，我们也提供了全新的全栈套件。
  ​

2.X - 全栈工程

在 2.0 版本中，我们更多的是将 Vite 和 Midway 拼接了起来，如上图的项目目录 & npm scripts 所示。
​

3.0 - 全栈套件

在 3.0 中，我们开发了新的全栈套件，提供统一的 dev/start/build & 工程配置功能，来简化用户的学习成本和认知成本。
​

新请求 SDK

我们还开发了新的请求客户端 @midwayjs/rpc，作为“零”API 调用默认的请求客户端。
​

新的请求客户端对于原版本（基于 axios），体积减少了 64%（5.6kb -> 2kb），且支持 Browser & Node.js 环境，并且支持了配置中间件、替换请求客户端等新功能。
​

上图是支持的配置项。
​

自定义的请求客户端

如上图所示，我们可以非常方便的替换为自己的请求客户端。
​

请求中间件

我们参考 Koa 的洋葱机制实现了请求客户端的中间件，可以实现打印日志、统一错误处理等非常多实用的功能。
​

前端构建器

在 3.0 中，我们基于 unplugin ，提供了 Vite / Webpack 的插件，用于快速接入前端工程。相比于 2.X 的接入方式，3.0 可以实现一行代码接入的效果。

预览

目前一体化 3.0 已对外发布预览版，文档、试用可以访问我们的官网：https://midwayjs.org/，也欢迎大家提交反馈。
​

开源

年初的时候，Trott 提名我成为了 Node.js Core Collaborator（就是下图）。



这个其实主要与 2020 年年末阶段的工作有关，那段时间内，因为想深入学习 Node.js & 融入开源社区，于是选择了给 Node.js 提交 PR 的方式。那段时间基本上每天晚上都在忙活，每晚也都有 1-2 个 PR 产出（修复 BUG & 补充单测为主）。
​

简单，充实，快乐。于是也顺利的在 2021 年的年初获得了提名，也算是为全年开了个好头。

英语

2021.01 - 04，因为参与开源社区的原因，便主动的自学起了英语，主要以练口语为主（之前都是哑巴英语，简单的对话都不敢进行），辅以一点点的英文材料学习。
​

个人主要是通过 Cambly 这个网站去学习英语的，之前也有朋友在朋友圈推荐过，我使用过后觉得确实很不错，于是也推荐给了我的朋友们。
​

这个网站的特点在于，可以寻找不同的外教，我个人的话是基本上每次都找不同的外教上课，聊天。很开心的是聊过天的外教都觉得我讲的还行，大部分情况下还能听懂，就是发音有些不太标准，需要多加练习。


最后也尝试在真实的语境下与老外进行了交流，感觉挺好，物超所值。

晋升

在 4 月底时，我被通知获得了晋升 P7 的提名。
​

我是 18 年校招加入阿里的，19 年晋升了 P6，在晋升的当时给自己定的目标就是 3 年升 7 。还记得晋升 P6 的当天，老板给我通知结果，我还很认真的问了 P7 的要求是什么，该怎么达到。
​

接下来在 5-6 月份，就是在忙活准备晋升材料的事情，今年晋升的形式和以往做 PPT 的方式不太一样，改成了写文字稿，于是又来回倒腾了一段时间。
​

7 月底，主管公布了晋升的结果，我晋升 P7 通过。之后的那几天，我走在路上时常会有一种不真实感，3 年升 7 曾一度而言，对我是个遥不可及的目标，而我如今确确实实的实现了。
​

嘛，还是要感谢这一路上帮助过我的所有人，ღ( ´･ᴗ･` )比心！

健身

我是一个胖子，一直都是。
​

我也想减肥，一直都想。只是之前要么停留在想，要么总是中途失败。


之后有一天，朋友通知我说要结婚了，送上恭喜的同时，也在心里震惊同龄人已经要结婚完成人生大事了，而我还是一个死肥宅（降不下来的那种）。
​

于是这次下定决心，要调整体重。从饮食开始，到寻找专业的健身教练（真的很重要！之前找过一次不专业的导致我直接不敢去健身房），再到和同事互相约健身，成为健身房的常客，只花了 3 个月。
​

下面是我的体重变化曲线。s



当然，现在又胖回来了~
​

不过不再焦虑了，这次感觉在饮食方面还存在非常非常非常大的改进空间，之前健身期的饮食感觉要么不规律，要么营养配比不均衡，争取在新的一年继续试试看吧~

恋爱

在瘦下来后，真的会遇见春天。
​

而和女朋友认识的经历也颇为神奇，神奇到让我觉得这就是天意。
​

在遇见她的前一周，我去了一趟法喜寺，为自己的姻缘祈福 🙏🏻。在离开寺庙时，看见门口的牌匾上写着四个大字：“莫向外求”。
​

而在一周后，我在微信搜索关键字时，发现能搜到之前的“摇号相亲群”，而我早在八月份就退出了。好奇的我点了进去，发现不能说话，但是能加好友，也能看群里的文档。于是试着加了女朋友的微信，发现也能加上，聊了几句后对方也觉得不可思议。
​

再然后，就很快很快的在一起了 ❤️，超甜的那种！
​

买房

2020 年 10 月份，我动了买房安居的念头。
​

主要是有以下几点原因

• 不想租房，不想被涨房租，想要稳稳的幸福
• 想用上自己喜欢的家电，提升生活质量
• 投资 & 保值

​

但杭州的二手房一直很贵，并且 2020.10 -> 2021.05 这段时间，房子每天都在涨价，我整个人也是非常恐慌的状态。因为定不下来，就得考虑换城市的事情，甚至一度还在长沙缴纳了几个月的社保。后续因为购房政策的原因（杭州 30 岁单身非人才以下不得参与红盘摇号），也放弃了很多。
​

2021 年的 11 月，我使用了人才证参与了新一轮红盘摇号，这也是我的第五次摇号，这次很幸运的中签了。回溯起当时的心情，应该就俩字，开心。
​

随后的两天请了年假，忙忙碌碌的走完了买房，选车位，签合同，付首付等一系列事情。当付完首付后看着银行卡里所有积蓄一扫而空的状态，就感觉：“嗯，当有今日”。


也是从买房后，真切的感受到人生在加速，并且是以极快的加速度在前进。

摇到号当天女朋友给送的花

年度好书

今年读到的年度好书是：《被讨厌的勇气》。
​

读完之后感觉整个人的心灵得到了解放，我又可以重新做回我自己，果敢的做决定，不再内疚、后悔、患得患失。
​

年度设备

今年不出意外的也购入了很多电子设备和小家电。从中选出了我很喜欢的几件。

1. 文石 Boox Poke 3 电纸书
   1. 尺寸完美，可以塞进口袋里，基于安卓，可以安装微信读书，性能强续航长。我从买来后阅读了很多之前在手机上不会去读的书籍
2. 小米 4 件套洗碗机
   1. 再也不洗碗，吃得开心
3. 小浪即热 TDS 上水器
   1. 可以用 20L 的水桶，不用频繁换水，随时随地喝热水幸福感 Max
4. Macbook Pro 13寸 M1 版
   1. 性能强，轻，续航长，各方面都接近完美的一台笔记本，也是我第一台全新的电脑（终于不捡二手了）

演讲 & 文章 & 视频

2021 年我做了很多场分享。

• 【03.06】Node.js 地下铁#10 ——《Midway Hooks — 更具生产力的全栈框架：全栈、“零” API、Hooks 开发后端》
• 【03.25】Midway.js 春季直面会 —— Midway Hooks 2.0
• 【05.23】Node.js 地下铁#11 ——《 Node.js & Midway.js 源码贡献指北》
• 【07.24】Dev Meetup 前端技术巡回沙龙上海站——《渐进式的 Web 框架: Midway.js 的设计与思考》
• 【08.11】Midway.js 夏季直面会 —— Midway Hooks 2.0 + 小程序
• 【10.19 - 10.22】云栖大会——云端一体研发模式工作坊
• 【11.15】前端练习生计划——师兄师姐分享
• 【12.05】深圳 GMTC —— 跨云 & 跨端——小程序云开发一体化方案
• 【12.19】杭州 D2 前端论坛——《Node.js Web 框架再进化，面向前端与未来标准》
• 【12.26】前端早早聊——《探索面向未来标准的 Node.js Web 框架》

​

也写过一些文章。

• net 模块，参数传错就进程崩溃
• Jamstack ，你真的了解它吗？
• 程序员最重要的能力是什么？
• 从文科生到前端专家 - 在转行时我想过的问题
• 还有一些文章在内部，就不提了……

​

也参与录制了一段视频。

其它

生活里还有其他许多值得纪念的事情。

百年校庆

2021.06 川西自驾游（真的好好看，下次还来）

25 岁生日，我心目中的成年日（年轻人的第一个生日蛋糕）

新电脑

第一场音乐交响会

阿里三周年

陈老板的婚礼 & 家园红包

全程负责的《前端修炼小册》

喜提家里的第一辆车

表白的花花

音乐节

2022

2022 年才刚开始，新的主题我也已经想好了（先保密）。
​

希望在新的一年：

• 培养正确的饮食习惯，继续健身
• 拿到驾照（21 年报名了，但是因为懒一直没有去成，但是又很想开车自驾游 OTZ）
• 工作顺利
• 多参与开源，希望能做出自己满意 & 社区喜欢的作品

​

新的一年，继续大步向前~

演讲录音转文字 + 校对，偏口语化。

​

大家下午好，非常感谢大家的到来。
​

我是刘子健，花名繁易。目前在阿里巴巴淘系前端的 Node.js 架构组就职。今天给大家带来的分享话题标题是：《跨云 & 跨端 — 小程序云开发一体化方案》。
​

个人简介

​

​

首先是个人自我简介，我叫刘子健，花名繁易，Github 的账号是 Lxxyx。 目前在阿里巴巴的 Node.js 架构组担任前端技术专家一职。
​

个人工作主要专注于以下三方面：

• Node.js
• Serverless
• Web 框架

​

然后我个人也有积极在参与开源社区，简介如下：

• 阿里 Node.js 框架 Midway.js 团队核心成员，负责框架研发工作
• Node.js Core Collaborator
• TC39 阿里巴巴代表，对部分提案提供反馈 & 意见

​

大纲

​

今天的分享会从以下四部分给大家去讲述。
​

• 介绍一下小程序和云开发
• 介绍推出的云开发一体化方案
• 内部落地实践案例
• 展望和总结

​

小程序与云开发

小程序

​

从上图大家可以看到，自小微信推出小程序开始，各大厂商都针对自己的平台推出了相应的小程序的方案，可以说层出不穷，基本上每一个场都有一个对应的小程序的一个方案。
​

但是很多第三方开发者或者厂商，他开发的应用不只是投放至单一平台的。他很多时候有一码多投或代码复用的需求，在这种情况下，开发者必须去使用跨端框架。
​

然后大家也知道微信传统的小程序开发模式，我认为是非常低效且痛苦的。于是很多开发者想着使用前端框架来解决开发体验的问题，所以也会去使用跨端框架，比如基于 Vue 或基于 React 的各种第三方跨端框架。
​

因此对于目前小程序跨端框架的现状，我的判断是：“跨端和效率的需求催生了大量的跨端框架，每次都有新方案，每年都有新东西。”
​

云开发

第二部分我会讲述云开发。要提到云开发，就不得不先提我们传统的服务开发。
​

在我们传统服务开发中，如果你要去开发一个应用的后端，其实是非常繁琐的。
大家可以看上图，在实际开发过程中，开发者其实是需要关心应用扩容、安全、文件存储、容灾等各方各面的。开发者在服务端需要做非常多的运维工作，然后也需要花费很多时间在接口联调上，然后才能去实现业务逻辑，整体工作其实非常繁琐。
​

对一些第三方一些小的开发者，甚至说个人开发者，这个部分的成本其实高到难以接受的。
​

面对这些问题，云厂商推出了云开发功能。关于云开发，我把它拆解成以下两个部分：

• 平台特定的 API
• 云开发基础能力

​

那么云开发到底节省了哪部分的时间呢？我认为有以下两方面：

1. 在一些常用的功能的开发上，你不再需要重新去做很多事情了。例如登录支付功能，你如果有做过对接都知道这个过程非常痛苦。但是有云开发提供的 API 情况下，你可以直接调用它内置的 API 去实现功能，从而节约你的开发成本。
2. 云开发的基础能力（函数、文件、数据库等）。也就是说你不用再关心运维，不用再关心安全，不用再关心容灾，直接去调用这些就可以。然后它整个的目标是为了让你能专注到业务逻辑上。

​

关于云开发，我们的判断是：“Serverless + BaaS，可以降低小程序开发成本。”
​

但云开发不是一个新东西，它在 18~19 年左右，其实就已经有云厂商提出并落地了。大家在各种会议上听分享，其实可以看到社区重点提的都是跨端框架，例如我的框架可以跨几个端，但几乎没有人关注到云开发可以怎么做。
对于这一点，其实我们也有自己的一个判断：云开发和跨端之间存在“不可调和”的矛盾。我们可以做跨端，但很难说跨端框架上可以很好的去利用云开发的能力。
​

我们进行的归纳总结，认为跨端与云开发间存在以下三个矛盾。
​

矛盾 - 云开发语法分裂

第一个矛盾是：云开发的语法分裂。
​

在上图中我列举了几个云：阿里云、腾讯云、轻服务。这一点其实非常有趣，因为我在长期跟踪各个云的云函数功能，发现每个云为了让自己长得不太一样，它必须设计一个不太一样，但其实一样的语法。例如：

• 阿里云：context
• 腾讯云：event
• 轻服务：params

​

虽然功能大致是一样的，但不同厂商有着不同的一个语法，导致云开发的语法其实相当分裂。之前做跨端小程序，开发者可以通过同一套 DSL 去做，但在云开发上其实很难去做，每个云服务商你都要学习和接受全新的语法。
​

矛盾 - 开发繁琐

第二个矛盾是：开发繁琐。
​

目前所有云开发的目录结构或者是云开发所谓的架构都是上图的模式。

• 架构视角：端侧使用了云开发 BaaS 服务进行开发
• 代码视角：前端后端同一个仓库，通过 monorepo 的方式去开发，其中小程序的每一个函数都需要创建新文件夹

​

这种情况下，其实我们认为它只是机械的组合资源，你的代码很多部分是雷同的，并没有发挥 JavaScript 通吃前后端的优势。
​

矛盾 - 云平台锁定

第三个矛盾是：云平台锁定。

云平台锁定其实是提的比较多的一个概念。简单来说，如果你选择了一家云服务厂商，你的数据，你的代码、你的服务器全都上云之后，如果这个云服务厂商的质量没有达到你的要求，或者说它的功能达不到你要求，你想去切换云的时候，这种时候成本是非常高并且难以接受的。这种时候我们称为云平台锁定。
​

然后很多时候很多厂商会选择多云策略，同理做小程序也是一样，做小程序时，开发者可能说不止投一个平台，但很多时候你也希望去使用别的平台的功能，就容易遇见云平台锁定问题。
​

云开发一体化方案

说完以上三个矛盾，接下来我给大家一起来看我们是如何去解决这些问题的。这边就要提到我们推出的云开发一体化方案。
​

一体化应用开发方案

​

一体化应用开发方案它并不是一个非常新的一个概念。这个方案其实是我们团队 2020 年 4 月份在阿里内部发布的。因为涉及到非常多配套的云平台，因此也没有做大规模的宣传。

目前在阿里内部有 2500+ 一体化应用，它也是目前阿里前端主流开发模式之一。举个例子：目前我们在开发中后台应用的时候，已经很少在开发那种纯资源型的应用，而是选择一体化应用的研发模式，它可以更好地利用函数与 Serverless 的能力，让开发者可以去做一些后端的一些事情，我们认为这对应用是一个增强的能力。
​

然后一体化应用本来只是我们在开发 Web 应用时去使用的方案，比如说 C 端或者中后台应用。但是我们发现如果把它的方案和我们内部的小程序方案去做一个结合（例如淘宝小程序），其实也可以解决小程序所带来的非常多的一些痛点。
​

因此这次我们也将云开发与小程序的方案去进行了一个融合，这边会讲到我们是如何解决上面的三个矛盾的。

语法分裂 — 函数式

第一个矛盾是语法分裂。
​

上图可以看到，不同厂商有不同语法。往往这种时候，我们需要设计一种 DSL，通过跨端的DSL 来解决这个问题。而在后端情况下我们发现其实有更简单的方式，因此我们最终选择的 DSL 可能简单到，我相信在座的每个同学不用学习就会了。

函数式 - 函数即接口

在这里，我们使用的 DSL 是 JavaScript 函数，也称作为： JavaScript 函数即接口 - 统一 & 无协议。
​

我们发现，在你实际开发的过程中，你去开发一个 JavaScript 函数，这个函数所携带的信息其实就已经足够描述API 接口或者云函数需要的信息。这边我以 HTTP 接口为例。

• HTTP 路径：函数名 + 文件名
• HTTP Method：无参数为 GET，有参数为 POST
• HTTP Body：参考 RPC 设计，使用数组来映射函数实际入参
• 返回值：TypeScript 自带类型分析

这一点就是我们所提出的一个理念，叫做基于函数元信息是生成接口。同理如果你生成的是一个云函数，你有一个函数名，你就能只要保证这个函数名不重名，你就能使用函数名作为函数 ID 去生成一个云函数。
​

然后大家可以看图中的代码，可以看到用了一个 useContext 的 API，这也是我们方案的创新之处。
​

函数式 - 使用 Hooks 开发后端接口

这一点我们称之为: 使用 Hooks 开发后端接口。
​

为了给开发者提供更好的开发体验，解决语法问题，解决 DSL 问题。我们提出了一个全新的理念：Hooks 开发后端接口。在传统的 Web 开发中，大家其实需要传递 Context 的，此处 Context 你可以理解为 Express 的 req/res 或者是 Koa 的 ctx。也可以理解为云函数里面 Context 所带的一些函数信息。
​

上图有简单的示例，这个如果你云函数支持 HTTP 请求的话，可以使用 useContext Api 来获取到 Context，从而拿到请求的 IP。这种情况下你可以获取上下文，而且不需要手动传参数，使用方法也与前端保持完全一致，然后这一点也会引出我们后面的一个核心 feature ，后文会说到。
​

然后在当时做的时候其实也遇到了一些难题，比如在我们做的时候，其实 JavaScript 是不支持线程级 Context 传递的，想要实现需要依赖 Node.js [async_hooks](https://nodejs.org/api/async_hooks.html) 模块。
​

然后这背后其实也有一个小故事，就是 JavaScript 不支持线程上下文，我们想让它支持，要怎么办？我们团队在 2020 年 的 6 月份向 ECMA 去提交了一份关于线程上下文的提案，但是因为各种语言语义等潜在的问题，并没有通过，所以后面我们才切换到 Node.js async_hooks 的实现。所以我们也在积极参与标准，只不过这个过程比较坎坷，不像 Error Cause 提案推进的比较顺利。
​

然后当我们在使用 async_hooks 时，其实也存在两个问题：

• 性能问题非常严重
• 稳定性不足，Node.js Module Stability 1

​

然后我们也尝试做了两版方案，来解决提到的这两个问题。
​

编译时方案

首先是性能问题，我们通过编译器解决。我们自研了 TypeScript 的编译器 mwcc，这里面用到了非常多的 TypeScript Internal Api。我们通过将所有函数的调用编译为带 bind 的调用方式，同时去生成正确的 source map ，从而得到一个可以正确被加载和调用的函数，也解决了性能问题。当然也存在一定的语法限制。
​

但最后我们还是放弃了这个方案。因为在 TypeScript 3.9 迭代到 4.0 的时候，TypeScript 4.0 出现了非常多的 breaking changes，然后内部的 API 改动也也非常大，我们已经改不动了，所以我们决定投入到第二版方案，运行时方案。
​

运行时方案

这个使用了 Node.js 中的 [AsyncLocalStorage](https://nodejs.org/api/async_context.html#class-asynclocalstorage) API。[AsyncLocalStorage](https://nodejs.org/api/async_context.html#class-asynclocalstorage) 是 Node.js JS 为了专门解决请求上下文追踪难题或者用来做监控的一个模块，它性能比较好，然后也没有语法限制，API 也比较稳定。
​

然后在这之后我们也在积极参与社区。图里面其实是我们参与社区的例子，包含我们对 [AsyncLocalStorage](https://nodejs.org/api/async_context.html#class-asynclocalstorage) 的反馈等，推进这个 API 达到稳定可用的状态。

在 Node.js 16.x 时，这个 API 正式落地了，目前是一个 Stability: 2 的稳定模块。整个过程略显繁琐，但其实也是我们在不断探索的一个过程，也是我个人加入 Node.js 社区的初衷。
​

​

开发繁琐 - 全栈架构 & 简化调用

​

关于开发繁琐。其实大家可以看到你用传统的开发模式，去开发一个全栈应用或者云函数应用其实是非常繁琐的。你每一个云函数你都需要新建一个文件夹，需要拷代码，很难复用。你抽象成一个 npm 模块，你需要来回发布，也非常繁琐，并且前后端其实也是不连通的。
​

全栈架构

在这里，我们也推出了一个全新的架构模式，叫全栈架构。
​

这个就是目前我们内部使用一体化去开发的一个目录结构。可以看到与传统的方式完全不一样的是，src 目录内包含了云函数、小程序页面等前后端的资源。
​

这么做的好处其实有很多：

• 统一依赖管理：不再需要重复安装依赖了，你也不需要再复制粘贴文件了
• 统一工程配置：避免来回配置
• 共享 src：这个其实带来了非常大的一个想象力空间，你可以共享代码，你也可以共享类型。之前前后端那种分割的模式下，你每次需要手动生成类型的时代已经过去了，你们都在一起，为什么还要互相引用呢？为什么还要互相生成呢？直接引用就行，而且是最新的。

​

云函数依赖管理

针对这个目录结构，我们也做了非常多的优化，其中就包括依赖管理。
​

上图左侧是我们云开发目前的函数结构，我相信所有做过云开发用过函数的都知道，每个云开发函数都是一个单独的一个实例，它包含业务逻辑 / node_modules / package.json，每个函数都互相分隔开来。
​

这样做会带来以下的问题：

• 跨函数逻辑复用：比如说你要去检查用户是否登录，utils 的抽象复用，都会带来逻辑复用的问题
• 重复依赖：每个函数如果要用到 loadsh，就得重复安装
• 重复文件：package.json 等

针对这个问题，我们提出了新方案：一体化函数。
​

我们将函数以入口文件的方式做了隔离。简单来说，我们不再是像左边一样一个函数包含所有文件，而是只包含一个入口文件。
大家可以看到这边我每个函数都有一个入口文件， A 函数 / B 函数 / C 函数其实是可以引用公用的一些逻辑的，比如说有 utils / model / service， 然后共享同一份 node_modules 和 package.json。然后在打包的时候，我们在工程上做优化，而不是在你让你手动去做优化。

​

在打包的时候，我们会根据每个函数入口文件去打包成一个函数，然后单独去做部署，相当于是说你在保留了应用开发的习惯之下，你同时拥有了函数的一个优势，而且不需要去做切换，也不会遇到刚才的那些问题。
​

在这一点，其实我们是使用了 vercel 的 ncc 。 ncc 有个最简单的解释： “Webpack for Node.js”。它是可以把一个函数的入口文件去打包成单独的一个 bundle 的，会把这个函数所引用到的各种的后端的一些模块，不管你是 lodash 还是相关的模块，它都会帮你打包在一起。这样做的话其实是可以保证说你每个函数入口文件都是一个单独的可以部署的一个 JS。
​

然后在这里其实我们也对新的方案做行了一个优化。在我们传统的一个打包方案过程中，我们打一次包其实可能会需要 20 秒到 30 秒，我们需要做非常多构建和优化的一些事情。压缩包也很大，然后解压后的体积也很大，启动时间也很慢。
而在单文件的情况下，我们不仅打包时间快，我们压缩包大小也小，我们解压体积也小。因为 Webpack 大家都知道它有 Tree Shaking 的功能，可以把一些用不到的模块给去掉，因为体积小所以启动时间也快。
​

通过这种方案，我们解决了云开发工程中资源机械组合的问题，但是我们觉得还可以再往前进一步。
​

简化调用 - “零” API 实践

我们把后面进一步的实践叫：“零” API 实践。
​

刚才我说过共享 src 的代码其实有非常广阔的想象空间，想象空间就在于此。因为你共享代码之后，那么你调用函数或者接口，其实你不需要再去手动发请求，或者不需要再手动使用云函数的客户端。你只需要两步就可以完成整个调用。
​

1. 把你的函数从 API 目录里面导入进来，比如上图的 getUserProfile 函数
2. 调用函数，拿到返回值

​

在这个过程中，我们把原来传统的云函数的发布、调用、获取返回值的过程给精简化了。
为什么我们上一章会提到用 JavaScript 函数去写接口，因为这一章我们就要用 JavaScript 去调用。把云函数开发或前后端调用的过程中的胶水层给抹到 0。
​

然后这个就是我们一个核心的设计理念，“零” API。这样做的好处很多：

• 前后端调用的胶水层都被抹去了
• 通过 useContext 获取到请求上下文，调用接口函数和普通函数是一样的
• 前后端都使用 Hooks 的语法，前后端非常一致

​

简单且容易理解。
​

简化调用 - “零” API 原理

整个方案的原理其实也很简单。
​

大家都知道前端工程里，我们会依赖 Webpack / Vite 此类的构建工具。我们可以通过 Webpack Loader 或者 Vite 的 Plugin 来对导入的文件做处理。
​

如上图所示，一个导入的函数，我们可以在 Loader 中，通过 es-module-lexer 来解析导出的函数，最终构建出前端可用的 API Client。也就是说，前端在编辑器里面引入的是后端接口，但实际运行的时候其实已经被替换成了 API Client，从而可以正确的发起调用。

提一句题外话，es-module-lexer 实际上也是个非常有趣的库，这也是 Vite 使用的底层库，用来分析导入导出的，大家有兴趣可以上 Github 看看相关文档和实现。
​

云平台锁定 - 跨云 & 多云适配

刚才我们有提到过云平台锁定，那么我们能不能去做一些多云的适配工作呢？其实是可以的。
​

函数式 - 多云适配

​

多云适配的原理比较简单。
​

我们针对不同的云厂商，开发了不同的 adapter，每个 adapter 负责如下的工作：

• 解析参数
• 调用函数
• 错误处理

​

​

上图中有 adapter 简单的示例。一个 adapter 接收 fn 和 ctx 两个参数，其中 fn 就是我要调用的云函数，ctx 则是调用的上下文。
​

关于 ctx，因为不同云对应的入参不一样，因此获取参数的方式也不一样，可以看上图。通过这种方式我拿到它的入参。当我们拿到入参的时候，因为之前提到过入参的格式是数组的话，其实是可以直接和后端参数映射上的。这种情况下，你前端传入的参数就是后端实际收到的参数，就可以实现跨云的一体化调用了。

跨云原理 - 多云部署

同时多云其实还涉及到部署的问题。
​

上图是我们的部署产物的结构，包含：

• User Code：用户代码
• entry.js：云平台入口文件，不同云平台要求入口文件格式和导出方法不一致
• Args Adapter：云平台适配

这些构建产物可以去部署到不同的云平台，比如说我生成的是阿里云的部署结构，我就可以部署到阿里云生成到腾讯云的结构，我就可以部署到腾讯云，生成到自有服务的结构，就可以部署到自有的一个云平台，非常自由。
​

然后关于该方案其实后面还有很多可以做的事情，但基本原理就是根据不同云平台去生成适配代码，提交部署。而且适配代码大家可以发现是做的非常的轻量的，你不需要去关心特别多的事情，你只需要说去拿到参数，调用函数并返回即可。

跨云 - 使用 Case

这里我会列举一下跨云的使用 Case。
​

例如小程序 + 云函数的组合，去落地跨云方案时，其实是可以根据不同云平台去使用不同用的云函数的一些服务的。例如：

• 支付宝：支付宝小程序 + 阿里云 FC
• 微信：微信小程序 + 微信云函数
• 头条：头条小程序 + 轻服务

​

因为你的代码你不涉及到具体的后端服务，其实你在云平台上就可以部署和调用。
​

然后还有一点，是关于我们的内部场景，我们称为自建云服务，这个其实能做的事情就非常多了。我们开发的一体化应用，前端可以部署为 Web / 小程序 / Native 页面，后端也可以部署在自建的云服务 / FaaS / 裸机上的。在这种架构模式下，我可以在不同的前端源站及云服务间切换，不仅防止锁定，而且可以统一语法，降低学习成本。
​

这里其实也提到了一个很重要的概念，就是降低统一语法，降低学习成本。像之前社区有两个概念：

• Learn once write everywhere. 这个是 React 的理念
• Write once run everywhere. 这个是国内部分开源产品推荐的理念

​

而我们实际上更认可前者，学习一次在哪儿都能写。

iFashion 落地实践

在解决了上述的问题后，我们尝试在内部找了一个小程序 IFashion 做落地尝试。
​

项目概况

​

iFashion 是淘宝服饰的应用，也是我们内部流量非常大的一个小程序应用。
​

技术栈如下：

• Rax
• 阿里云定制版
• 构建工具 Web
• 投放平台：手淘小程序 & H5 页面（我们开发的应用会投放至全网。投放在手淘是小程序，投放在外部我们是 H5 页面）

前两年淘系前端在推动一个前端研发模式升级战役，在一体化方案推出后，iFashion 也希望使用一体化方案来去接入一个内部的云服务去提升效率。然后这一点就是我刚才提到的那个使用的 case ，如何去把这个服务去部署到自建云平台上。因为有些公司不会用公有云，它自己就有云服务（比如阿里、腾讯等云服务商）。
​

Webpack 工程接入

实际工程接入一体化应用需要解决几个问题，第一个就是如何接入 Webpack 的工程体系。
​

这一点其实非常简单。这一点我们开发了 Webpack Loader 和 Express（for webpack dev server） 的中间件，然后使用 Webpack chain 去快速接入原有的工程。
​

然后上图就是我们实际接入的代码，你通过这简单的几行代码，你就可以去接入一体化工程，成本很低。然后图中右侧就是我们实际的调用流程图。
​

一体化调试

然后还有这部分是第二部分是关于一体化调试的，这部分也是目前我们做的觉得体验非常好的一个功能。
​

这里我写了一个简单的工程，前后端代码分别如上图，功能也很简单，就是展示 Rax 和 Midway 两个仓库的 Stars。

题外话 +1。大家看上图的后端代码，我第四行其实有个注释，这个给 Github 的 Copilot 用的。整段 Demo 基本上是 Copilot 写的，在小 Demo 的场景非常好用。
​

然后下面是我们调试录制的视频。在一体化调试功能下，你可以在编辑器中，一次完成从前端到后端的全链路 Debug。
​

一体化调试放大版

​

一体化发布

关于应用的发布，我们也去定制了我们内部的发布工作流。
​

如上图所示。当我们在点击发布之后，我们 Workflow 会运行设定好的 steps ，去做不同的事情。
​

从源码检查开始，然后同时会进入一个并行的构建的过程。首先是前端进行构建，这种时候前端会进将它的产物进行一个上传和部署，你是网页就到 CDN，你是小程序就到小程序平台。然后也会对函数做一个构建和一个部署，去部署到相应的 FaaS 平台上或者多个云平台上。
​

构建完成，我们有一体化灰度和切流的节点。简单的说，相较于之前的前后端分开切流，中间需要配合不一样。我们在一体化切流的 workflow 中也做了非常多的一些定制，我们能保证整个应用现在按一体化的维度去做切流，新应用新接口，老应用老接口，新老接口不会串。我们认为这种是一种更简单的一种开发方式。

灰度完成后即正式上线。

提效 30%

这个是我们上线数据实测的结果。
​

图中上半部分，是我们之前在开发一个需求时，需要投入前端和后端两名同学，大概一起开发 13 个人日。
而图中下半部分则是使用一体化这种开发，只要投入一个人 + 10 个人日即可。
​

这个听起来有点不可思议。但是我们在内部大量的应用的实践的情况下，我们发现当你使用一体化这种开发的方式，你去开发一些简单或者一般的需求的时候，你完全可以实现节约人力投入且节约时间的效果。
​

因为在开发过程中，其实大家有做过前后端联调，都知道联调是非常繁琐的一个过程。联调 / debug /上线等待花费了很多时间，但可能你的改动就两行代码。因此在使用一体化的时候，你一个人开发，就可以大大加速整个流程。
​

总结与展望

最后一部分是总结与展望。
​

总结

在跨端小程序方案中，我们去尝试引入云和一体化的开发方案来进一步为开发同学提效。
​

这一点其实也是我们架构团队一直在探索的，我们认为端侧红利及工程红利已经见顶的时候，有什么办法能进一步提高它的开发效率呢？
​

于是我们尝试了云和端的一个结合，这个也是我们未来非常重要的目标和方案，我们会尝试去更多的和云上的能力去做一个结合，而不仅仅是在端上去寻找更多的一些红利。因为你端上再怎么做，你还是需要那么多人。而你在云上做，你一个人做掉了反而可能效率更高，这是一个非常神奇的一个反应。
​

展望：云端融合

在目前的场景中，我们也去加入了 TC 39，参与提案的讨论。
​

上图中有两个提案，一个是 JS Module Blocks，另外一个是衍生的提案 JS Module Fragments。我们更关注的是后者，因为这能为一体化应用带来更好的研发体验。
​

上图就是我们基于 JS Module Fragments 写的 Demo。这里面我可以有一个叫 cloud 的模块，写一些后端的代码，我可以去引入微信的服务端的 SDK，可以去拿到微信的 context，我可以去获取它的 OpenId。同时我可以有一个 client 的模块，来写前端的逻辑。其中后端接口的调用可以直接从云端这个 cloud 这个模块导入。
​

可以发现在这个提案下，一个 JS 文件就包含了前端、后端两部分的代码，并且非常和谐。然后这个也是目前我们未来可能会去倡导的一个理念叫云端更加融合，更加一体化。
​

题外话 +2，云端一体在前端框架的趋势已经非常明显了，无论是 Next.js/Nuxt/Svelte Kit 或者是新出的 Remix 框架，大家都在更多地去结合云函数的能力，去提供服务 OR 实现 SSR。

然后目前我们也在和前端委员会的标准化小组去共同推进提案，这个是我们的反馈链接：https://github.com/tc39/proposal-module-fragments/issues/14。
​

欢迎关注

整个一体化框架是基于 Midway.js 开发的，也欢迎大家多多 Star 或者 Watch 我们的 Repo，看看我们最近在搞什么新东西。
​

图中“让 Node.js Web 开发更简单 & 有趣”是个人的 Slogan，也是一直在努力的方向。
​

本次分享到此结束，谢谢大家！

在 2021 年的 8 月份，工作中的我接到了淘系技术运营同学的约稿，邀请我谈一下“程序员最重要的能力是什么”。随后我根据自身经历，写下了回答，全文发表在淘系技术公众号的《程序员最重要的能力是什么？》中。
​

到了九月底，淘系技术运营的同学和我说文章发表出去的反馈不错，希望我能继续写一下具体的心路历程，于是就有了这篇文章。
​

希望能为和我一样，对编程感兴趣/犹豫转行/正在转行的同学们提供一点经验分享。
​

我的编程学习经历

我是转行成为程序员的，可以分享一下我的编程学习经历。
​

在学习编程之前

在高中时，因为学不会物理和化学，我选择了文科，这也意味着计算机专业类对我关上了大门，不过在当时我也没有想到自己在未来会喜欢上写代码并以此为生。
​

现在回想起来，与编程有关的只有两件事情。
​

一是在繁忙的高中生活中，我一直订阅着《电脑报》，并通过它了解互联网的时事。二是当时的文科数学需要解一种流程图题，也是我最喜欢的题型，现在看来与代码流程其实是无异的。
​

流程图题

从 C 语言开始

升学后，我就读的是人力资源管理专业。2015 年初，大一上学期的期末考试刚结束，距离回家尚有一段时间，因为闲着无聊便上网络学起了翁恺老师的《C 语言基础》课程，随后就被带入到了计算机编程的坑中，至今尚未脱坑并越陷越深。

记得当时的我，在 2015 年寒假一个月的时间内。开始了每天听课，思考。然后把代码输进手机慢慢运行的过程（那时候还没有笔记本电脑）。当时最开心的就是图片的这一段代码，一次性编译运行通过。
​

从“年轻工程师”到阿里前端技术专家

往后的半年中，编程的学习也并没有像想象中的那样顺利。学习进度停滞不前。我还清楚的记得当时的自己：“会用 20 门语言输出 Hello World!”，“别人一周就能上手的 BootStrap 我学了四个月” 等诸如此类的事情。

偶然的一个契机，我找到了愿意带我写代码的同学，并磕磕绊绊的完成了第一次 Ajax 操作。那之后的我仿佛开窍了一般，编程世界的大门，终于向我敞开，任我探索和遨游。
​

直到有一天，我遇到了瓶颈。
​

2016 年的前端，技术日新月异，当时的我颇有一些手足无措，总觉得时间不够用。于是在参加当年的 JSConf 时，遇见了当时前端圈的名人贺师俊（Hax），于是便壮着胆上去交流了一番。
​

对话的内容我只记得个大概，在交流结束时我向贺老致谢，他回复我说：“学东西不要有那么强的功利心，而且对于我来说，能帮你们这些年轻的工程师就非常好了。”
​

在那时候我发现，对编程的兴趣已经托着我从学生过渡到大家眼里“年轻的工程师”了。时间一晃眼已经过去了 5 年，当年的学生，也从“年轻的工程师”蜕变成了阿里的前端技术专家，身份在变、环境在变、技术在变，只有对代码的兴趣没有改变。
​

从 Node.js 使用者到 Node.js Collaborator

由兴趣驱动的源动力，往往是纯粹且不掺杂利益的，而在软件世界中，兴趣驱动与开源精神是高度契合的。

在 2020 年冬季到来的时候，我遇到了新的瓶颈，想学习更多 Node.js 的知识却不知从何下手。
​

这一次我的选择是参与 Node.js 开源社区的协作。我开始阅读 Node.js 的源码，解决 Github 上的 Issue 等。在事后提名 Node.js Core Collaborator 时，我统计了一下，两个月的时间内我一共提出了 50+ 的 Pull Request。
​

现在回头来看，这些与实际工作“无关的兴趣”，最终支撑着我走的更远，现在的我在 Node.js 架构团队，全职负责着 Node.js 的工作，个人的眼界也开拓了许多。
​

转行的那些问题

转行并非是一帆风顺的。在这个过程中，最常见的问题莫过于如下：

• 非科班的同学，能学会计算机吗？
• 计算机专业学了 4 年，你自学的能跟得上吗？
• 出来后能找到工作吗？
• 转行的过程中需要做什么呢
• ……

​

这些问题从我学习编程时，就一直萦绕在耳旁，时至今日依然会有同学找我聊天，然后再问出上述的问题。也是借着此机会，我写一下我的想法。
​

非科班能学的会计算机 / 自学能跟得上吗？

答案是肯定的：“可以的，没问题的”。
​

说起来，我从未纠结过自己非科班的出身。在学习编程的伊始，我就想清楚了，如果想要成为一名优秀的程序员，科班 / 非科班的身份根本就无关紧要，真正的关键在于个人的学习效率与投入的时间。
​

而在大学中，我投入了大量的时间，平均每天编程 6h，这样的生活一直持续到毕业。而在毕业时，我已经完成了大约十几个项目，写过十几万行代码，也有一个十几万字的博客。
​

博客统计

大学时写的一个项目

Commit 记录

​

换言之，我也认为，如果一名非科班的同学，学过计算机的课程，写过很多行代码，也可以顺利的完成项目，那么他就是程序员。
​

出来后能找到工作吗

答案也是肯定的：“可以的，没问题的”。

计算机编程就业环境还是很好的，并不会卡死专业，而是通过过往的经历 + 笔试/面试来决定是否录用你。所以不用太担心这方面的问题。
​

这个问题我之前在知乎也回答过，所以就不再重写啦，可以看下面的截图，也可以通过链接查看。

​

转行的同学要如何学习呢

这可以说是社区每天都能遇见的问题了。但授人以鱼不如授人以渔，我说一下我自学新领域所使用的方法。

方法很简单：上知乎，搜索 XX 入门（如计算机入门，前端入门），就会出现一大堆提问，你需要的只是耐心读完其中高赞的一些回答，并归纳总结分析，大概心里就有数了。随后选择其中你觉得靠谱的高赞回答去学习即可。

许多提问的高赞回答其实都回答的很详细也很好，认准教程后跟着学习即可，学习的过程中你又会遇到新的问题，这个时候继续再搜索即可。
​

这个方法很管用，时至今日，我在学习产品、设计、演讲、游戏等新领域时都是这样做的，在尝试和摸索的过程中，你的自学能力也会得到提升。
​

我的自学方式

我在刚学习前端时，幸运的在知乎上看到了大漠关于前端自学的回答。
​

后面我还经历了这样的一过程,我思考过三类问题,并且将他们列在一起： 1.哪些知识点懂了？ 2.哪些知识似懂非懂？ 3.哪些知识不懂？
接下来有了这样的三份清单之后，就能非常清楚自己知道自己，然后先解决第二个清单中的 list，再解决第三个清单中的 list。
最后建议，学习这个过程是不断渐进的，整个过程把握：多看、多想、多问和多做。这也是我自己的四多原则。如果你时间允许，多写写东西，总结自己的知识。现多看看规范。
​

我想做 web 前端，怎么学习–大漠的回答

​

后面也针对自己的情况，画了一张思维导图，把似懂非懂的知识点列了出来。

后面在寒假里针对这些问题重点攻关，并写成总结的技术文章。
​

2016 年的文章

目前来看，找到自己“似懂非懂”的知识，学习，总结，分享是一个非常有效的学习方式，有兴趣的同学也可以参考试试。
​

我也一直坚持，学习方案的重点在于学习效果，而不是方案有多复杂和多详尽，适合自己就好。
​

转行的过程中需要做什么呢

这里我的建议是：

• 多做项目
• 多写总结
• 多打基础

首先我建议多做项目，比起打下“扎实的基础”，对于转行的同学，培养起对编程的兴趣是更重要的。不同于科班良好的学习氛围与节奏，自学往往对自制力的要求更高，这时候培养起对计算机的兴趣，能让自己继续学习写代码才是更重要的。
​

其次我建议多写总结，总结是一个非常高效的学习过程，如果你要把一件事情给讲清楚，那么首先一定要弄懂这个知识。自学计算机的过程中，多总结不仅可以查漏补缺，也可以让自己在回顾的时候多一份积累的感觉。
​

最终则是建议多打基础，转行计算机的同学，计算机底层原理，算法等知识接触较少，但这些却实打实的是基础，可以帮助你未来少踩很多坑的知识，因此在学习之余也可以多关注计算机基础知识（至于怎么学习，可以参考上面的回答）。
​

回头看转行

时光荏苒，回头看已经写了快 7 年代码了。
​

回头再看自己的转行经历，与其说是文科生转行学了计算机，倒不如说是自己发现了对计算机的兴趣，并持续投入至今。
​

最后，送上我很喜欢的一段话作为结尾。
​

「_Your work is going to fill a large part of your life, and the only way to be truly satisfied is to do what you believe is great work. And the only way to do great work is to love what you do. If you haven’t found it yet, keep looking. Don’t settle. As with all matters of the heart, you’ll know when you find it. _」 — Steve Jobs

esbuild 原有下载机制的问题

最近有用户在 esbuild 的 Github 仓库提了一个 Issue：Different strategy for installing platform-specific binaries，报告了部分用户在安装 esbuild 依赖时出现的权限错误。

1
2
3
4
5
6
7
8
9
10
11
12
13
14

> esbuild@0.8.43 postinstall /usr/local/lib/node_modules/netlify-cli/node_modules/esbuild
> node install.js
Trying to install "esbuild-linux-64" using npm
Failed to install "esbuild-linux-64" using npm: EACCES: permission denied, mkdir '/usr/local/lib/node_modules/netlify-cli/node_modules/esbuild/esbuild-r63cli2pgpi'
Trying to download "https://registry.npmjs.org/esbuild-linux-64/-/esbuild-linux-64-0.8.43.tgz"
/usr/local/lib/node_modules/netlify-cli/node_modules/esbuild/install.js:217
      throw e;
      ^
Error: EACCES: permission denied, open '/usr/local/lib/node_modules/netlify-cli/node_modules/esbuild/bin/esbuild'
  errno: -13,
  syscall: 'open',
  code: 'EACCES',
  path: '/usr/local/lib/node_modules/netlify-cli/node_modules/esbuild/bin/esbuild'
}

背后的原因也很简单，因为 esbuild 是使用 Go 语言开发的，因此如果要使用 esbuild ，那么在安装时就必须下载各自平台对应的二进制包。

而在之前的 esbuild 版本中，这段逻辑是利用 npm postinstall 的 hooks 去实现的，在安装时会通过 node 判断系统平台，并下载对应的二进制包。

这样做也带来一些问题：

• 权限问题，动态下载可能会报错
• 二进制包是从 npm 下载的，不支持内网、自定义 npm 源、代理等情况，速度也慢

在 Issue 中，也提到了可以使用 npm 的 optionalDependencies + cpu 来解决多平台二进制包分发的难题。

随后 esbuild 实现了该逻辑，并提交了 PR。

测试数据的结果也非常喜人，安装时间从 5.4s 减少到了 1.5s，提速了大约 3 倍。

在仔细查看相关 PR 后，我觉得这是一个非常巧妙的解决方案。

npm 的 optionalDependencies 与 cpu

长话短说。

在 npm 中，optionalDependencies 意味着是可选依赖，此类依赖在安装时，即使是安装失败了也不会中断安装的过程，而是交由 npm 包自行去判断。

而 cpu 字段则代表这个 npm 包只能在指定的 cpu 架构上运行。比如你指定了"cpu": [ "arm" ]，那么 npm 在安装时会通过 process.arch 来判断，这个包是否可以安装。

而 esbuild，正是通过 optionalDependencies 与 cpu 字段的配合，实现了下载提速 3 倍的效果。

下载提速的原理

在 PR 中，esbuild 将所有的二进制包都加入了 optionalDependencies 中。

而同时在每个二进制包的 package.json 中，指定了 cpu 字段，也就是将原来的匹配平台，下载对应二进制包的工作交由了 npm 去实现。

尝试通过 npm i esbuild --verbose 来输出日志，可以清晰的看到：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

npm verb reify failed optional dependency esbuild/node_modules/esbuild-windows-arm64
npm verb reify failed optional dependency esbuild/node_modules/esbuild-windows-64
npm verb reify failed optional dependency esbuild/node_modules/esbuild-windows-32
npm verb reify failed optional dependency esbuild/node_modules/esbuild-sunos-64
npm verb reify failed optional dependency esbuild/node_modules/esbuild-openbsd-64
npm verb reify failed optional dependency esbuild/node_modules/esbuild-linux-ppc64le
npm verb reify failed optional dependency esbuild/node_modules/esbuild-linux-mips64le
npm verb reify failed optional dependency esbuild/node_modules/esbuild-linux-arm64
npm verb reify failed optional dependency esbuild/node_modules/esbuild-linux-arm
npm verb reify failed optional dependency esbuild/node_modules/esbuild-linux-64
npm verb reify failed optional dependency esbuild/node_modules/esbuild-linux-32
npm verb reify failed optional dependency esbuild/node_modules/esbuild-freebsd-arm64
npm verb reify failed optional dependency esbuild/node_modules/esbuild-freebsd-64
npm verb reify failed optional dependency esbuild/node_modules/esbuild-darwin-64
npm verb reify failed optional dependency esbuild/node_modules/esbuild-android-arm64

npm http fetch GET 200 https://registry.npmjs.org/esbuild-darwin-arm64/-/esbuild-darwin-arm64-0.13.3.tgz 3635ms (cache miss)
npm timing reifyNode:node_modules/esbuild-darwin-arm64 Completed in 3641ms

因为我的系统是 m1 的 mac，因此只有 esbuild-darwin-arm64 这个包被安装了下来，其他的包则失败了。

这么做的好处在于：

• 不用动态去 npm 拉取包，对于使用自定义 npm 源的用户是友好的（特别是使用 npm 镜像源做反代的情况）
• 安装全程由 npm 完成，最大程度的避免了权限的问题

原理很简单，但是思路很巧妙，值得学习。

淘系技术 - 技术运营约稿

TLDR：对写代码始终充满兴趣，这是我一切的源动力。

过往 - 从 HR 专业学生到程序员繁易

我是一名半路出家的程序员。高中读的文科，大学选的人力资源管理专业，生活如果按部就班的下去，这个世界或许会多一位叫繁易的 HR 或者猎头，波澜不惊。

引导我走上程序员之路的故事也很简单，2014 年刚入学，大一课程少，期末时便在网络上自学起了 C 语言，当时没有电脑就在手机上的 C 语言软件敲着简单的 if/else，就这样我入坑了。
​

往后的半年中，编程的学习也并没有像想象中的那样顺利。学习进度停滞不前。我还清楚的记得当时的自己：“会用 20 门语言输出 Hello World!”，“别人一周就能上手的 BootStrap 我学了四个月” 等诸如此类的事情。
​

虽然整个过程中极其令人丧气，但我始终知道，我对写代码这件事情是抱有极大的兴趣的。在当时同龄的同学已经纷纷在准备考证、找实习之类的事情，而我依旧乐此不疲。
​

我想，如果不是因为真的有兴趣，我大概会放弃编程，选择做一些“更适合”自己的工作。
​

成长 - 从“年轻工程师”到阿里前端技术专家

在学写代码半年后，偶然的一个契机，我找到了愿意带我写代码的同学，并磕磕绊绊的完成了第一次 Ajax 操作。那之后的我仿佛开窍了一般，编程世界的大门，终于向我敞开，任我探索和遨游。
​

直到有一天，我遇到了瓶颈。

2016 年的前端，技术日新月异，当时的我颇有一些手足无措，总觉得时间不够用。于是在参加当年的 JSConf 时，遇见了当时前端圈的名人贺师俊（Hax），于是便壮着胆上去交流了一番。
​

对话的内容我只记得个大概，在交流结束时我向贺老致谢，他回复我说：“学东西不要有那么强的功利心，而且对于我来说，能帮你们这些年轻的工程师就非常好了。”
​

在那时候我发现，对编程的兴趣已经托着我从学生过渡到大家眼里“年轻的工程师”了，我想我会继续带着兴趣走下去，尽全力去 Coding 就行。
​

时间一晃眼已经过去了 5 年，当年的学生，也从“年轻的工程师”蜕变成了阿里的前端技术专家，身份在变、环境在变、技术在变，只有对代码的兴趣没有改变。

开源 - 从 Node.js 使用者到 Node.js Collaborator

由兴趣驱动的源动力，往往是纯粹且不掺杂利益的，而在软件世界中，兴趣驱动与开源精神是高度契合的。

在 2020 年冬季到来的时候，我遇到了新的瓶颈，想学习更多 Node.js 的知识却不知从何下手。
​

这一次我的选择是参与 Node.js 开源社区的协作。我开始阅读 Node.js 的源码，解决 Github 上的 Issue 等。在事后提名 Node.js Core Collaborator 时，我统计了一下，两个月的时间内我一共提出了 50+ 的 Pull Request。
​

现在回头来看，这些与实际工作“无关的兴趣”，最终支撑着我走的更远，现在的我在 Node.js 架构团队，全职负责着 Node.js 的工作，个人的眼界也开拓了许多。
​

总结 - 兴趣与代码

在别人眼里，我是枯坐一整天的“怪人”，在我的脑海中，我是“键新世界（阿里 2018 年校招 Slogan）”的程序员。
​

因为是兴趣，所以获得成长时会快乐，而停滞不前时也不会焦虑与抱怨。对代码的兴趣支撑我走到了现在，我想后面也会是一样。
​

这就是我眼中程序员最重要的能力与我的经历。

如果你之前从未了解过 Jamstack，我推荐先阅读文章：《Jamstack，下一代 Web 建站技术栈？》。

Jamstack 是什么

Jamstack 是一套用于构建现代 Web 站点的技术栈，拥有高性能、安全性、易扩展的特性。
​

Jamstack 技术栈 & 生态

​

Jamstack 聚合了现代前端开发所需要的脚手架，框架，工作流等，从而最大化的提高工程师的生产力。
​

工作流

​

在这里，Jamstack 的核心理念是预渲染、使用 JavaScript 实现动态功能、使用 HTTP Api 连接第三方服务。
​

举个例子

当你要开发一个博客，在这之前你可能会使用 Wordpress 去搭建你的博客站点，但与此同时，你也需要负责维护 Wordpress 的服务与数据库等。
​

而如果你使用 Jamstack，你可以使用诸如 strapi 的 headless cms 服务(意为只提供 API 而不提供页面渲染)，用来存放你的文章数据，你在前端可以使用类似 Next.js 的框架去构造站点，通过请求 headless cms 的 Api 来渲染页面。
而在发布时，你将在构建时生成静态页面，并发布至 CDN。因为是静态页面，所以性能好，而托管至 CDN 意味着该页面是只读的，安全性高，且 CDN 是全球部署的话，那么页面也能实现全球部署，拓展性非常好。

误区

Jamstack 在国内落地时，总是会有同学认为这是新瓶装旧酒，或者是前端炒出来的新概念，但实际上忽略了 Jamstack 自身架构的特性与优势。

Jamstack 是不是新瓶装旧酒

Q：Jamstack 和之前的手动发布页面到 CDN 有什么区别，是不是新瓶装旧酒？
A：这里我可以很明确的给一个答案：不是。

首先在我看来，Jamstack 虽然表现的都是页面和资源托管至 CDN，是实际上背后的工作流与过往是截然不同的。相较于以往手动开发和发布的模式，Jamstack 是聚合了现代前端框架、工作流、发布平台的，这一点非常的重要。
​

​

对于工程师而言，效率就是生产力，之前的页面不一定是基于现代工程的，每次生成静态页面也依赖于自己写的脚本，每次页面更新还需要手动发布，效率偏低。而使用 Jamstack，你可以利用你最熟悉的框架，通过框架去批量生成静态页面，并且聚合 Git 等服务，实现推送即发布的全自动工作流。效率会高很多。
​

举个相似的例子：使用 React/Vue/Angular 和使用 jQuery 写页面，最终都是操作 DOM，所以 React/Vue/Angular 和 jQuery 是一样的，新瓶装旧酒？
​

先进的工具带来先进的生产力，即使最终的表现是前端页面和十年前一样，部署至 CDN。但实际上生产效率与质量还有可生产的页面已经发生了很大的进步。
​

不论是什么前端页面，能打开的更快终究是更好的，因此如果只关注到部署的结果，而没有注意到生产流程与生产效率的变革，便会落入“Jamstack 是新瓶装旧酒”这个论点的坑中。顺带一提，近几年的前端工具基本上也是朝着“性能更好”、“更易用”等方向去前进的。
​

Jamstack 能适应所有的场景

Q：那是不是什么网站都上 Jamstack 就对了？
A：明确的回复，不对，Jamstack 的优势非常明显，所以劣势也很明显。
​

如果只关注到 Jamstack 的性能优势，希望将 Jamstack 用于所有场景，其实是不正确的。Jamstack 的站点为了获得性能、安全、可拓展性的优势，需要将页面托管至类似 CDN 的服务中，这个过程中，一个页面需要经过以下两步才会真正的发布到线上。
​

1. 预渲染
   1. 需要提前渲染出最终的页面
2. 发布
   1. 托管服务刷新缓存后展示新页面

​

针对预渲染，由于往往需要在构建时或者运行时实现功能，那么会存在一定的限制。构建时生成无法实现千人千面，运行时生成则需要考虑生成的数量与成本的考虑。假定将每一条微博都生成一个静态页面，诚然性能是好了，但所带来的成本也是不可估量了，且许多微博往往访问的人极少，那么运行时生成的性能可能还不如之前，
​

在 Jamstack 架构下，CDN 是最常见的托管服务，但 CDN 为了保证性能也存在着缓存的机制，这意味着页面的实时性无法保障。现有的 Jamstack 框架也会添加定时生成的功能，比如每 10S 就刷新一个页面并推送至 CDN，但不论怎么做，在实时性上还是不如实时服务的。

Jamstack 最适合一些内容更新不太频繁的网站（比如新闻、电商、文档）。它不适合 Feeds 流、聊天室、论坛、个性化推荐这样高度动态化的网站，以及邮箱、编辑器这样偏重型的 Web 应用。

Jamstack 会是企业级框架的核心特性而非唯一，混合渲染是未来方向

这个观点是我个人的想法。
​

在我看来，之所以 Jamstack 在国内难以落地，除去老生常谈的工作流、部署平台、底层依赖的限制外，其实还存在着适用范围单一的问题。
​

这里我抛出我的观点：在国内的市场下，Jamstack 将会成为企业级框架的核心特性，但并非唯一的特性，混合渲染才是未来的方向。
​

诚然，Jamstack 的优势非常明显，用过的同学都说省事都说好，但我在前文也提到了 Jamstack 的劣势，这决定了在企业内部错综复杂的场景中，Jamstack 不是那么万能的。
​

此外，Jamstack 作为一种现代 Web 站点的开发理念，其是易于被框架实现的。这也意味着，在企业级的场景中，往往会是框架去实现 Jamstack 特性，这个过程是新增而不是替换。因此 Jamstack 会是企业级框架的核心特性而非唯一特性。
​

至于后一句提到的混合渲染，Idea 实际上是源于 Next.js 10。在 Next.js 中，框架配合 Vercel 云服务平台，实现了纯静态页面托管、增量生成、服务端渲染等多种渲染策略的聚合。从这个角度来看，Next.js 相较其他的 Jamstack 框架是更有优势的。
​

静态生成

增量生成策略

​

先进的框架 + 先进的工作流 + 更多渲染场景的适配，我认为这才会是企业级框架进步的方向。

总结

Jamstack 是一套优秀的现代 Web 站点开发技术栈，在现代前端工程的加持下解决了开发效率与性能的难题。但由于其劣势也非常明显，所以在企业级框架中，Jamstack 会是一种核心的特性，但不是唯一的特性，企业级是需要支持类似混合渲染的开发模式的。
​

BTW，本文没有提及到使用 JavaScript 与连接第三方服务这两个特性，理由是：构建现代站点，完全脱离 JavaScript 不现实，故略过；预渲染页面时，往往就包含使用第三方服务（当然我觉得这一点的商业价值实际更大），故也略过。
​

推荐阅读

• Jamstack，下一代 Web 建站技术栈？
• https://jamstack.org/
• Next.js - Data Fetching

话不多说，先来看第一个 BUG：使用 net 模块的 BlockList 类时，如果调用 addSubnet 的第 2 个参数为 NaN，进程就会 Crash 退出。

Issue 由我发现和修复，目前已合并至 Node.js 主分支中，并在 15.6.0 版本中分发。

Github 上提交的 Issue 和 PR：

• Issue: net: blockList.addSubnet throw Assertion `args[2]->IsInt32()’ failed when prefix is NaN
• Pull Request: net: throw ERR_OUT_OF_RANGE if blockList.addSubnet prefix is NaN

复现

Node 版本: 15.4.0

问题代码如下：

1
2
3

const net = require('net');
const blockList = new net.BlockList();
blockList.addSubnet('', NaN);

报错信息：

1
2
3
4
5
6

> blockList.addSubnet('', NaN)
node[2155]: ../src/node_sockaddr.cc:614:static void node::SocketAddressBlockListWrap::AddSubnet(const FunctionCallbackInfo<v8::Value> &): Assertion `args[2]->IsInt32()' failed.
 1: 0x101379d05 node::Abort() (.cold.1) [/usr/local/bin/node]
 2: 0x1000bde89 node::Abort() [/usr/local/bin/node]
 ....
[1]    2155 abort      node

而这种在 C++ 抛出的异常，是你用 Try/Catch 也捕获不了的，如果你传入了错误的参数，那么进程只能 Crash。

定位

在 net 模块中，BlockList 负责网络黑名单的工作，用于屏蔽某些 IP 地址。本次出问题就是其中的 addSubnet 方法。

在 Node.js 的源码中，所有 JS 提供的功能都在 lib 目录下，简单的搜索 BlockList 关键词，我定位到了本次发生问题的代码文件及方法：https://github.com/nodejs/node/blob/37a8179673590af10b9e8e413388adffc21ba713/lib/internal/blocklist.js#L81-L105。

在 addSubnet 方法中，会对传入 prefix 参数做校验，而这个校验实际上是存在漏洞的。

在使用 typeof 来校验 number 时，往往会遗漏 NaN 的校验，因为 typeof NaN === 'number' 。此次的问题也是如此。

在最终调用 this[kHandle].addSubnet(network, type, prefix); 时我们传入了 NaN，而 this[kHandle] 是 C++ 的 binding。

1
2
3
4
5
6
7

const { BlockList: BlockListHandle } = internalBinding('block_list');

class BlockList {
  constructor(handle = new BlockListHandle()) {
    this[kHandle] = handle;
  }
}

在 C++ 代码中，则对传入的参数又做了一次校验。

而 NaN 不是 Int32，因此将导致进程异常退出（exit code: 134，代表中断）。

修复

了解问题后，修复并不困难，只要在 JavaScript 侧加入对 NaN 的校验即可。

而在 Node.js 的内部提供了 validateInt32 方法，用于校验数字。我们只需要将原来的 if (typeof prefix !== 'number') 替换为 validateInt32 即可。

下面是完整的 Diff。

单测

在 Node.js 源码中，任何变更都需要配上相应的单元测试，此次也不例外。

我在 test/parallel/test-blocklist.js 加入了单元测试，本地测试通过后便提交了 Pull Request。

单元测试的代码：

1

assert.throws(() => blockList.addSubnet('', NaN), /ERR_OUT_OF_RANGE/);

提交 & 合入主分支

相关的 Pull Request: net: throw ERR_OUT_OF_RANGE if blockList.addSubnet prefix is NaN

因为改动不大，且 BUG 确实存在，因此这个 PR 没有争议的迅速通过了。

提出 PR 大概一周的时间，代码就已经被合入 Node.js 主分支，并在 Node.js 15.6.0 中分发到全世界了（顺带一提，在 15.6.0 版本中，我有 12 个 commit 被合入当前版本）。

后续

全文看下来，你会发现往 Node.js 提交 Pull Request 并不困难，且修复 BUG 的过程也是熟悉源码的过程。感兴趣的话不妨阅读 Node.js 的文档：《Contributing to Node.js》 与 Starkwang 的文章：《为 Node.js 贡献你的力量》。

后续我也会持续更新这个专栏，将我解决过的 Issue 写成文字，供大家学习和参考，有兴趣的同学可以点个关注~

自我介绍

首先是个人介绍，我的花名叫繁易,目前就职于阿里巴巴-淘系技术部-前端架构团队，主要负责淘系前台业务的 Serverless 落地和前端提效战役，目前也在负责 Midway Serverless 框架云端一体场景的架构设计和落地工作。

大纲

本次分享我将会从以下 4 部分出发：

• 阿里巴巴 Node.js Serverless 建设现状
• Midway Serverless 介绍
• 新一代云端一体研发方案
• 未来规划

阿里巴巴 Node.js Serverless 建设现状

在过去的 2019 年中，阿里经济体前端委员会提出了四大技术方向。分别是：

• 搭建服务
• Serverless
• 智能化
• Web IDE

Serverless 与前端

Serverless 首次作为一个技术方向，被列为前端委员会的主要攻关方向。这背后也是有一定原因的。


首先是在阿里巴巴集团，我们拥有 1600+ Node.js 应用，但应用常年的 CPU 利用率非常低，大部分 CPU 利用率 < 10%，甚至有 < 5% 的应用。


从技术视角来看，Node.js 的维护实际上是有一定难度的，在开发的过程中，我们会遇到非常多前端之前所没有处理过的问题。例如 Docker、限流、日志、跨语言调用等。而这一系列的难题则会带来非常高的成本。
恰巧的是，这些传统应用开发所会面对的一些问题，正好是我们函数开发中的优势。因为函数可以提高服务器的利用率，按量付费，也可以减少非常多不必要的运维成本。


而从业务视角来看，前端也提出了一些业务上的诉求。阿里巴巴是几年前开始了中台战略，并希望做到大中台小前台的目标，因此我们前端同学，也希望借中台服务来快速组合为各类业务接口，从而达到快速交付的目标。更快的完成业务需求和降低业务试错成本。
因此我们需要 Serverless 来赋能前端，让云原生给前端降本增效。

Serverless 落地成果

经过大约一年的实践之后，我们也取得了一定的一些成果。


首先，我们在多个 BU 实现了 Serverless 的落地 ，平稳度过了双促。这些 BU 大家可能也都很熟悉，比如：淘系、新零售、飞猪、ICBU、天猫精灵等。


而在业务增效降本上，Serverless 也有亮眼的表现。


在机效方面，我们传统业务机器成本降低 ~30%，而中后台业务机器成本更是降低 ~87%，Serverless 帮我们节约了成本的同时，也一定程度上解决了服务器利用率低下的问题。
在人效方面，使用函数整体人效提升 ~48%。这部分是我们根据用户使用工具埋点 + 调用时长 + 代码量测算得出。


最后则是 Serverless 整体架构经过了双促的验证，零故障。有力的证明了 Serverless 架构的稳定性。

Midway Serverless 体系介绍

我们在整个 Node FaaS 落地的过程中，都是基于我们 Midway Serverless 框架去开发的。所以在讲述云端一体前，我还会向大家介绍一下整个 Midway Serverless 的体系。

简介

下面我们以请求调用为例，大家可以看到请求处理的过程中，云开发平台的 Runtime 会加载 index.js，而 index.js 又会执行我们的 Midway Serverless Framework，最后再由框架去执行用户代码，返回结果。

体系

而在整个 Midway Serverless 的体系里面。我们一共有以下三个部分：

• 工具链
• 框架
• 标准化

首先是工具链，我们在本地工具链这边做了非常多的事情。包括本地触发器的模拟、调试、一体化、多平台的发布等。

第二部分则是框架，包括数据模拟、环境配置、请求适配、组件拓展、IoC 等。这部分都是希望开发者可以更方便的去开发应用


最后一个则是标准化。目前云厂商在 Serverless 标准层面是割裂的，而我们则希望一定程度上的去解决这个问题，比如我们推出的 yml 标准、前端调用标准，运行时标准、一体化标准。这一切都是希望大家在 Serverless 时代能更好的去利用 Serverless 的红利来加速开发。

新一代云端一体研发方案

这部分我们将会向大家介绍新一代一体化云端一体研发方案，至于为什么是新一代，这儿先卖个悬念，后面会提及。

我们遇到的问题

在阿里巴巴实践 Serverless 并不是一帆风顺的，我们也遇到了许多难题。


首先是上手难度高的难题，因为 Serverless 虽说把运维的成本降低了，但是你在开发一个应用时，需要去接触后端，相比于传统的前端开发来说，难度是升高的。

其次是前后端割裂的问题，我们现阶段主要在负责纯函数的开发。从代码层面来看，就是前端是一个仓库，后端是另外一个仓库，前后端分开开发与发布。虽然都是一个人在做，但依然会有比较强的一个割裂感。


最后则是研发成本高问题，上面提到前后端割裂的问题，当你前端和后端在不同的仓库时，意味着你需要分开发布，并且多次联调，这部分带来的研发成本是偏高的。

带着这些问题，我们经过了大约一年的思考与探索，推出了我们自己的解决方案：云端一体应用开发模式。

云端一体在社区的定义

云端一体这个概念并不是一个新词，近期在社区也很常见。而在社区的视角上，关于云端一体主要有以下两种定义。

架构视角

第一种是架构视角出发的。他们所认定的云端一体，是云服务和端侧技术能够结合在一起使用。比如说前端使用 BaaS 服务进行开发，他们把这种开发模式就叫云端一体。

代码视角

另外一种是从代码视角出发，当前后端同仓库时，我们通过 monorepo 等工具进行开发，也被称之为云端一体。
像下图中展示的就是一种比较经典的研发模式。Server 端与 Web 端分别是一个文件夹，双方管理自己的依赖，一同开发与一同发布，这种也称之为云端一体。

但是我们在去年调研方案时，我们觉得这两种方向，只是机械的将资源组合在一起，并没有发挥出 JavaScript 统一前后端的优势。

Midway Serverless 的云端一体方案

对此，我们也提出了自己的云端一体解决方案。新方案的定义为：云端协同开发、无缝融合。

然后在下图有我们方案的一个目录结构。在新方案中，前后端是在同一个仓库里的，而且前后端只需要管理一份依赖。这么做有以下几个好处：

• 易于开发：前后端在一个仓库里，只需要管理一份依赖。可以降低开发时的心智负担
• 易于维护：前后端都在一起的时候，功能是一同开发一同管理的，可以提升项目的可维护性
• 易于部署：前后端都是一个仓库，在一次发布中，我们可以同时发布前后端，降低部署的成本

Midway Serverless 云端一体特性

我们这次推出的云端一体方案，主要有以下 4 个特性：

• 函数式研发（Functional R&D Solutions）：函数即接口。我们通过函数来统一前后端的体验，减少不必要的样板代码，加速应用研发
• 一体化调用（Api not required）：从此不再手动调用 Api。在新框架中，你可以直接从服务端导入函数并调用，就像调用普通函数一样简单
• Hooks（Using Node.js like React Hooks）：通过 Hooks 开发 Node.js 应用。是全新的体验，也是你熟悉的语法。更为函数式开发带去了完善的能力支持
• 渐进式开发（Progressive development）：简单和复杂场景通吃。通过对于 IoC 的支持，我们可以复用阿里 Node.js 复杂应用最佳实践，支撑企业级应用开发

**

函数式研发：Functional R&D Solutions

当前云厂商接口开发模式

在当前的云厂商提供的 Serverless 服务中，不同云厂商的接口开发方式是不一样的。

比如说阿里云，腾讯云、AWS 这三个云平台，他们都有着不同的入参。而不同的入参意味着需要开发者去自行了解各个平台间的差异，学习成本高。

我们在经过思考之后，觉得这种开发模式所带来的成本太高了，那么有没有一种更简单的方式呢？

用最简洁的方式开发接口

答案是有。


我们发现，其实使用原生的 JavaScript 函数，就可以实现我们的目标。以下图为例，左边的是 Get 接口的开发方式，右边的是 Post 接口的开发方式。

当函数没有参数时，则接口的 HTTP Method 为 Get，而当接口需要传参时，它就是一个 Post 接口，整个开发方式是自然且完全对齐 JavaScript 函数开发体验的。

像写 JavaScript 函数一样写接口。

函数元信息

使用 JavaScript 函数，是可以描述函数的信息的。


JavaScript 函数与接口元信息的映射关系如下：

• 路径：文件名 + 函数名
• HTTP Method：函数是否有参数
• HTTP Request Body：函数参数

通过这种方式，我们使得函数元信息能转换为接口的信息，来进行 HTTP 服务的开发。

一体化调用：Api not required

我们通过函数自身的信息，来生成接口的信息，这中间实际上包含了一个转换的过程。如果要让开发者手动拼接路径，调用函数，那无疑是一种倒退。


接下来展示的一体化调用则会向大家展示我们是如何解决这个问题，充分发挥函数的优势。

重塑接口调用体验

在过往的开发中，我们要完成接口的请求，总是需要手动去拼接参数并且调用，整个过程显得繁琐不堪。
而在云端一体的开发场景下，我们希望重塑整个接口的调用体验，真正做到云端融合，忘记 Api 和 Ajax 调用。

一体化调用：最简单的接口请求方式

我们选择使用函数开发接口，是为了实现一体化调用。

所谓一体化调用，就是在接口的调用过程中，我们不再手动调用 Ajax 与 Api，而是直接通过 JavaScript import 的方式，导入函数并调用。


调用接口，就和调用普通函数一样简单。

Get 接口调用

Post 接口调用

和普通函数一样写接口，也和普通函数一样调接口，从此忘记 Ajax 和 Api 调用。

前后端调用示例

实现原理

一体化调用的实现原理并不复杂，我们基于 Webpack 和 Babel 开发了编译插件，将前端对于函数的引用转换成了 HTTP 的请求。


具体的可以看下图：

Hooks：Using Node.js like React Hooks

为什么会有 Hooks

在传统的 Web 应用开发中，我们需要的不仅仅是函数参数，还包括非常多的请求上下文信息，例如请求的 Header、Method 等。

但在一体化调用中，由于接口也是通过 JavaScript 函数开发，因此无法获取到请求上下文的信息，也不能通过参数手动传入（因为会损害调用体验，前端也无法传入上下文参数）

通过 Hooks 获取请求上下文

我们在借鉴和吸取了 React Hooks 的经验之后，决定通过 Hooks 去解决获取请求上下文的难题。

整个 Api 非常简单：

1

const ctx = useContext();

通过 useContext 这个 Api 与 Hook 的开发方式，带来了以下三个好处：

• 解决了在函数中获取请求上下文的难题
• 无需手动传入参数，不损害调用体验
• 遵循 React Hooks Style 的开发方式，云端一体融合不仅仅是项目目录结构与接口调用的融合，更是开发心智的融合

下面是一些简单的示例：

通过 Hooks 的方式，我们可以像写 React Hooks 一样去开发 Web 服务。

可复用的 Hooks

在 Hooks 的开发中，我们也支持将复杂或重复的逻辑，提取成单独的 Hooks 并进行复用，从而减少重复性的劳动。

实现原理与性能问题的解决

在实现 Hooks 语法的支持时，实际上是存在一波三折的。


在社区上，Node.js 官方提供了 Async Hooks 这个模块，可以用于模拟实现请求上下文的传递功能。但该模块也存在两个问题：

• 模块 Api 不稳定
• 性能问题严重

其中，第二个问题是我们弃用该方案的直接原因，具体的 Benchmark 可以看下图：

Async Hooks 所带来的性能损耗十分惊人

因此，我们尝试另辟蹊径，通过在工程上预编译的方式，来实现 Hooks 的开发与请求上下文的传递。


编译原理并不复杂，主要是以下两点：

• 获取请求上下文：转换为对 this 的引用
• 调用 Hooks：转换为 bind 调用，将 this 传递下去

通过这种方式，我们在函数间对于上下文与 Hooks 的引用，串成了一条完整的调用链。而 bind 操作所带来的调用开销完全是可接受的。


由于我们是使用的 TypeScript，在编译过程中对于源码的更改会影响到 Source Map 的生成，因此我们也自研了 Midway 的编译器 mwcc，不仅解决了 Source Map 生成等问题，更是提供了类似于 Babel + Babel Traverse + Plugin 的开发体验，有兴趣的同学可以自行了解一下~

渐进式开发：Progressive development

阿里在落地 Node.js 时，会遇到非常多复杂的业务场景，这部分将向大家介绍我们在 Node.js 企业级应用开发的实践与解决方案，及在函数式开发的场景下，如何复用这部分最佳实践。

阿里巴巴企业级 Node.js 应用开发实践

在设计整个 Midway 框架时，我们一直在思考一个问题：“用什么方式解决复杂业务问题”？而我们给出的答案是参考软件设计的经典原则：SOLID 软件设计原则>)与其中的依赖倒置原则。

同时我们也参考了诸多业界的实践，发现成熟的 IoC 设计已经能够解决复杂业务的问题，包括 Java 的 Spring、JS 社区的 Nest.js/TypeOrm 等，都采用了基于 IoC 的实现方式。


因此，我们决定通过自研的 IoC 框架，作为 Midway 体系的核心去解决复杂应用的维护问题。


而函数式研发作为 Midway 体系的一种解决方案，因此在设计之初我们就考虑了函数与 Midway IoC 体系的融合，使得函数式研发可以复用 IoC 的最佳实践。

函数式与 IoC 的结合

这儿我们依然通过 Hooks 来解决这个问题。


我们提供了 useInject Api，通过这个 Hooks 在函数中来使用 IoC。





通过这种方式，我们实现了函数式与 IoC 的无缝结合，从简单到复杂场景都能处理。

内部落地情况

Midway Serverless 的云端一体方案在对外发布前，在阿里内部实际上已经探索了有大半年的时间。


项目时间轴如下

• 2020.02：Idea 提出 & POC 演示
• 2020.03：核心功能确认 & Api 确认
• 2020.04：首个业务落地
• 2020.05 - Now：多个业务落地并使用，持续迭代中

内部落地的 BU

未来展望

开源

目前 Midway Serverless 的云端一体方案已正式对社区发布并可用，大家可以进入 Midway Serverless 的 Github 仓库，查看云端一体方案的文档与使用方式，觉得好用的话记得点个 Star 哦~

未来：多场景落地

在阿里巴巴内部，我们主打的是中后台与移动端的场景，但实际上这套方案是可以用于多场景的。因此在未来，我们希望能投入到开源，结合前端框架、SSR、小程序等各种场景并落地。



这部分是我们未来的一个规划，也欢迎大家来参与开源，提交 Idea 与代码。一同去打造更优秀的研发体验。

本次则会为大家分享哇哦视频在这半年中发生的故事，与大家一起看看在一线业务同学的眼中，Serverless 会给前端同学带来什么，而我们又能收获什么？

分享内容

本次分享我会从以下三个部分出发：

• 业务落地
• 从零到一
• 未来抉择

业务落地

哇哦视频是在手淘首页的短视频导购业务。

“三高”业务

而其作为手淘的导购业务，其具有“三高”的特点：

• 流量高
• 稳定性要求高
• 迭代频率高

流量高指的是哇哦视频业务体量大，日常流量高，随着高流量所带来的，就是稳定性要求高的特点，且作为导购业务，其迭代频率也是非常高的。

开发痛点

在长达一年的开发实践中，我逐渐发现了业务在开发中遇到的一些痛点。

在这里我以最近三次首页改版的时间为例。通过下图这个时间轴，我发现整个业务迭代的过程中开发联调时间较长，从而导致需求完成时间往往会超过 10 天。

基于此我也开始在思考业务研发模式中存在的一些痛点。

首先站在整个业务的大背景来看，有两个特点：

• 淘系大力推行中台化战略，业务能力实现了中台化，日常需求基本可以通过中台能力组装实现
• 导购业务一直处于高速迭代期，从未停歇。

基于以上的背景，我们会发现在目前业务的研发模式中有着诸多的痛点。

联调

首当其冲的痛点则是联调。在联调期中前后端需要不断对数据字段、业务逻辑进行确认，从而确保需求实现的正确性，而这种密集的沟通所带来的成本是非常高的。在哇哦视频这儿，我们发现联调成本一般要占到开发成本的 30% 左右。

居高不下的联调成本，一方面使得工程师们精疲力尽，另一方面也不利于业务的快速迭代。

业务开发的枯燥

对于业务开发来说，日常工作就是取数据调接口，枯燥且重复。

前端资源化

值得一提还有前端资源化的痛点。

在目前前后端的分工模式中，前端只负责交互逻辑与相对应的 UI 实现，对于业务核心逻辑无需过多了解。虽然这使得前端团队可以快速完成某些业务，但同样也带来了前端资源化的隐患。而在强调前端要深入业务，具有商业化思考能力的今天，前端资源化实际上是不利于前端的自身发展的。

因为很多时候前端想去深入业务，想进一步升级自己的能力，但往往会苦于没有相关场景。至于说介入后端的工作领域，毕竟术业有专攻，很多事情也掺和不进去。

研发模式升级战役

恰好 2019 年的 4 月份，淘系前端开启了研发模式升级的战役。而我也参与进去负责导购体系 Node FaaS 相关建设的工作。基于 Node FaaS 提供的能力，我开始重新思考上面碰到的业务痛点，并认为研发模式升级是可以解决以上的痛点问题的。

对于为什么研发模式升级可以解决上述提到的痛点，我个人认为主要有以下三点：

• 单人负责前后端，且均使用 JS，能极大的减少沟通与联调成本，满足业务高速迭代需求
• 离用户最近，熟悉业务规则，业务方沟通成本低。
• 前端对于自身能力升级的渴望。对于身为前端的我来说，我不想也只是作为一个资源，每次被调配，我也希望自己可以去对业务负责，也希望可以有机会去赋能业务，去做更多的事情。

而对于后端同学来说，当前端负责前后端，后端同学则可以从业务中释放出来，从而选择去开辟更多的新战场，去做更多更有挑战性的事情。

业务迁移

带着以上这些思考，我仔细阅读了业务的后端代码并梳理整体的业务逻辑，发现其具有以下的特点：

• 后端无状态
• 复杂度适中

这两个特点使得业务非常适合使用 Serverless 技术来承接。
而在正式进行迁移前，我和业务方沟通了这个事情对于业务可能产生的影响以及后续规划。业务方对于技术侧的改造是没有意见的，只有一个诉求，那就是业务不受影响。

整个诉求看似简单，拆解下来包括以下三部分：

• 不会为技术侧改造预留时间，原定需求要按时完成
• 迁移后线上不能出任何问题，线上对迁移无感知
• 后端工作交接至前端后，对后续需求推进无影响

说起来就是既要快，又要稳，还要能扛住后续需求。而在充分梳理和分析后，我确认我可以在“不坑业务”的基础下，完成整个迁移。

在开始迁移后，事情进展比我们想象中的要顺利很多。下面是我们研发过程中的一些数据。

在迁移完成后，我又尝试接了几个需求，并对前后所用的时间做了一个对比。

可以看到在之前完成一个业务迭代，前端总共需要投入 10 天，整体投入人数是 2 人。
而在研发模式升级后，前端总投入时间增加到 12 天，虽然看起来投入时间增加了，但是却减少了一个人的投入。总的来看还是节约成本的。

从零到一

这部分我主要我想讲清楚一个问题，那就是业务从开始迁移，到研发完成上线，这个过程中都发生了什么？

在这里我把它主要分为以下 4 个部分来讲述：

• 需求承接
• 本地研发
• 部署与调用
• 运维

###

需求承接

迁移的基础是原有需求的承接，而需求承接的核心就在于需求评估。在业务方提出需求时，我们会按照如下的节奏开始需求工作流：

• 召开需求评审会，确认需求与具体内容
• 召开技术评审会，确认实现方式与涉及到的二方平台
• 需求开发、发布等
• 经验积累总结

而在需求承接的过程中其实会遇到一个难题，那就是如何确认需求是可实现的？
这是一个前期困扰我许久的问题，然而答案却也简单，那就是：如果需求的实现不涉及三方平台的，那么依据自身能力评估即可。如果是涉及到三方的需求，则需要让业务方组织技术评审会，会上确认是否该需求是可实现。

研发流程

这部分是关于函数研发流程相关，会按以下四部分去阐述：

• 函数开发
• 服务调用
• 单元测试
• 函数发布

本地研发

整个本地研发，按照时间顺序主要分为以下四个步骤：

• 函数开发
• 服务调用
• 单元测试
• 函数发布

值得一提的是，在之前我提到过：“哇哦视频作为淘系首个落地 Node FaaS 技术的项目，其开发的整个过程，也与 Serverless 体系的成长密不可分。”

所以这部分即会讲述到本地开发，也会讲述到哇哦视频从迁移伊始到上线这段时间内，给 Node FaaS 带来的一些改变。

多函数的目录结构

在这之前，主流 FaaS 项目结构如我图中所画的那样。每个函数间是相互隔离的，这样虽然比较干净，但其实也带来了非常多的一些痛点。比如跨函数逻辑复用困难，重复的依赖安装和重复的文件。

因此我们在思考，既然 FaaS 的优势在于零运维，那我们不应该为了运维的优势而强行降低开发者的效率。

因此我们提出了新的目录结构方案。在新的目录结构中，我们使得多函数可以复用同一依赖，避免重复的文件与依赖。且我们也提出了新的打包方案，每个函数入口文件都会被打包为一个函数单独部署。

至此，我们获得了应用级的开发体验，也获得了 FaaS 零运维的优势，从而达到开发者提效，专注业务逻辑开发的目标。

整洁架构的探索

在开发过程中，哇哦视频也对业务的架构做了一些新的探索。在此我参考了整洁架构的一个实践，事后证明配合 IoC 与依赖倒置，有效的减少了业务的迭代难度。

同时关于这个架构与具体的落地实践，外部有非常多的案例，有兴趣的同学可以自行查阅。

服务市场 - HSF 调用一站式解决方案

在业务开发的过程中，一定会遇到的就是 HSF 的服务调用。为了简化开发工作量，尽可能的提升研发效率，对此我们也提供了对应的解决方案：服务市场。

服务市场囊括了 HSF 服务，从调用到测试的全流程支持。是我们在开发业务时的一把利器。

单元测试

在之前的 Midway 项目中，是默认支持使用 Mocha 测试的。

而正好在今年的 JavaScript 开发者报告中，关于测试框架一项，Mocha 的人气在持续的走低，而 Jest 作为近两年的新起之秀，人气在不断的升高。因此我们在原有的 Mocha 支持上，又新增了 Jest 的支持。

同时哇哦视频有着通过单测保障代码质量的需求，因此我们也打通了 FaaS 函数在内部 Ci 系统单元测试的链路。

错误处理

其实这部分与实际的代码书写风格相关，虽然说是战时盯着屏幕看监控，但是如何第一时间发现错误源于何处，是否需要处理其实是值得琢磨的问题。毕竟无效的监控一多，人就会陷入到报警疲劳中。

在这儿，哇哦视频采取对于错误采取了以下的几个小策略，确保线上可以快速定位问题：

• 错误分级：将错误分为 忽略/警告/重视 3 种等级，方便一眼确认重要错误
• 自定义错误名：将错误自定义名称，而非是笼统的 Error，方便迅速确认具体错误
• 携带关键信息：针对不同错误，携带不同关键信息，方便快速定位与复现问题

简单示例如下：

而在实际业务中的监控中，实际上会较容易的区分与定位错误：这样最终是对于线上问题的排查与修复是有帮助的。

Java 兜底

对于 Java 兜底，我现在就一个感觉，真香！
虽然这是一个临时性的方案，但是在你出问题时还有兜底的服务可以帮忙扛着，无比安心呀。


具体实现上非常简单，实际上就是在请求自己接口失败时，再去请求一次 Java 接口，确保可以提供服务。毕竟两个应用同时都宕机的几率是非常低的。

发布流程

这部分主要与代码的发布，我们提供了一站式的研发平台，来帮助你管理函数，实现版本管理与回滚等功能。

调试闭环

对于现代化的开发而言，调试是必不可少的一项能力。在此 Sandbox 平台 提供了一站式的调试闭环服务。我们可以在函数中启用远程调试，然后在预发去调试代码，从而帮助我们更快的去定位问题。

函数监控

关于函数监控，在此我们也提供了一站式全功能的 Node.js 治理平台，Sandbox。包括运维数据、链路分析、监控告警、白屏化日志四大功能。

运维数据

在此，我们可以通过 Sandbox 提供的功能，清楚的看到当前函数的运行数据。功能也非常简洁明了。

链路分析

在阿里做后端，怎么能缺少全链路分析的辅助。

在此，Sandbox 也对全链路分析做了支持。
对于函数的每个请求，我们可以查看到其链路的详情与对应的链路，帮助我们快速定位到链路问题。而针对于错误链路，在这里也能看到其对应的链路分析与错误的日志。

白屏化日志

Sandbox 也提供了白屏化日志的功能，通过查看实时日志，可以有效的了解函数情况。

监控报警

Sandbox 提供了监控报警的功能，在这里我们可以设定自己的报警项。在报警触发时，会通过短信电话等方式实时通知到同学。

配合之前提到的那些功能，可以使得快速发现并定位修复故障。

FaaS 的业务能力

基于以上的这些功能，与哇哦视频业务长达半年的实践与踩坑，我们可以说：

“FaaS 函数工具完备，完成业务就像是搭积木一样！”

如果有相关业务需求的同学，可以大胆的放心的使用 FaaS 去完成。

未来抉择

这部分是业务迁移 FaaS 半年后，个人的一些思考与总结。

研发模式升级推论

首先先看一个研发模式升级的推论。

1. 因为：我们在技术上使用 Serverless
2. 所以：实现前端能力升级
3. 结果：助力业务先赢

这个推论听起来好像是很正确的一件事情，但却让我想起我之前听到的一个故事。

故事：科技改变生活

都说科技改变生活，以前我们遇到不懂的问题，要去图书馆查资料。
而现在，遇到不懂的问题，我们只需要掏出手机，然后，你就会忘记这个问题。

而这个故事和之前研发模式升级的推论，在我看来是差不多的。虽然我们有了新的方式去解决问题，但最后的结果可能天差地别。

在这里我就发现前端能力升级，并不一定能助力业务先赢，这也是困扰我长达半年之久的问题。

我在哇哦视频的选择

“研发模式升级究竟能否助力业务先赢？”

这个问题就像心魔一样在我心头萦绕，但遇到问题就要解决问题。总得试试看，因此在半年内，分为 3 个阶段，我做了如下的一些尝试。

支撑（19.06 - 19.09）

第 1 个阶段我称为支撑，时间是 19 年的 6 月份到 19 年的 9 月份。

在这期间我对自己的要求就只有一个，那就是“活下来”。因为首先要能做业务，才有后续与业务谈价值的可能性。否则都只是空中楼阁罢了。

对话（19.10 - 19.11）

第 2 个阶段我称为对话。

在能做业务的基础上，我开始尝试去理解业务数据，主动去沟通、学习、了解相关业务领域知识。并且在遇到问题时会习惯性与业务方进行沟通，看看这个问题，从业务视角出发是如何理解的。

助力（19.12 - 至今）

第 3 个阶段我称为助力。

在逐渐理解业务规划、与业务方也有了一定的信任后，我开始尝试参与部分业务规划，与业务方一同去挖掘痛点。同时同时站在技术的角度上做一些技术预研，尝试为业务带去更多的发挥空间。

抉择

在我刚提到的第一阶段“支撑期”时，我经历了非常长一段时间的思想抉择。

在我可以支撑业务时，当时的我面临着两个选择：

1. 做一辈子的业务工具人：业务说什么我做什么，承接需求就好
2. 尝试做一次业务合伙人：试着给自己提出的问题（研发模式升级究竟能否助力业务先赢？）找一个答案

当时的纠结在现在看来，主要是以下几点：

• 作为一名技术同学，尝试着做非常多看起来与技术不相关的事情，风险高难落地拿不到结果
• 受非技术因素影响多，业务的走向与起起落落，并非是技术可解的问题
• 做成了可能与技术无关，做不成却一定有自己的问题

但最终我还是选择尝试做一次“业务合伙人”，因为我觉得如果研发模式升级如果不能证明它能助力业务先赢，那么整个战役实际上是失败的。对于自己而言，也只是简单的完成了一次业务迁移的过程，而没有真正的去解决问题。

比起拿到迁移的结果，我更想知道研发模式升级的答案。

业务对话

在下决定后，我开始按自己的思路去做这一切的事情。

首先是对既有经验的一个学习。正好最近阿里经济体前端委员会在阿里技术论坛出品了《技术与业务同行》这个专题，里面有非常多业务思考的文章，细细拜读后收获颇多。

在拜读相关文章后，我开始主动去了解业务的数据，目标与未来的规划，且在此基础上，我开始主动要求与产品经理，去做一个沟通，希望能去与业务方，共同了解整个产品业务的规划与交流。

在这之后，我被邀请去参与哇哦视频用户调研活动。这也是我第一次面对面的去与用户对话，了解用户的真实需求。
而在与用户面对面沟通后，我发现自己业务思考上的诸多盲区。这件事情也是一个警醒，虽然我自诩为前端是离用户最近的岗位，但实际上与用户面对面之后，才知道实际上相差甚远，比起自嗨，我们仍然需要更多的去倾听用户的声音。

例子：承接手淘 Push

哇哦视频的业务方之前一直存在一个痛点，那就是业务入口流量不足。在与业务频繁对话的那段时间，这个问题时常会被提起。

针对这个问题，我开始尝试与业务方讨论有没有相应的解法，最终将目标锁定在使用手淘 Push 消息的能力来为业务导流。
与业务方沟通并达成一致后，技术侧迅速开始了改造，为哇哦视频新增了承接手淘 Push 的能力，且随着消息的推送，不断进行相应的调整与优化。
在多日的持续优化下，哇哦视频通过手淘 Push 实现 UV 单日最高提升 20%+的结果。

而在经过这件事情后，我想我找到了“研发模式升级究竟能否助力业务先赢”这个问题的答案：Serverless 是前端撬动业务场景的一把利剑。

总结：FaaS 给前端带来的变化

在我之前写的文章《哇哦视频 ❤️ FaaS - 迁移前后的那些事儿》中，公司的同事留了一句评论：

而对于我来说，后续的目标则是希望在助力业务成长上去探寻到更多的可能性。基于 FaaS 的研发模式升级，实际上是为了助力业务先赢。

我们不要因为走得太远，而忘记为什么出发。

前言

作为一位技术同学，我相信你对于今年集团内部 Serverless 与 FaaS 的热度一定有所感知。

在看了那么多“技术原理/顶层设计/平台建设”相关的文章之后，我相信你对 FaaS 肯定产生过跃跃欲试的感觉，但也肯定存在诸多疑惑，例如：

• FaaS 在业务中能落地吗？
• FaaS 能帮助前端同学实现能力升级吗？
• ……

而这些疑惑对于刚开始接触 FaaS 的我而言，只会多不会少。恰好，我所负责的“哇哦视频”业务是淘系第一个基于 Node FaaS 开发的线上业务，在线上已经稳稳当当的跑了 4 个月，这期间不仅接手了 Java 同学的工作，同时也顺利的承接了日常与双十一需求。

关于上面的这些疑惑，经过了这四个月的考验，我想我已经有了自己的答案。接下来我将会向大家分享我这四个月的历程，带大家一起看看，在一名一线业务同学的眼中，FaaS 究竟会给前端同学带来什么？

背景

哇哦视频是在手淘首页的短视频导购业务，业务核心目标如下：

打造围绕“人用物”为核心有 “温度”的短视频；引导更多的商家视频，商家模板化生产;增加首页分发效率，让用户快速的且容易定位到自己想看的视频内容。

而其作为手淘的导购业务，其具有“三高”的特点：

由于是身处手淘首页的业务，其流量相对于普通业务而言是比较高的，属于大流量业务。而流量高的特点也带来了稳定性高的要求，由于用户众多，因此线上的任何不稳定都有可能产生舆情。

而作为导购业务，业务本身还有一个迭代频率高的特性。为了能实现更好的导购效果，业务需要不断的推陈出新，快速建场，从而获得更好的导购效果。

淘系导购研发模式

中台化

在淘系，随着中台化战略的成熟与导购侧近几年的发展，导购业务的开发工作由独立开发各种能力向中台化支持转变。业务所需要的绝大部分能力均可以由中台提供。

这么做带来的好处是显而易见的。大部分常见的导购业务，都可以通过中台能力的组装从而实现快速上线，避免重复开发带来的人力物力的浪费。如下图所示，此时在哇哦视频，后端绝大多数的工作在于调用中台的在线服务与离线服务，编写相关的业务逻辑来完成相关需求。

工作流

在淘系导购业务现今的开发中，一般都由一位前端搭配一位后端一起完成，每个需求的开发，都需要遵循开发 + 联调 + 测试的完整流程去进行。

而我也针对于哇哦视频最近的几次需求开发做了时间的分析，具体结果如下图所示：

后端同学得益于中台能力的完善支持，许多代码可以复用，因此开发工作量会小一些。而前端则由于 UI 开发的特性，许多东西需要推倒重来，难以复用（首页改版，整体样式都换了），所以工作量会稍微大一些。

这一套流程实际上已经相当成熟，但成熟并不代表完美。实际上开发过程中，痛点还是有很多的。

研发模式痛点

联调成本过高

首当其冲的痛点则是联调。在联调期中前后端需要不断对数据字段、业务逻辑进行确认，从而确保需求实现的正确性，而这种密集的沟通所带来的成本是非常高的。

如下图所示，在业务开发中我们发现联调成本一般要占到开发成本的 30% 左右。

居高不下的联调成本，一方面使得工程师们精疲力尽，另一方面也不利于业务的快速迭代。

前端资源化

值得一提还有前端资源化的痛点。

在目前前后端的分工模式中，前端只负责交互逻辑与相对应的 UI 实现，对于业务核心逻辑无需过多了解。虽然这使得前端团队可以快速完成某些业务，但同样也带来了前端资源化的隐患。而在强调前端要深入业务，具有商业化思考能力的今天，前端资源化实际上是不利于前端的自身发展的。

因为很多时候前端想去深入业务，想进一步升级自己的能力，但往往会苦于没有相关场景。至于说介入后端的工作领域，毕竟术业有专攻，很多事情也掺和不进去。

遇见 FaaS

吐槽归吐槽，但是工作还是要继续的。既然每天的工作有这么多痛点，那么是否有办法去尝试解决它呢？

恰好今年的四月份我开始参与淘宝导购体系 Node FaaS 相关建设的工作，开始接触到一些 Serverless & FaaS 相关的工作。在经过一段时间的基础建设后，我们需要一个业务作为试点业务来检验工作成果。

出于对自身能力升级的渴望，我主动梳理与分析了当前业务的特性，并且主动要求将哇哦视频作为 Node FaaS 的首个试点业务。

哇哦视频后端分析：

哇哦视频是一个主打纯视频的导购业务，流量高。基于对后端代码与日常需求的剖析，总结其特点为：运营位多、强依赖算法推荐、数据源多、无状态服务 四点。
其中运营位多 + 强依赖算法推荐的特性，使得业务具有一定的复杂度，改造工作量主要在于理解业务规则，填充数据。

而数据源多则代表其引用的外部服务较多，如视频服务、话题、特斯拉资源位定投等。该部分工作量主要在于熟悉上下游系统。

最后无状态服务是改造 FaaS 的大利好消息，无状态则意味着横向拓展极其便利，完美契合 FaaS 的工作场景。（其他导购业务应该也类似）

总结：哇哦视频复杂度适中，无状态的业务模型十分契合 FaaS 的业务场景，且个人在通读完代码后，有把握能 Hold 住整个后端业务迁移 FaaS 的需求。因此我认为哇哦视频迁移 FaaS 平台是具有高可行度的。

非常顺利，也没有任何波折的，哇哦视频成为了淘系首个 Node FaaS 试点业务。怀揣着对于能力升级的渴望，我开始尝试将现有的业务逻辑迁移至 Node FaaS 实现。


期望达到的效果如下图所示：

迁移进行中·

在正式进行迁移前，我和业务方沟通了这个事情对于业务可能产生的影响以及后续规划。业务方对于技术侧的改造是没有意见的，只有一个诉求，那就是业务不受影响。

整个诉求看似简单，拆解下来包括以下三部分：

• 不会为技术侧改造预留时间，原定需求要按时完成
• 迁移后线上不能出任何问题，线上对迁移无感知
• 后端工作交接至前端后，对后续需求推进无影响

说起来就是既要快，又要稳，还要能扛住后续需求。

针对这个诉求与当时的实际情况，我采取了以下三个措施，来保障整个迁移对业务侧没有影响：

• 快速 Copy Java 代码上线
• 使用 Java 兜底，保障线上稳定性
• 谨慎评估后续需求，确保需求可实现

Copy Java 代码上线

Copy & Paste 听起来像是不光彩的事情，但这并不是一件需要遮遮掩掩的事情。相反我现在还很庆幸自己在迁移刚开始时选择了这样的方式，而没有愣头青一样选择另起炉灶，从零开始。毕竟学会跑之前得先学会走路。

前面也提过，哇哦视频是一个大流量导购业务。即使诸多能力已经中台化，但必要的胶水代码 + 相关的业务逻辑代码，总行数也高达 5000 行左右。
选择从零开始固然炫酷，但是这样难以保障代码的稳定性，毕竟原有的业务代码不仅包含必要的业务逻辑，也包含了诸多的错误处理与边界处理，而技术侧改造是必须要考虑到稳定性问题的。

且对于原有 Java 代码的 Copy 也算是一种另类的学习方式了，在这个过程中对于 Java 开发也有了足够的了解，毕竟在整个集团都是 Java 技术栈的情况下，对于 Java 的学习与了解非常有利于后续工作的开展。

非常幸运的是，后端同学的代码质量很高，该有的注释一个不缺（如下图所示），因此整个读代码 & Copy 的过程非常流畅。

也因此在后续 FaaS 版本的哇哦视频提测时，是 0 BUG 直接上线的，节约了大量的返工时间，从而避免对业务需求造成影响。

使用 Java 兜底

这其实算是一个开发中的小 Tricks 了，但却足够好用。

在之前的导购研发中，为了避免后端宕机对线上带来的影响，因此网关层做了一个 CDN 容灾方案，如下图所示：

注释：

• XCtrl - 前端调用 mtop SDK
• TCE - 淘宝导购网关

对于前端同学而言，当请求线上接口失败时，前端的请求 SDK 就会根据当前请求数据，去 CDN 上获取最近成功的数据，从而确保对于用户端产品是可用的。
但目前导购侧的业务基本都接入了千人千面的算法，而 CDN 容灾的一个缺点便在于只是随机取一份成功数据存入 CDN，并不支持千人千面。


非常不妙的是，在我迁移 FaaS 时，底层能力还相对羸弱，时不时会有宕机等问题，这时候即使有 CDN 容灾能保障产品可用，但用户侧的体验依然是有一定损失的，属于有损降级。
而此时其实产品需求并未发生较大的变更，原有的 Java 接口也能继续使用，因此灵机一动准备将 Java 作为兜底的数据源，确保在降级的请求用户体验是完整的。


整体思路其实非常简单，请求路径整理如下：

• 之前的：Java 接口 - CDN 容灾
• 现在：FaaS 接口 - Java 接口 - CDN 容灾

得益于这种设计，哇哦视频在上线后，顽强的活了下来。即使那段时间底层时常不稳定，但对于用户体验来说并没有多少损失（两个接口 RT 都很短，请求两次基本无感）。

迁移之后

在完成代码迁移之后，便开始筹备上线的事情。上线的过程中倒是没有什么故事可以说，波澜不惊的按照既定节奏进行灰度、放量，慢慢的也就上线了。

在整个业务真正交接到自己手中的时候，我开始遇到了真正的麻烦。

这个需求我该怎么做？

随着技术侧改造的完成，业务交给我的新需求也得继续推进，于是迷迷蒙蒙的去参加了很多场业务需求会，接触了很多自己之前作为前端根本不会接触的方面。

但事情的进展并不顺利，自己刚转型成后端，很多事情都是迷迷糊糊的，似懂非懂。于是那段时间每天最大的疑惑就是：“这个需求我该怎么做？”虽说导购业务都是调用中台，但是一个需求到我手上，哪些应该调中台，哪些应该自己完成我都是不清晰的。

于是那段时间整个人的工作都变的非常拘谨，开始主动 Push 自己去学习和了解更多业务知识，了解更多后端的业务中台。整个人面对需求，进入了一种“谨慎评估”的状态。

遇到需求，首先做的不是一口答应承接下来，而是和业务确定具体要做的事情，然后拆分需求。根据业务方的指引与自己的认识，开始不断找各个对应的后端同学去学习和了解完成需求的方式。我记得有好几个下午，我都坐在之前哇哦视频后端同学的身边，不断询问和学习着后端完成问题的思路。

逐渐的，自己的状态从 “这个需求我该怎么做” 开始向 “这个需求我觉得应该这么做” 转变，整个人面对后端的工作状态从手忙脚乱像游刃有余转变。（其实这也算能力升级吧~毕竟可以 Hold 住更多的事情了）

总结

在整个迁移的过程中，个人最深刻的感受便是“撕裂”。因为 Serverless & FaaS 并不仅仅只是一种编程方式，它更多的是给了你去 Owner 业务的机会。

而为了把握住这个机会，你需要或主动或被动的去 Push 自己学非常多的东西，也需要思考比之前多的场景，比如：

• 业务的完整链路
• 业务需求与最终目标的关系
• 后端的工作方式
• 中间件、数据库、运维……
• ……

不断的学习新东西，不断的思考更多，不断的对原有自己造成更大的冲击。如果要给我迁移 FaaS 期间的感受下一个总结，那么一定是：“在撕裂中成长”。

回到我们最初的疑惑，我想我可以对第一个问题进行解答了：

• Q：FaaS 在业务中能落地吗？
• A：能，虽然过程很辛苦，但现在你们落地应该会好很多，因为坑都被我们填的七七八八了

而关于第二个问题：“FaaS 能帮助前端同学实现能力升级吗？”，我想看完全文的你，心中已经有了答案。这儿也给出我的答案：

• Q：FaaS 能帮助前端同学实现能力升级吗？
• A：能，且能力升级并不止于技术，更多的是业务思维的成长。FaaS 使得前端有机会可以更深入业务，从而更好的去支持业务。技术能力与业务思维共成长，非凡不止一面。

前言

如果说近期我最关注的的事情，那么无疑是 TS 3.7 的更新。因为在官方的迭代计划中，其包含了众多令人期待的新功能。

其中在 TS 语言层面的更新令我尤为激动（具体的改动可以看下面的链接）

• Optional Chaining
• Nullish Coalescing
• Assertion Signatures
• Recursive Type References
• ECMAScript Private Fields
• Top-Level await

而今天我想介绍的，就是 TS 3.7 中个人认为最甜的语法糖：“Optional Chaining & Nullish coalescing operator”

Optional Chaining

这个 Feature 于我而言，是相当有用的特性。

因为我相信，大部分的开发者都和我一样，为了保证能正确的取到值与代码不报错。写过这样的代码：

1
2

const res = getData();
const videoCover = res && res.data[0] && res.data[0].video && res.data[0].video.cover;

虽然可以通过一些类似于 lodash.get/ts-optchain 的工具去解决这个问题，但总归是需要考虑包体积与兼容性的问题。

而且这个 Feature，其实已经在 C#/Swift/Kotllin/… 等主流语言存在多时，属于常见功能。
于是就有人在 TC 39 发起了 proposal-optional-chaining 的提案，时至今日已经是处于 Stage 3 状态，即将合并进入 ECMAScript。

Syntax

这个语法糖可以说是相当简洁易懂了，如下面的代码所示。

1
2
3

obj?.prop; // optional static property access
obj?.[expr]; // optional dynamic property access
func?.(...args); // optional function or method call

你可以通过 ?. 的操作符，实现可选链式调用，其中包括以下功能：

• 读取属性
• 读取动态属性
• 执行函数

基本上 Cover 到了我们日常使用的情况。

Demo

举个 🌰，可以看下面的获取属性 Demo，不难看出获取属性从此可以变得非常简洁：

1
2
3
4
5

let nestedProp = obj.first && obj.first.second;

// ===>

let nestedProp = obj.first?.second;

通过使用?.操作符取代.操作符。JavaScript 知道在尝试访问obj.first.second之前先明确的校验并确定obj.firstt 是非null且非undefined。如果obj.first是null或undefined，表达式将会短路计算直接返回undefined。

MDN - Optional Chaining

Nullish coalescing operator

另一个值得关注的 Feature 是 Nullish Coalescing，同样也是进入了 stage 3。

这是与 proposal-optional-chaining 十分搭配的 feature，通过 ?? 来表示默认值的功能。（感觉后续会看见 JS 中遍地都是 ?????? 的场景。。）

Nullish coalescing 的用法和 JS 的默认值语法：“||”非常像，但还是有一些本质的不同。

“||” 语法在进行判断时，实际上是基于 JS 的 Truthy 特性去判断的。隐式类型转换带来的问题，代表着在 “0 || 1 ”之类的场景下，实际上可能是不符合用户期望的。

而 “??” 的判断条件则更为严谨，我们称之为 nullish。nullish 实际上指的是这个值与 null/undefined 严格相等，因此与 Optional Chaining 可以说是相当搭配了。

Demo

举个 🌰，可以通过下面的示例了解这个 feature。

1
2
3
4
5
6

false ?? true; // => false
0 ?? 1; // => 0
'' ?? 'default'; // => ''

null ?? []; // => []
undefined ?? []; // => []

真甜

上面两个 feature 总结下来，非常符合语法糖的特性：“使用简单，用户友好”。

而同时在 TC39 的 Proposals 中，我们可以看到许多类似的提案正在不断的被提出，不断的在简化着我们的编码：

• globalThis
• Private fields
• ……

不得不说，虽然语法糖有一定的学习成本，但是：

首先我们需要明确的是，ECMAScript Modules 在现在已经不是什么新鲜事了。
早在 ES6 规范推出时，我们通过 Babel/TypeScript 等工具便已能在项目中使用该 Feature，那为什么我们还需要关注该 Feature 在 Node.js 上的实现与具体使用呢？

答案是明确的，因为 ECMAScript Modules 在 Node.js 规范中的实现与使用，实际上与现今 Babel/TypeScript 的使用是有较大的区别的。

关于这一点，我想从 Babel/TypeScript 当时的设计思路上去分析。

Babel/TypeScript 的设计思路

首先我们看一下 Babel/TypeScript 的 Slogan：

• Babel：Babel is a JavaScript compiler：Use next generation JavaScript, today.
• TypeScript：TypeScript is a typed superset of JavaScript that compiles to plain JavaScript.

从两个产品的 Slogan 上不难看出，Babel 专注于通过编译，在现在的 JS 引擎中使用最新的 JS Feature。而 TS 则是通过编译，实现静态类型的校验等。

而这两者的最终产物都受限于当前 JS 引擎的能力，也就是说 Babel 和 TypeScript 并不能凭空模拟出之前 JS 引擎尚未支持的 Feature。

这一点非常重要，因为在 Babel 与 TypeScript 对 ECMAScript Modules 时，实际上是编译成 Node.js 所支持的 CommonJS 规范，从而使得最终产物可以在 Node.js 上运行。

也就是说，当时我们的使用方式，其实是遵循了 CommonJS 的规范的，只是写法上是 ECMAScript Modules 而已。且由于底层缺失对于 ECMAScript Modules 的强约束（因为还不存在），所以大家的写法上也都是五花八门的，只能最终编译成 CommonJS 时能运行即可。

而 Node.js 12 的这个 Feature，则对 ECMAScript Modules 的开发与使用做了强约束，所以在正式开始使用该规范前，我们还是需要对其有一定的了解的。

启用 Feature

通过 –experimental-modules ，我们可以在 Node.js 中启用该 Feature。

当设置该选项时，Node.js 便会以 ECMAScript Modules 的方式去解析 JS 并运行，在这儿值得注意的是，在新模式下，文件的后缀与解析规则也发生了变更。

在该 Feature 下，文件分为了以下几种后缀：

• .mjs：ECMAScript Modules 模式，使用 import/export
• .cjs：CommonJS 模式，也就是原有的 Node.js 模块解析方式
• .js：在 ECMAScript Modules 模式下，如果 package.json 中 的 type 字段为 module 时（后文会提及），则该文件会被认为是符合 ES Module 规范的文件。

通过 package.json 区分模块类型

ECMAScript Modules 由于具体实现上与之前的 CommonJS 有较大区别，因此在使用时是需要对两种情况进行区分的。而官方则提供了一种简单有效的方式，那就是通过 package.json 中的 type 字段。

该字段主要影响该 package 下 .js 后缀的解析，而新增的 .cjs/.mjs 后缀则从文件名上已经做了类型区分，Node 会根据后缀切换不同的解析方式。

在规范中，package.json 的 type 字段一共有两种值，”module” 与 “commonjs”，而当 type 字段不存在时则默认使用 “commonjs” 来适应原有规范。

1
2
3
4

// package.json
{
  "type": "module" | "commonjs"
}

而在具体使用时，当导入项目中的 js 时，根据 type 的值，会有以下两种情况：

• module：以 ECMAScript Modules 模式解析
• commonjs：以 commonjs 的方式解析

通过这种设计，我们可以非常方便的实现对原有代码的兼容，且 CommonJS 与 ES Modules 之间也能互相引用，Node.js 会处理好运行时的一切。

至于解析的例子，大家可以看下面的代码：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

// package.json 中 "type" 为 "module".

// 以 ECMAScript Modules 解析与加载
import './startup/init.js';

// 以 CommonJS 加载，因为 ./node_modules/commonjs-package/package.json
// 缺乏 "type" 字段或者 "type" 为 "commonjs".
import 'commonjs-package';

// 以 CommonJS 加载，因为 ./node_modules/commonjs-package/package.json
// 缺乏 "type" 字段或者 "type" 为 "commonjs".
import './node_modules/commonjs-package/index.js';

// 以 CommonJS 加载，因为 .cjs 后缀即代表该模块遵循 CommonJS 规范.
import './legacy-file.cjs';

// 以 ECMAScript Modules 加载，因为 .mjs 后缀即代表该模块遵循 ECMAScript Modules 规范.
import 'commonjs-package/src/index.mjs';

ES Modules 与 CommonJS 的区别

在 Node.js 的实现中，ES Modules 实际上与 CommonJS 的规范在部分细节上已有了较大的区别。这部分差异直接影响到我们书写代码的方式，因此我会具体贴出部分重要改动。

导入模块时需要提供文件拓展名

在 CommonJS 时代，我们在导入模块时无需书写文件后缀，而是由 Node.js 自行通过 extensions 来加载指定文件。如 import ‘index’ 在 Node.js 中实际上会加载 index.js，Node 会帮忙自动尝试加载该文江。
而在 ES Modules 规范下，导入一个模块时，我们需要提供确切的文件拓展名。

这一点虽然对比现在的方案缺失了灵活性，但却使得整体模块的依赖关系可以在编译时就确定，而不需要等到运行时。这是符合 ES Modules 的设计初衷的。

require, exports, module.exports, filename, dirname

Node 在实现 CommonJS 规范时，实际上给每一个文件都做了包裹，传入了以上的这些变量，从而使得在代码中可以使用 require/exports 等方式实现模块化。

而在 ES Modules 规范下，这些都将不复存在。这一点对于原有的代码而言，是一个非常大的变更。
这也就是为什么在 Babel/TypeScript 等工具体系下，明明可以使用 ES Modules 进行开发了，还需要关注 Node 具体实现的原因，因为之前的代码强依赖于这些变量，在新规范下必须进行修改才能继续使用。

然而这些都是 Node 运行的基础，总不能一下子就没有了吧？答案是确定的，这些变量在 ES Modules 规范下的使用方式，Node 官方也给出了具体的方案：

比如 require，可以通过 module.createRequire() 方法使用。

又比如 filename 与 dirname：

1
2
3
4
5

import { fileURLToPath } from 'url';
import { dirname } from 'path';

const __filename = fileURLToPath(import.meta.url);
const __dirname = dirname(__filename);

import.meta

这儿其实有一个小知识，那就是关于 import.meta 的。
在 MDN 的文档中，解释如下：

import.meta是一个给 JavaScript 模块暴露特定上下文的元数据属性的对象。它包含了这个模块的信息，比如说这个模块的 URL。

1
2
3
4
5
6

console.log(import.meta);

// 输出
{
  url: 'file:///home/user/my-module.mjs';
}

没有 require.extensions 与 require.cache

在 ES Modules 规范中，require.extensions 与 require.cache 将不再被使用。

基于 URL 的文件路径

在文件路径上，ES Modules 的解析与缓存是基于 URL 规范的。
这也就意味着，模块实际上是可以携带查询参数的，且当查询参数不同时，Node 会重新加载该模块。

1
2

import './foo.mjs?query=1'; // loads ./foo.mjs with query of "?query=1"
import './foo.mjs?query=2'; // loads ./foo.mjs with query of "?query=2"

总结

在此需要特别提及的是，目前 Node.js 所提供的 ECMAScript Modules 规范并非是最终解，其具体实现与诸多技术细节未来也可能进行一定的调整。
比如关于 CommonJS 与 ES Modules 的互相调用，实际上是还没有完全确定下来的（因此我这儿也没有特别去阐述如何使用）。也因此在 Node.js 的文档中，ECMAScript Modules 规范的稳定性等级还是 1，属于 Experimental 。

而个人对于 ECMAScript Modules 规范态度，总体是看好的。强有力的约束有利于 Node.js 去做更多的优化，统一的模块规范则避免了浏览器与 Node.js 生态的进一步割裂。虽然过程是曲折，但前途却充满了光明。

参考文档

• ECMAScript Modules - Node.js 官方文档
• Plan for New Modules Implementation - Node.js 规划
• The new ECMAScript module support in Node.js 12 - 2ality
• import.meta - MDN

起因

最近因为工作等原因，开始接触到 ncc 这样的 Node 打包方案，而在阅读其源代码的时候，看到了如下的一段代码，用来引入 Typescript 模块的，代码不长，但是很有意思。

代码如下：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

const { Module } = require('module');

const m = new Module('', null);
m.paths = Module._nodeModulePaths(process.cwd() + '/');

let typescript;
try {
  typescript = m.require('typescript');
  console.log('ncc: Using typescript@' + typescript.version + ' (local user-provided)');
} catch (e) {
  typescript = require('typescript');
  console.log('ncc: Using typescript@' + typescript.version + ' (ncc built-in)');
}

module.exports = typescript;

整个代码的运行规则比较简单，当本地存在 TypeScript 模块时，则引入本地的，否则引用当前项目中内置的 TypeScript。
仔细想想，这其实在开发工具时是一个非常常见的需求，部分涉及到运行时的依赖，框架在调用时希望优先引用用户本地的版本，本地不存在则引用内置或者全局安装的版本。

而我则对其原理产生了好奇，自己之前也没有见过 module 模块，更没有见过这种可以自由改变模块加载时搜索路径的用法。

本文则是本人的探秘之旅，也仅仅专注于这一个问题上，并不扩散。

module 模块的实现

Node 中，关于 Module 部分的源代码在 lib/internal/modules/cjs/loader.js 中。整个文件的“分量”还是有些重的，代码量高达 1000+ 行。

直奔主题，从代码中我们不难发现，我们首先初始化了一个 Module 的实例，并通过调用 _nodeModulePaths 的静态方法，设置实例的 paths 为当前目录。

那么，通过对以下几个要点的探索，我们应该就可以得出想要的答案：

• _nodeModulePaths 方法内部的实现
• Module 实例中，paths 变量的作用
• 调用 Module 实例的 require 方法，是怎么样引入模块的

_nodeModulePaths，引用模块时，逐级查找 node_modules 的秘密

在代码中，我们通过 Module._nodeModulePaths(process.cwd() + '/') 的方式，来设置 Module 的 paths 变量。

而这也是一段非常有趣的代码，大家都知道 Node 在定位模块时，是会逐级的向上查找的。而向上查找路径的生成代码，就是这个 _nodeModulePaths 函数。

代码如下：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36

const CHAR_FORWARD_SLASH = 47;
const nmChars = [115, 101, 108, 117, 100, 111, 109, 95, 101, 100, 111, 110];
const nmLen = nmChars.length;

function _nodeModulePaths(from) {
  // Guarantee that 'from' is absolute.
  // Return early not only to avoid unnecessary work, but to *avoid* returning
  // an array of two items for a root: [ '//node_modules', '/node_modules' ]
  if (from === '/') return ['/node_modules'];

  // note: this approach *only* works when the path is guaranteed
  // to be absolute.  Doing a fully-edge-case-correct path.split
  // that works on both Windows and Posix is non-trivial.
  const paths = [];
  var p = 0;
  var last = from.length;
  for (var i = from.length - 1; i >= 0; --i) {
    const code = from.charCodeAt(i);
    if (code === CHAR_FORWARD_SLASH) {
      if (p !== nmLen) paths.push(from.slice(0, last) + '/node_modules');
      last = i;
      p = 0;
    } else if (p !== -1) {
      if (nmChars[p] === code) {
        ++p;
      } else {
        p = -1;
      }
    }
  }

  // Append /node_modules to handle root paths.
  paths.push('/node_modules');

  return paths;
}

Online Demo

调用如下：

1
2
3
4
5
6
7
8
9
10

console.log(_nodeModulePaths('/Users/lxxyx/playground/node'));

// output
[
  '/Users/lxxyx/playground/node/node_modules',
  '/Users/lxxyx/playground/node_modules',
  '/Users/lxxyx/node_modules',
  '/Users/node_modules',
  '/node_modules',
];

可以看到，这个路径是由传入的目录决定，并逐级生成的。

因此，在此我们可以明确我们的两个疑惑：

• _nodeModulePaths 方法内部的实现：通过对传入路径的处理，生成 Node 引用模块时逐级引用的目录，由于是根据用户传入的变量生成的，因此也会改变引用模块的初始路径
• Module 实例中，paths 变量的作用： Node 引用模块时逐级引用的目录路径

require 方法，引入模块的具体实现

require 方法应该是每个接触 Node 同学最为熟悉的函数之一，其核心作用便是引用模块。

而之前的我却也只是知其然而不知其所以然，只是看些文章，未曾深入的学习与理解，似懂非懂的。

首先我们看像 require 的源代码：

1
2
3
4
5
6
7
8
9
10
11
12
13
14

// Loads a module at the given file path. Returns that module's
// `exports` property.
Module.prototype.require = function (id) {
  validateString(id, 'id');
  if (id === '') {
    throw new ERR_INVALID_ARG_VALUE('id', id, 'must be a non-empty string');
  }
  requireDepth++;
  try {
    return Module._load(id, this, /* isMain */ false);
  } finally {
    requireDepth--;
  }
};

代码相对简单，核心逻辑都在 Module._load 方法中实现了。

Module._load，引入模块的内部实现

Module._load 方法是一段较长的函数，有五六十行，里面包括了模块的加载、缓存、解析等机制，可以说是引入模块的核心逻辑。

而 Node 的开发者们，也非常贴心的留下了注释供我们参考：

// Check the cache for the requested file.
// 1. If a module already exists in the cache: return its exports object.
// 2. If the module is native: call
// NativeModule.prototype.compileForPublicLoader() and return the exports.
// 3. Otherwise, create a new module for the file and save it to the cache.
// Then have it load the file contents before returning its exports
// object.

由于内部逻辑较多，且许多与本次探讨的内容无关，因此关于该方法，我会着重于探索以下几个问题（也是个人比较感兴趣的）：

• 缓存逻辑是怎么实现的
• Node 如何加载一个模块，模块中调用的 exports/require 等对象又是从哪儿来的
• 加载模块时，如何通过 paths 变量改变引入模块时查找的 node_modules 目录

缓存逻辑的实现

Node 中关于 require 的缓存逻辑比我想的要简单许多。
缓存仅仅是一个对象，通过：Module._cache = Object.create(null); 来创建。

每次加载文件时，当发现这是一个新文件时，则通过唯一的文件名作为 Key，存入该模块的实例。
而当重复加载某文件时，则会先检查缓存中是否已存在，有的话则返回已存在的实例。

代码：

1
2
3
4
5
6
7
8

// 设置缓存
Module._cache[filename] = module;

// 从缓冲中取出
const cachedModule = Module._cache[filename];
if (cachedModule !== undefined) {
  return cachedModule.exports;
}

通过这也不难发现，如果一个文件被缓存起来了，那么在整个生命周期内，它都是在缓存中的。

想要更新也很简单，清空一下 cache 对象即可，而我们常用的清除 require.cache 方式，实际上是清空的 Module 的 _cache，这一点在代码中也有所表示：

1

require.cache = Module._cache;

如何加载一个 JS 模块

在 Node 中，加载某个具体的文件是通过 module.load(filename); 方法实现的。

load 方法源码如下：

1
2
3
4
5
6
7
8
9
10
11
12

// Given a file name, pass it to the proper extension handler.
Module.prototype.load = function (filename) {
  debug('load %j for module %j', filename, this.id);

  assert(!this.loaded);
  this.filename = filename;
  this.paths = Module._nodeModulePaths(path.dirname(filename));

  const extension = findLongestRegisteredExtension(filename);
  Module._extensions[extension](this, filename);
  this.loaded = true;
};

在源码中有一行关键的代码：Module._extensions[extension](this, filename);。而这行代码负责引入文件的编译与执行，这也是我们本次想了解地方。

Module._extensions 实际上是一种模块加载的机制，通过定义后缀名与处理方法，来去支持某个文件在 Node 代码中的直接引入。

JS 代码的处理如下：

1
2
3
4
5

// Native extension for .js
Module._extensions['.js'] = function (module, filename) {
  const content = fs.readFileSync(filename, 'utf8');
  module._compile(content, filename);
};

模块的编译与执行

从代码中不难看出，此处先读取了代码的内容，并且 JS 代码进行了编译操作。

而在 module._compile 的实现中，调用了 C++ ，将其包裹为一个函数：

比如你书写的代码：

1
2
3
4
5

const fs = require('fs');

fs.readFile('./file.txt', 'utf-8', (err, data) => {
  console.log('data: ', data);
});

将在 compile 后变为：

1
2
3
4
5
6

(function (exports, require, module, __filename, __dirname) {
  const fs = require('fs');
  fs.readFile('./file.txt', 'utf-8', (err, data) => {
    console.log('data: ', data);
  });
});

这其中就包括了运行时的一些关键变量，exports/require/__filename 等。
执行时则是通过传入这些预先定义或者生成好的变量，来执行并拿到结果：

而执行结果，就包括 module.exports 变量，可以通过这个变量拿到这个模块导出的所有内容。
至此，我们就可以将整个 require 的链路完整的串起来了。

paths 变量对于引用模块的影响

回到我们一开始的问题，我们通过定义 paths ，使得 require 的查找路径可以从我们指定的目录开始。
那么自然我们也想知道这部分在代码中是如何实现的。

在代码中，关于这部分的代码有这么几段：

• 基于传入的 paths 生成最终需要查找的目录：链接
• 依据 paths ，逐级查找 npm 包：链接
• 根据 npm 包中的 main 字段，定位到最终 require 的文件：链接

那么关于这个问题，我想也有明确的答案了。

后记

而此次对于 Node 模块加载机制的深入学习与了解，于我而言是更了解底层实现的一个过程，除此之外感受最深的则是：代码虽然很多，但读起来完全不会觉得累或者绕弯子。看似冗长的变量名，恰到好处的注释，一点也不“优雅”的代码组织方式，恰恰让这段代码比许多代码都要好读。

现在想想，ES201X / TypeScript / ESLint 等诸多工具，其实与能不能写出好的代码关系不大，从道术器的理论来探讨，工具也只是“器”而已，具体还是要看使用者的道行。

希望自己将来也可以写出这种“容易看懂”的代码吧~

现在的我认为，好的体验定义从不应该局限于 UI、工具、技术体系。
它指的是一种以人为本的产品设计理念，目标是辅助使用者尽可能高效的去理解庞杂的系统并自然完成某些工作任务。

好的体验应当辅助用户理顺整个流程的生产关系，尽可能的减少工作中不必要、反人性的事务，使整体使用变的自然且高效。

前端的价值

前端的价值在于创造尽可能好的体验，在不同阶段对于体验的要求也不一样。

• 写出一段好的代码，后面的同学维护起来很方便，那么你在代码层面创造了好的体验。
• 开发了一个简洁易用的工具，特定场景下的使用者感觉好用，那么你在工具层面创造了好的体验。
• 设计出一个完整的体系，解决了某个领域的问题，你开始创造价值，但并不一定创造了好的体验。
• 归纳总结某个体系，理顺生产关系，减少不必要的事物，提升生产力。那么你在某个领域下创造了更好的体验。

前端的价值不只是 Code Less，而应该是 Input Less，降低人力投入。
技术要有投入产出比，而技术产品也要考虑。

随着 React 版本的更迭，越来越多的新 Feature 加入到了 React 当中，其中需要 Api，在社区都引起了极大的反响与相当的争议。

而 React Hooks ，则是社区最近热议的话题，个人也对其十分的感兴趣。
比如下面的例子，便能实现一个简单的计数器。

1
2
3
4
5
6
7
8
9
10
11
12
13

import { useState } from 'react';

function Example() {
  // Declare a new state variable, which we'll call "count"
  const [count, setCount] = useState(0);

  return (
    <div>
      <p>You clicked {count} times</p>
      <button onClick={() => setCount(count + 1)}>Click me</button>
    </div>
  );
}

简洁而不简单

正如上面的例子说是，Hooks 的代码看上去非常的简洁易懂，然而背后原理却不简单。看似是纯函数，却自身拥有状态。这种“黑魔法”让我着了迷，不自觉的想去了解其中的原理。

在查看源代码与相关文章之前，凭借着自己的编程知识，我做了如下几个假设：

• 使用 Hooks 的函数式组件，看似函数内部并没有保存状态，但其状态一定存在于某个地方，只是我们看不见。
• 由于内部状态依赖于外部调用，因此这种关系是非常脆弱，且容易被更改的，所以使用 Hooks 的组件，需要准备某种强规范才能确保运行时不出问题。

Rax 与 Hooks

Rax 是阿里巴巴的淘宝前端团队开源的类 React 框架，拥有速度快，体积小，适配多种容器等诸多优点。

官方介绍如下：

「Rax 基于 React 的标准，支持在不同容器中渲染，当前最重要的容器即 Weex 和 Web」

而自己在校招时，有幸加入了淘宝前端团队，并且与 Rax 的核心开发者们有过一段时间的讨论与交流，收益颇多。

在 React 甩出 Hooks 这个重磅 Feature 时，我有幸与 Rax 之父元彦讨论过 React Hooks 的实现机制与原理。我当时的想法是 Hooks 是基于 React Fiber 的，没有 Fiber 就没有 Hooks。而元彦则认为目前 Rax 基于递归的方式，也可以做出 React Hooks 的效果。

过了几天，在我日常浏览 Github 获取第一手知识与信息的时候，我看到 Rax 的仓库里多了个 PR：

仔细看了一下，不太相信自己的眼睛，随后又认真的看了几遍，确认是 Hooks 相关的 PR。
元彦实现了自己的想法，而我在知道自身想法不足之余，也想看看不基于 Fiber 的 Rax，是如何实现 Hooks 的这个 feature。

关于 Hooks 的疑惑

首先，看一个上文提到过的 Demo：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

import { useState, useEffect } from 'rax';

function Example() {
  // Declare a new state variable, which we'll call "count"
  const [count, setCount] = useState(0);

  useEffect(() => {
    document.title = 'Count: ' + count;
  });

  return (
    <div>
      <p>You clicked {count} times</p>
      <button onClick={() => setCount(count + 1)}>Click me</button>
    </div>
  );
}

这是一个大家都能轻易看懂的 Demo，而从上述的代码中，可以得到三点信息：

• 这个函数式组件会被 Rax 调用
• 函数式组件内部调用了 Rax 内置的 useState 方法，来获得最新状态与修改的方法。
• 在调用 setCount 改变 count 时，也会触发 useEffect 所定义的回调

我个人的疑惑如下：

• 函数内部不保存状态，那么这个状态究竟是保存在哪儿，怎么样确保每次重新渲染组件，都能拿到正确的值？
• 在调用修改状态的方法后，为何能触发组件更新？
• 在状态改变后，为何 useEffect 也能够被调用？

而在这儿，首先要介绍一下 Rax 是如何渲染函数式组件的。

Rax Hooks 原理解析

函数式组件的渲染

在 Rax 这儿，并没有直接去调用函数式组件，来获取生成的 Elements（created by createElement），而是将函数式组件做了一层包裹，简化后的代码如下：

1
2
3
4
5

// 函数式组件
if (typeof Component === 'function') {
  // Functional reactive component with hooks
  instance = new ReactiveComponent(Component);
}

在代码中，可以看出如果是函数式组件，函数式组件会被 ReactiveComponent 包裹一层。而注释中也明确的写着：”Functional reactive component with hooks”。此处不难看出，这个 ReactiveComponent 就是 Hooks 的运行时的核心了，并且与 useState 、useEffect 等 Api 共同组成了 Hooks 这个功能。

首先，让我们来看一看，useState 作为核心的 Api，在运行期都做了什么？

useState 的实现

useState 的 API 如下，传入 initialState，便可以获得两个返回值，state 与 setState，第一个代表当前值，第二个则是函数，可以更新当前值，属于非常简洁易懂的 Api。

1
2
3
4
5

// 初始化 state
const [state, setState] = useState(initialState);

// 更新状态
setState(newState);

在这儿其实还有一段小插曲，Hooks 用的是数组解构的方式来传递当前值与更新的函数，有人则在 React RFC 中提出为何不用对象的结构方式，对此官方给出的解释是：对象结构需要指定名字，而基于数组的结构不用，你可以随意命名。

1
2
3
4
5

// 初始化 state
const [state, setState] = useState(initialState);

// 更新状态
setState(newState);

在这儿，我们看向 Rax 中，useState 的具体实现方式（为方便理解，精简部分代码）：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29

// 获取当前正在渲染的组件，设置时机如下：
// 此处 Component 为当前正在处理中的组件
// 1. currentInstance = Component
// 2. Component.render() 【也就是说在组件 render 期间，currentInstance 是组件自身】
// 3. currentInstance = null
function getCurrentRenderingInstance() {
  const currentInstance = Host.component._instance;
  return currentInstance;
}

function useState(initialState) {
  const currentInstance = getCurrentRenderingInstance();
  const hookId = currentInstance.getCurrentHookId();
  const hooks = currentInstance.hooks;

  if (!hooks[hookId]) {
    const setState = (newState) => {
      const current = hooks[hookId][0];
      if (newState !== current) {
        hooks[hookId][0] = newState;
        currentInstance.update();
      }
    };

    hooks[hookId] = [initialState, setState];
  }

  return hooks[hookId];
}

在 useState 函数中，第一步便是取得当前正在渲染中的组件。而 currentInstance 这个值，是在组件调用 render 前被设置的，render 结束后便会被设置为 null。

而这也就意味着：组件在 render 期间调用 useState ，useState 函数是可以知道当前渲染的组件的，同一个函数式组件的调用，拿到的 currentInstance 永远是其自身。

我们的疑惑点在于：函数内部不保存状态，那么这个状态究竟是保存在哪儿，怎么样确保每次重新渲染组件，都能拿到正确的值？

现在看来，一切仿佛都有了头绪，既然我能在调用 useState 时，拿到当前的实例且同一个函数式组件，每次调用 useState 都能获取到当前实例。那么当前实例将会是一个保存与隐藏组件状态的最佳地点。

原因如下：

• 同一组件，获取到 currentInstance 始终是其自身，储存其中的数据，并不受 Rax 的更新影响
• 不同组件，获取到的实例也不一样，通过 useState 获取到的状态，也互不影响

这样一来，所有的函数式组件，调用的同一个 useState 方法，却互不影响，既保证了代码的整洁性，又保证了功能的完善性，该处理方法不可谓不巧妙。

而在前面我们提到过，Rax 的函数式组件，是被 ReactiveComponent 所包裹着的，而在 useState 的具体实现中，也出现了 getCurrentHookId 等属于 ReactiveComponent 的方法调用，因此想要理解透彻 Rax 的 Hooks 机制，我们需要看 ReactiveComponent 的实现。

ReactiveComponent 的实现

首先，看源代码（为方便理解，精简部分代码）：

核心参数解释如下：

• pureRender：传入的函数式组件，调用方式如下：

1
2
3
4
5
6
7
8
9
10

// 函数式组件
function Component() {
  return <h1>Hello Hooks</h1>;
}

// 函数式组件的初始化
if (typeof Component === 'function') {
  // Functional reactive component with hooks
  instance = new ReactiveComponent(Component);
}

ReactiveComponent 源码：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30

function scheduleImmediateCallback(callback) {
  setTimeout(callback, 99);
}

class ReactiveComponent extends Component {
  constructor(pureRender) {
    super();
    // A pure function
    this.pureRender = pureRender;
    this.hooksIndex = 0;
    this.hooks = {};
  }

  getCurrentHookId() {
    return ++this.hooksIndex;
  }

  // Async update
  update() {
    scheduleImmediateCallback(() => this.forceUpdate());
  }

  render() {
    this.hooksIndex = 0;
    let children = this.pureRender(this.props);
    return children;
  }
}

export default ReactiveComponent;

而此时再看 useState 的源码，一切都清晰了起来。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30

// useState 源码

// 获取当前实例，此处指的是 ReactiveComponent
const currentInstance = getCurrentRenderingInstance();
// 获取当前调用的 Hooks 下标，用于解决函数式组件内调用多个 Hooks 的问题
const hookId = currentInstance.getCurrentHookId();
// 之前存放的 Hooks，
const hooks = currentInstance.hooks;

// 如果是首次渲染，则创建这个 Hooks 的值与对应的更新函数
// hooks[hookId] 指代当前调用的 Hooks 所对应的 [state, setState]
if (!hooks[hookId]) {
  // 更新函数
  const setState = (newState) => {
    // 上一次的 state 值
    const current = hooks[hookId][0];
    if (newState !== current) {
      // 如果值更新了则更新 State
      hooks[hookId][0] = newState;
      // 调用 ReactiveComponent 的 update 方法
      // 而 update 方法会在 99ms 后调用 forceUpdate 来更新组件
      currentInstance.update();
    }
  };

  hooks[hookId] = [initialState, setState];
}

// 返回当前调用的 Hooks 所对应的 [state, setState]
return hooks[hookId];

引申出一个小话题
Q：Why ReactiveComponent 在调用 update 方法时，需要延迟 99ms 执行？
A：Rax 中 forceUpdate 是同步执行的，如果 update 方法同步执行，则会造成 Hooks 下标的错乱问题。

大家有注意到，在这儿，我们提起了一个之前未曾提起的概念：当前执行 Hooks 的下标。由于函数内部可能会不止一次调用 Hooks ，因此需要实现一个多次调用钩子的解决方案。

多次调用 Hooks 的实现方式

首先，看一段代码：

1
2
3
4
5
6
7
8
9
10
11
12
13

// useState.js
const hookId = currentInstance.getCurrentHookId();

// ReactiveComponent
getCurrentHookId() {
  return ++this.hooksIndex;
}

render() {
  this.hooksIndex = 0;
  let children = this.pureRender(this.props);
  return children;
}

在组件 Render 前，ReactiveComponent 会把 hooksIndex 设置为 0，而在后续的过程中，每次调用 useState 等 Hook 时，都会将 hooksIndex 执行 +1 操作。而这样则保证了，同一个组件内部，不同的 Hooks 调用，相互之间是不影响的。

这样一来，便允许函数内部存在多个 Hooks，且相互之间不影响。因为每次调用时，都会获取到一个独一无二的下标。

但是这样做，也带来了另外一个问题，那就是函数内部的 Hooks 调用是强依赖于执行顺序的。

Hooks 所带来的问题

具体原因可以看下面一段伪代码：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22

function Example(props) {
  let count, setCount;

  if ((props.useCounter = true)) {
    [count, setCount] = useState(0);
  }

  const [name, setName] = useState('Hello');

  return (
    <div
      onClick={() => {
        setCount && setCount((count += 1));
      }}
    >
      {name}： {count}
    </div>
  );
}

Example({ useCounter: true });
Example({ useCounter: false });

我们知道，hooks[hookId] 代表着对应 Hooks 存放数据的地方，而在此处，第一次渲染时，Props 中的 useCounter 为 True，此时：

1
2

hooks[0] = [count, setCount];
hooks[1] = [name, setName];

而第二次渲染时，Props 中的 useCounter 为 False，而 Hooks 是不会重复创建的，因此：

1
2
3
4
5
6
7
8

// example.js
const [name, setName] = useState('Hello');

// useState.js
// 调用 useState('Hello') 时
hookId = 0;
hooks[0] = [count, setCount];
return hooks[0];

你调用的明明是 useState('Hello') ，但返回的却是 hooks[0] = [count, setCount] ，这就会引发未知的 BUG。

而这恰恰也是 Hooks 所带来的问题与争议，React 开始变的不那么明确，或多或少的有了一些隐式规则，对于这个问题，Facebook 官方提出的解决方案是引入一个 ESLint 插件，来确保 Hooks 的正确书写。

插件地址如下：https://github.com/facebook/react/blob/ab03e3d6518ae3c68feca8d5debf2ef69a91a38c/packages/eslint-plugin-react-hooks/README.md

解决了一个问题，引入了新的问题，打上了新的补丁。

useEffect 的实现

在上文中，我们解答了最开始的两个疑惑：

• 函数内部不保存状态，那么这个状态究竟是保存在哪儿，怎么样确保每次重新渲染组件，都能拿到正确的值？
• 在调用修改状态的方法后，为何能触发组件更新？

我们还剩下最后一个疑惑：“在状态改变后，为何 useEffect 也能够被调用？”。

如下面的例子：

1
2
3
4
5
6
7
8
9
10
11
12
13

function Example() {
  const [width, setWidth] = useState(window.innerWidth);

  useEffect(() => {
    const handleResize = () => setWidth(window.innerWidth);
    window.addEventListener('resize', handleResize);
    return () => {
      window.removeEventListener('resize', handleResize);
    };
  });

  return <p>Window width is {width}</p>;
}

就实现了以下的效果：

• 状态改变后， useEffect 也能够被正确调用
• useEffect 可以返回一个函数，在组件取消订阅时使用

这儿需要再次看向 ReactiveComponent 的源代码（精简部分逻辑）：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41

class ReactiveComponent extends Component {
  constructor(pureRender) {
    super();
    // A pure function
    this.pureRender = pureRender;
    this.hooksIndex = 0;
    this.hooks = {};
    this.didMountHandlers = [];
    this.didUpdateHandlers = [];
    this.willUnmountHandlers = [];
  }

  componentDidMount() {
    this.didMountHandlers.forEach((handler) => handler());
  }

  componentDidUpdate() {
    this.didUpdateHandlers.forEach((handler) => handler());
  }

  componentWillUnmount() {
    this.willUnmountHandlers.forEach((handler) => handler());
  }

  getCurrentHookId() {
    return ++this.hooksIndex;
  }

  // Async update
  update() {
    scheduleImmediateCallback(() => this.forceUpdate());
  }

  render() {
    this.hooksIndex = 0;
    let children = this.pureRender(this.props, this.forwardRef ? this.forwardRef : this.context);
    return children;
  }
}

export default ReactiveComponent;

在 ReactiveComponent 中，与之前的代码对比，主要是增加了 Handlers 这个概念。Handlers 是数组，里面会存放函数，并且在对应的生命周期执行时，执行该函数。

主要涉及以下几个生命周期：

• componentDidMount
• componentDidUpdate
• componentWillUnmount

包括了组件的初次挂载，升级，卸载这三个步骤。

让我们继续看一下 useEffect 的源码（为方便理解，精简部分代码）：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46

function useEffect(effect) {
  useEffectImpl(effect);
}

function useEffectImpl(effect) {
  const currentInstance = getCurrentRenderingInstance();
  const hookId = currentInstance.getCurrentHookId();
  const hooks = currentInstance.hooks;

  if (!hooks[hookId]) {
    const create = () => {
      const { current } = create;
      if (current) {
        destory.current = current();
        create.current = null;
      }
    };

    const destory = () => {
      const { current } = destory;
      if (current) {
        current();
        destory.current = null;
      }
    };

    create.current = effect;

    currentInstance.hooks[hookId] = {
      create,
      destory,
    };

    currentInstance.didMountHandlers.push(create);
    currentInstance.willUnmountHandlers.push(destory);
    currentInstance.didUpdateHandlers.push(() => {
      const { destory, create } = hooks[hookId];
      destory();
      create();
    });
  } else {
    const hook = hooks[hookId];
    const { create } = hook;
    create.current = effect;
  }
}

通过分析源代码，我们可以得知，useEffect 会在初次挂载时，创建两个函数，create 与 destory。并且订阅了 ReactiveComponent 组件的生命周期。

也就是这一段：

1
2
3
4
5
6
7

currentInstance.didMountHandlers.push(create);
currentInstance.willUnmountHandlers.push(destory);
currentInstance.didUpdateHandlers.push(() => {
  const { destory, create } = hooks[hookId];
  destory();
  create();
});

create 函数

在组件触发 componentDidMount 时，会触发 create 函数，用于初始化钩子，而 create 函数会调用 useEffect 中传入的回调。

1
2
3
4
5
6
7
8
9
10
11
12

function useEffectImpl(effect) {
  const create = () => {
    const { current } = create;
    if (current) {
      // 如果有返回值，则将 destory.current 设置为 返回值
      destory.current = current();
      create.current = null;
    }
  };

  create.current = effect;
}

这儿需要注意的是，由于 useEffect 通常会用来处理一些副作用，比如订阅某些事件，所以 useEffect 在设计 Api 时，是支持传入的 effect ，在调用后有一个函数的返回值，用于在组件更新或者销毁时，取消订阅的。

如下面的代码所示：

1
2
3
4
5
6
7

useEffect(() => {
  const handleResize = () => setWidth(window.innerWidth);
  window.addEventListener('resize', handleResize);
  return () => {
    window.removeEventListener('resize', handleResize);
  };
});

destory 函数

destory 函数在此处的作用比较单纯，就是在触发该函数时，会触发 effect 的回调值。用于取消事件订阅。

组件更新触发 useEffect

在这儿，我们之前提出的第三个问题：“在状态改变后，为何 useEffect 也能够被调用？” 也能够得到解答。

在 useEffect 钩子第一次在组件内部使用时，它会订阅组件的 componentDidUpdate 事件，在组件升级后，它将依次调用 destory 与 create 函数。

1
2
3
4
5

currentInstance.didUpdateHandlers.push(() => {
  const { destory, create } = hooks[hookId];
  destory();
  create();
});

而之所以先调用 destory 的原因，是需要先取消之前的订阅，然后再执行订阅的流程。
这样也就避免了，多次订阅所带来的问题，确保每次只会订阅一次。

那些没有提到的

在写这篇文章时，贴出源代码的部分，我都会加上“为方便理解，精简部分代码”这句话。因为随着 Rax 的能力增强，其项目整体的复杂度也在逐渐的提高。

在文章中，为了能让读者清晰的了解到 Hooks 是什么，与 Rax 的实现方式，我精简了许多代码。包括异步更新/Ref 的处理/重复循环的检测。
而这些东西，也同样的有价值，具有其闪光之处，建议有兴趣进一步了解 Rax Hooks 实现的同学，自行前往 Rax 的仓库中阅读源代码，你会收获的更多。

Rax 仓库地址：https://github.com/alibaba/rax/tree/master/packages/rax

Hooks 将给我们带来什么

在 Hooks 出现之前，React 在实现部分功能时，因为涉及到生命周期等操作，是略微繁琐的。
而这时候的解决方法是 HOC，将组件包裹一层，但是组件包裹多了也不好呀，看起来整个层级就会特别的深。
而 Hooks 的出现，以其简洁的 API，解决了这个问题。
Hooks 将给我们带来的，首先是代码量上的减少。

当函数具有生命周期，可以通过 Hooks 做很多 Class Component 才可以做到的事情，也预示了 Class Component 在将来很长的一段时间内，不再是唯一推荐的范式。又随着 Memo 等 Api 的出现，函数式组件第一次可以尝试与 Class Component 做一番较量。
Hooks 将给我们带来的，是 React 编程范式的变更。

总结

纵观 React 发布这几年，官方推荐的编程范式随着时代不断的变更着。万变不离其宗的，是 React 希望做好 View 层框架的基础理念。Mixins/HOC/Class Component/Hooks，概念总是在增加，在变化。

在学习 Hooks 过程中，比起 Api 与具体的实现，我更为关注的是 Why Hooks？
把握 React 这一类框架在技术选型， Api 设计上的思考，可以很好的让自己了解到整个前端框架界，遇到的实际问题，大家的想法与最后的解决方案。

很多时候，选择做不做一件事情，比起把所有功能都提供给用户，是一件更难的事情。这意味着你需要在万千种范式中选择出最合适的几种，融入自己的思考，形成一套新的体系。在功能完善的同时还需要足够好用。

如果说自己想要什么的话，大概就是上面提到的，希望自己可以有一双智慧的双眼，可以指引自己做出正确的选择。

附录

Rax 1.0 思考

随着前几天 Rax 1.0 Api PR 的提出，Rax 正式确定了自己在新版本中的方向。
有一个比较大的改动是，Rax 将原有属于 JSX 的 Component/PropTypes/isValidElement 等 Api 抽离出来，打成了一个单独的包。
单独看可能还不是很理解意义何在，但是在这之前，Rax 还做了一波改动，使其能够支持 3 种 DSL：

• JSX（React Style）
• SFC（Vue Style）
• 小程序

这样看来，将原有属于 JSX 的一些 Api 抽离出来，单独打包的意义也就凸显了出来：

• 精简 Rax，减少 Bundle Size（12kb -> 8kb）
• Core 的 Api 更为精简，可以支持多种 DSL
• 业务的选择与定制性更强，只需要引入自己需要的 Api 对应的 package，就可以实现部分功能。

当然这种拆成多个 Package 的方式也并非没有缺陷，比如业务使用起来需要引入多个 Package，同时也需要管理多个 Package 的版本。
就像那天和元彦聊 React 一样，他说过一个技术有优势肯定也有其劣势，并没有什么技术是完美无缺可以 Cover 到所有 Case 的。而 Rax 1.0 的升级也一样，有优势也有缺点。

期待后续 Rax 的升级与改进，想知道 Rax 如何将 1.0 拆分多个 Package 所带来的影响降低到最小，也想了解在引入 Hooks 后会产生如何的化学反应。

这本书

遇见《坚守底线》这本书时，我还是大二，也喜欢去图书馆。
时光荏苒一过 3 年，回头来看，这本书是大学期间改变我最多的一本书籍。

在那之后，如果有朋友让我推荐几本书给他，我一定会推荐的一本书，就是这本《坚守底线》。
书的内容很简单，讲的东西也不复杂，需要的只是认认真真的去读了，按照书里面指引的信念认认真真去做，仅此而已。

聪明人

在我的大学期间，遇到过很多聪明的人，他们读书读的比我快，脑子比我转得快，去过更远的地方，接触过更高层次的人。
我是小城镇里出来的，没有见过什么世面，很多时候不自觉的就会对自己的能力产生怀疑，在大学的前一年，我看着那些生活与过往履历光鲜亮丽的朋友们，想着如果能和他们合作，一定可以学到很多东西吧。虽然我见识少，但是站在巨人的肩膀上能看的更远这个概念我还是清楚的。

但是与部分聪明朋友在实际的合作中，便会出现一种怪象，明明这件事情只需要坚持下去便能守得云开见月明，但是朋友们却觉得收益太低，转而投向其它的方向。

我在继续坚持着，同时也在观察着这些聪明的朋友们，希望可以汲取到一些经验，以便为自己将来的决策提供参考。

经过很长一段时间的观察（大概 1 年），我发现身边的聪明朋友们，除了极个别的同学，拿到了自己想要的成就外，其它的聪明朋友，在这一年之中都是东一榔头西一棒子，看起来所获颇微。

在这之后，我接触到了《坚守底线》这本书，忽然也明白了一些什么，于是开始坚定且认真的相信自己，并走自己的路。

再读

读完《坚守底线》，把书还给了图书馆。
还回去的是书，而留下来的则是指导自己整个大学生活的信念。

工作后，我从网上又买了这本书，并带在身边，随时翻阅。
这一次也是正好借着读书笔记的活动，把自己觉得的精华与感悟记录下来。

其中有一些，我会带上具体的事例。

笔记

能力与人品

如果是说“选能力还是选人品，二者必须选择其一”。那么，我会毫不犹豫的回答：“人品最重要”。

其实这句话，是与我在家园工作的过程中，一直在做的事情。
而类似的话，其实在《家园信条》中也有提出：“所有事情的基础，一颗为学校出力的心，一个正直的人品。”

在家园招人的过程中，总会有个把能力突出，但是品行不佳的同学。“目中无人，狂妄自大，甚至随意攻击家园同学”。
这种情况下，即使能力突出，也选择劝退。

经营家园

作为经营者，如果你真想把公司搞好，让员工自豪，让员工感觉到工作的喜悦，那么你就要把全部心血倾注在事业上，并做出自我牺牲，为员工的幸福和公司的发展殚精竭虑。没有这样的奉献精神，就不要当经营者。

在大三的时候，我加入了家园中心组，那时候时时刻刻都想着如何让家园变得更好，如何从泥淖里脱身。
但当时的我，除了参考一些成熟公司或者团队的做法，剩下的时候便是按着这句话，努力认真的去做事情，即使有些时候会“自我牺牲”。

经营家园是一件需要极其认真的事情。

而两年下来，家园也给我带来了出乎意料的回报，这儿就暂且不提了。

优秀人才与愚钝之人

从长远的眼光来看，比起那些半吊子的所谓优秀人才，倒是头脑略微迟钝但拼命努力的人可以从事伟大的工作。

这句话对我影响深广。
在那之前，我一直觉得自己还可以，挺聪明的，但不知道为何就是一无所获。

读到这句话后，我放弃了编程外所有的机会，即使有些机会非常的诱人。
自那之后，我给自己的定位就是“头脑略微迟钝”的人。
知道编程的未来不是一塌糊涂，知道自己坚持下去就可以超越很多人，就足够了，老老实实认认真真的努力，会是最稳妥的方法，也是生活最简单的方法。

社会的不公

一味的怨恨社会的不公平，老是抱着这种心态，自己的人生就会不顺畅

在学校偶尔能看到跑车，那种看起来就很贵要大几百万的跑车。
我知道现在的自己买不起，将来的自己也可能买不起，更有可能这辈子都只能看看而已。

在那时候，我觉得这样的生活有些糟糕，毕竟自己再努力也只是活成别人的一个零头。

读完书后，我开始乐观的看待这一切，开始正视自己心中的欲望，认真的思考并给自己一个答复。
之后再看到豪车，我的想法变成了：“哇哦，好棒，羡慕 ing，希望自己多多努力，将来虽然开不起保时捷法拉利，但至少可以搞辆自己喜欢的汽车”。

喜欢自己的工作

人生的道路是漫长的。人要在现实社会里生活工作好几十年。因此，对踏上社会后从事的工作要有种迷恋的心态，这点很重要。如果喜爱自己的工作，就会涌出一股力量，促使人持续地钻研努力。同时，持续不懈地努力，不知疲倦地反复钻研、琢磨创新，就有可能到达被称为名人高手的境界。

想起读书时，对比起编程这件事情来说，其他的一切事情都仿佛是那么的苍白无力。
在选定编程作为方向后，我曾经往某个崇拜的前辈的知乎专栏中，投过一篇稿子，并得到了如下的回复。

而三年过去了，自己在面对代码时依旧充满了思考与力量。

一味祷告纵然心虔

踏上社会，在最初就职的公司里使我懂得，不管所处的环境多么恶劣，不管被逼入何等绝望的境地，如果只是一味地发牢骚，逃避现实，犹豫彷徨，那么，人生绝不会出现转机。

在高三时，我每周不会落下的，是“进击的巨人”这部番剧。
在片首曲中，有这么一句话：

一味祷告纵然心虔，世间又能有何改变。

而坚守底线中的这句话，是一样的意思。
在家园工作与学习的过程中，时常有同学夸奖我执行力很强，而执行力强的缘由，便是这两句话。

同样的话，在家园信条中也有提及：

我们需要能够提出问题的人，但是更需要能够解决问题的人，提出问题 80 分，解决问题 100,但是我们坚信：100 分大于 80 分,80 分大于 0 分

有想法，大胆去做就好了~

无欲则刚

包括自己的生命在内，只有能够彻底抛弃私心的人才能成就大事”。这句话凝缩了最重要的思想不仅对经济界，而且对政界、官界、各行各界都适用。我坚信，领袖的必要条件就在于克己奉公。

看到这一段时，只想起了一句话：

海纳百川，有容乃大。壁立千仞，无欲则刚。

我自己逐渐可以体会到其中的意思，只是距离这样的高度还非常非常的远，在此不做评价。

四个关键字

再次阅读《坚守底线》这本书，我提炼出了四个关键词。

在大学四年中，我受其影响最深，但却一直没有总结，直到写下文章的今天，脑海中突然冒出来的四个关键词，即代表了我为人处世的态度，也代表了我未来会一直努力的方向。

它们是：认真、正直、努力、坚持

我会结合自身经历，对其一一进行解释。

认真

千万不要自己感动自己。大部分人看似的努力，不过是愚蠢导致的。什么熬夜看书到天亮，连续几天只睡几小时，多久没放假了，如果这些东西也值得夸耀，那么富士康流水线上任何一个人都比你努力多了。人难免天生有自怜的情绪，唯有时刻保持清醒，才能看清真正的价值在哪里。 ——于宙 《我们这一代人的困惑》

首当其冲的，是认真。

认真有很多具体的解释，比如认真的对待自己的生活，认真对待工作，等等等等。
而我自己对于认真的理解，则是：“运用科学的方法与自身的智慧，为当前与未来寻找最优解。”

认真的对待一件事，就意味着不能以“战术上的勤奋掩盖战略上的懒惰”。
只有认认真真的去了解，去探知，去努力，才知道一件事情，一份工作是否真正的合适自己。切忌自己跪在地上把自己感动哭了这种情况。

剩下的三个关键词，在我心目中都同等重要，并无先后之分。

正直

堂堂正正的做人，堂堂正正的做事，不搞歪门邪道。
于我而言，这会是一种让我内心感觉安稳的生活信念。

这中间涉及到非常久远的个人历史背景故事，在此我就不做赘述了。
还好个人经历的一些黑历史，并没有让我成长为一个病态的人。

努力

下面是我很喜欢的一句话：

杀人须就咽喉上着刀，吾人为学，当从心髓入微处用力，自然笃实光辉 — 王阳明

在认真的去观察一件事情，做出决定后，剩下的就是需要自己持之以恒的投入。
努力对于我意味着什么呢？
想了一会儿，脑海里给出的解释是：“认认真真，拼尽全力，做到最好”。

就像自己之前在【中国诗词大会】武亦姝 cut 合集的第一个视频中，看到了她的自我介绍与准备。最后在总结时她说了一句：

我是武亦姝，既然来了就做到最好吧。

**
而我的想法也是一样，既然认认真真的做出了决策，那么来了就做到最好吧。

坚持

若有恒，何必三更眠五更起；最无益，莫过一日曝十日寒。

很多事情，一味想着快速出成绩，人就容易变的浮躁，而浮躁过后便是放弃。
一曝十寒说的就是这个道理。

但凡是我人生中重要的技能，无一不是由常年累月的积累而熟能生巧的。
就算是我最喜欢的编程，也是坚持了半年才摸到了门槛。

除此之外，生活之中还碰到过许多事情，明明我不是最优秀的那个，但最后却是收货最多的。无他，只是因为我坚持的最久而已。

总结

把这四个关键字，整理一下，便得到了自己做人做事的理念。

做人做事堂堂正正，做事之前要认认真真的分析，决定后便要持之以恒的努力。

这本书教会我的，总结下来，也就是这么一句话。
但知易行难，就像韩寒的那句：“听过许多大道理，却依然过不好这一生”一样。真正对自己有用的，并不是大道理，而是自己对于大道理的理解，实践，并将这些“大道理”改造，内化到自身的这一个过程。

读书也是一样，只是阅读精要，阅读那些给出的道理，自己除了有一种“醍醐灌顶”的感觉外，所获颇微（仅针对个人而言）。
真正扩展自己知识边界的，恰恰是自己在读书中大量的思考，交流与查阅的过程。在这个过程中，这些“大道理”从别人的哲理，变成了我自己的想法，我会去实践，会去根据实际情况做调整，会去讲解这些“大道理”。

正所谓，知行合一。

2018 年，于我而言，是剧变的一年。

生活产生了剧变，上半年还在学校里聆听着老师的教诲，与同学自由开心的玩耍，而下半年却是投身于阿里，埋头于无穷无尽的工作中。

身份产生了剧变，从学生到工作人士，压力也随之而来。而到了年底，则越来越明白，学校已成母校，再回去也难。家园已成记忆中的家园，她闪闪发光，只是我不再是其中的参与者。只记得学校的一切都是那么的清晰，但是却也在慢慢的离我而去。

朋友圈产生了剧变，学校里身边的朋友们各奔东西。毕业离别的那段时间，我清楚的知道，我们依然还是很好的朋友，只是日后再难相见。

学校的生活熟悉且简单，工作后的生活繁复但新鲜，每天都能接触到新事物新挑战。

但于我而言，真正走出大学校园的那一刻，发现自己还是想呆在学校，做一个无忧无虑的学生，过着简单的生活，哪怕只有一个月。

但是时间的残酷之处，在于自己不能回头，也不会等待自己踌躇不前。在校门口望了南昌大学一眼，我拉着我的拉杆箱，上了去南昌西站的出租车。

想起毕业前给家园的学弟们分享的那两句话：

我在我的大学，得到了我认为最好的培养，进入了南昌大学最好的社团，遇见了我认为最好的朋友们，做了一些我认为最正确的事情，这样的生活，虽然离开后万分想念，但是却没有遗憾。

GoodBye NCUHOME

从机缘巧合加入家园，到成为家园的中坚力量，再到南大家园的诞生，最后再到自己的身份变成了老家园，从此不再出现在机房。在家园的三年半时间，如同白驹过隙，转瞬即逝。

在这儿，我想阐述，家园与我而言，意味着什么？

这个问题，我思来想去的想了两年多。两年前，佛爷和我说，他希望能给家园找一个关键词来定义她。从那时起，我便也开始了寻找。

两年后的今天，我坐在电脑前，脑海不断浮现家园的回忆，就像一幅画卷一样，在自己的眼前展开。在画卷的最后，我看见了家园的关键词：“家”。

家园于我而言，就是我在南昌大学的家，我在这儿成长，我在这儿完成一些了不起的事情，在这儿认识大学里最好的朋友们，也在这儿做出了属于自己的一份努力与贡献。

在家园这儿，我生根发芽，结果开花，最后的最后也尽自己努力，培养下一代的家园人。

在很久之前，我觉得自己是有点自私的。而遇到家园之后，有什么事情需要我去做的，都会全力以赴的去做。那些时候的思路，是“家园需要我，我必须挺身而出”。

在家园这儿，我学会了无私，一开始我也疑惑与纳闷，只是一个大学社团而已，为什么自己会有这般的转变？

直到今天，我才意识到，其实自己早已被家园同化，成为家园这个大家庭中的一份子，且对于家园，有了真正的家的认同与责任感。

而一个人，又怎么会对家里的事情，总是计较得失呢？

“My NCUHOME.”

这是我的家园，我的大学生活，我毕业时最难以割舍的部分。

一些照片与留念

家园：

夜里的家园：

我的工位：

我的工牌：

我的朋友们：

七月初的我，带着对学校的无限留恋，踏上了东去的列车。

背后是再难回去的校园，与十几年的学生生活，身前是复杂的社会，与余生不可知的生活。

Hello Alibaba

到公司入职的那一天，天很蓝，拍出的照片也很好看。

园区和之前一样好看，多了几座雕像，除此之外没有什么变化。

当时的心情，现在想起来很是复杂。兴奋与不安掺杂其中，不知道自己在期待什么，又在害怕什么。

到今天，我理解了我当时的心情。不安源于没有退路，之后的几年间，在这家公司无论遇到何种困难，我再也没有一个回学校躲着恢复元气的机会了，只能硬着头皮去扛，硬着头皮去闯。

在入职结束，去往工位的路上，自己小声的嘟囔了一句：

“Hello Alibaba.”

天猫未来店

这是一场盛大瑰丽且不应该忘记的梦。梦里有我的朋友，我的心血，与最好的我自己。

下图是云栖大会开幕前夕，天猫未来店场馆

这是我入职后的第一个任务，负责云栖大会天猫未来店的前端开发，并承担前端 PM 的任务。

当时的情况就是，开发任务重，时间紧凑，现场情况各种不稳定，团队成员对于这种线下开发的业务，之前基本没有接触过。

所以整个下来，压力是非常之大的。

中间的日子，有住过工地，有扛过物资，也有当过超市店员理货与接待客人。中间的情况多变与复杂，难以言表。

在九月份，连续上班 22 天，整个的生活就像是一场马拉松赛，明知终点就在那儿，但是过程却是艰苦漫长。

遇见最好的自己

超高强度的工作在给我带来极大压力的同时，也给我带来了极大的收获与成长。

首先是个人能力的极限压榨。

硬件

我从初中开始玩电脑，接触到大量的电脑应维知识，如硬件、系统、维护、Etc.。因此对于电脑硬件等杂七杂八的知识，都有相关的了解。大学时也曾参加朋友的创业项目，维修了 3 位数的电脑（笑，因为修电脑时感觉到了重复与无趣性，所以后面选择转向了开发）。

在天猫未来店项目中，前端页面是部署在各种设备上的，如下图中挂着的电视机，闸机上放着的小屏幕等，且这些设备的硬件，是需要前端去做选择的。同时现场需要考虑容灾的问题，比如突然停电等问题。

我的应维知识，在选择硬件，部署页面，应对突发情况，都起到了非常关键的作用。它使我在面对复杂的线下场景时，不会两眼一抹黑，而是知道如何一步步的去解决问题，得到最优解。

Eg：悬挂屏硬件选择与现场停电问题

Answer（悬挂屏硬件选择）：上图中后方挂着的四块大屏幕，其实是由一台主机驱动的。屏幕需要实现最好的显示效果，因此需要实现 4k60FPS ，而如何用一台主机带动 4 块 4k 的屏幕，也是一个难题。最终，我们选择了 4 台具有 HDMI 2.0（1.X 系列智能到 30FPS，带宽限制） 的电视机 + 一台拥有 GTX1080 的服务器（正好实验室里可以临时借用），实现了这个功能。假如对帧率的知识不太了解，那么买来的电视机只能实现 4k@30FPS。假如对 GPU 知识不太熟悉，有可能不支持 4K 输出，也有可能爆显存。

Answer（悬挂屏硬件选择）：主机是放在悬挂的黑盒子中，平时如果断电了，只能爬梯子上去重启，并且连接蓝牙鼠标，进行服务恢复，整套弄下来大概 20 分钟，且需要关闭店门。而我由于对硬件知识的了解，知道主板可以在 Bios 设置来电后自动开机，所以只要启用这个功能，就可以避免需要爬梯子上去重启的问题。且我在电脑中安装了一个远程管理的软件，并设置为开机自启。这样就能确保，我无论在哪儿，出问题可以第一时候在远程进行控制。几次实践后，断电后该悬挂屏恢复服务只需要 3 分钟不到。

这些事情，看起来与前端无关，但是却与整个项目息息相关。所以我会去重视，会去不断的尝试各种解决方案解决问题，而不是轻飘飘的来一句：“我是前端”，就再也不管不顾了。而这也是我今年一直以来的理念，我是工程师，然后才是前端工程师，身为工程师的话，注定是要解决问题的。在现场人力紧张的情况下，把问题甩给其他同事，并非是明智之选，选择留下，选择解决问题，才是自己应该做的。

Last man standing. —— 《阿里土话》

项目管理

在项目中，我也负责这个项目的前端 PM 工作，开始着手于项目管理。

实践过程中，往往有着跨部门的沟通协作，本部门的工作分配，进度安排等工作，和项目经理一样，细碎，繁杂。

同时我也要负责开发，负责 Code Review，负责现场调试时紧急问题的修复，而这一切得益于我在家园大三时的工作经历，整个过程虽然细碎繁杂但是也处理的井井有条，不至于手忙脚乱误了事情。

最后的结果也非常喜人，前端页面在整个四天的活动过程中，实现了 0 BUG 的目标。

技术

项目里虽然忙碌，但也是实践自己过往想法的一片大好天地。

一路做下来，主要集中与前端工程化、HTML5 开发理念、RxJS、TypeScript 等方面。看起来像是名词的堆砌，其实是个人对于前端开发最佳实践的一种实验。

得益于过往的经验，前端工程化、RxJS、TS 等事物我都有大概一两年的实践与学习经历，项目当中，虽然有很多坎坷，但最后的结果却是好的。

和我在天猫未来店的总结会里讲的一样，技术方面的事情，我并不准备长篇累牍的去赘述，点到为止即可。

毕竟我还年轻，很多事情还没有接触到，也正如我学前端开始一直对自己说的那句话一样：

前端路漫漫，且行且歌。

百阿

百阿又称百年阿里，是阿里每个新人都要参加的培训，为期两周。

在百阿过程中，认识一群不同年龄，不同地域，不同岗位的好朋友们。

虽然时间不长，但我们的情谊地久天长~

一起去酒吧夜谈（年轻人的第一次酒吧之旅）：

一起去做公益：

一起玩钉钉办公楼里的滑滑梯：

一起跳了《卡路里》这支舞蹈（年轻人的第一次跳舞）：

一起在西湖山边的小酒馆吃好吃的，有一种空山新雨后，天气晚来秋的感觉：

在培训的最后，也写下了自己的小目标：

生活

带表哥和爸妈来杭州玩了一圈，第一次完整的游了西湖，吃了盒马。

来之前，我妈在电话里一直和我说，她从小就听说上有天堂下有苏杭，只是从未去过，这次终于可以见识到了。

带着爸妈，去了雷峰塔，游了西湖，吃了好吃的，也坐船上摇了一个小时。

当时的天气很好，西湖很美，我们都很开心。

2019 - 新生

过完了充满转变的 2018 年，自己也逐渐的稳定了下来，对于生活也有了一定的掌控力。

在 18 年的年底，我想清楚了自己在 2019 年，需要做的三件事情。而这三件事，会让我迸发新生。

• Running
• Coding
• Reading

Running

随着工作压力的增加，自己在锻炼上的投入愈发的少，身体也在不断的给自己报警。

对于运动，我的想法并不是“生命在于运动”，或者“运动是一种爱好”等。

我想要的，是我的身体可以承受住我的工作压力，可以保障我安全的活下去，安全的工作。

“多活几年。”

这就是我最真实的想法。

2019 年，定一个小目标，跑 365 KM。

Coding

代码是兴趣与工作所在，也是占据我生活最大的一块。

2019 年的目标，定在以下 3 个方向：

• 数学
• 英语
• 架构

于我而言，一直以来就有的问题是，写业务代码是全然没有问题的，也能按时完成工作，但自己却难以写出好的代码。所以在新的一年，加大在架构层面的投入，属于一件磨刀不误砍柴工的事情。

数学和英语则是自己在工作中，实实在在遇到的问题。

在接下的任务中，有一个是实现一个前端框架，在工作过程中，翻阅了大量的资料。深感英语与数学上的不足，给自己带来的掣肘。同时在这两门学科上的头颅，也是一件磨刀不误砍柴工的事情。

Reading

读书是兴趣，也是一种极有效缓解我压力的方式。

当静下心来，捧上一本书，边上放一杯温开水，打开台灯，仿佛整个世界就剩我与书。

万籁俱静，但我心不平静。

2019 年，目标是读 27 本书，平均 2 周一本。

在知识的海洋遨游，与先贤大拿交流，学习接触着那些我知道或者不知道的事情。

至于能给自己带来的作用，我向来没有考虑太多，正如胡适先生说的那句话一样：

怕什么真理无穷，进一寸有一寸的欢喜。

学习这件事情本身给自己带来的愉悦与充实感，就已经是莫大的奖赏了。

新生

“谢谢曾经努力的自己。”

这句话我在实习入职阿里时，说过一句。

在我转正的那天，也对自己说过一句。

如果能实现这些 Flag，我相信明年这个时候的自己，一定会如获新生。

期待这明年的自己，可以对着自己说出那句话。

2019，我准备好了~