在研发计划曝光数年之后，谷歌终于向市场推出了 Fuchsia OS：从 Nest Hub 开始，谷歌的操作系统可以在实际的消费类设备上运行了。据 9to5Google 报道，谷歌已经向其确认，Fuchsia OS 将向 2018 年发布的初代 Nest Hub 智能显示器推出。更新后的 Nest Hub 将不会有功能改变，但系统底层将由基于 Linux 的 Cast OS 变更为 Fuchsia OS。谷歌 Fuchsia OS 项目技术负责人 Petr Hosek 在推特上庆祝了新平台的发布：“今天是个重要的日子，我们发布新操作系统啦！”Nest Hub 基于 Fuchsia OS 的更新会在未来几个月内陆续推出，考虑到界面和体验将保持不变，用户可能不会有直接的感知。自 2016 年以来 Fuchsia 的发展一直备受关注，从实验性的用户界面开始，一直到运行至一些内部测试设备，包括谷歌智能家居和 Chromebook 系列的全部产品。如今，谷歌宣布将在几个月内为初代 Nest Hub 智能显示器用户推送 Fuchsia OS，这表明它已经准备好在个人设备上提供服务。不过，Fuchsia 不只是智能显示操作系统。彭博社（Bloomberg）于 2018 年发布的一份报告迄今都完全命中 Fuchsia 的发布计划，其中提到谷歌希望“在三年之内”首先在联网的家用设备上发布该操作系统。该报告还指出了 Fuchsia 的下一步措施，包括计划在 2023 年大规模扩张到智能手机和笔记本电脑。谷歌在 Fuchsia OS 上投入了数百人，经过五年多的发展，Fuchsia OS 已经开始引起其他行业巨头的关注。最近，三星开始与谷歌合作开发该项目。很多人猜测 Fuchsia OS 未来可能会全面取代 Android 与 Chrome OS，而三星可能会成为最先抛弃 Android 改用 Fuchsia OS 的手机厂商。谷歌 Fuchsia OS 是什么？Fuchsia 是一套全新的操作系统，其项目定位一直在发展变化。作为一套新的操作系统，Fuchsia 最初于 2016 年首次亮相于谷歌代码库与 GitHub，该项目完全开源：https://fuchsia.googlesource.com/。更重要的是，Fuchsia 并非基于 Linux 内核，而 Linux 内核又恰恰是 Android（谷歌打造的移动操作系统）与 Chrome OS（谷歌台式机与笔记本电脑操作）的核心基础。很明显，Fuchsia 承载着谷歌更大的野心。谷歌 Android 工程副总裁 Dave Burke 在 2017 年接受采访时如何介绍 Fuchsia：“Fuchsia 是一个早期实验项目。大家可能都知道，我们在谷歌筹划过不少非常酷炫的早期项目。我认为最有趣的点在于 Fuchsia 直接开源，每个人都可以查看成果并做出评论。与其他早期项目一样，Fuchsia 也会不断发展变化。”时间到了 2018 年，Fuchsia 开发者 Travis Geiselbrecht 通过公共 Fuchsia IRC 频道强调，这套操作系统绝不是“玩具”，于是情况变得更加扑朔迷离。他证实称，Fuchsia 的开发进度已经颇为可观，而且参与其中的谷歌开发人员可以随意进行兴趣化探索。在他看来，Fuchsia“绝不是那种用掉就丢的垃圾项目。”之后的两年 Fuchsia 蜇伏了起来，直到 2020 年谷歌再次推动宣传，希望通过平台开放为其吸引更多软件开发支持者。2021 年初，先是项目的 F1 分支，之后又有 F3 分支，随着一个个重要代码开发步骤的落地，Fuchsia 的面貌及发展方向也开始愈发清晰，事实证明这套操作系统已经达到了一系列重要发展里程碑。谷歌 Fuchsia OS 的意义何在？Fuchsia 只是一套内核。谷歌可能想用 Fuchsia 证明自己对未来的探索。与基于 Linux 的 Android 或 Chrome OS 不同，Fuchsia 基于 Zircon（原名 Magenta）构建而成。该内核开始时使用的是 C ++ 代码，为了实现其安全目标，现在正朝着 Rust 发展（现在已经达到 50％）。一年前谷歌还向 Fuchsia 添加了对 Swift 的支持。目前比较流行的观点是，Fuchsia 应该代表一款新型操作系统，未来用于将 Chrome OS 与 Android 统一在同一套系统之下（自 2015 年以来始终存在此类传闻）。但根据最近浮出水面的说明文档、代码以及 UI 来看，这套操作系统好像并不是 Android 与 Chrome OS 的融合体、甚至不属于任何完整操作系统。目前，它还只是个内核项目——也就是操作系统的核心所在。谷歌公司在内部文档中指出，Fuchsia 主要面向采用“高速处理器”加“低内存容量”的“现代手机与个人计算机平台”。文档还明确提到，“Fuchsia 不是 Linux”。Fuchsia 的 GitHub 页面上出现了两位顶尖嵌入式系统开发者的姓名，一位是谷歌高级软件工程师、另一位则是前 Android TV 与 Nexus Q 项目工程师。此外，卡片化设计的早期用户界面 Armadillo 内置于谷歌的 Flutter SDK 之内，而后者专门用于创建可在多种设备及操作系统上运行的跨平台代码。使用 Armadillo，用户可以随意拖动不同卡片实现屏幕拆分、或者在选项卡式界面中使用。同时，Fuchsia OS 的核心独立于硬件规格，使用模块化方法，这意味着它将不再是一大堆代码，而是将其分割成多个构建块或“包”，制造商能够根据设备选择 Fuchsia 的功能。Fuchsia OS 中的模块化，来源: 9to5GoogleFuchsia 的模块化框架带来的另一个优势是，它可能仅通过安装更新的组件就可以添加新功能。从实际出发，模块化不仅可以解决系统更新时可能出现 Bug 的问题，而且还可以加快应用程序的更新速度。这种模块化方法对于 Fuchsia 所提供的统一体验至关重要。因此有猜测，未来我们可能会看到 Fuchsia 与其他新兴技术融合在一起，发展成为一个集合的、相互连接的设备系统，这样操作系统就不会单独运行在每个设备上。取而代之的是，可以在每个设备上以分散化的实例形式运行这个无所不包的 OS，所有这些实例都可以协同工作。谷歌 Fuchsia OS 会取代 Android 吗？新系统确实能解决 Android 中的不少问题。但 Android 已经全面铺开，何必重新发明轮子？Android 最初是为带有 QWERTY 键盘的智能手机设计的，后来逐渐适配触摸屏控制。并且有说法是 Android 在设计时并未考虑虚拟现实或增强现实。鉴于它已经有十年历史了，因此如果谷歌希望应对下一个十年的挑战，那么比起修改 Android 代码，也许重新开始设计一个新操作系统才是更好的办法。Android 本身的碎片化问题仍然很严重，根源当然是几十家手机制造商推出的数百款设备都在使用不同的自定义 Android 版本。另外，由于 Android 系统为开源项目，所以在更新方面也有不少冲突。谷歌为 Android 制定了年度更新发布时间表，但要真正向整个生态系统推开还需要一段时间。目前，谷歌仍然只能将 Android 新版本交付给 OEM 厂商和电信运营商，再由他们安装并加载至目标硬件上，这种无法由谷歌直接控制的体系必然导致碎片化加剧。另外，Android 还基于 Linux 内核，而后者目前不仅面临诸多法律问题的困扰，而且内核还经历了一番全面调整，极大提升了出现 bug 及安全漏洞的可能性。也许一套全新操作系统平台能帮助谷歌解决以上所有问题，同时也将有效回避昂贵的专利许可成本。由于从零开始构建而成，这套现代化操作系统将更安全、更可靠且优化度更高。另外，新系统既可以采用模块化设计、也可以强调统一性，保证更全面地覆盖各类设备。但无论如何展望，我们都需要回答最核心的灵魂拷问：Android 已经全面铺开，何必还要重新发明轮子？延伸阅读：https://9to5google.com/2021/05/25/google-releases-fuchsia-os-nest-hub/amp/https://www.pocket-lint.com/laptops/news/google/138518-google-fuchsia-os-what-s-the-story-so-far

前言本篇文章是 TypeScript的另一面：类型编程 系列的第 1 篇，这一系列将发布在同名专栏中（见 知乎专栏 或 掘金专栏）。同时，这一系列的文章将主要继承于笔者在去年的同名文章（原版，炒冷饭版）内容中各部分，并进行进一步扩展深入，除本篇的 never 类型以外，还将包括如条件类型与协变 & 逆变、infer与递归 & 尾递归、TypeScript中的控制流分析、TypeScript 工具链的探索等部分，欢迎关注。至于会有这个系列的原因，首先是因为这篇文章原版其实阅读还蛮广的，不论在内网外网，可能都是我目前阅读最高、受众最广的一篇。而在这篇文章中，我尝试把绝大部分的内容都塞进去，导致并不是所有人都能读下来，或者读下来都能还保持神志清醒。同时，原文中的部分内容在今天的笔者看来也显得有些太浅太泛了（水平有限，还望见谅）。所以就有了这个系列，区别于一股脑填鸭，这个系列的每一篇文章只会关注一个独立的问题，因此保证了内容纯粹（就跟笔者的人格一样纯粹） + 篇幅精简。最重要的是，本系列文章默认你已经拥有 TypeScript 的基础，阅读过之前的专栏文章更好。另外，本文以及本系列内容部分来自于笔者将在 12月 QCon+「TypeScript 在中大型项目中的落地实践」 专题中进行的分享，同样欢迎关注。本篇主要从以下部分出发，介绍 TypeScript 的 never 类型，由于笔者才疏学浅，未曾了解过其他计算机语言中的类型系统知识，如果出现错漏，还望不吝指出。TypeScript 中的三个特殊类型：any、unknown、never如果只用 never，我们可以做到什么？never 在工具类型中的作用在开始前，感谢 雪碧老师、阿伟、寻找海蓝、三七二十 等前辈的 TypeScript 相关分享，本文内容也大量受到他们的影响，再次向以上前辈的分享精神致敬。P.S. 你可以在 GitHub 获取所有示例代码。never、any、unknown在 TypeScript 中，有这么几个类型可能一直困扰着初学者们，any、unknown 以及 never，这都是啥玩意啊？？啥时候用 any，啥时候用 unknown，never 好像没见过人用？先想想我们一般啥时候用 any，比如某个变量实际上就是某个类型，但是由于中途各种操作你没做的严丝合缝，到某一步类型报错了，这个时候可以先 as 成 any，再 as 成你想要的类型，然后你就又有类型提示了（当然，我觉得直接 as any 的情况比较多）。// 要是你在公司这么写代码被打了，别把我供出来 const foo = {} as any as Function;as 意味着什么？你指着编译器的脸告诉它，这个变量的类型就是这个，不服憋着。为什么要 as 两次？不能直接 as Function？好问题！因为 TS编译器会用报错狠狠的抽你 as 实际上只能转换存在父子类型的关系，对于风马牛不相及的关系它是不理你的，所以你需要先 as 成 any，像中介一样强行把原类型和新类型关联起来。如果要稍微规范一点，应该先 as 成原类型和新类型的父类型，再 as 成新类型，如雪碧老师的例子：// Deer、Horse的公共父类型 interface Animal {} interface Deer extends Animal { deerId: number } interface Horse extends Animal { horseId: number } let deer: Deer = { deerId: 0 } // 并不能一步到位 let horse = deer as Horse // 先提升成共同的父类型，再定位到子类型 let horse = deer as Animal as Horse后来，我们有了 unknown，编译器对于关联不相关的两个类型的提示也变成了 “求求你先 as 成 unknown 吧”，那么 unknown 和 any 有啥区别？首先，在 TypeScript 的类型系统中，any 与 unknown 都属于 Top Type（在大部分类型语言中都有这么个玩意，如 PHP 中的 mixed，Kotlin中的 Any? 等），也就是说在类型层级中它们位于顶点，但 any 类型的变量可以被赋值以任意类型的值，而 unknown 则只能接受 unknown 与 any。二者的出发点其实是一致的，那就是快速表示一个未知/动态的值，但 any 显然更加无拘无束：let foo: any; foo.bar().baz();这样都不会报错！和 JavaScript 还有啥区别（狗头），使用 any 意味着你在这里其实完全放弃了类型检查，更可怕的是 any 的传染性，一个变量被声明为 any，那么接下来所有基于其操作派生来的值就都被打上了隐式 any（如果没有类型断言或者基于控制流分析的类型收窄）。但 unknown 不一样，它就像是类型安全版本的any：因为类型检查仍然存在。let bar: unknown; // 这里是会报错的 // @ts-expect-error bar.baz().foo();对于被声明为 unknown 的变量，你没法直接读写它，而是必须先指定类型，显式指定、类型守卫、编译器的自动分析都行，比如类型守卫：function isString(input: unknown): input is string { return typeof input === "string"; }既然有 Top Type，那么就应该要有 Bottom Type，在 TypeScript 中 never 就是那个 Bottom Type。Bottom Type 意味着一个不表示任何类型的类型，在 Kotlin 中它是 Nothing，在 Rust 中则用 ! 修饰一个没有返回值的类型。你可能觉得，string 已经挺具体了，'linbudu' 这种字面量类型就更具体了，但 never 还要更具体。它是所有类型的子类型，是类型系统的最底层，也就意味着没有任何类型可以赋给它，除了 never 本身。在 TypeScript 中，一个必定抛出错误的函数，它的返回值就是 never。说到这里你可能会想还有一个特殊的小伙伴 void（我们经常会写 Promise<void> 来表示一个直接 resolve 掉的 Promise），而 void 和 never 的区别就在于，返回 void 的函数其内部还是会调用 return 语句，只不过它啥也没返回，void 代表啥类型也没有（甚至 void 其实并不应该被看做一个类型），而返回 never 的函数其内部压根就没有调用 return 语句，never 代表返回压根就不存在，哪来的类型捏。了解了 never 的基础概念，接下来要准备用用它了:)最基本的 never 使用never 单独使用的场景是非常少的，但也不是没有，我们前面说过，它是任何类型的子类型，没有比它更 narrow 的类型，所以就不可能被复制给 never 类型。我们可以使用这一点来确保在 if...else 或者 swicth case 语句中，所有可能的(类型)分支都被穷举到。在 TSConfig 中，有个类似的 noImplicitReturns 选项，它确保了函数的所有路径分支都必须返回值，但很明显粒度（也可以说力度）并不够。一个简单的例子，某个变量使用联合类型定义：const strOrNum: string | number = "foo"; if (typeof strOrNum === "string") { console.log("str!"); } else if (typeof strOrNum === "number") { console.log("num!"); } 看起来好像没啥问题，假设某天这个变量的联合类型又多了一个成员：const strOrNumOrBool: string | number | boolean = false;而一个很经常出现的场景是，你需要这个变量所有可能的联合类型都被处理到，并对每一个联合类型的成员进行特殊处理。在上面的代码中，如果你忘记了处理 boolean 类型的情况，TypeScript 也不会报错（当然不会了，如果它能智能到这种程度，干脆改名叫 AIScript 好了）。那么，要怎么在漏处理类型分支的时候抛出错误？首先，由于 TypeScript 的类型收窄能力，我们能在每一个 else 的 语法块中将变量的类型收窄到对应的值。如果我们在上面的语句中加一个 兜底的 else 语句：const strOrNumOrBool: string | number | boolean = "foo"; if (typeof strOrNumOrBool === "string") { console.log("str!"); } else if (typeof strOrNumOrBool === "number") { console.log("num!"); } else { // ... }在最后的 else 语句块中，如果我们还使用这个变量，那么它就会被智能推导为 boolean 类型。这肯定不是我们想看到的，它都走到兜底语句块了还有未收窄过的类型。所以我们简单粗暴的把它赋值为 never（回到最开始的例子）：const strOrNumOrBool: string | number | boolean = false; if (typeof strOrNumOrBool === "string") { console.log("str!"); } else if (typeof strOrNumOrBool === "number") { console.log("num!"); } else { const _exhaustiveCheck: never = strOrNumOrBool; }好的，报错来了：不能将类型“boolean”分配给类型“never”。ts(2322)我们再加上一个处理 boolean 类型的分支：if (typeof strOrNumOrBool === "string") { console.log("str!"); } else if (typeof strOrNumOrBool === "number") { console.log("num!"); } else if (typeof strOrNumOrBool === "boolean") { console.log("bool!"); } else { const _exhaustiveCheck: never = strOrNumOrBool; }现在就没问题了，因为在穷举完所有类型分支后，strOrNumOrBool的类型当然就也是 never 啦。这样做只是从 TypeScript 类型层面避免了遗漏，为了安全起见，我们可以在 else 兜底语句中抛出一个错误：// ... else { const _exhaustiveCheck: never = strOrNumOrBool; throw new Error(`Unknown input type: ${_exhaustiveCheck}`); }一个类似的场景，枚举 + switch case 语句，可能是最常见的组合之一：enum PossibleType { Foo = "Foo", Bar = "Bar", Baz = "Baz", } function checker(input: PossibleType) { switch (input) { case PossibleType.Foo: console.log("foo!"); break; case PossibleType.Bar: console.log("bar!"); break; case PossibleType.Baz: console.log("baz!"); break; default: const _exhaustiveCheck: never = input; break; } }现在这个是没有问题的，可是一旦你在枚举值中新增了一个成员（见示例），就会出现不能赋值给 never 的报错提示。在工具类型中大显身手好的，又到了喜闻乐见的工具类型环节，多少同学曾为了一个洋洋洒洒几十行的工具类型挠破头。其实吧，对于类型体操这一类，我感觉会中级的基本上就够了，你在写业务的时候来一个巨复杂巨绕十几个泛型参数的工具类型，你看同事会不会捶你。回到 never，never在工具类型中的作用其实可以概括为三个方面：作为泛型参数的默认值，以支持工具类型内部，基于入参个数变化的类型处理逻辑。与 infer + 条件类型结合，提取符合特定 Type Structure 的特定位置的值，如果待提取的类型参数不符合此结构，则返回 never。通过将接口中的部分属性指定为 never，去除其中的某些属性，以此来实现裁剪/组装/扩展接口。首先是作为泛型参数的默认值，上一个稍微绕点的例子：type Equal<X, Y, A = X, B = never> = (<T>() => T extends X ? 1 : 2) extends < T >() => T extends Y ? 1 : 2 ? A : B;严格来说，这个例子和第一点并没有特别大的关系，但这会是后面比较重要的工具类型的基础，同时也普遍被反馈比较难理解，所以这里扔上来提前讲解一下。这个结构是不是还挺诡异的，1 和 2 是什么东西，为什么 extends 里面还有泛型，这个 A 和 B 又是干啥的？定睛一看（对不起，最近郭德纲和于谦两位老师的相声听多了，定睛一看老是想到...），其实就是两个东西作比较：(<T>() => T extends X ? 1 : 2) 和 (<T>() => T extends X ? 1 : 2)，再定睛一看，这不就是一样的两坨吗。等等，T 又哪来的？再一个个来，首先这个结构就是，如果 (<T>() => T extends X ? 1 : 2) 能够 extends (<T>() => T extends Y ? 1 : 2)，那就返回 A，否则返回 B。关于 extends，这涉及到协变与逆变相关的部分，在这里你可以简单理解为，左边的类型更加狭窄具体，右边的类型更加宽松广泛时（即，右边类型中有的在左边肯定有！），extends 成立：// "TRUE" type Test = { foo: string; bar: boolean; } extends { foo: string } ? "TRUE" : "FALSE";这个泛型 T，你会发现它实际上也没有具体的值，而是作为整个 (<T>() => T extends X ? 1 : 2) 结构的一部分参与到比较当中（毕竟才刚定义嘛，通过<T>）。在这个例子中我们其实只是用这个套了一层作为条件，来比较 X 与 Y 是否相等。诶，怎么又变相等了，说好的 extends 是一个狭窄一个宽松呢？仔细看老伙计，这里不是简单的 X extends Y，不然我为啥要外面套一层这东西？通过将 X 与 Y 放置在临时函数的返回值中间接判定，确保了只有在 X 与 Y 完全一致时才能通过 extends。这里的完全一致指修饰符啥的也一致，比如两个接口的话，接口A的属性 foo 是只读 readonly 的，那接口 B 的属性 foo 就也得是只读的，一个简单例子：// fail type TestEqual1 = Equal<[], readonly [], "pass", "fail">; // pass type TestEqual2 = Equal<[], [], "pass", "fail">;再看这里的 A 和 B，其实就是决定了 extends 通过与否对应的返回值，这里的 A = X 和 B = never 其实和它实际的场景有关，完全可以不写或者自由发挥。下一点，与 infer + 条件类型结合，说到这我可就不困了啊，毕竟这是最简单的场景了，甚至可以直接看例子就行。当然，前提是你了解 infer。type FuncReturnType<T extends (...args: any) => any> = T extends ( ...args: any ) => infer R ? R : never;基本上所有进行单次提取行为的工具类型都是这个结构，比如 TS 4.5 新增的 Awaited（或者叫 PromiseValue），提取一个 Promise 的内部类型；同样是内置的 Parameters（提取函数参数类型）、ConstructorParameters （提取构造函数参数类型），都是这么个套路，没啥意思。然后是不带 infer 玩，never 和条件类型搞小团体的版本，这种单次判断也很简单，比如 Exclude、Extract 两兄弟：type Exclude<T, U> = T extends U ? never : T; type Extract<T, U> = T extends U ? T : never;看起来好像很朴素，那是因为这里的 T 和 U 通常是联合类型为多，如：interface Tmp1 { foo: string; bar: string; baz: string; } interface Tmp2 { foo: string; baz: string; } // "bar" type ExcludedKeys = Exclude<keyof Tmp1, keyof Tmp2>; // "foo" | "baz"; type ExtractedKeys = Extract<keyof Tmp1, keyof Tmp2>;当然，你也可以把 keyof 封装进去，即type ExcludedKeys<T, U> = keyof T extends keyof U ? never : keyof T; type ExtractedKeys<T, U> = keyof T extends keyof U ? keyof T : never;为什么不呢？我希望看到这里，你已经摸到了一丝 never 实际作用的曙光，即它在工具类型里到底起什么作用，如果没有也没关系，不然我这摊子就摆不下去了。接下来我们来看一些更常见、更强大的 never 应用吧。先来看这样一个接口：interface ITmp { foo: number; bar: string; baz: never; }你猜使用这个接口的对象能不能有 baz 属性？事出无常必有妖，所以这里肯定是不行。这么一个接口有作用？好像是没有，显式的声明 never 意味着你都知道有哪些属性是需要剔除（而且需要手动声明）的了。那如果我们通过各种体操动作，最后得到这个接口呢？这也是 never 的第三种作用，也是我个人认为最强大最 Amazing 的一种：通过将接口中的部分属性指定为 never，去除其中的某些属性，以此来实现裁剪/组装/扩展接口。我们可以通过使用 映射类型 + 条件类型 很容易的得到这种结构的接口，如type ProcessedTypeWithNonFuncPropAsNever<T extends object> = { [K in keyof T]-?: T[K] extends Function ? K : never; }; interface IInterfaceWithFuncProps { foo: string; bar: string; func1: () => void; func2: () => void; }好吧这个名字有点小长，将就一下好了，一直 foo bar baz 怪敷衍的。这里的 -? 意为去除 ?: 标志。这个得到的结果是：type Result = ProcessedTypeWithNonFuncPropAsNever<IInterfaceWithFuncProps> type Result = { foo: never; bar: never; fun1: "func1"; func2: "func2"; }这个好像没啥用啊？函数还可以更近一步，获取所有函数类型的键组成的联合类型，比如 "foo1" | "foo2"，只需要加上一点小小的东西：type FuncTypeKeys<T extends object> = { [K in keyof T]-?: T[K] extends Function ? K : never; }[keyof T]; // "func1" | "func2" type Result = FuncTypeKeys<IInterfaceWithFuncProps>把 T[K] extends Function ? K : never; 改成 T[K] extends Function ? T[K] : never; 就可以直接拿到值啦。这个可能简单了点，看个稍微复杂点的：type MutableKeys<T extends object> = { [P in keyof T]-?: Equal< { [Q in P]: T[P] }, { -readonly [Q in P]: T[P] }, P, never >; }[keyof T]; type Equal<X, Y, A = X, B = never> = (<T>() => T extends X ? 1 : 2) extends < T >() => T extends Y ? 1 : 2 ? A : B;如果前面没有讲过 Equal 这个类型的作用的话，那这个 MutableKeys 还是要皱眉看它个三五分钟才能看懂的，但讲过就好办多了。我们前面讲过 Equal 中的 extends 需要两边的类型完全一致，包括修饰符如 readonly 以及 ?，所以我相信你大概还是没看懂，拆开来看：首先用映射类型把这个接口的键提取出来：[P in keyof T]然后再对这个键提取一次：{ [Q in P]: T[P] } 与 { -readonly [Q in P]: T[P] }使用 Equal 比较上面的两个提取，并在比较通过时返回第一步中首次提取的键。对于第二步，我们实现一个中介类型：interface IInterfaceWithReadonlyProps { readonly foo: string; bar: string; readonly func1: () => void; func2: () => void; } type Tmp<T extends object> = { [P in keyof T]-?: { [Q in P]: T[P] }; }; type A1 = Tmp<IInterfaceWithReadonlyProps>;这个 A1 的类型大概是这样：type A1 = { readonly foo: { readonly foo: string; }; bar: { bar: string; }; readonly func1: { readonly func1: () => void; }; func2: { func2: () => void; }; }其实就是 K:V 变成了 K:(K:V) 的形式，为啥要这么做嘞？我们在比较时为 Equal 中的 Y 传入了去掉最外层 readonly 的版本，就变成了 readonly foo: { readonly foo: string } vs foo: { readonly foo: string } ！很明显这两个比较是通不过的，那么就说明 foo 肯定是只读的，MutableKeys 里不准有它！比起来 readonly，可能 ?: optional 更多一些，那实现个 OptionalKeys 吧：export type OptionalKeys<T> = { [K in keyof T]-?: {} extends Pick<T, K> ? K : never; }[keyof T];我们前面说过，extends 的左边不能比右边更宽松，所以，{} extends { a:number } 肯定不成立，但是 {} extends { a?: number } 可以，所以使用 Pick 择出来可选类型就好了。好了，美好时光总是短暂的，我也没估计读到这里大概要多久，十分钟应该要吧，让我们最后再看一个实用的工具类型，然后请关闭手机/电脑屏幕，做五分钟眼保健操。我们经常遇到这种场景：某个对象同时只能且必须满足多个接口之一，比如如果你是普通用户，那么肯定就不是 VIP。某个对象中同时只能有多组属性之一，比如你要么有普通用户才有的属性（距离下一次赠送 VIP 体验券还有多久），要么有 VIP 用户才有的属性（VIP等级）某个对象中的数个属性必须同时存在或不存在，比如你要么同时有 VIP 用户才有的 VIP等级 和 VIP到期时间，要么啥也冇。这些场景其实全部可以抽象为一种，互斥类型，而用 never 来实现可能是最优雅简单的办法。比如第二种情况，其实就是 { sendVIPExpTime: number; vipLevel: never; } | { sendVIPExpTime: never; vipLevel: number; } ，实现也很简单：type Without<T, U> = { [P in Exclude<keyof T, keyof U>]?: never }; type XOR<T, U> = (Without<T, U> & U) | (Without<U, T> & T);我觉得这个应该不用解释了吧，看看效果：interface Foo { foo: string; } interface Bar { bar: string; } // foo + bar:never | bar + foo:never type FooOrBar = XOR<Foo, Bar>; const fooOrBar1: FooOrBar = { foo: "foo" }; const fooOrBar2: FooOrBar = { bar: "bar" }; // Error // @ts-expect-error const fooOrBar3: FooOrBar = { baz: "baz" }; // Error // @ts-expect-error const fooOrBar4: FooOrBar = { foo: "foo", bar: "bar" };以及至少满足一种备选类型的情况：// 必须有sharedProp，container、module至少有其中一个 // 如果去掉 Partial，则是必须至少有一个 type ComposedOption = { sharedProp: string } & Partial< XOR< { container: { containerId: number; }; }, { module: { modId: number }; } > >; const option: ComposedOption = { sharedProp: "foo", container: { containerId: 599, }, };写到这里，全文也该结束了。其实这篇文章还是超出了我对精简的预期，毕竟很多知识点都是牵一发而动全身（尤其是工具类型部分），如果直接扔出来的话就只能我和读者四眼懵逼了。本篇文章作为此系列的第一篇，应该是存在着很多不足的，比如我听着相声写下这篇文章，让它显得不是很严肃...，但也希望你能从中学到一些，再提醒一下，你可以在 GitHub 找到此系列的所有代码，我们明年下次再见。

编者按：本文整理自龙蜥大讲堂技术解读，分享主题为《构建商用密码操作系统》，直播视频回放已上线至龙蜥社区官网：商用密码操作系统如何构建？，欢迎观看。作者张天佳，来⾃阿⾥云操作系统团队，是龙蜥社区商密软件栈 SIG 负责人。主要研究⽅向为 OS 安全，包括可信计算，机密计算，⽬前专注于国内商⽤密码的⼯程开发以及推广⼯作，我们团队主导开发了 Linux 内核、libgcrypt、OpenSSL 等多个项⽬中主要的商密算法⼯程化以及优化实现。缘起说到密码算法，⼤家⼀定很熟悉 MD5、AES、RSA 这些通用的国际标准算法，这也是目前我们普遍采⽤的密码学算法，它们在数据安全、互联网、通信、区块链等众多领域都有着⼴泛的应用。众所周知，这些算法标准都是国外制定的，⼯程实现也主要由国外主导，在某些情况下这会对国内信息安全有不利影响。当下有实力的国家，甚⾄有些大公司都制定了自己的算法标准。密码算法是保障信息和数据安全的核⼼技术，随着近年来外部的国际贸易冲突和技术封锁，国内互联网的快速发展，我们不能单⼀依赖国外的的技术标准和产品，增强我国⾏业信息系统的安全可信显得尤为必要和迫切。商⽤密码算法给我们提供了⼀个新的选择，使得我们可以完全使用商密技术来构建⽹络和数据安全环境。因此，建立⼀套商⽤密码的基础设施就显得尤为必要和迫切，本次分享带给⼤家我们是如何基于 Linux 内核构建起商⽤密码基础设施，基于商⽤密码的应⽤，以及未来的思考和规划。商用密码简介及现状商⽤密码标准完全由中国密码管理局制定，作为中国⾃主研发可控的密码算法，主要的⼯程实现也基本是国内开发⼈员完成的，这对于摆脱国外的密码技术和产品依赖，以及保护国内数据和网络安全是非常有利的。商用密码，简称商密，拼⾳缩写是 SM，⼝语中⼀般称呼为国密，通俗来说可以认为是密码算法的国产化，跟其它领域⼀样，中国的商密算法为我们提供了⼀个新的选择，在必要的场合中可以选择替代那些国际主流算法，尤其是当下国际贸易冲突，技术封锁不可忽视的⼤环境下，⼤规模推⼴和采⽤商密算法将为国内重要的网络基础设施提供可靠的数据安全保障。近⼗多年来，国家密码管理局陆续发布了多项商⽤密码⾏业标准，其中⼀些成为国家标准，很多基础类的算法标准也陆续成为 ISO/IEC 国际标准，到⽬前为⽌，商⽤密码标准已经⾮常成熟，也提供了完全⼀致的算法接⼝和⽤户体验，完全可以⽤来替代主流的国际算法。商密算法并不是⼀新技术，⾃ 2012 年以来，SM2/3/4 的商密标准陆续公布，⾄今⼗多年，商密商业应⽤基本处于⼀个相对空⽩的状态，国内的商密软硬件⽣态，技术⽅案实现存在很严重的碎⽚化情况，我们经常可以看到各种个⼈或组织名义开源的⽀持商密算法的库，技术⽅案参差不齐，在安全更新和社区活跃度也做的不够好，这也⼀定程度上限制了商⽤密码的⼤规模应用；商密的推⼴仍然任重道远，需要我们中国基础软件的开发者和⽤户共同努力。碎⽚化的⽣态就导致没有统⼀的技术⽅案，进而造成商密的产业化应⽤就特别的慢，导致鲜有⼈愿意为反哺商密⽣态，造成这样⼀种恶性循环。尤其是当前的⼤背景下，密码算法的国产化已经势不可挡，这也是我们必须要做的事情。2020 年 1 ⽉ 1 ⽇，《中华⼈⺠共和国密码法》正式实施，从法律层⾯规范了国家商⽤密码的应⽤和管理，这也为推⼴和应⽤商⽤密码提供了必要的法律保障。与国际算法的对比这⾥是商密算法和国际通⽤算法的⼀个对⽐，可以直观地看到商密的⼀个基本情况：针对各种常⽤的国际能⽤算法类型，⽐如对称算法，公钥算法和消息摘要算法，商密标准都定义了对应的相同功能的商密算法，⽐如 SM4 提供了与 AES 同样的加密强度，并且⽀持各种加密模式；SM2 是基于椭圆曲线的公钥算法，同时定义了⾮对称加解密，数字签名和密钥交换标准，相对于 RSA、SM2 的密钥更短，但⽀持的加密强度却更⾼；SM3 是商密定义的消息摘要算法标准，摘要⻓度是固定的 256 位，强度等同于 SHA256。除了基础的算法，商密标准也定义了 TLCP 商密双证书协议，⽤以⽀持国内的传输层安全协议。这⾥还有⼀个好消息，今年三⽉份，TLS1.3+ 商密单证书协议正式被国际标准所承认，并且以 RFC8998 标准发布，这意味着我们可以选择在 TLS1.3 协议中使⽤完整的商密套件，⽬前我们也在联系正规浏览器⼚商⽀持这个标准的实施和应⽤。同时商密标准也定义了使⽤商密算法的 X509 证书，使⽤ SM3 哈希算法，SM2 算法作为数字签名，证书类型 SM2-with-SM3。对开发者来说，商密提供了⼀个选择，可以选择从国际通⽤算法平滑迁移过来。除此之外，商密还有其它⼀些算法标准，是不太常⽤的，⽐如 SM9、ZUC 算法等。商密基础设施架构万事俱备，有了基础商密算法⽀持，我们便可以构建出⼀个围绕商密算法展开的基础软件⽣态。这是⼀个商密⽣态的垂直场景，也是我们在 Anolis OS 上的商密⽣态架构，同时它也是⼀个全栈商密解决⽅案：从底层固件、内核、到基础密码学库，在主要链路上做商密改造，最终形成⼀个完整的基于商密的安全信任链条。图上右边是⼀些垂直的商密应⽤场景，⽐如 SecureBoot、IMA、内核模块签名、⽂件完整性校验等。到⽬前为⽌，我们已经在 Linux 内核、BabaSSL、libgcrypt、Gnulib 等主流的基础组件中⽀持了商密算法，这部分的⼯作都已经回馈到了上游开源社区，有兴趣的开发者可以直接拿来使⽤或者作为参考，⽬前实现的特性已经全部通过 Anolis 商密版 OS 输出，关于这个商密版的 OS，后⾯会做⼀个详细介绍。从中也能看到，商密⽣态涉及到的软件栈⾮常多，形态也是各种各样，要逐步完善这个⽣态，还有很⻓的路要⾛。近⼏年的国际技术封锁也给了我们做这件事的决⼼和动⼒。⽬前我们已经和 ARM，海光等⼚商有⼀些合作，也⾮常欢迎业界有兴趣的开发者能够参与到社区，⼀起来做这个事情，之后我们的⼯作都会在 Anolis 社区以开源⽅式运作，秉着开放包容态度，继续补充完善这个⽣态，最终达到的⼀个⽬标是：整个安全信任链是完全建⽴在商密算法之上。BabaSSL前世今⽣BabaSSL 是主打商密的密码算法库，与 OpenSSL1.1.1 保持兼容，作为商密的密码算法解决⽅案⽽诞⽣。BabaSSL 是基于之前蚂蚁集团和阿⾥集团内部的 OpenSSL 版本合并⽽来，我们希望将 BabaSSL 打造成⼀个灵活、⼩巧并且健壮的基础密码学库，项⽬主体已于2020 年 10 ⽉在 Github 开源（链接见文末），当前开源的版本是 8.2.1，也是⽬前最新的稳定版本。BabaSSL 的主要发起者是蚂蚁集团的杨洋，杨洋也是 OpenSSL 项⽬在国内唯⼀的 Maintainer，主导开发了其中商密相关的算法，并且组织制定了 RFC8998 规范，关于这个规范，后⾯也会详细介绍。BabaSSL ⽬前完全以社区⽅式动作，已经组建了技术委员会，由阿⾥和⾏业内其它公司主要开发者组成，技术委员会决策项⽬的发展⽅向以及运营⼯作。BabaSSL ⽬前在阿⾥集团和蚂蚁集团内部得到了⾮常⼴泛的使⽤。从具体场景来看，有如下三个⽅⾯，分别是存储、网络和端上的设备。其中网络服务的场景，是 BabaSSL 最⼤的⽀撑场景，例如淘宝、天猫、阿⾥云等各种涉及到链路加密的服务器端。此外移动端 App，例如⽀付宝⼿机 App 中集成了 BabaSSL 来实现多种密码学的能力。特⾊功能以下是 BabaSSL 当前最新稳定版本 8.2.1 的主要特⾊功能特性：基于 OpenSSL1.1.1，具备 OpenSSL1.1.1 的全部能⼒并且保持兼容⽀持商密 SM2、SM3 和 SM4，SM4GCM/CCM 模式算法更加完善的 SM2 算法⽀持，⽐如 X.509 证书签发、验签的⽀持，这是 OpenSSL1.1.1 欠缺的能力GM/T0024 和 TLCP 商密双证书 TLS 协议⽀持 RFC8998：TLS1.3+ 商⽤密码算法套件提供了对 IETF 正在标准化过程中的 DelegatedCredentials⽀持 IETFQUICAPI 底层密码学能力正在申请软件密码模块⼀级资质与 OpenSSL 对⽐接下来是⼤家很关⼼的 BabaSSL 和 OpenSSL 这种⽼牌的密码算法库之间的区别：从图上可以看到⼀些主要区别：对于⼀些新的密码学技术标准，BabaSSL 会采取⼀种相对激进的策略快速跟进，⽐如在 IETF 中⼀些正在标准化流程中的技术⽅案，例如 delegatedcredentials、compactTLS 等，会进⾏原型的实现和快速跟进，⽽ OpenSSL 则是相对保守，因为 OpenSSL 社区的策略是原则上只实现已经发布了的国际标准和国家标准。在对于商密算法、商密协议、商密的监管合规、云计算⼚商的深度集成、以及国产化硬件等⽅⾯，BabaSSL 会进⾏更加深度和⼴泛的⽀持，而 OpenSSL 则⽀持的⽐较有限。对于 API 的易⽤程度，由于没有历史包袱，所以 BabaSSL 可以提供更加简单易⽤的 API，而 OpenSSL 的 API 则相对复杂。对于资源受限的嵌⼊式设备，BabaSSL会进⾏体积裁剪和内存使⽤量的规划，OpenSSL 则明确表示没有相关的计划。社区回馈情况我们在商密⽣态多年的开发⼯作已经全部回馈到了社区，其中绝⼤部分贡献到了主流开源项⽬的上游，包括 OpenSSL、Linux内核、libgcrypt、Gnulib 等，代码量超过 23000 ⾏，图中绿⾊打勾部分都是我们⾃主开发的。以下是这些贡献主要的成果：Gnulib 库中实现了SM3 算法的基础实现，Gnulib 是 GNU 软件栈中⼀个通⽤的基础库实现了 libgcrypt 中基础的商密算法 SM2/3/4实现了 Linux 内核⾥ SM2 算法，以及⽀持了使⽤ SM2/3 算法的 pkcs#7 签名，X509 证书使⽤ x86AVX2 指令集优化内核的 SM4 算法，相⽐于纯软件实现，有接近 8 倍的性能提升Linux 内核 Kernel TLS ⽀持使⽤ SM4GCM/CCM 算法IMA 场景⽀持使⽤ SM2/3 算法组合，包括内核和⽤户态⼯具 ima-evm-utils 的⽀持在 Rust ⽣态中主流算法库 RustCrypto 中实现了 SM3 算法⽀持 coreutils 社区实现 sm3sum ⼯具，⽬前以cksum -a sm3 方式在上游社区支持OpenSSL 的 KTLS ⽀持以及商密实现上的若⼲问题修复QUIC、证书压缩等还处于 RFC 阶段的特性经过几年的努力，我们基本建起了商密的基础软件设施，当然这个⽣态不管是横向还是纵向还有很多⼯作要做，需要更多开发者参与进来⼀起建设，我们⾮常欢迎与⼤家⼀起合作。技术解读OpenSSLASYNC机制OpenSSL ⾥的异步协程机制，这其实是⼀个与今天主题关系不⼤的技术点，主要是国为 OpenSSL ⾥实现了协程，我们也做了⼀些优化，因此做⼀个简单介绍。协程是近⼏年⽐较⽕的⼀个技术，⼀些主流语⾔都或多或少⽀持了协程，⽐如 rust 和 go，Nodejs 和 C 语⾔也有相应的技术或者协程库。但是协程并不是⼀个新技术，Lua 在 18 年前的 5.0 版本中就已经原生⽀持了协程。协程是⽤户⾃主控制的任务调度单元，对操作系统来说是透明的，协程主要应⽤于异步⾼性能场景，⽤户实现负责抽象异步的⾮阻塞和任务单元的调度，提供⼀个协程的开发和运⾏环境。相比于其它⾼性能场景的解决⽅案，协程主要有以下优势：相⽐于线程，协程更轻量，协程占⽤的资源⾮常少，创建释放也只是⼀个函数调⽤，不需要内核参与。协程是⾃主调度的，⼀般只在阻塞时主动选择调度到其它协程，比起线程的抢占式调度，可控性更⾼，调度的成本也⾮常低，往往只是⼀个函数调⽤。也由于⾃主调度的特点，协程是没有竞争条件的，也就不需要同步，我们知道，同步问题往往是造成多线程编程的恶梦。同步书写，异步执⾏，这是协程相⽐于 nginx、nodejs 这种回调式⾼性能⽅案的最⼤优点，nginx 和 nodejs ⼯程⾥为了实现异步，使⽤了⼤量的回调，甚⾄是多级回调的嵌套，把同步⽅式中的串⾏流程打断到多个回调函数中去执⾏，这当然是很⾼效的模式，也是他们的编程模型决定的，这⼀定程度也导致了程序的可读性差，可维护性低。协程完美的解决了这个问题，在⼏乎不影响性能的前提下，把原来分散到若⼲回调函数中的⽚断代码集中起来，我们可以⽤串⾏⽅式来写异步代码，由协程背后的异步机制来负责调度串⾏的代码⽚断，达到同步书写，异步执⾏的⼀个效果，左图对这个概念表达的不太完整，每个协程是分散在若⼲的⽚断中被执⾏的，但是我们作为开发者，不⽤考虑这些细节，只需要采⽤同步的⽅式来编码即可。⽬前也已经有很多框架采⽤了这种模式，⽐如 openresty，rust ⾥的协程也是这样的模式。图上是⼀个⾮常简单的 TCPecho 服务器伪代码，采⽤了协程机制来实现，这可以让我们对协程有⼀个直观的感受，虽然是伪代码，已经很接近真实的代码实现，在⼀个协程⾥ listen，针对每个连接过来的客户端，再开⼀个协程负责与这个客户端交互，看起来跟同步多线程模型⾮常像，整个过程是⼀个同步的书写模式，但背后是异步的协程在负责调度，性能也⽐同步多线程⾼了许多。这是⼀个非常典型的场景，OpenSSL 由于需要实现异步 TLS，也实现了⼀个简单的协程机制 ASYNC，可能由于 OpenSSL ⾥场景⽐较简单的缘故，ASYNC 并不⽀持左图中的这种编程模式，主要是它实现的⼀些缺陷造成的：引⼊了 dispatcher 作为调度器，并存储协程状态同⼀时间只能存在⼀个协程只能在 dispatcher 和唯⼀的协程之间切换⽆法⽀持左图中的场景因此我们在 BabaSSL 中引⼊了相应修复⽅案，⽬前已经在 BabaSSL 中得到了⽀持，同时也把这个修复以PR形式提交给了OpenSSL社区。TLS证书压缩TLS 协议是基于 TCP 协议，但也有点类似于 TCP，TLS 连接建⽴之前会有⼀个握⼿过程，作为⼀个安全协议，客户端⼀般会验证服务端的身份，这是通过服务端的证书来完成的，经过我们调研，TLS 握⼿过程中的主要⽹络流量就是消耗在证书传输上，尤其是存在过多的中间 CA 会导致证书链成倍的增⼤，这种情况在双向认证时也很明显。因此，在握⼿过程中对证书进⾏压缩就很有必要，从握⼿过程上来看，客户端会在 ClientHello 的扩展中告诉服务器⽀持的压缩算法列表，如果服务端也⽀持压缩，会把压缩过的证书传输给客户端，从而减少不必要的流量消耗。TLS 证书压缩已经是 RFC 的标准规范，已经率先在 BabaSSL 中得到了⽀持，由于 OpenSSL 相对保守，现在仍然不⽀持这个特性。证书压缩⽬前⽀持三个压缩算法，也⽀持使⽤字典⽅式压缩。开发者可以在 BabaSSL 中体验证书压缩特性：#编译时需要开启TLS证书压缩功能 ./config enable-cert-compression #如果是应⽤开发者，调⽤该API开启证书压缩功能 SSL_CTX_add_cert_compression_alg(); #s_server/s_client命令体验 openssl s_server/s_client -tls1_3 -cert_comp zlibBabaSSL 在编译时提供了⼀个开关选项，需要在编译配置时打开，如果是应⽤开发者，需要调⽤图中这个 API 在 SSLCTX 中⽀持使⽤证书压缩。⼀般⽤户也可以通过 s_servers_client 命令来体验这个功能，在命令⾏中指定证书压缩选项以及对应的算法。从我们的测试数据来看，普遍可以达到 70% 多的压缩率，甚⾄在使⽤ zstd+ 字典模式时，压缩率可以达到不到 1%，也就是说证书的流量被压缩到了原来的 1% 不到。使⽤证书压缩功能，可以⼤⼤降低握⼿过程中的⽹络传输消耗。从实验数据可以看到，就算加上除证书之外的其它握⼿阶段，在整个握⼿过程中，传输的流量最低只有原来的 20% 多⼀点，我们节省了 80% 的带宽。内核 SM4 算法优化图中是我们在 Linux 内核对 SM4 算法做的⼀个优化之后的性能数据，对⽐了纯软件实现，AVX 优化实现，AVX2 优化实现的性能，在 1024 ⼤⼩的 block 下，AVX2 的优化相⽐于纯软件实现，CTR 模式下的性能提升了近 8 倍。因为 CBC 和 CFB 加密时有块依赖关系，⽆法进⾏并⾏的优化。不像 AES 这种国际主流算法，各种架构 CPU 都有提供相应的指令集来做加速，SM4 就没有这么好的待遇了，x86 的 CPU 都是没有这样的指令集的，⽬前只有 ARM 的 spec ⾥有优化指令集的定义，因为这是个可选的指令集扩展，因此主流的 ARM 芯⽚默认都选择了不⽀持，当然这也与国密的整个⽣态影响力有关。不过我们可以借助于 aesni 和 avx 指令集间接优化 SM4，通过两次矩阵转换和⼀次 AESSBOX 查表来实现⼀轮 SM4 优化，并且把这⼀系列操作⽤ AVX 指令集来并⾏化，最⾼可以达到 16 个块并⾏计算，虽然看起来链路更⻓了，但都是在硬件层⾯的优化，实际的性能提升⾮常明显。Anolis商密版OS以上我们主要介绍了 BabaSSL 和商密基础软件⽣态上做的事情，为了让⽤户能有⼀个直观的体感，更快速的使⽤到商密的技术，我们把所有的技术⽅案都⽀持到了 OS 里，以操作系统的形式提供给有需求的⽤户。为此，龙蜥社区开发了⽀持商⽤密码的 OS 镜像，⽀持了商⽤密码基础设施和应⽤开发⼯具包，同时⽀持了诸多商⽤密码的应⽤场景，对安全合规，数据机密性，以及安全性要求较⾼的⽤户可以基于这个商密⽣态开发出丰富的符合⾃身需求的商密应⽤。Anolis 商密版 OS 是国内⾸家从操作系统层⾯提供商⽤密码的 OS 解决⽅案，在保持 100% 兼容普通 Linux OS 的基础上，从内核到应⽤层基础算法库的全链路上完整⽀持了商密算法，以及基于商密算法的安全认证机制，完全抹平了商密使⽤⻔槛，提供给有需求的⽤户⼀个开箱即⽤的操作系统环境。这⾥⾮常感谢 OpenAnolis 社区提供给我们这样⼀个平台，⽬前项⽬源码完全在社区开源，也欢迎⼤家能够参与以及贡献。有兴趣的⽤户可以从以下地址下载体验，为了⽅便⽤户体验，同时提供了 ISO 镜像和虚拟机镜像（链接见文末）。Anolis 商密版 OS ⽀持以下主要的特⾊功能： 使⽤ BabaSSL 替代 OpenSSL 作为系统默认的基础密码算法库linuxkernel ⽀持完整的 SM2/3/4 算法以及使⽤商密算法的 PKCS#7 签名和 X509 证书提供给开发者 SM2/3/4 商密算法基础库以及使⽤商密算法的 X509 证书以及 SM2 签名能⼒提供 GM/T0024 和 TLCP 商密双证书协议基础库⽀持 RFC8998 协议开发，在 TLS1.3 中使⽤商密算法套件内置了sm3sum⼯具，提供与sha256sum，md5sum类似⼯具⼀致的⽤户体验除此之外，对于业界领先的 QUICAPI 底层密码学能力，以及 IETF 正在标准化过程中的 DelegatedCredentials 也做了⽀持。商密应用场景基于 Linux 内核和 BabaSSL 提供的通⽤的商密技术⽅案，可以开发出各种使⽤商密的产品和应⽤，以下⼏个场景是我们做的商密化改造的典型场景。HTTPS、Web 场景的商密化改造当前的互联⽹时代，密码学应⽤最⼴泛的⽆疑是 HTTPS，众所周知，HTTPS 是构建在 TLS 协议之上的，TLS 是当之⽆愧的互联网通信背后的安全基⽯，因此，我们要在 HTTPS 中使⽤商密算法，只需要考虑在 TLS 协议中⽀持商密算法。⾮常荣幸，IETFRFC8998 规范在 2021 年 3 ⽉正式发布，这个规范是由蚂蚁集团主导完成的，规范完整定义了在 TLS1.3 协议中使⽤商密算法套件的标识，以及 TLS1.3 要求的算法定义。主要内容包括两个对称加密算法 TLS_SM4_GCM_SM3， TLS_SM4_GCM_SM3、数字签名sm2sig sm3以及在密钥交换中使⽤ SM2 曲线的标识。 当前版本的 BabaSSL 已经完整实现了 TLS1.3 和 RFC8998 中定义的商密套件，图中是 Wireshark 的⼀个抓包，可以看到 TLS 协议是完全构建在商密算法之上的。另⼀⽅⾯，TLS 的产业化应⽤还要考虑很多问题，从技术上来说，商密的性能是不⾜的，为此，我们为 TLS 商密化做了很多的优化，降低了商密的应⽤成本，使得⼤规模商⽤变得可能。我们主要以以下⼏个⽅⾯做了优化：⽀持了 TLS 的 offload 到内核，⽬前是纯软的 SWKTLS，这在数据量较⼤的 TLS 场景下减少了不必要的两次数据拷⻉，性能提升⽐较明显更进⼀步的，使⽤AVX2指令集优化了内核SM4算法，达到了近8倍的性能提升，让KTLS可以充分利⽤到这部分性能优化，这个优化⼤幅度提升了TLS商密的性能还有更彻底的NIC KTLS优化，TLS offload 到硬件⽹卡上去，这需要业界同胞们的共同努力。IMA 和 modsign 商密化我们知道，密码学算法从来就是为安全服务的，我们来看两个在安全领域具体商密改造的例⼦。 IMA 是 Linux 内核提供⼀个⽂件完整性度量架构，⽤于检测⽂件是否被恶意篡改，内核模块签名的⽬的是类似的，⽤于检测模块的发⾏源头是否可信，是否在分发途中被恶意篡改。它们都提供了自己的签名⼯具，签名⼯具依赖BabaSSL提供的SM2 签名⽂件的能⼒，⽤于在⽤户态做签名。⽂件签名的验证是在内核⾥完成的，由于内核不能直接使⽤应⽤层的库，为了⽀持在 Linux 内核⾥验证⽂件签名，我们在内核⾥实现了商密 SM2/3/4 算法以及商密证书的⽀持，⽤来验证签名是否合法。通过对相应软件栈的改造，我们完全基于商密算法构建了 IMA 和内核模块签名的安全机制，⽽这些之前都是由国际算法来保证的。Anolis 商密软件栈 SIG以下是我们在 OpenAnolis 上的商密软件栈 SIG，⾮常欢迎有兴趣的开发能参与到社区中来，为中国的基础软件安全添砖加瓦。 SIG地址：https://openanolis.cn/sig/crypto代码库：https://codeup.openanolis.cn/codeup/cryptoGithub开源链接：https://github.com/BabaSSL/BabaSSLISO 镜像和虚拟机镜像：https://mirrors.openanolis.cn/anolis/8.2/isos/ShangMi/相关阅读：Anolis商密OS最佳实践之内核模块签名商密化 国内首家商密OS重磅发布，Anolis商密版OS为用户数据保驾护航Anolis商密OS最佳实践之IMA商密化—— 完 ——加入龙蜥社群加入微信群：添加社区助理-龙蜥社区小龙（微信：openanolis_assis），备注【龙蜥】拉你入群；加入钉钉群：扫描下方钉钉群二维码。欢迎开发者/用户加入龙蜥社区（OpenAnolis）交流，共同推进龙蜥社区的发展，一起打造一个活跃的、健康的开源操作系统生态！关于龙蜥社区龙蜥社区(OpenAnolis)是由企事业单位、高等院校、科研单位、非营利性组织、个人等按照自愿、平等、开源、协作的基础上组成的非盈利性开源社区。龙蜥社区成立于2020年9月，旨在构建一个开源、中立、开放的Linux上游发行版社区及创新平台。短期目标是开发龙蜥操作系统(Anolis OS)作为CentOS替代版，重新构建一个兼容国际Linux主流厂商发行版。中长期目标是探索打造一个面向未来的操作系统，建立统一的开源操作系统生态，孵化创新开源项目，繁荣开源生态。龙蜥OS 8.4已发布，支持x86_64和ARM64架构，完善适配Intel、飞腾、海光、兆芯、鲲鹏芯片。欢迎下载：https://openanolis.cn/download加入我们，一起打造面向未来的开源操作系统！https://openanolis.cn

https://blog.jetbrains.com/phpstorm/2021/11/the-php-foundation/就在前天（2021 年 11 月 22 日）Phpstorm 的开发商 JetBrains 宣布，将与 Automattic、Laravel、Laravel、Acquia 等多家公司共同成立 PHP 基金会。据介绍，PHP 基金会将是一个非营利组织，其使命是确保 PHP 语言的活力和繁荣。Nikita Popov 的离开加速基金会成立今年 5 月 JetBrains 开始与多位 PHP 社区的主要贡献者讨论成立基金会的想法，之后，PHP 主要贡献者 Nikita Popov 的一个决定加速了成立基金会的进程。Nikita Popov 于 2011 年开始研究 PHP，并于 2019 年 加入 JetBrains 。Nikita Popov 在 JetBrains 从事 PHP 工作近三年，在三个主要版本 PHP 7.4、PHP 8.0 和 PHP 8.1 中都取得了很多成就。除了 PHP，Nikita 还是 Rust 和 LLVM 的贡献者，并且 Nikita 决定未来会专注于 LLVM。Nikita 于 12 月 1 日离开 JetBrains，这对于 PHP 社区来说是一个巨大的打击，也加速了成立 PHP 基金会的进程。JetBrains 公司在与社区成员以及一些对PHP有既得利益的公司进行了多次交流后，最终联合以下公司将共同组成一个PHP基金会:AutomatticLaravelAcquiaZendPrivate PackagistSymfonyCraft CMSTidewaysPrestaShopJetBrainsPHP基金会将是一个非盈利组织，其使命是确保PHP语言的长寿和繁荣。同时，该基金会将通过 Open Collective 来实现。Open Collective 是一家处理法律和会计方面的基金会服务提供商，Vue.js、Open Web Docs、webpack、Yii Framework 等多个开源项目都采用其服务。此外，PHP 基金会预计每年将筹集约 300000 美元，其中，JetBrains 将每年捐款 100000 美元，任何 php-src 的贡献者都可以向基金会申请资助。在基金会成立初期，将设立一个临时管理机构，临时管理机构包括的成员有：Rasmus Lerdorf、Dmitry Stogov、Joe Watkins、Sara Golemon、Derick Rethans、Sebastian Bergmann 和 Nikita Popov。同时，当前的 RFC 流程不会改变，语言决定将始终留给 PHP Internals 社区。PHP 基金会的官网https://opencollective.com/phpfoundation官网非常友好，方便全球 PHP 开发者捐款，在贡献者列表里，看到了很多熟悉的面孔！激动的我，马上拿出手机想出一份力，可惜我自己的信用卡不行，最后用同事的招商国际信用卡搞定了。资助的形式可以是单次的，也可以是月度和年度的方式支付，最少支付1刀，支付完，你的头像都会出现在贡献者排行榜上哟，PHPer 支持起来吧，厉兵秣马，胜利在即！

希望广大对Internet Computer开发有兴趣的小伙伴可以来现场进一步交流，同时也可以带上电脑可以现场部署，本次活动会进行线上同步直播，无法到现场的同学也可以线上观看。本次黑客松是打响DFINITY生态大爆炸的第一枪，优胜团队不仅可以获得丰厚奖励，还可以获得专业的创业指导。大家通过这次黑客松牛刀初试，也可为明年的2022 DFINITY Supernova全球黑客松夯实基础，备战2022！除此之外DFINITY与DoraHacks将在11月24日开启线上第一期技术分享活动，欢迎大家线上学习，加入DFINITY技术交流discord（https://discord.gg/Dq6hwXv2Pt）进一步获取学习资料，获取最新黑客松信息。冬天来了，大家一起来Hacking吧~~~面向人群● Web 开发者 ● Rust 开发者 Rust SDK● 使用Motoko语言的开发者 Motoko SDK ● 使用传统技术栈的应用与游戏开发者● 希望参与Internet Computer生态和工具建设的开发者● 任何希望学习在Internet Computer开发的入门选手● 任何想在Internet Computer上实现应用的个人和团队● 想快速实现自己的 Idea本次活动为技术沙龙活动，请大家报名通过审核后参与活动报名链接：http://hdxu.cn/36i18立即报名Warpspeed 2021 DFINITY×IAF黑客松通过报名链接即可直接报名·DFINITY 官网: https://dfinity.org‌·黑客松报名链接：http://icphackathon.mikecrm.com/2kwg1YV‌关于Internet Computer Protocol （IC）Internet Computer Protocol（互联网计算机协议）是世界上第一个以不受限制的、以网络速度运行的区块链。同时，它代表了除比特币和以太坊外的第三项重大的区块链创新，是一个区块链计算机，可扩展并以网络速度运行智能合约的计算和数据，有效地处理和存储数据，并为开发者提供强大的软件框架。为了使这一切成为可能，互联网计算机实现了对软件的彻底重新构想——提供了一种可构建代币化的互联网服务、泛行业平台、去中心化金融系统，乃至于传统的企业系统和网站的革命性新方式。该项目由Dominic Williams于2016年10月创立，得到了加密社区的极大关注。DFINITY基金会总计募资1.61亿美元，投资人包括安德森·霍洛维茨（Andreessen Horowitz）， Polychain Capital，SV Angel，Aspect Ventures，Electric Capital，ZeroEx，Scalar Capital和Multicoin Capital以及其他一些著名的以太坊早期支持者。关于Internet Computer亚洲生态基金（IAF）Internet Computer 亚洲生态基金 （Internet Computer Asia Fund - IAF），由SNZ Holding和Dfinity基金会发起, 同时得到Hashkey Capital，分布式资本等其他顶级基金和社区的共同支持。本基金致力于支持Ineternet Computer生态上的项目建设和发展，主要包括基于Internet Computer的Web3.0基础设施、开放金融协议、元宇宙及其他创新性应用，重点关注亚洲生态的项目。

本人是一名在读的本科学生，专业是计科，由于不太可能时时刻刻带着电脑在身边，但是有时候需要随时进行开发，本人通常拿云服务器做前端开发，学习rust等，本来一开始是使用coding的cloudstudio进行前端开发的，但是由于其存储空间太小，就必须要一个更大的空间，而且也为了方便的学习rust通常，一个项目中的依赖会逐渐增多，以至于我node_modules经常超过一个，而且内存空间，cpu资源等也很有限制，导致经常在控制台中出现killed的信息导致任务终止所以解决这些问题就需要一台用于开发的远程服务器，本来是拿着腾讯云的规格为1核2G1M的服务器来进行开发的，在这一年的使用中，我感到1核明显的卡顿感，这给我开发效率带来了较大困扰而一年过去了，服务器也到期，我打算找一个性能高一些的服务器，期望是两核的，但是查看了各大云服务商，对于学生而言，大多数2核服务器都比较贵，几乎很少有针对学生优惠的2核服务器这就给我带来了困扰，作为学生固然不太可能每个月花这么多在服务器上所以寻找一个能够满足我的东西，于是我找到了阿里云的飞天加速计划，他为我提供了一个2核的服务器，我完成了基础的任务，领取了一个两周的服务器我就体验了一下，给我的一些感受是2核要流畅的多，几乎很少才会有明显的延迟核卡顿，编译构建速度要明显提升数倍。

icejs 是什么？icejs 是一个基于 React 的渐进式研发框架，由淘系前端飞冰（ICE）团队于 2020.02 发布 1.0 版本，icejs 目前广泛服务于阿里内部以及社区用户，如下图所示，在阿里内部每天至少有 400 多个仓库基于 icejs 构建并发布，目前已经服务了内部 3K 多的开发者以及 5K 多项目。很多人可能会问，为什么需要或者什么场景下需要使用 icejs？这里把其中的 icejs 换成 Next.js、UmiJS 或者 Nuxt.js 问题依然成立，核心的问题都是此类研发框架的价值是什么？我尝试讲一下飞冰团队对于这个问题的思考：通过内置功能+插件化能力保证跨项目的一致性：对于稍具规模的前端团队往往会涉及很多个前端项目以及跨团队的协同，一致性的开发&使用方式能够更好的保证协同效率通过开箱即用的框架能力降低重复劳作：小到 TypeScript、CSS Modules 之类的构建配置，大到 MPA/SPA/微前端等不同模式的能力提供某些原本很复杂的功能可以让业务低成本接入：诸如 SSR/SSG、一体化这些能力，基于 Webpack/Vite 需要做非常多的事情，框架可以让这个成本大幅度降低同时也必须承认的是相比于直接基于 Webpack/Vite 这样的构建工具，研发框架会带来黑盒、带来约束、不够灵活……而这也是对框架开发团队最大的挑战：在提供各种能力的基础上如何还能保证良好的研发体验。全新的 2.0 版本自 2020.02 发布 1.0 版本至今一年半的时间里，icejs 结合社区的反馈迭代了 70 多个正式版本（平均每周一个版本），这也使得框架的功能丰富度&稳定性不断提升。而在 2021 年前端社区非常重要的两个趋势：基于 ES modules 的 Bundleless 模式: 随着浏览器对于 ES modules 的原生支持，社区也出现配套的构建工具 Snowpack 以及后续的 Vite，Bundleless 模式正在撼动着以 Webpack 为主流的 Bundle everything 模式基于 Rust/Go 重写前端工具链：替代 babel 的 swc，替代 Webpack 的 esbuild，Rome 用 rust 重写，Next.js 引入 Rust 后构建速度提升 5x这两个趋势也让大家更清晰的认识到传统 Webpack 工程体系构建速度太慢了，前端的调试构建体验有很大的提升空间，因此飞冰团队围绕「开发者体验」开始探索 icejs 2.0 版本，经过 3 个月的研发周期，总共 100+ Pull Requests，我们在 2021.09.28 正式发布了 2.0 版本，目前阿里内部 200+ 的项目已经基于 2.0 版本，我们也在今天向社区正式输出 icejs 2.0 的介绍文章。2.0 的一些重要特性：Vite 模式：在原先 Webpack 基础上，同步支持了 Vite 模式，同时在工程配置和框架能力上尽量保持一致性Webpack 5：将 Webpack 从 V4 版本升级到 V5 版本，引入新版本的 Module Federation、Cache 等相关能力swc&esbuild：试验性的在 Webpack 模式下引入 swc 替换 babel，尝试提升 Webpack 模式下最耗时的代码编译阶段，同时压缩链路也支持使用 esbuild 替代 terser更加完善的业务解决方案：提供状态管理、请求库、环境配置、微前端、SSR、SSG（新增）、PWA（新增）、keep-alive（新增）等完备的解决方案全新的文档：通过 Docusaurus 构建全新的文档站点，得益于 Docusaurus 丰富的能力，文档在 SEO、加载体验、Dark Mode、搜索、手机端体验等能力上有了大幅度的提升对于 2.0 版本，可以通过命令行快速创建，支持 antd/fusion/... 等多种模板：$ npm init ice icejs-example # 同时支持 yarn $ yarn init ice icejs-example为了保证基础的开发体验，建议使用 cnpm 或者国内的 npm registry 安装依赖。除了 CLI 以外，我们同时提供了研发工具 AppWorks 用于可视化创建项目，只需要在 VS Code 插件市场中搜索并安装 AppWorks 即可：Vite 模式：突破随着社区不断涌现的基于 ES modules 的构建工具，以及逐步完善的生态支持度，ES modules 的开发方式被越来越多的开发者所接受和尝试。得益于 Vite 本身的成熟度，icejs 也是能够快速的支持 ES modules 开发模式，同时我们的官方脚手架也已经默认开启了 Vite 模式。// build.json { "vite": true }快速适配 Vite 模式对于完全基于 Webpack 建设的框架体系，引入 Vite 最大的问题就是两种模式在使用上如何尽量保持一致、框架代码如何更好的维护。针对这个问题，首先在配置上统一沿用原先的 build.json 配置文件，支持 publicPath、alias 等工程配置，对于框架中所有的工程配置操作都基于原先的 webpack-chain 进行，一般情况下不需要面对 Vite/Webpack 的配置差异，通过抽象的 webpack-service 以及 vite-service 两个适配层，在 service 这一层实现对应的 start/devServer/build 能力，同时借助 wp2vite 将 Webpack 的配置一次性转换为 Vite 配置。如下为大体的架构设计，后续我们也会有专门的文章来介绍这部分的设计和实现。启动与热更新在引入 Vite 之后，我们针对 fusion-design-pro 这个较为复杂的项目做了一些测试，首先是项目启动时间，首次启动时间上，Vite 本身有按需构建的机制，加上借助 esbuild 的加持比 Webpack 快了 50%，但是二次启动时间上，得益于 Webpack 5 Cache 机制的加持下反而是 Webpack 要稍快于 Vite。由于 Vite 的 devServer 启动不依赖源码编译，因此 Vite 的 启动编译结束时间基于源码开始执行时间计算其次是热更新时间，与启动时间相比热更新时间 Vite 是完全碾压 Webpack 模式的，Vite 模式下热更新时间提升了 10 倍以上，只需要 100ms，并且不会随着项目变复杂而劣化。这也是我们觉得 ES modules 模式带来的最大收益点。框架能力适配除了上述基础的配置以外，框架还提供了更上层的能力，对于这些能力我们也做了同步的支持：MPA/SPA/微前端/一体化等不同应用模式的工程能力适配本地调试实时的 TypeScript/ESlint 检测能力：实现 vite-plugin-ts-checker 以及 vite-plugin-eslint-report 插件JSX+ 语法支持：结合 Babel 实现对应的 vite-plugin-jsx-plus 插件SSR/SSG：支持中通过上述工作，我们保证了 icejs Webpack 模式下 80% 的能力在 Vite 模式下一致性的使用方式，其他能力我们也在结合业务诉求同步支持中。Webpack 模式：稳中求进icejs 1.0 有大量存量的 Webpack 模式项目需要持续支持，同时在某些场景也无法切换到 ES modules 模式，因此在 2.0 中我们对于 Webpack 模式依然跟随社区的脚步在做持续的优化。Webpack 5从 ice.js 2.0 版本开始，底层工程依赖的 Webpack 版本将默认采用 v5 版本，工程上对 Webpack 相关的生态进行适配升级，确保开发者能够顺利过渡到 Webpack 5。借助 Webpack 5 的 Cache 能力，在 2.0 中热启动时间提升了近 5 倍，同时将 React Fast Refresh 做了内置将热更新的时间减少了 30%。另一方面我们也将诸如 postcss, less-loader, sass-loader 等依赖升级到了最新版本，确保开发者可以享受到新的功能。基于 Module Federation 的预编译方案借助 Webpack 5 的 Module Federation 特性，icejs 2.0 支持将应用的依赖预构建为一个 Module Federation 的 remote 应用，供当前应用进行消费，应用依赖不再编译到一个文件中，以减少 Webpack 对于依赖打包所需的时间。{ "remoteRuntime": true }通过 Module Federation 预编译的开启，热启动相比 1.x 版本提升明显，并且让热更新时间缩短近 60%。使用 SWC 替代 Babel（试验）swc 利用 rust 大大提升 JavaScript 源码的编译效率，目前已支持大部分 babel 编译的场景。因此 icejs 提供一键开启 swc 编译能力：{ "swc": true }开启 swc 编译后，除了 babel 被替换以外，默认的压缩器也从 terser 切换至 swc，进一步缩短时间：开启 swc 编译后，编译速度平均提升 50%，压缩速度提升近 35%。不过 swc 目前对于自定义插件支持还不友好，因此如果强依赖了一些其他 babel 插件，那么 swc 下目前是很难对齐，因此我们也将该项能力标识为「试验性」。目前前端社区对于 swc 越加重视， 飞冰团队也在积极参与 swc 相关方案的讨论，相信在不远的未来我们可以使用 swc 完全替代掉 babel。更多新特性微前端 x ESM在 icejs 支持 Vite 模式之后，同为飞冰团队开源的微前端框架 icestark 也同步支持了 ESM 规范的微应用，只需要在微应用上配置 loadScriptMode: import参数即可开启：<AppRouter> <AppRoute title="商家平台" + loadScriptMode="import" url={[ '//unpkg.com/icestark-child-seller/build/js/index.js', '//unpkg.com/icestark-child-seller/build/css/index.css', ]} /> </AppRouter>在开启该选项之后，icestark 会通过 dynamic import API 加载微应用资源。由于 ES modules 脚本只执行一次的策略，微应用二次加载渲染的速度提升非常明显。跟 SSR 一致的 SSG 方案SSG(Static Site Generation) 即静态站点生成，对于一些官网或者文档的场景，SSG 能够提供更好的 SEO 以及首屏渲染能力。icejs 1.0 中 SSG 方案基于 puppeteer 实现，开发者经常会遇到环境依赖的问题，在 2.0 中我们将 SSG 和 SSR 的方案做了更好的对齐，使用起来更加简单，仅需在工程配置中开启即可：// build.json { "ssr": "static" }仅需上述配置，在 build 之后就会生成每个路由的静态 HTML 文件，并且也同时支持 SSR 下的 Page.getInitialProps 在构建时获取初始数据能力：├── build | ├── dashboard | | └── index.html # 预渲染 Dashboard 页面组件得到的 HTML | ├── index.html # 预渲染 Home 页面组件得到的 HTML | └── js | └── index.js针对动态路由的场景，也支持在页面路由组件上设置 getStaticPaths 属性：// src/pages/Project/index.tsx: /project/:id const Project = (props) => { return <>Hello</>; } +Project.getStaticPaths = async () => { + return Promise.resolve(['/project/1', '/project/100', '/project/1001']); +} export default Project;SSG 的构建产物支持直接使用 nginx、oss 以及后端服务等多种部署方式，而应用的渲染模式上也支持按页面维度分别以 SSR 或者 SSG 方式渲染。更稳定的依赖管理方案研发框架往往会包含非常多的工程相关依赖，而我们也时不时会遇到社区依赖发包导致框架不可用的问题，因此在 2.0 中我们将依赖的 70+ 社区 NPM 包进行了预打包，只要 icejs 不主动升级，这些包以及其依赖的包版本就不会变化，以此来保证框架不会受这些依赖包发版影响，同时预打包也能间接提升框架安装的速度。未来Vite 模式下的能力完善目前我们核心的工程能力已支持 Webpack/Vite 两种模式一键切换，包括 SPA/MPA/微前端等场景，但是 Vite 模式下依然有很多需要突破的地方：SSR/SSG 能力支持进一步对齐 Vite/Webpack 的工程能力，比如 Vite 中更为简洁直观的 Static Assets 使用方式统一 Vite 模式下 AST 转换的能力，受限于 Vite 内置编译工具 esbuild 的开放 API 能力，强依赖 Babel 的场景（react-rerefsh、jsx、jsx+）都是插件各自调用 Babel，我们会在框架层面对这一层进行统一，同时会尝试直接引入 swc更轻量的一体化研发模式在很多中小型中后台系统的业务场景下，往往都是一个开发者从前到后负责整体的研发，在这种场景下以往的前后端分离反而会增加代码管理、接口联调、发布部署流程等成本。得益于前后端都使用 JavaScript 带来的语言一致性，以及 Serverless 基建保障低运维成本，过去一年里，我们基于 icejs + midway-hooks 的一体化研发模式在阿里内部落地了众多中小型中后台系统，同时也为 C 端业务低成本的实现 SSR 方案提供了巨大支持。在 2.0 版本里，我们希望进一步完善一体化方案，一方面会让服务端框架更加轻量以提升 API 的开发调试体验，另一方面也会在 FaaS 基础上支持 Node.js 部署，保障即便在没有 Serverless 基建的公司中也能够使用一体化能力。关于我们飞冰（ICE）团队隶属于淘系前端架构团队，希望能通过研发框架和研发工具改善前端开发者的体验。如果对 icejs、Vite、Webpack、VS Code 插件、Electron 等领域比较感兴趣，欢迎关注我们的 GitHub 仓库：https://github.com/alibaba/ice如果在使用飞冰相关产品中遇到问题，欢迎加入飞冰社区钉钉群反馈&交流：相关链接飞冰（ICE）站点：https://ice.work/icejs GitHub 仓库：https://github.com/alibaba/iceicejs 2.0.0 Release Pull Request https://github.com/alibaba/ice/pull/4334VS Code 插件 AppWorks：https://appworks.site/飞冰钉钉群二维码：https://ice.alicdn.com/assets/images/ice-group.png微前端方案 icestark：https://github.com/ice-lab/icestarkVite: https://vitejs.dev/swc：https://swc.rs/esbuild: https://esbuild.github.io/icejs NPM 依赖预打包：https://github.com/ice-lab/builder-deps

Android作为一个完整的操作系统解决方案，涉及到很多移动的部件。总的来说，这些部分先是应用生态系统，然后才是操作系统本身。作为一个开发者，你选择的编程语言，根据你正在开发的Android的哪一部分而有所不同。对于应用开发者来说，Java和Kotlin是当下流行的选择。对于从事操作系统及其内部底层部分的开发者来说，C和C++是迄今为止一直热门选择。今天，谷歌为Android操作系统开发者增加了第三个选择——Rust，现在Android开源项目支持Rust编程语言来开发操作系统本身。C和C++的局限性Android操作系统的底层部分需要C和C++等系统级编程语言构架。这些语言为开发者提供了控制和可预测性，这些在访问低级系统资源和硬件时非常重要。但却带来了一个缺点，C和C++不能提供内存安全保证，使得容易出现错误和安全漏洞。而且开发者有责任在使用这些语言时管理内存寿命，但在复杂和多线程的代码库中，这种想法做起来比说起来难太多。现在，C和C++共同构成了Android平台上数以千万计的代码行，这些内存安全漏洞成为最难解决的代码错误来源，占Android高危安全漏洞的70%左右。想要从修复Bug的角度处理问题已经变得不现实，更好的办法还是从一开始就预防这些Bug。缺乏内存安全性保证迫使开发人员在严格受限和无特权的沙箱中运行Android进程，但沙盒在资源上的成本很高，不仅消耗额外的开销，还引入延迟。沙盒也不能完全消除代码的漏洞，而且由于Bug密度高，沙盒的功效会降低，进一步让攻击者连锁多个漏洞。另一个限制不是C和C++独有的，但适用于所有的内存安全问题，那就是错误状态必须在工具化的代码中实际触发，才能被检测到。所以即使你的代码有很好的测试，实际的Bug也可能一直没有被发现。但当你发现Bug时，让它们得到修复又是一个漫长且昂贵的过程，而且不一定能得到修复。因此，Bug检测变得不可靠，鉴于这些局限性，Bug预防才是更好的方法。这就是改用Rust这样的内存安全语言的原因。Rust的好处Rust通过使用编译时检查和运行时检查相结合的方式提供内存安全保证，以强制执行对象的寿命/所有权，并确保内存访问是有效的。在实现这种安全性的同时，还能提供与C和C++相当的性能。Rust还减少了对沙盒的需求，让开发人员有更多的开销空间来引入更安全、更轻量的新功能。虽然Rust确实有它的好处，但一夜之间将整个Android操作系统换成Rust也是不现实的，而且也根本不需要这样做，因为大多数Android的内存错误都发生在新的或最近修改的代码中，甚至有大约50%的代码是一年内写的。因为谷歌认为，其内存安全语言的工作最好集中在新的开发上，而不是重写成熟的C和C++代码。Rust一个重要优势是它专注于防止出现Bug，而不是严重依赖于检测Bug，从最开始就提高代码的正确性。它还有几个关键特性，如内存安全、数据并发、更有表现力的类型系统、默认的不可变引用和变量、更安全的整数处理、标准库中更好的错误处理等。切换到Rust对Android意味着什么？谷歌表示，在过去的18个月里，它一直在为Android开源项目添加Rust支持。但在Android平台上添加一门新语言是一项巨大的工程。除了需要维护一些工具链和依赖关系外，必须更新测试基础设施和工具，并且需要培训开发人员。谷歌有一些早期采用者项目，他们将在未来几个月内分享。但即便如此，人们还是明确表示，将Rust支持扩展到更多的操作系统是一个多年的项目。从目前情况来看，谷歌已经在一些地方使用了Rust。Android新的蓝牙协议栈重写代码 "Gabeldorsche "就是用Rust编写的。Gabeldorsche的工作大约在Android 11的时候就开始了，但目前仍未投入使用。Android的Keystore 2.0模块是用Rust编写的，Android的IPC驱动binder的用户空间部分也是如此。虽然与Android无关，但Fuchsia的新netstack也是用Rust编写的。对于应用开发者来说，这个切换对你作为应用开发者如何编写应用或框架API来工作没有任何改变。这个切换只影响操作系统的编写方式。据Android开发者关系团队的一位成员透露，谷歌目前也不打算发布Rust NDK。应用开发支持的语言将继续是Kotlin、Java、C和C++。

微软 Azure CTO 办公室开源主管 Sarah Novotny 近日在开源博客上分享了过去一年中微软在开源领域所做的工作，希望微软的经验可以为 2021 年进行构建和协作的开发人员或团队有所帮助。2020 年的全球疫情从根本上改变了许多公司的工作模式，人们不得不改变他们的沟通和协作方式。但是，对于从事开源的人来说，远程工作才是常态。因为开放源代码社区庞大且分布在全球各地，需要来自世界各地的开发人员的有效合作。那么，开源的采用和使用在今年显着增长也就不足为奇了，GitHub 2020 Octoverse 报告显示，GitHub 上去年有超过 6000 万个新存储库创建，开发者数量超过 5600 万。尽管开源开发人员已经建立了许多成熟的远程实践，但今年，各种规模的公司都面临挑战，要求以新的方式集成其开源软件体验和开发模型。一、接受不同观点有助于更好的开发软件在开源领域的成功既取决于你对社区的贡献，也取决于你从社区中学到了什么。在每个拉请求、问题和代码片段的背后都是一个人。与他们建立联系非常重要，需要倾听、学习和与他们产生共鸣。也许他们可以提供团队没有想到的不同的观点和反馈。Sarah Novotny 提到了一个社区反馈改变他们观点的例子，Dapr 项目收到了大量用户反馈，要求提供一个流线型的 API 来检索应用程序应用程序机密。而微软负责 Dapr 的团队并没有计划在当前的周期内进行这项工作，但是社区明确表示这个新的 API 将解决开发人员面临的许多问题。Dapr 的维护人员与社区成员密切合作，在社区成员提交了多个 PR 后添加了这个功能，涵盖了从代码到文档到示例的所有内容。在添加了这个功能之后，微软的客户也选择了这个功能，并在他们的 Dapr 实践中使用了它。这表明，倾听社区反馈非常有价值，只要有机会，在得到鼓励和支持的情况下，社区成员就会为实现需求做出贡献。二、在政策和自主权之间找到平衡为了帮助推动开源工作，微软有一个专门的开源计划办公室（OSPO），其目标是帮助员工安全、有效、轻松地使用和参与开源。Sarah Novotny 说，过去一年中他们收到了很多企业客户（包括零售商，银行到汽车制造商）的信息，希望在内部建立类似的办事处和业务。我们分享并讨论了如何在制定政策和授权员工做正确事情之间找到平衡的最佳实践。虽然 OSPO 会根据公司的需要而有所不同，但我们经常讨论的一些常见做法包括创建跨职能小组，设置明确的策略并使它们易于查找和理解，对工具进行投资以及提供奖励和动力都可以满足。微软希望继续建立自己的内部实践，并在分享过程中帮助其他人也做到这一点。三、确保安全至关重要在开发过程中使用开放源码有许多优点，包括加速了产品开发、降低了所有权成本和提高了软件质量。然而，开源软件和其他软件一样也有风险，开源软件可能存在导致漏洞的安全缺陷。最新研究显示，安全漏洞通常在被披露之前的四年多时间里都不会被发现。因为开放源码软件本质上是由社区驱动的，所以没有中央或单一的权威机构负责质量和维护。它的源代码可以被复制和克隆，从而导致版本控制和依赖项的复杂性过大。更糟糕的是，攻击者可以伪装成维护者并引入恶意软件。随着越来越多的系统和关键基础架构开始更多的依赖开源软件，通过社区驱动的流程建立更好的安全性比以往任何时候都更为重要。确保开放源码是确保每个公司供应链安全的重要组成部分。2020 年，微软与 GitHub、 Google、 IBM 和其他公司一起创建了开源安全基金会(OpenSSF)。该小组正在帮助开发人员利用资源识别开源项目的安全威胁，提供教育和学习资源，并寻找加快漏洞披露的方法。在即将到来的一年中，OpenSSF 希望提供实际的帮助，以提高世界上最重要的开源项目的安全性。四、积极沟通大公司和大型开源项目知道，重要的信息必须通过不同的渠道广泛而频繁地交流。即使有了这些知识，微软在 2020 年也不得不像许多其他公司一样迅速改变。因为疫情，我们不再有那种偶然的互动时刻，比如在咖啡馆里碰到某人，和同事一起去开会，或者和某人一起等电梯时学到一些有用的东西。现在，微软已经认识到了频繁沟通的重要性，这已经成为开源社区的一个标志。积极沟通是非常重要的，因为不确定性可能比好消息或坏消息所带来的压力更大。以 Kubernetes 项目为例，该项目从未设立过办公室，如今它们拥有 407 个聊天频道，涵盖了从地区用户群到开发者讨论特定技术子系统的所有领域。这些聊天室，无论是 IRC channels,、Twitter hashtags,、Teams 还是 Slack，都是开源项目的办公室。但是，聊天内容的存储是短暂的，聊天室不是新的公告电子邮件或文档存储库，很少有人会去翻阅聊天室的历史记录。理解沟通是如何改变的，以及对每种媒介的期望是什么，可以使内部沟通成为良好协作文化的重要支持。展望 2021前文提到的四点是开源协作的一部分，但它们对于形成良好的企业文化同样重要。很多问题都需要一个团队或整个行业来解决，意味着我们所有人都需要成为开源中值得信赖的合作者和有自我意识的参与者。几年前，如果你想让几家大型科技公司在一个软件项目上联合起来，建立开放标准，或者在一项政策上达成一致，通常需要几个月的谈判、会议、辩论……现在，开源已经完全改变了这一点。它已经成为跨公司协作的行业接受的模型，当看到新的趋势或问题出现时，我们知道共同努力解决这些趋势或问题会更好。这时，只要几周时间更方就可以达成一致，共同使用已建立的模型来指导工作。因此，公司之间的合作越来越频繁，我们能够完成的跨行业工作量也在加速增长。仅在 2020 年一年，微软就参与了数十个行业组织和协会的活动，从 Linux 基金会和 Apache 基金会等老牌组织，到 Rust 和 WebAssembly 等新兴社区。这项跨越公司和行业的工作将在未来一年继续下去，我们期待在开源中学习，成长，并在开源中赢得我们的地位。

近日在一次演讲中，谈到微软为解决相应内存问题所做的工作，微软在英国的研究人员 Matthew Parkinson 提到了微软正在开发的基于 Rust 的新编程语言，这个项目，微软内部称为“Verona"。此前，微软表示正探索将 Rust 作为 C 和 C++ 的安全替代方案，并且也对外展示了使用 Rust 重写 Windows 组件的体验，根据微软的说法，Rust 是一种从根本上考虑安全性的编程语言，他们将尝试使用 Rust 重写各种产品，因为在过去的十年里，微软 70% 以上的安全补丁都提供了与内存相关的错误，而 Rust 正是解决这个问题的“良药”。演讲中，Matthew 先是分享了微软在 MemGC（Memory Garbage Collector）上所做的工作，MemGC 是指 IE 和 Edge 浏览器上的内存垃圾回收器，它解决了标准浏览器一个特性——文档对象模型（DOM）中的漏洞，DOM 以树结构表述了 HTML 文档内容。之后他由此牵出另一个问题：如何构建最安全的产品？不仅仅丢弃已有的东西，而要考虑可以在更加安全的系统中构建一些什么。他介绍了微软正在使用 Rust 重写某些组件，并提出：“如果我们想要隔离，并精简遗留代码，以使攻击者的利用代码无法逃逸出来，那么如何设计语言呢？”Matthew 提出了微软正在开发的基于 Rust 的新编程语言 Verona，他表示这是首次讨论该项目，微软宣称这门语言是用于“安全的基础设施编程 - safe infrastructure programming”，Verona 项目很“快”会开源。Matthew 介绍，Verona 由 C# 项目经理 Mads Torgensen 与 微软剑桥研究院研究软件工程师 Juliana Franco 维护。微软面临的挑战是应对宽广的应用领域，范围从 C# 桌面应用到 C 或 C# Exchange、ASP.NET、Azure 与设备驱动程序，再到内存管理和启动加载器等底层 Windows 组件，以及 Windows 内核硬件抽象层（HAL，hardware abstraction layer）。“执行内存管理确实很困难，如果有任意并发突变，则临时内存安全性将非常困难”，Matthew 介绍了 Verona 的设计思路：“Verona 的所有权模型是基于对象组的，而不是像 Rust 那样基于单个对象的所有权模型。在 C++ 中，可以获得指针，并且它是基于对象的。但这与我关于数据和语法的思考不同，我认为数据结构是对象的集合，而对象的集合则是生命周期。 因此，通过在对象的所有权级别获得所有权，我们就可以更接近人们正在使用的抽象级别，它使我们能够构建数据结构而不会超出安全范围。”