最近，我写了一篇关于如何构建你的第一个 Web 组件的文章，以及一些关于基本的 v1 Web 组件规范的历史和解释。但自 2020 年 v1 获得完全支持以来，Web Components 的世界发生了更多的变化。未来还有更多的计划。让我们看一些使用当前标准构建的值得关注的例子，以及调查一些将在 2023 年及以后推出的新的 Web Components 标准工作^1。

Web Components 应用实例

随着所有浏览器都支持 v1 Web Components，许多公司已经采用并基于这些新标准构建了重要的业务。以下是我认为值得关注的一些例子。

YouTube

YouTube 是最早采用 Web Components 技术的应用之一，多年来一直使用这种技术构建其界面。检查源代码，你会看到各种自定义元素，从 ytd-video-preview 到 iron-ally-announcer。

Photoshop

是的，Adobe 使用 Lit 将 Photoshop 带到了浏览器中。它现在还处于 beta 版本，如果你是 Adobe 的订阅用户，可以自行尝试。整个应用程序中有很多自定义元素，从构成应用程序根的 psw-app，到像 psw-layers-panel 这样的 shell 元素，再到像 sp-action-button 这样的 UI 组件。

MSN, Edge, Bing, VS Code, and More at Microsoft

几年前，微软使用基于 FAST 的 Web Components 重构了 MSN。这将性能提高了 30% 到 50%，比之前使用 React 构建的版本性能更好。

基于 OpenAI 的 New Bing 也是使用 FAST Web Components 构建的，如下面的屏幕截图所示，最近由其中一位开发人员分享。

甚至用于扩展 VS Code 新功能的 Webview UI 工具包，也是使用 FAST Web Components 构建的。

在过去三年中，微软大约有 1,500 个团队/项目采用了 FAST Web Components。

Salesforce

作为客户关系管理（CRM）、销售和营销自动化平台行业中最大的品牌之一，Salesforce 多年来一直在基于 Lightning Web Components 进行开发。

SpaceX

如今，Web Components 甚至在太空中也得到了应用。SpaceX 的机组人员显示屏正在运行 Chromium，广泛使用 Web Components。

标准现状

Web 标准不断发展，其中包括 Web Components。自从 v1 版本发布到所有主流浏览器以来的三年中，Web Components 下的功能数量几乎翻了一倍。以下是各种已发布、正在进行和计划中的 Web Components 相关标准的图示。

让我们逐一查看图示中按照功能划分的六个高级类别中的每一项：组合和作用域、平台互操作性、渲染和性能、样式、包和分发、API 范式。

组合和作用域

Web 组件的作用域/封装特性对于传统编程中的信息隐藏、维护、代码库可扩展性等方面同样非常重要。但是，当涉及到 Web Components 时，它们还为 HTML 和 CSS 运行时提供了额外的元数据，可以用来优化绘制和布局。

Shadow DOM Shadow DOM 是 HTML 中用于作用域、封装和组合 DOM 及相关样式的基本机制。它是一个多方面的特性，具有许多不断扩展的能力。

• 命名插槽分配（全面支持）—— 原始的 v1 Shadow DOM 规范提供了一种完全声明式的机制，用于在 Shadow DOM 中使用命名的 <slot>元素来定义元素组合的占位符。开发者只需在宿主元素的任何子元素上放置一个 slot 属性，浏览器就会自动『插入』该元素的呈现输出到插槽的位置。

• 开放和封闭模式（全面支持）—— v1 Shadow DOM 规范中的 attachShadow() API 的 mode 选项是其中一部分。它允许组件开发者选择其首选的封装模式。open 模式允许从宿主元素外部访问 shadowRoot，而 closed 模式则禁止访问。

• 事件重新定向（全面支持）—— 当在 Shadow DOM 内部的元素上触发事件时，这些事件会被『重新定向』，以便它们看起来来自宿主 Shadow DOM。这个 v1 Shadow DOM 规范的能力是正确封装内部结构的重要部分。

• 手动插槽分配（全面支持）—— slot 元素上的新的 assign API 扩展了 v1 的原始插槽分配功能，除了之前的声明性式插槽机制外，还提供了一种命令式 API。

• 焦点委托（全面支持）—— 这个在 v1 之后的特性使 Shadow DOM 可以告诉浏览器，当其宿主元素获得焦点时，它应该将焦点委托给 Shadow DOM 中的特定元素。默认情况下，第一个可聚焦的元素被选中，但可以使用 autofocus 属性覆盖该行为。

• Cross-root ARIA（接近共识）—— 即将到来的特性，与社区和浏览器厂商接近达成共识，Cross-root ARIA 将极大简化在 Shadow DOM 外部与 Shadow DOM 内部的 ARIA 关键元素相关联的操作。例如，将 Shadow DOM 外部的 label 元素与 Shadow DOM 内部的 input 元素关联起来。这些类型的 ARIA 场景今天已经有解决方案，但并不是容易实现的。Cross-root ARIA 将大大改善这种情况。

• 在 Shadow CSS 中使用自定义属性（共识）—— 如今，一些浏览器可以使用 @property 语法来自定义 CSS 属性。但是，目前在 Shadow DOM 中尚不起作用。CSS 对象模型始终可以从自定义元素代码中来全局定义这些属性，但在 Shadow DOM 中以声明形式提供此功能是一个常识性的改进。这已达成共识，因此希望我们很快就能看到这个功能。随着浏览器更普遍地支持新的 CSS 语法。

作用域元素注册表（共识） 在自定义元素的 v1 规范中，所有元素都通过 customElements 全局对象在全局自定义元素注册表中注册。这个新的补充功能使得能够实例化非全局注册表并在其中注册自定义元素。

const myRegistry = new CustomElementRegistry();  
myRegistry.define("my-element", MyElement);

这个注册表中的元素仅定义为该注册表所分配的 Shadow DOM。这极大地改进了浏览器中的作用域，使得可以按照需要为每个 shadow root 定义元素。当它被应用到浏览器中时，这将会是一个巨大的进步，为新的架构可能性打开了大门。目前，社区和厂商之间已经达成共识，Chromium 正在开发第一个实现。

平台互操作性

Web Components 最重要的方面之一是它们如何在组件和平台之间实现互操作性。让我们看一些当前和未来的特性。

自定义元素

• 自治自定义元素（全面支持）—— Web Components v1 的这个核心功能通过向 customElements 全局对象注册一个类来定义继承自 HTMLElement 的自定义元素。基本的生命周期回调和观察属性也是规范的一部分。

• 自定义内置元素（已拒绝）—— 最初，有一个提案允许从内置元素（例如 HTMLParagraphElement）继承，但 WebKit 实现者发现了几个技术问题，因此已经拒绝了这个规范。它很可能在将来被删除，所以应该避免使用。请参见下面的『自定义属性』，了解可能更好的替代方案。

Element Internals

一个 v1 之后的新 API，ElementInternals，使得自定义元素能够更深入地与现有的 DOM 子系统进行平台级集成。

• Shadow Root 访问（全面支持） —— 这个简单的功能添加使组件开发者可以检索一个 closed 模式元素的 Shadow Root 实例。如果没有这个功能，具有 closed 模式声明式 Shadow DOM 的元素将无法在运行时访问其根节点。

• 与表单关联的自定义元素（全面支持） —— 这个重要的新功能使得自定义元素能够完全参与表单，包括表单验证、提交和重置。

• 默认可访问性角色、状态和属性（大多数已支持） —— 这个新的 API 集合 使得可以通过直接在内部与平台进行通信来设置自定义元素的默认可访问性特性，而不是通过可能被用户无意中删除的宿主元素上的外部属性。目前，除 Firefox 外的所有主要浏览器都支持这个新的 API，对于 Firefox，则提供了一个 polyfill。由于 Firefox 已经实现了 ElementInternals 其他部分的 API，如果他们在不久的将来没有发布这个功能，我会感到惊讶。

组合选择（共识/无规范） 这个改进提出了一个新的 getComposedRange() API，用于 Selection 对象，它使得范围的起始和结束可以跨越多个 Shadow Root。它还将提升浏览器在处理这些情况时的一致性。对于 这个 API 草案，有普遍的共识，但在浏览器可以进行实现之前，仍需要一个完整的规范。在 Web Component 的正常开发过程中，你不太可能遇到这种情况。它主要涉及到富文本编辑器的实现。

自定义属性（已确定） 虽然这个功能不一定是 Web Components 的一部分，但它与 Web Components 旨在服务的场景有很高的重叠。这个草案提议启用可重用行为的创建，这些行为可以附加到任何 HTML 元素，遵循类似于 Web Components 的模式。例如，想象一下你想将 Material Design 水波纹效果应用到任何 HTML 元素上，那么这样做会不会很好呢？

<button material-ripple>Click Me</button>

在我为 TPAC 2022 准备的草案提案中，我演示了这个功能的编程模型可能是什么样的：

class MaterialRipple extends Attr {
  // ownerElement inherited from Attr
  // name inherited from Attr
  // value inherited from Attr
  // ...

  connectedCallback () {
    // called when the ownerElement is connected to the DOM
    // or when the attribute is added to an already connected owner
  }

  disconnectedCallback () {
    // called when the ownerElement is disconnected from the DOM
    // or when the attribute is removed from a connected owner
  }

  attributeChangedCallback() {
    // called when the value property of this attribute changes
  }
}

customAttributes.define("material-ripple", MaterialRipple);

你会注意到，这个模式和生命周期与 Web Components 是一致的。这也将为被拒绝的可定制内置自定义元素提案中的 is 属性提供更好、更健壮的替代方案。

渲染和性能

渲染和性能对于 Web Components 来说非常关键。虽然基本功能已经就位，但这仍然是一个活跃的探索、讨论和未来创新的领域。

HTML Template 元素（全面支持）

HTMLTemplateElement及其定义惰性 HTML 内容的能力是 v1 Web 组件功能的关键部分。在引入该元素之前，没有办法声明不会被浏览器激活的 HTML，因此很难创建需要在需求时重复渲染相同 HTML 的组件。

声明式 Shadow DOM（大多数支持） Shadow DOM 的 v1 规范仅允许通过 attachShadow() JavaScript API 创建 Shadow Root。这个 Shadow DOM 的新增增强功能允许在 HTML 中完全声明 Shadow DOM 内容，无需使用 JavaScript，为服务器框架提供了有趣的可能性。

<host-element>  
  <template shadowrootmode="open">  
  <slot></slot>  
  </template>  
  <h2>Light content</h2>>  
</host-element>

这个规范重用了 template 元素。不要被这个搞混了。它不是一个模板，它是由 HTML 解析器流入 Shadow Root 的活动 DOM。

当前除了 Firefox 之外，所有浏览器都支持声明式 Shadow DOM。 如果需要，该功能可以通过几行 JavaScript 代码进行 polyfill。

子节点更改回调函数（提议） Web Components 在自定义元素的 v1 规范中有一个明确定义的生命周期，但这并不意味着我们不能在未来扩展这个生命周期。其中一个常见的对于开发者的挑战是使 Web Component 能够对子节点的添加或删除做出响应。虽然现在可以使用 slotchange事件 和 MutationObserver 实现这一点，但是如果有一个像 childrenChangedCallback() 这样的生命周期回调函数，可以提供更好的性能、简化和与 HTML 解析器本身的集成，那就更好了。目前有一个草案提议，并且实现者也表现出了兴趣。需要一份完整的提案来推动这个功能进入下一个阶段。

模板实例化 虽然 HTML 有模板，但它还没有一种机制来实例化与数据连接的模板，并在其相关数据更改时更新它们。这个『模板实例化』的领域有几个独立有价值的部分。

• DOM 部件（提议） - 这个提案 将提供一种标准机制，在 DOM 树的特定位置插入或替换内容。你可以把它看作是一种低级别的启用器，帮助创建更高效的模板引擎和批量更新现有的 Web Component 库和 JavaScript 框架。它不提供响应性解决方案或模板语法，只提供定位和更新 DOM 部分的低级别标准基础设施。
• 模板语法（已确定） - 一旦定位和批量更新的低级别基础设施就位并被现有库成功使用，那么关于语法的大辩论就会开始。模板语法是一个非常有争议的问题，但我们已经认识到 HTML 应该有一个基本的语言来处理这个问题，即使它只是为其他库提供编译目标。
• 响应性（已确定） - DOM 部件提供批量更新 DOM 的标准机制。模板语法提供声明式机制来创建 DOM 部分。剩下的是确定何时应执行 DOM 部件更新的机制。这就是响应性的作用，以完成整个图景。这是另一个有争议的问题，但已经有一些先例，例如通过 Web Components 的 attributeChangedCallback()。这个主题需要更多的探索。

模板实例化工作类别被分解为上述三个子特性，旨在先解决某些较少有争议的问题，并为现有库和框架提供路径，以利用不那么主观的、改进性能的功能，避免在社区中引起过多争议。

样式

虽然 Shadow DOM 提供了样式的封装，但有许多 CSS 特性直接与 Web Components 相关，并且在日常使用中非常重要。

使用 有几项当前和未来的标准与 Web Components 如何使用样式来创建 Shadow DOM 的呈现方式有关。虽然一直以来都可以在 Shadow DOM 中创建样式元素，但新标准提供了更好的可读性和性能优势。

• 可构建样式表（全面支持） — 你知道在这个标准之前实际上无法创建 CSSStyleSheet 实例吗？这个标准修复了这个问题，现在您可以编写代码 new CSSStyleSheet()。这种能力使得在 Web Components 中更动态地创建和使用样式成为可能，包括在组件之间共享样式表。
• 采用样式表（全面支持） — 针对给定的 CSSStyleSheet 实例，如何将其与特定的 Shadow Root 或全局 document 关联起来？这个新标准 在 document 和所有 Shadow Root 实例中添加了一个 adoptedStyleSheets 数组。只需将样式表推入该数组中，就可以开始使用了。
• CSS 模块脚本（Chromium） — 可构建样式表和采用样式表本身提供了创建、共享和关联文档表的原始机制，但仍需要在 JavaScript 中编写 CSS 代码。CSS 模块脚本标准 允许使用 JavaScript 模块导入.css 文件，从而平台会自动创建一个 CSSStyleSheet 实例，无需在 CSS 运行时和 JavaScript 运行时之间来回切换。
• 声明式 CSS 模块（已确定） — 随着声明式 Shadow DOM 和采用样式表的出现，已经创建了几个临时提议，以便声明 CSS 模块并将其与声明式 Shadow DOM 关联。这方面需要更多的探索，但这是 HTML 和 CSS 未来的一个令人兴奋的可能性。

呈现 主要来说，CSS 关注的是呈现方面的问题。有一些标准扩展了 Web Components 的样式设置的可能性。

不仅仅是 Web Components，对于创建组件系统来说，自定义 CSS 属性 是一个非常重要的规范，它能够创建本地 CSS 变量，并可以在 shadow roots 中使用。

• CSS Shadow Parts（全面支持） — CSS 部分 允许在 Shadow DOM 中声明元素作为『部分』，可以使用外部选择器对其进行样式设置。这是通过 part 属性和 the exportparts 属性 实现的，用于嵌套场景。
• CSS 自定义状态（Chromium） — 原生元素可以具有自定义状态，在 CSS 选择器中可用。例如，复选框的『已选中』和『未选中』状态。这个新功能 允许 Web Components 定义自己的状态。已经达成共识，Chromium 已经发布了第一个实现，可以通过 ElementInternals 访问。在等待其他浏览器跟进时，可以使用 polyfill 进行支持。
• CSS 主题（提议） — 尽管可以通过仔细使用 CSS 自定义属性和 CSS Shadow Parts 来实现丰富的主题化，但可以通过明确地将主题的概念引入 CSS来简化和改进这一过程。
• 开放式 Shadow Root 样式（已确定） — 尽管可以使用可构建样式表和采用样式表使任何全局 CSS 在 Shadow Root 中共享，但对于普通 Web 开发人员来说，这可能不是一个直观的过程。有一些探索机制的方法，明确选择允许外部 CSS 进入某些 shadow roots。

打包和分发

到目前为止，我们主要谈论了与 Web Components 实现相关的标准。但同样重要的是考虑组件如何打包和加载。

自定义元素懒加载（提议） 现在，我们可以使用全局的 customElements 注册表定义组件，很快还可以使用自定义注册表。但是，在这两种情况下，在定义组件之前，组件的实现必须已经被加载。使用自定义元素懒加载，开发人员将能够告诉平台有关元素的信息，但是可以延迟加载它，直到元素首次出现在 document 中时才加载。它可能会像这样工作：

customElements.defineLazy(  
  "my-element",   
  async () =\> (await import("my-element.js")).default  
);

这个规范似乎被大多数人认为是一种很好的东西，尤其是对于某些架构来说。然而，该提议的细节仍在争论中。

HTML 模块脚本（已确定）

HTML 模块脚本是 CSS 模块脚本的 HTML 等效物。通过 HTML 模块脚本提案，模板（和其他 HTML 片段）将通过 JS 模块系统直接可导入。目前只有一个草案提案，还需要进一步讨论许多细节，但这被认为是一个重要的长期增强功能，特别是考虑到未来可能存在只有单个 HTML 文件的 Web Components 的情况。

API 范式

最后一个标准类别与我之前讨论的所有内容有些不同。这些标准涉及 Web Components 的基本编程范式。Web Components v1 主要是一种命令式的 JavaScript 编程模型。有一些值得注意的例外，比如声明式的 slot 分配。但基本上，它完全是命令式的。自 v1 以来，我们一直在努力引入越来越多的声明式特性。其中一个很好的例子是声明式 Shadow DOM。总的来说，最好为所有场景提供声明式和命令式的 API。但最终目标是拥有某种完全声明式定义的 Web Components，以便服务器可以向浏览器发送元素定义，在 noscript 上下文中可以完全工作。我们还有一段路要走，但当我们到达那里时，它将从根本上改变客户端和服务器开发。

下一步是什么

标准的工作永远在进行中。事实上，从今天开始，W3C Web 组件社区组正在召开其 2023 年春季面对面活动。就像 TPAC 一样，这是一个机会，供库作者、组件创建者、浏览器厂商等聚集在一起，并花费专门的时间来解决仍需要共识或存在开放问题的规范的细节。我期待在后续的博客文章中向大家更新活动结果。请关注/订阅以确保您获得更新 😄

总结

我希望本次的 Web Components 标准之旅对你来说是有意义的。你看到我们已经走了多远，未来还有什么等待我们，这很有趣。随着 v1 版本的发布，过去几年中已经发布的功能翻了一番，以及即将到来令人兴奋的新功能，现在是成为 Web 开发人员的好时机。

写在前面

入行前端已两年有余了。之前我在一篇文章中写了——要明白前端领域的变与不变。现在和两年前一样，各种框架层出不穷，让人眼花缭乱。很多时候我也在问自己『这个还需要学吗』。这样很容易让我产生焦虑感。而且在面对新事物时，我经常会感到手足无措。归根结底还是基础知识不扎实，内功不够。这也是我写这篇文章的目的——提升内功，更好的理解『变与不变』。

要开始了

先从这段代码开始探索之旅吧

console.log('开始了')

// setTimeout1
setTimeout(function () {
  console.log('timeout1')
  // promise1
  new Promise(function (resolve) {
    console.log('timeout1_promise')
    resolve()
  }).then(function () {
    console.log('timeout1_then')
  })
}, 2000)

for (var i = 1; i <= 5; i++) {
  // setTimeout2
  setTimeout(function () {
    console.log(i)
  }, i * 1000)
  console.log(i)
}

// promise2
new Promise(function (resolve) {
  console.log('promise1')
  resolve()
}).then(function () {
  console.log('then1')
})

// setTimeout3
setTimeout(function () {
  console.log('timeout2')
  // promise3
  new Promise(function (resolve) {
    console.log('timeout2_promise')
    resolve()
  }).then(function () {
    console.log('timeout2_then')
  })
}, 1000)

// promise4
new Promise(function (resolve) {
  console.log('promise2')
  resolve()
}).then(function () {
  console.log('then2')
})

开始之前，喜欢思考问题的小伙伴可能会有两个问题。javascript为什么被设计为单线程语言，为什么又会有同步任务和异步任务的区分。这两个问题，在这里我就不细述了。感兴趣的同学请看阮老师的这篇文章。 现在我们来看一下js大致是怎么执行的。

到底哪些是宏任务，哪些是微任务呢。大体上这样区分。

宏任务（macro-task)

• script(整体JavaScript代码)
• setTimeout()
• setInterval()
• setImmediate()
• I/O
• UI render

微任务（micro-task)

• promise
• async/await(同☝)
• process.nextTick
• MutationObserver

预备知识已经准备的差不多了，现在我们开始执行上面那段代码。

• 首先整体script进入主线程，遇到console.log()，立即输出『开始了』
• 接下来遇到setTimeout，2s后回调函数function()被分发到宏任务Event Queue中（注意这里不是2s后执行），这里标记为setTimeout1
• 遇到for，直接执行，同理setTimeout中的回调函数被分发到宏任务Event Queue中（这里涉及到闭包的知识），标记为setTimeout2，然后执行console.log，输出『1，2，3，4，5』
• 遇到promise,new Promise直接执行，输出『promise1』。then被分发到微任务Event Queue中，标记为then1
• 接下来又遇到了一个setTimeout，1s后回调函数function()被分发到宏任务Event Queue中，标记为setTimeout3
• 又遇到promise，同理，输出『promise2』，then被分发到微任务Event Queue中，标记为then2

第一轮事件循环的宏任务已经执行完毕。Event Queue中的任务如下表所示

根据上面的流程图，宏任务执行完后，js引擎的监视进程会检查此时有没有可以执行的微任务。这时后分发到微任务Event Queue的then将被执行。依次输出『then1』，『then2』

第一轮事件循环全部执行完毕。

好了，现在开始第二轮事件循环(1s后)。

• 遇到setTimeout2,输出『6』，没有可以执行的微任务。执行新的宏任务。
• 遇到setTimeout3,输出『timout2』，new promise立即执行，输出『timeout2_promise』，then被分发到微任务Event Queue中。标记为then3 第二轮事件循环的宏任务执行完毕。Event Queue中的任务如下表所示

同理，宏任务执行完后。执行此轮的微任务then3。

第二轮事件循环全部执行完毕。

• 遇到setTimeout1，执行console.log，输出『timeout1』，new promise立即执行，输出『timeout1_promise』,then被分发到微任务Event Queue中。标记为then4
• 第三轮事件循环宏任务执行完毕，执行此轮的微任务then，输出『timeout1_then』

第三轮事件循环执行完毕。

• setTimeout2中依次会产生4个宏任务，每隔1s输出一个6

至此，整段代码全部执行结束。

总结：宏任务执行完了，执行该宏任务产生的微任务。如果微任务在执行过程中产生新的微任务，则继续执行微任务。微任务执行完毕后，回到宏任务中开始下一轮循环。

async

node

参考资料

• 说说事件循环机制
• 这一次，彻底弄懂 JavaScript 执行机制

前言

最近在github上发现了一个很有意思的开源项目，格律诗编辑程序。它不但可以自动检查平仄等格律规则，并且能够通过机器学习来将自己的作品和《全唐诗》的诗句做对比。从而得出和自己所写诗句相似度高的唐诗。 想来，高中的时候也有一段时间痴迷于创作诗词，只是当时对于很多的基础知识都不是很了解。所以写出来的东西也只是自娱自乐，没有什么章法可言。 cope这个项目是使用node.js写的，运行在electron框架。刚好自己也在学习相关的知识，学习开发的同时又能学习诗词创作，何乐而不为呢。

基本要素

平仄

1. 四声 解释：简单来说，对于普通话而言，1，2声为平，3，4声为仄。
2. 基本句式

• 平起平收：平平【仄】仄平
• 平起仄收：【平】平平仄仄
• 仄起平收：【仄】仄仄平平
• 仄起仄收：【仄】仄平平仄 解释：平完了仄，仄完了平。【】里面的可平可仄。七言律诗同理，只需在前面加上两个平仄相反的字。

押韵

规则

双数句必须是同一个韵部，必须是平声韵。

对仗

规则

1. 律绝句不需要必须对仗

王昌龄《出塞》 => 不对仗

清时明月汉时关，万里长征人未还。但使龙城飞将在，不教胡马度阴山。

杜甫《绝句》 => 对仗

两个黄鹂鸣翠柳，一行白鹭上青天。窗含西岭千秋雪，门泊东吴万里船。

2. 八句律诗中间两联必须对仗

李商隐《锦瑟》

锦瑟无端五十弦，一弦一柱思华年。【庄生晓梦迷蝴蝶，望帝春心托杜鹃】。 【沧海月明珠有泪，蓝田日暖玉生烟】。此情可待成追忆，只是当时已惘然。

3. 八句以上的排律除了首尾两联，中间所有联必须对仗

对仗的不同种类

1. 工对 => 词性和门类均相同，上文杜甫的绝句就是典型的工对。两个 || 一行；黄鹂 || 白鹭；窗含 || 门泊；
2. 宽对，邻对 => 词性和大的类别相同，如上文的柳 || 天；雪 || 船；它们门类不同，但都是名词。
3. ....

黏连

规则

双数句的第二个字和单数句的第二个字平仄要一致

结语

这篇文章整理了格律诗创作的基本知识和一些规则。当然格律诗创作如果过于追求形式上的规范，也可能会失去创作的乐趣。不过对于初学者而言，还是应该明白这些规则和常识。其实学习之道也大抵于此，只有先熟练掌握规则，才能创造。

什么是账户抽象

在回答这个问题之前，我们先思考两个问题「以太坊有哪些账户类型」以及「为什么要提出账户抽象」。

账户类型

• EOA(externally owned account)
• CA(contract account)，不能主动发起交易

为什么提出「账户抽象」

从上面的 EOA 交易机制流程图中我们可以发现目前存在的一些问题：

• 私钥管理 -> 单点失败风险（no you key, no you coin）
• 依赖于 ECDSA 签名 -> 无法对抗量子计算
• 交易验证逻辑写在协议层 -> 糟糕的用户体验

纵观近几年的 EIP 提案，开发者们始终希望用户的账户具备图灵完备的能力。相关工作一直都在进行，终于 ERC-4337^1 应运而生。业内也统一了「Account Abstraction」的说法。

这个方案不需要修改协议层，实现了把账户抽象的交易验证从协议层抽离出来，放在了应用层。但是虽然在应用层，它还是属于一个技术标准，新开发的智能合约钱包们应该遵循这个标准^2。

重新回到一开始的问题——「什么是账户抽象」。回顾上述内容，我们大概已经明白了 EOA 交易机制目前存在的问题以及 ERC-4337 的交易流程。于是可以试着给「账户抽象」下个定义：

账户抽象是一种使用可编程方式来验证交易有效性的技术方案

应用场景

• 找回私钥
• Gas 费代付，批量授权及交易
• 权限管理

用户可以找回账户私钥，解决了「单点失败」的问题，开发者可以在 Web3 的世界中引入 Two-factor 验证来授权，私钥丢失了也可以使用邮箱找回。

用户可以获得更好的交易体验，不必再去理解什么是 Gas 的问题。Defi 场景下的先授权再交易步骤，也可以合并成一笔交易，更加地方便。

用户可以对账户进行权限管理，在一个公司或者 DAO 组织，管理者可以根据不同的用户角色设置不同的支出权限。

相关产品

• thirdweb
• unipass
• biconomy
• visa

一些思考

尽管已经看到有很多的产品加入了「AA」这个赛道，但它目前仍处于非常早期的阶段。我很喜欢 lixin 在这个播客[^3]中的类比，「AA」之于「EOA」就如同「自动挡汽车」之于「手动挡汽车」。当自动挡汽车刚出现的时候，会充斥着费油和不安全的质疑声。

或许 ERC-4337 已经给账户抽象搭好了框架，但是谁也无法预测它的下一个产品形态——相关的标准仍在制定中。这条路上充满了未知，机会，也许是荆棘。不过这也正是它最迷人的地方不是吗？

[^3]: Ep.29: HODLong 后浪

这周轮到我做技术分享了，思来想去，还是决定选择git作为本周技术分享的主题。原因有二，一是最近在使用git时出现了一些难题，具体下文会有提到。二是，尽管每天都在使用git，但对于一些基础概念还是有模糊的地方，也想通过这次的分享进一步理解git。

git原理

workspace: 工作区（当前的开发位置）

• git pull: 从远程仓库拉取最新的代码到工作区 => git fetch + git merge
• git diff: 查看修改但未暂存的文件

index: 暂存区

• git add: 工作区修改的内容提交到暂存区

repository: 本地仓库

• git commit: 将暂存区内容提交到本地仓库
• git fetch或者git clone: 从远程仓库拉取/克隆代码到本地仓库

remote repository: 远程仓库

• git push: 将本地仓库内容提交到远程仓库

常见问题

1. git push origin master具体是在做什么事?

把本地master分支上的内容，推一份到origin这个地方，并且在origin这个地方建立一个同名的master分支 完整指令:git push origin master:master => git push <远程主机名> <本地分支名>:<远程分支名>

2. git merge和git rebase的区别

举例：把test分支合并到master分支

git merge的结果

git rebase的结果

在线演示

最近遇到的问题

1. 本地项目运行出错，想要回退到之前的版本 => 本地仓库回退到之前的版本

git reset --hard/soft [需要回退的提交点]

2. 撤销已经推送到仓库的提交 => 远程仓库回退到之前的版本

git reset --hard [需要回退的提交点]
git push origin HEAD --force 

更多

• 图解Git
• 为你自己學Git
• Git-Branching

前言

日复一日地重复生活，加上最近酷热的天气让我感觉有些疲倦。不由冒出「去一个人不多的地方待上几天」的想法。不必要去做详尽的旅行规划，只想在一座陌生的城市之中走走停停。

出发

我用很快的时间便确定了城市漫步的目的地——四川江油。理由很简单：

• 出行方便，适合短期旅行
• 气温尚可，不算特别炎热
• 有山有水，还有值得探索的文化与美食

从西安出发前往江油，只有两个多小时的路程。自北向南列车穿过关中平原、秦岭山区，窗外是久违的大山大河。两小时的时长很短，短到我刚好可以听完一期完整的播客。

人们

江边早市摆摊的商贩

天微微亮，早市中此起彼伏的吆喝声便叫醒了还在沉睡之中的小城。我住的地方是一个依江而建的民宿，江风吹来阵阵吆喝声已然让我无法入睡，便索性起床逛逛江边早市。

出门抬眼就看见了市场，大部分商贩都是骑着电动三轮车来这里摆摊，卖的东西都是些日常的瓜果蔬菜。吆喝声被商贩们提前录好放在大喇叭中，在循环播放。我听见过很多地方的吆喝声，在西安的路边或是在我家乡的集市上。不同的是，这里的吆喝声更加地特别，内容好似经过一番设计。在四川方言的加成下，显得更加抑扬顿挫。

实习的警校女生

午睡之后，我来到了城区中唯一的一家星巴克。坐在我对面的是两个戴着口罩的女生，她们正在用普通话交流。显得与周围格格不入。我主动和她们攀谈起来，原来她们是来当地实习的大学生。

我很好奇这座小城市会提供怎样的实习的岗位，于是便问起了她们的专业。出乎意料，眼前这两个文弱的女生竟然就读于一所警校。和大部分面临毕业而感到迷茫的大学生相比，她们的未来将更加确定。

自驾游的情侣

从城区打车前往二十公里之外的「中华洞天」，远离烈日之下的城市，在溶洞中漫步是再好不过的选择。途中与司机闲聊，他告诉我江油正在大力发展旅游业。交通便利则是先天优势，一座只有几十万人口的地级市，却坐拥三个高铁站。言语间我感受到他对于这座城市未来的希冀。

洞口把外面的世界和里面的洞天分割成两个不同的季节。一步之遥，仿佛便从炎炎夏日进入初秋。洞内的温度只有 20° 左右，地上湿漉漉的，感觉非常凉爽。走几步往里看，五彩斑斓的灯光打在形状各异的乳石上，更显奇幻迷离。

回去的途中又遇到了刚才漂流时同一条船上的两人，我询问他们是从哪里过来的——如果是回城区的话可以一起拼车。男生告诉我他们是从四川另外一个城市——阆中，开车两百多公里过来的。并说他们刚好要开车回去，顺路可以载我一程。短暂的二十分钟车程，我们聊了一些关于四川方言，以及周边有哪些值得去的地方。到了城区，当我下车准备给他转账时，他谢绝了我的车费，并鼓励我继续探索四川的美食与文化。

咖啡店的老板

在巷子中闲逛，余光不经意间瞥向了左手旁半掩着的铁门。走近看了下招牌，原来是一家咖啡店。总共两层，一层的院子里种满了紫罗兰、睡莲还有一些我叫不出名字的植物。

楼道中贴满了各种各样的明信片，大致看了下内容都是「高考」、「恋爱」之类的主题，可能是老板找高中生写的（逃。其中一张明信片上留下了这样一句歌词——「十七岁的那年，吻过他的脸，就以为和他能永远」。

二层有两个精心装饰过的咖啡厅，旁边还有两个房间可以打麻将。我点了一杯拿铁，坐在靠近过道的位置。整个咖啡厅只有我和老板，还有一个店员。老板似乎看出我是从外地过来的，便主动问我来自哪里。接着，我们聊了一些关于这里的物价，以及消费力的话题。

李白

这座城市之中到处都是李白留下的影子，诗仙大道、太白公园、李白纪念馆。遗憾的是，当我到达李白纪念馆时却看到门口的公告栏正写着「闭馆维护中」。

铩羽而归的途中，路过了太白公园。看到公园门口进进出出散步的老人，还有正在追逐玩耍的孩子们。我不由想起了李白的那句诗——「今人不见古时月，今月曾经照古人」。一代代的人们终将逝去，又有什么会是永恒呢？

最后

写这篇文章的时候，我已经回到了西安，烈日依旧。最近再次阅读《把自己作为方法》这本书，我也在思考一个问题。如何找到日常生活的意义感，又不至于被只有意义而没有脚踏实地生活的虚无感所淹没。

一直想这个问题反而会让我陷入到问题本身，或许并没有什么标准答案。去行走，去阅读，去写作。把自己放在不同的环境下，看看会发生什么。。。

学习日语已经有一周多的时间了，这一周的时间主要是基础部分的学习。包括日文的结构，五十音的读写和发音。 为什么要学习日语呢？直接原因是，一周前，我看了少数派的一篇文章——《聊一聊50音起源的再设计》。作者是一名独立开发者，对产品设计与体验有着极致的追求。然后我便在ipad上体验了这个app。与其说是一个学习的app，不如说它是一个艺术品。于是，我决定立即学习日语（🆒）。 当然也有很多其他的原因，例如日语发音很好听，想要学习ruby，喜欢听日文歌之类的。 日式料理马上就要开始了，只有app作为食材是完全不够的。作为一个完全零基础的日语学习者，一开始，我甚至不知道50音是什么。所以我决定在mooc上选择一门入门的课程。mooc上有很多关于日语学习的课程，看了课程的视频简介后，我选择《自由自在日本行》作为我的入门零基础入门课程。一边学习日语，一边还能了解日本的文化与名胜。すごい！

学习方式

组成结构

混合书写是日本文字表达的特色

• 万叶假名： 使用和日语同音的汉字来书写日文，以补足用汉语记录日语假名是相对于『真名（汉字）』而言的，假是『假借』的意思
• 日文汉字： 主要用于表达实物的名称和动作
• 平假名：日文中表音文字的一种，从万叶假名演化而来，形近汉语草书。主要用来标注日文汉字的注音，还有一些具有语法功能的助词和助动词
• 片假名：平安时代初期为了训读^1汉文发明的。由万叶假名的楷书写法中简化而来。主要用来书写外来语，拟声拟态词
• 罗马字：多用于招牌和广告

日文汉字

中国人学习日语，自然是有天然的优势。因为汉语和日语都传承了古汉字的字形和字义，而且现代汉语中有很多词也借用了明治时期的日文翻译语。但在日文汉字中很多尽管字形和汉语相同，但含义却完全不同。

旅行中常见的日文汉字

格外注意的日文汉字

50音学习

50音是日语学习的基础，但也让初学者很头疼。假名记不住，易记混，这可能是大部分人都要面临的问题。关于假名的记忆方法有很多种，我目前采用的方法是根据词源记忆。当然，你也可以试试形象记忆。这里我想强调的是50音起源app的开发者kevin的一句话，『我认为日语学习并不是简单的学习假名，词汇，语法。而是应该是从其背后的文化开始学起，产生共鸣与认同』。

发音

发音也是50音学习过程中非常重要的一部分。好在汉语拼音基本包括了日语的罗马字读音。

音调

• 口型不变
• 音调不变

清音

注意： さ行中

し => 发xi的音 す => 发音时要用接近う的口型

浊音

共有四行，在相对应的清音右上角加两点。口型和舌位与对应的清音一致，声带震动的时间要比清音早一点。 注意： za行和da行，有两对假名发音一样，但是在日语单词中以じ、ず优先。

半浊音

在は行的右上角加上一个圈圈

注意：

长音

在日语中，元音的长度会影响到单词的意思。长元音的发音长度大致是短元音的两倍，一个假名一拍，长音的长度是两拍。

最近看了篇文章——《新技术学习不完全指北》^1，很受启发。我经常会陷入「不知道学什么」和「不知道怎么学」的困境。有的时候也会做出一些所谓看起来的努力，但是收效甚微。

这篇文章会列举出部分上文中提到的关于新技术学习的方法，同时结合自己最近学习react的经历。探索一下如何学习。

先来审视下自己。拿现在自己从事的前端开发工作来说，我熟悉的技术栈都有哪些呢。工作中主要以JavaScript + Vue + CSS为主。因为公司的业务相对比较简单，所以并没有太多纵向探索的空间^2。因此我想横向突破自己，也就是上面说的第一个困境——学什么。

学习动机

工作需求

工作需求，是一个强烈的、持续性的、外部驱动的学习动机。那些跟工作关联起来的技术，通常就是我们掌握得最扎实、构成我们核心技术能力的部分。而那些跟工作关联程度弱的技术，则是最容易中途放弃的部分。

其实很早之前就想学习react，typescript，但一直都没有去做。对于typescript的了解，只是知道它是javascript的超集。具体是啥样的，一直没有去看。原因是没有充分的学习动机。尽管我在github上看到很多优秀的开源项目都是以ts + react为技术栈，但是一直没有深入持续地探索。

严肃学习

反思之前的失败经验

很早之前——刚刚接触前端的时候，我在做一些看似努力的行为。经常会去看掘金社区的文章，还有「反复」看一些官方文档。首先我看一些技术文章的时间，大部分是在等待吃饭或者等地铁的时候。这部分其实是相当「碎片」的时间，很难去系统地学习。

所以这次再次决定学习react，在一开始我就制定了目标——完成frontend-bootcamp上的练习。因为这个项目是使用typescript + react实现的。

高强度间歇性训练

让阅读材料反复出现

结合学习react来说，主线学习是以frontend-bootcamp这个项目为主。总共分为两大步，总计13个小节。在写这篇文章的时候，我已经完成了全部的13个练习——使用ts + react实现了一个todo app。包括使用状态管理工具redux和fluent-ui来优化项目。

超纲训练

• 给todoitem加上颜色标签
• 对todoitem进行分类

成果积累 => 输出

• github
• blog

作为一个重度 AI 用户，在用 ChatGPT、豆包或 DeepSeek 处理复杂任务（比如写代码、构思文章）时，我经常遇到一个问题：

“思维发散时，对话却只能线性堆叠。”

当我进行长下文对话时，思路往往是发散的。比如解决一个 Bug，我可能会针对 A 方案问几句，发现不行，又退回去针对 B 方案问几句。但在原本的网页里，这些对话全部混在一起，非常杂乱。

过几天想找回当时的某个思路？基本只能靠鼠标滚轮疯狂向上翻页，去寻找当初的那个提问。

为了解决这个问题，我开发了 Megi。

Megi 是什么

简单来说，Megi 是一个浏览器扩展，将原本平铺直叙的对话记录，重构为树状结构。

它支持目前主流的 AI 平台（ChatGPT, Gemini, DeepSeek, 豆包, 文心一言, 通义千问, 腾讯元宝等），并提供以下核心功能：

• 结构化整理：自动抓取你的提问，生成清晰的目录树，让对话脉络一目了然。
• 沉浸式导航：点击侧边栏问题，对话框瞬时滚动至目标位置。无需反复上下翻找。
• 拖拽分组：你可以把一个「追问」直接拖拽到另一个问题下面，成为子节点。像在 Notion 里整理笔记一样，把散乱的对话手动整理成一颗知识树。
• 长文折叠：当粘贴大段代码或长文档时，自动收起冗长输入。既保留上下文，又保持网页干净整洁。

比答案更重要的，是提问的逻辑

市面上也有一些生成 AI 会话大纲的插件，但 Megi 的核心理念在于——重塑提问的价值。

你会发现，Megi 的侧边栏只提取问题，不提取答案。这并非技术限制，而是我有意的产品克制。

我相信：能否提出一个好问题，往往比得到答案更重要。

像整理笔记一样整理对话

Megi 支持拖拽分组。这是它最能体现“思考树”特性的功能。

你可以把一个“追问”，直接拖拽到主问题下面，使其成为子节点。
当你手动进行这个动作时，你其实是在整理自己的逻辑树：

• 这个问题的根源在哪里？
• 我为了解决它，尝试了哪几个分支？
• 哪个节点最终导向了解决方案？

回头再看侧边栏，你看到的不再是一堆零散的 Q&A，而是一条完整的、由自己亲手构建的思维路径。

思考的留白

当 AI 正在思考或生成答案时，侧边栏会浮现一个问题卡片。这些问题来自于我之前看过的一本书 —《那些古怪又让人忧心的问题（What if）》

• “如果所有人类都消失了，那么最后一个人造光源何时熄灭？”
• “在这个世界上离其他活人最远的人是谁？他们孤独吗？”
• “如果你把元素周期表里的元素制作成立方砖头，并按照周期表的排列方式把这些方块一个个拼起来，会发生什么？”

希望在等待 AI 给你答案的时候，这些没有标准答案的问题能引发你的小小思考。

数据隐私

• 无服务器：Megi 没有搭建任何服务器来同步你的数据。
• 本地存储：所有的树状结构、分组调整、折叠状态，全部存储在你的本地浏览器中（Local Storage）。

写在最后

工具的本质是思维的延伸。如果你厌倦了在长对话中迷失方向，如果你也认为“提问”本身就是一种高价值的创造，希望 Megi 能成为你 AI 之旅中的那根手杖。

目前 Megi 已经上架 Chrome 和 Edge 商店，虽然已经迭代了几个版本，体验趋于丝滑，但作为个人开发者作品，难免还有 Bug。欢迎大家在评论区或通过邮件反馈，我会持续维护和改进。

网站

https://megi.dev/

下载地址

• (Chrome 应用商店)：
  [https://chromewebstore.google.com/detail/megi/gdnphcdionfgjohfhnjeoiaiicilbolj?utm_source=item-share-cb]
• (Edge 应用商店)：
  [https://microsoftedge.microsoft.com/addons/detail/megi/fpkmedhlhmeolnkndjjgdgpnmibcfcof]

使用效果图

这是一篇最近翻译的译文^1（也是我的第二篇译文👏），在文章的部分地方做了少许改动，同时也在原文的基础上增加了一些内容。希望不要误人子弟。Have Fun!

在计算机科学领域里只有两件事可以称之为难事：缓存失效（cache invalidation）和命名问题（naming things）。—— Phil Karlton

关于命名这件事，在某些时候的确是非常困难的。但却值得我们花费精力去研究它。回顾一下，之前你是否看过类似于这样的代码？

const convertObj = (x, y, z) => {
    const k = Object.keys(x);
    return k.map((key) => {
        return {
            [y]: key,
            [z]: x[key],
        }
    });
}

你能立刻知道它在做些什么吗？当然在你逐行读完这段代码后，可能会理解它想表达什么。但是，如果这段代码中的变量的命名方式更加优雅的话，我们会更容易理解这段内容。

好的变量命名是非常重要的，尤其是在动态类型语言中，因为没法用已经定义好的变量基本类型去帮助你理解该变量确切的含义。然而，如果能够在动态类型的语言中使用好的命名方法，代码较于静态类型的语言会变得更加易读。

接下来我将分享一些有关命名方法的基本规则，这些是我这些年来的经验之谈。通过变量不同的基本类型，对比举出一些例子。就让我们先从数组开始吧。

Arrays

数组对象是有序数据的集合，各项的基本类型大致相同。因为数组包含多个变量值，变量的命名应当是有意义的复数形式。

// 很bad很sad很drama
const fruit = ['apple', 'banana', 'cucumber'];
// 凑合
const fruitArr = ['apple', 'banana', 'cucumber'];
// 还不错
const fruits = ['apple', 'banana', 'cucumber'];
// 很好 - "names"暗示数组内容是字符串(strings)
const fruitNames = ['apple', 'banana', 'cucumber'];
// 优雅
const fruits = [{
    name: 'apple',
    genus: 'malus'
}, {
    name: 'banana',
    genus: 'musa'
}, {
    name: 'cucumber',
    genus: 'cucumis'
}];

Booleans

布尔类型只有2个值，true或者false。变量命名时使用『is』，『has』或者『can』作为前缀，将有助于读者理解变量的类型。

// bad
const open = true;
const write = true;
const fruit = true;

// good
const isOpen = true;
const canWrite = true;
const hasFruit = true;

当遇到predicate函数（该函数返回一个boolean值）时，在具名函数之后命名变量会有些烦人。

const user = {
  fruits: ['apple']
}
const hasFruit = (user, fruitName) => {
  user.fruits.includes(fruitName)
}
// 这个时候应该怎么命名这个boolean变量？
const x = hasFruit(user, 'apple');

由于我们已经给函数名称加了个has的前缀，因此不能再以hasProjectPermission这种形式命名x这个boolean变量。在这种情况下，可以给hasFruit这个函数加上check或者get来修饰谓语(has)。

const checkHasFruit = (user, fruitName) => {
  user.fruits.includes(fruitName)
}
const hasFruit = checkHasFruit(user, 'apple');

Numbers

至于数字类型，想想有哪些描述数字的词汇。诸如这些词汇，maximum,minimum,total.

// bad
const pugs = 3;
// good
const minPugs = 1;
const maxPugs = 5;
const totalPugs = 3;

Functions

函数应当使用动词和名词相结合的方式命名，当该函数在对象原型上产生某种行为时，它的名字应当能够体现出这一点。actionResource就是一个值得借鉴的命名格式。例如：getUser。

// bad
userData(userId);
userDataFunc(userId);
totalOfItems(items);
// good
getUser(userId);
calculateTotal(items);

通常情况下，我使用to作为函数名称的前缀来表示转换变量的值。

// I like it
toDollors('euros', 20);
toUppercase('a string')

遍历子项的时候，我经常使用这种惯用的命名方式。当接收函数中的一个参数时，应当使用数组名称的单数形式。

// bad
const newFruits = fruits.map(x => {
  doSomething(x);
});
// good
const newFruits = fruits.map(fruit => {
  doSomething(fruit)
})

回到开始

重构一下开头的那段代码

const arrayToObject = (array, id, name) => {
  const arrayList = Object.keys(array);
  return arrayList.map((key) => {
      return {
          [id]: key,
          [name]: array[key]
      }
  });
}

三省吾身

// 之前命名 => rsshub项目
// 1. 获取文章列表
const list = $('.con_list li h3')
      .find('a')
      .map((i, e) => $(e).attr('href'))
      .get();
// 2. 对遍历出的文章地址链接发出请求
const res = await got.get(itemUrl);

// 改进命名
const articleLists = $('.con_list li h3')
      .find('a')
      .map((i, list) => $(list).attr('href'))
      .get();

const responseData = await got.get(itemUrl);

目前网络上越来越多使用验证码了，验证码的本意是阻止机器刷流量挤占服务器资源，这本来无可厚非；但是验证码已经变得越来越过分，别说机器人了，连人也经常没法辨认！这就相当烦了，特别是被广泛使用更多reCAPTCHA，要你辨认出图中的XX，点了一次又一次还是结果错误，简直抓狂！迫不得已之下，只能祭出这款自动跳过reCAPTCHA验证码的工具了。

这款工具名叫“Buster”，它是一款开源的软件，具体形式是浏览器扩展。Buster在GitHub上有开源项目，大家可以下面的链接其GitHub页面，在页面中也可以找到Chrome、Firefox、Edge等浏览器的版本，找到对应的版本安装即可。

Buster GitHub主页：https://github.com/dessant/buster

Buster的原理是利用reCAPTCHA的语音，来自动识别验证信息，并通过验证。它并不能完全跳过reCAPTCHA验证码，还是需要进行一个手动操作。在出现reCAPTCHA验证码后，点击通过语音验证，Buster就可以识别语音，自动完成验证了。

总的来说，这是一个能大大改善上网体验的工具。

昨天在即刻上看到了 yiqin 发的一张图片关于——中国几个不同年龄段人口数量的分布^1。

刚好最近听的这期播客讲的也是关于人口老龄化的问题。还有结合最新出台的一些政策——上海落户进一步放宽，谈谈自己的一些思考。

播客内容

• 日本社会针对老年群体的个性化服务
  • 电子设备
  • 药品
  • 洗浴服务，裙带一些增值服务——染发，服饰，成人纸尿裤
  • 重视银发人群的品牌营销
• 创业公司的机会
  • 内衣，浴缸针对高龄群体应该如何设计

一些思考

• 社会问题如何成为新的创业机会
• 智慧养老产业的投资机会
• 银发经济，儿童经济的联动效应

开始之前

所谓 Prompt Engineering（提示工程），就是与 AI 进行有效沟通以实现预期效果的过程。至于为什么需要 PE 及其相关原理，并不是这篇文章的重点，感兴趣的同学可以看这篇文章[^1]。

本文想要介绍在提示工程中，一些对于开发者有用的技巧[^2]，以及分析在开源项目中的具体应用。

一些技巧

编写明确具体的说明

使用分隔符

分隔符可以是任何形式，例如：

'''text'''

"""text"""

< text >

<tag>text</tag>

const text = `
通过提供尽可能明确和具体的说明来表达你希望模型执行的任务。
这将引导模型朝着预期的输出方向发展，并减少收到无关或不正确回复的可能性。
不要混淆编写清晰提示和编写简短提示。
在大多数情况下，
较长的提示可以为模型提供更明确的上下文，从而产生更详细和更具相关性的输出结果。
`

const prompt = `
将三个双引号括起来的文本总结为一句话。
"""${text}"""
`

结构化输出

比如输出形式为 JSON 或 HTML

const prompt = `
生成三本虚构类书籍的书名、作者和类型列表。 
使用以下键以 JSON 格式提供：book_id、title、author、genre。
`

检查条件是否满足

const text = `
泡一杯茶很容易！首先，需要烧一些水。 
在水烧开的时候，拿一个杯子并把一个茶包放进去。 
然后把开水倒在茶包上。 
让它浸泡一会儿，茶就可以泡好了。 
几分钟后，取出茶包。如果你喜欢，还可以加一些糖或牛奶。 
就这样！你可以享受泡好的茶水了。
`

const prompt = `
如果文本包含一系列说明，请按以下格式重新编写这些说明：

步骤1 - ...
步骤2 - ...
...
步骤N - ...

如果文本不包含一系列说明，则仅写“未提供步骤”。

"""${text}"""
`

「Few-shot」 提示

「Few-shot」提示[^3]是指向 AI 模型提供有限数量的示例，从而引导模型更好地执行任务。这是一种常用于训练大语言模型（LLMs）的技术。

Few-shot prompting 的步骤如下：

1. 选择你想让模型生成响应的领域或主题。可以是一种文本类型、语言方式等。

2. 为模型提供少量的示例（提示），以作为后续样例的条件。通常只需提供 2-5 个示例即可进行「few-shot」学习。

3. 模型将分析提示中的模式、风格和结构。它将学习定义该领域响应的属性。

4. 让模型在相同领域中生成新的响应。通过提示的条件化，它可以生成符合所需风格、结构等的响应。

5. 评估响应并提供反馈以进一步改进模型。这可以是直接反馈给模型，也可以只是记录下一组提示生成的领域中需要改进的地方。

给模型时间「思考」

指定完成任务所需的步骤

const text = `
在一个美丽的村庄里，有一对兄妹杰克和吉尔。一天他们出发去从山顶的井中取水，
当他们欢快地唱着歌爬山时，不幸降临了——杰克被石头绊倒了，滚下山坡，吉尔也跟着摔了下来。 
虽然受了轻伤，万幸两人还是平安回家了。尽管发生了不幸，但他们的冒险精神却丝毫没有减弱，他们将继续探索大自然。
`

// 示例
const prompt = `
执行以下操作：
1-请使用一句话概括给出的文本内容。
2-将摘要翻译成法语。
3-列出法语摘要中的每个名称。
4-输出一个包含以下键的 json 对象：french_summary，num_names。

请使用换行符给出答案。

文本：
"""${text}"""
`

指示模型在决定之前先自行解决问题

const prompt = `
你的任务是确定学生的解决方案是否正确。
要解决问题，请执行以下操作：
-首先，自己解决问题。
-然后将你的解决方案与学生的解决方案进行比较，并评估学生的解决方案是否正确。
在自己解决问题之前，请不要决定学生的解决方案是否正确。

使用以下格式：

问题：

"""
问题
""

学生的解决方案：

"""
学生的解决方案
"""

实际解决方案：

"""
解决方案的步骤和您的解决方案在这里
"""

学生的解决方案是否与刚刚计算出的实际解决方案相同：

""
是或否
"""

学生的成绩：

"""
正确或不正确
"""

问题：

"""
我正在建造一个太阳能电站，我需要帮助解决财务问题。
-土地成本为每平方英尺100美元
-我可以以每平方英尺250美元的价格购买太阳能电池板
-我协商了一个维护合同，每年将花费固定的10万美元，以及额外的每平方英尺10美元
请计算出第一年的总成本是多少。
"""

学生的解决方案：

"""
设x为安装面积（以平方英尺为单位）。
成本：
1.土地成本：100x
2.太阳能电池板成本：250x
3.维护成本：100,000+100x
总成本：100x+250x+100,000+100x=450x+100,000
"""

实际解决方案：
`

他山之石

ai-code-translator

这个项目[^4]可以在不同的编程语言环境下转换代码。使用到了前面提到过的一些技巧，如使用分隔符来指示输入和输出的编程语言、提供「Few-shot」提示等。

const prompt = `
You are an expert programmer in all programming languages. Translate the "${inputLanguage}" code to "${outputLanguage}" code. Do not include \`\`\`.
  
      Example translating from JavaScript to Python:
  
      JavaScript code:
      for (let i = 0; i < 10; i++) {
        console.log(i);
      }
  
      Python code:
      for i in range(10):
        print(i)
      
      ${inputLanguage} code:
      ${inputCode}

      ${outputLanguage} code (no \`\`\`):
     `;
`

gpt-engineer

我们再来看一个更复杂的项目——基于描述来生成整个完整代码库，其中[^5]使用了大量的 propmts。下面列举部分步骤，来分析该步骤中使用到的 prompt。

flowchart TD
    A[Clarify] -->|main prompt + clarify| B(Gen_spec)
    B --> C[Respec]
    C -->|generate unit tests| D[gen_unit_tests]
    C -->E[gen_clarify_code]
    C -->F[gen_code]

const prompt_on_respec = `
You are a pragmatic principal engineer at Google.
You have been asked to review a specification for a new feature by a previous version of yourself

You have been asked to give feedback on the following:
- Is there anything that might not work the way intended by the instructions?
- Is there anything in the specification missing for the program to work as expected?
- Is there anything that can be simplified without significant drawback?

You are asked to make educated assumptions for each unclear item.
For each of these, communicate which assumptions you'll make when implementing the feature.

Think step by step to make sure we don't miss anything.
`

const prompt_on_gen_code = `
Please now remember the steps:

Think step by step and reason yourself to the right decisions to make sure we get it right.
First lay out the names of the core classes, functions, methods that will be necessary, As well as a quick comment on their purpose.

Then you will output the content of each file including ALL code.
Each file must strictly follow a markdown code block format, where the following tokens must be replaced such that
FILENAME is the lowercase file name including the file extension,
LANG is the markup code block language for the code's language, and CODE is the code:

FILENAME
CODE

Please note that the code should be fully functional. No placeholders.

You will start with the "entrypoint" file, then go to the ones that are imported by that file, and so on.
Follow a language and framework appropriate best practice file naming convention.
Make sure that files contain all imports, types etc. The code should be fully functional. Make sure that code in different files are compatible with each other.
Before you finish, double check that all parts of the architecture is present in the files.
`

[^1]: How ChatGPT works: a deep dive [^2]: 本文的主要示例来自 deeplearning.ai [^3]: Few-Shot Prompting [^4]: ai-code-translator [^5]: gpt-engineer

import { Callout } from 'fumadocs-ui/components/callout'; import { Tab, Tabs } from 'fumadocs-ui/components/tabs';

前言

写博客这件事，算起来已经进行了快十年。

最早是在 2017 年，使用 Hexo 搭建了第一个个人网站，那时候最大的乐趣就是魔改各种主题配置和折腾插件。后来到了 2023 年，为了探索去中心化写作，迁移到了链上博客 xLog。

遗憾的是，现在 xLog 已经停止维护。于是，我决定开启新一轮的“造轮子”工程——重构博客。

遇见 Fumadocs

关于博客的选型有太多太多的方案，我最终选择了 Fumadocs。它本质上是一个基于 Next.js 的文档框架，但其极高的定制性和优秀的交互设计，非常适合用来构建一个“开发者友好”的技术博客。

1. 极致的代码阅读体验

Fumadocs 深度集成了 Shiki 和 Twoslash，带来了 IDE 级别的阅读体验。

Shiki Transformers

// highlight a line
<div>Hello World</div> // [!code highlight]

// highlight a word
// [!code word:Fumadocs]
<div>Fumadocs</div>

// diff styles
console.log('hewwo'); // [!code --]
console.log('hello'); // [!code ++]

// focus
return new ResizeObserver(() => {}) // [!code focus]

Twoslash 静态类型检查

不再是简单的颜色高亮，现在支持静态类型检查。将鼠标悬停在下方的 user 变量上，可以直接查看 TypeScript 的类型定义。

interface User {
  id: number;
  username: string;
  role: 'admin' | 'user';
}

const user: User = {
  id: 1,
  username: "Fumadocs",
  role: "admin",
};

// 悬停在 user 上查看类型推导
console.log(user.role);

2. 代码驱动的可视化

得益于 MDX 的强大能力，图表与公式不再依赖截图，而是成为可维护的代码片段。

Mermaid 流程图

直接在 Markdown 中描述业务逻辑，对于解释技术架构非常有用。

graph LR
    subgraph clients [Client Layer]
    A([Web App]) --> B[API Gateway]
    C([Mobile App]) --> B
end
    subgraph services [Service Layer]
    B --> D[Auth Service]
    B --> E[User Service]
    B --> F[Order Service]
end
    subgraph data [Data Layer]
    D --> G[(Auth DB)]
    E --> H[(User DB)]
    F --> I[(Order DB)]
    F --> J([Message Queue])
end

KaTeX 数学公式

原生支持复杂的数学符号渲染，保持排版的一致性与优雅。

Attention 机制公式：

$$\text{Attention}(Q, K, V) = \text{softmax}\left(\frac{QK^T}{\sqrt{d_k}}\right)V$$

3. 极简设计

摒弃视觉噪音，内容优先是唯一原则。

• 字体：正文采用 Geist Sans，代码采用 JetBrains Mono。几何无衬线体与等宽字体的组合，保证了长时间阅读的舒适度。
• 深色模式：基于 Tailwind CSS v4 的语义化配置，实现了丝滑的明暗切换。
• 移动优先：对于移动端视口进行了适配，保证在任何设备上都能获得一致的阅读体验。

4. 技术栈

沉浸式写作

建议在 .vscode/settings.json 中添加以下配置：

"[mdx]": {
        "editor.lineHeight": 28,// [!code ++]
        "editor.wordWrap": "wordWrapColumn",// [!code ++]
        "editor.wordWrapColumn": 85,// [!code ++]

        "editor.lineNumbers": "off",// [!code ++]
        "editor.minimap.enabled": false,// [!code ++]
        "editor.glyphMargin": false, // [!code ++]
        "editor.renderWhitespace": "none",// [!code ++]
    },

结语

折腾博客的尽头是回归内容。

Fumadocs 提供了一个足够现代、高性能且低维护成本的地基。接下来的日子，希望自己多写点东西。

功能：

• 去掉百度、搜狗、谷歌搜索结果的重定向，回归为网站的原始网址
• 添加百度、搜狗、谷歌搜索结果中Favicon显示效果
• 百度和谷歌搜索页面可以设置为单列、双列模式
• 支持自动翻页
• 可以去广告

默认相关功能关闭，需要的请手动开启

实际效果

下载

https://scriptcat.org/zh-CN/script-show-page/3002

作为除了编辑器，浏览器之外，每天接触第二多的东西——终端。是要来好好折腾一番了。之前，我就下载了oh-my-zsh。但是使用的一直是它的默认主题——robbyrussell。这个主题，其实很不错了，相比于自带的zsh已经是非常的简洁美观。可是身为一个前端er,不折腾怎么能行了🌊。

折腾前的准备

1. iTerm2
2. oh-my-zsh
3. powerline font

具体的安装步骤，就不再赘述了，大家可以去文档里查看。

需要做的配置

iTerm颜色主题

这个主题库包含了170+种主题。可以把文件下载到本地，然后导入到color presets中就好了（使用快捷键cmd + i）。

zsh主题

我使用的是powerlevel9k,它可以对终端进行进一步的个性化定制，就像这样🌰。

安装powerlevel9k

1. clone主题的仓库地址

$ git clone https://github.com/bhilburn/powerlevel9k.git ~/.oh-my-zsh/custom/themes/powerlevel9k

2. 在.zsh中设定主题

ZSH_THEME="powerlevel9k/powerlevel9k"

zsh相关插件

• zsh-autosuggestions
• zsh-syntax-highlighting

这是我推荐的两个插件，当然，你也可以添加一些其他的插件。具体地址在这里。

安装zsh插件的两种方式

oh-my-zsh方式

1. clone插件的仓库地址

git clone https://github.com/zsh-users/zsh-syntax-highlighting.git ${ZSH_CUSTOM:-~/.oh-my-zsh/custom}/plugins/zsh-syntax-highlighting

2. 在~/.zshrc中找到plugins,添加这个插件

plugins = (
    git
    rails
    zsh-autosuggestions
)

.zshrc方式

1. 同上
2. 在.zshrc中添加一行

source ./zsh-syntax-highlighting/zsh-syntax-highlighting.

其他

隐藏用户信息

打开终端后会发现，总是有一段长长的用户信息前缀。感觉有些多余，我们如何来隐藏它呢。记得之前使用robbyrussell主题时是没有的，所以很有可能是主题文件的原因。于是打开powerlevel9k.zsh-theme文件（注意看上文clone的路径）。

# Note that if $DEFAULT_USER is not set, this prompt segment will always print

所以解决的方法就是在.zshrc中设置默认用户名就好了。

vs code配置

完成以上步骤之后，一个颜值又高又好用的terminal就此诞生了。让我们打开vs code，撸起袖子加油干吧。等下，乱码又是什么桂？原来是忘记设定终端字体了，打开settings.json文件，把下面这行加上去就好了。

"terminal.integrated.fontFamily": "Meslo LG M（你使用的字体） for Powerline"

最近把开发环境迁移到了 windows 上，久违的 windows 还是给我带来了不少的惊喜。简单的折腾[^1]之后，终端的使用体验已经非常接近 Mac 了。 这篇文章作为之前写过的一篇文章——《terminal折腾记之Mac篇》的姊妹篇。实现思路上大都相似。

准备

1. windows-terminal
2. iTerm for windows
3. oh-my-posh
4. powerline font

配置

terminal 配置

profiles.json 结构

复制 iTrem 上的颜色主题，导入到 schemes 数组中。然后在 list 中，使用这个键值 "colorScheme":"lovelace"，生效主题颜色。当然你也可以把它写到 defaults 中，这样就会覆盖 list 中配置的所有终端。

powershell 配置

1. 安装 oh-my-posh

# 安装命令
Install-Module posh-git -Scope CurrentUser 
Install-Module oh-my-posh -Scope CurrentUser

2. 下载 powerline font
3. 配置 powershell_profile.ps1

# 如果之前没有配置文件，就新建一个 PowerShell 配置文件
if (!(Test-Path -Path $PROFILE )) { New-Item -Type File -Path $PROFILE -Force }
# 打开配置文件
vi $PROFILE
# 添加内容
Import-Module posh-git 
Import-Module oh-my-posh 
# 设置主题
Set-Theme Paradox

4. 在powershell中使用vim

# 使用git内置的vim

vs code 配置

如果之前在 vs code 中使用等宽字体的话，打开终端会发现命令提示符出现乱码。这时候要把终端的字体设为powerline，就像这样：

"terminal.integrated.fontFamily": "Meslo LG M（你使用的字体） for Powerline"

备份

现在，我们来整理一下整个改造终端的过程更改了哪些文件：

• profiles.json
• powershell_profile.ps1
• setting.json

备份了这三个文件，就能在任何一台windows设备上还原有颜同时又很强大的终端了。

最后

其实到了这里，只能说是实现 windows 下 terminal 的基本改造。还有很多的部分没有去折腾，比如：

• 快捷键的绑定
• WSL相关
• 编写自己的主题
• tricks and tips

更多的细节以及使用技巧，可以在官方文档中找到。

[^1]: 系统环境须在 Windows 10 (build1903)以上

『太多的资讯就如同太少的资讯一样，都是一种对理解力的阻碍。换句话说，现代的媒体正以压倒性的泛滥资讯阻碍了我们的理解力』

开始之前

很早就想写一篇关于自己如何做「信息管理」的文章了。前段时间看到 Twitter 上 Randy 的分享以及读了《打造第二大脑》这本书。我也再次思考自己应该如何来做信息管理。

对我而言，做好信息管理主要有两个目的：

1. 提升效率：在工作或生活中遇到难题时，能快速找到既有的解决方案
2. 激发灵感：通过旧知识的碰撞，产生更多有趣的新想法

输入

目前我的信息输入主要分为三类：算法推荐的信息流、主动订阅的 RSS，以及读书和听播客。

信息流

• Twitter
• GitHub
• Youtube
• 即刻

我在 Twitter 上关注了很多很棒的开发者，设计师，还有一些有趣产品的官推。从这些关注列表中可以看到他们最新的观点，又出现了哪些新的技术和产品。我把 Likes 当做收藏夹来使用，看到感兴趣的内容就会 like 一下。此外我还建了一些 Lists，这个功能算是一个分类吧，目前我建立的几个大类是 AI，FE，Web3。

GitHub 其实也有信息流 —— 「For you」，这个可能是很多人不太用到的。从这里可以看到关注的开发者都 star 了哪些 repo，此外它也会推荐一些最近比较流行的项目。我会把 star 的 repo 进行分类，你可以在这里看到。

Youtube 上主要是浏览订阅的一些频道。内容其实就比较广泛了，技术，生活，娱乐都有。这个上面也时常能够发现高质量的内容，比如加州伯克利大学的 Web3 Mooc，街头摄影师 Kai W，乒乓球博主 Adam 等等。

即刻是一个很不错的中文社区，Web3 和 AI 的内容质量都还不错，也会有一些活跃的独立开发者和投资人。不过最新的科技资讯还是稍微滞后于 twitter。

信息流最主要的特点就是——算法推荐，但它是一把双刃剑，有的时候会带来惊喜，发现更多有意思的人。另一方面则是很容易产生『信息过载』，用户总是一遍又一遍的刷新 APP。

RSS

RSS 订阅是我常用的另一种获取信息的方式。主要用来订阅一些技术博客，当然也有一些其他主题的订阅源。如设计相关的，Behance，Design-Milk。科技相关的，9to5Mac，The Verge。Web3 相关的，Weekly in Etherum，Foresight news 等。

RSS 和信息流相比，我认为优势在于文章的质量会更高一些 —— 因为订阅源是经过自己筛选之后才放到阅读器中的。我会定期刷新阅读器，来获取这些高质量的信息输入。

看书和听播客

如果想要更加系统的学习一门知识，我认为看书还是最好的学习方式。当然阅读完一本专业书是一件很困难的事情。因为大部分的情况下，Google（或许现在可以直接问 ChatGPT）或看文档就能解决问题。很少有人会再去花费大量的时间搞懂问题的来龙去脉。

播客的优势在于，获取到的是第一手的信息。比如我想了解 Sam 对未来 AI 发展的一些观点，去听相关的播客会比看相关媒体总结的文章可信度更高。

CODE 方法

CODE 方法是《打造第二大脑》这本书中的的核心内容。下面谈谈我自己的一些实践。

CODE 方法

• C(Capture) -> 获取能引发共鸣的信息
• O(Organize) -> 组织分类
• D(Distill) -> 标注精髓部分
• E(Express) -> 展示成果

对于「Capture」部分，主要就是上面提到过的几种方式，还有就是我会使用 Web Clipper 这个插件剪切网页文章到语雀知识库。然后在语雀知识库中进行「Organize」—— 通过文件夹分类的方式。再者就是在 Obsidian 上对写摘要完成「Distill」，最后就是写博客，发推特，发即刻来展示成果。

完成这些步骤就走完了 CODE 方法完整的一套流程。当然在具体实践中要根据自己的情况做调整，每个人使用的工具也都不尽相同。对于我来讲，D 和 E 做的还不够，也即是「输出」这个部分。

想法

做好信息管理，在学习新的技术或是解决不曾遇到过的问题时，不必要从零开始，而是建立在已有的知识库上。接下来，大语言模型加上个人知识库可能会让打造第二大脑的过程更加简单。但是无论方式如何，我们最应该关注的还是「看到过的信息，以后会去向哪里」。我想用之前看到过的关于 TypeScript 的一句话作为结尾。

As you write TypeScript, you need to think about where you want your contracts to be, and what needs to be done in order to meet them.

关灯看视频是一款能够在浏览器上播放视频的时候，自动调暗视频以外区域亮度，让你有一种置身于电影院中观影的感觉。支持众多浏览器。

暗色主题已经征服全世界了，一些视频网站已经自带关灯模式了。但还有一些网站，比如YouTube，就滞后一些，还不支持关灯模式。

于是可以先用扩展顶上，只需一键，就能在看在线视频的时候，非全屏状态下关灯、免打扰看视频。

关灯看视频 这个浏览器扩展，它能降低页面亮度，突出显示视频。

支持大多数视频，并且还有一些有趣的功能。

比如：

自动高清：自动将视频调整至高清画质
自动宽屏：自动在最宽模式播放视频
自动播放：按下播放按钮后自动关灯
淡入淡出：逐渐开关灯

自动播放功能比较全面，支持黑白名单，让一些网站自动，一些网站不自动。

关灯看视频的官网在这里在这里，感兴趣的可以自己去体验下。

console.log('A');

console.log('B');

需求分析

• 自定义显示的页码按钮的数量
• 自定义分页组件的颜色主题
• 可以选择显示文本内容或者图标来进行翻页操作

实现

1. 分页组件需要显示的页码按钮数量，可以通过pagesToDisplay()这个计算属性定义
2. 颜色主题可以通过绑定一个paginationClass的class，返回颜色type实现
3. 文本或图标的选择可以通过嵌套条件判断template实现

分页原理

实现分页主要依靠这两个参数，total(总条目数)，perPage(每页显示的条目数量)。后端可以通过这两个参数，返回相应的数据给前端。 整个分页组件中，相对来说比较麻烦的地方在于页码列表的显示逻辑。页码列表是一个返回[最小页码, 最大页码]的数组。进而，问题被切分为如何求解页码列表数组中页码值的最大值和最小值。这里定义两个计算属性maxPage()，minPage()来返回页码数组中页码值的最大值，和最小值。

页面组件

<template>
  <ul class="pagination" :class="paginationClass">
    <!-- 前一页 -->
    <li
      class="page-item prev-page"
      :class="{ disabled: value === 1,'no-arrows': noArrows }"
    >
      <a class="page-link" arial-label="Previous" @click="prevPage">
      <!-- 是否有文本 -->
        <template v-if="withText">
          perv
        </template>
      <!-- 箭头图标 -->
        <i class="arrow-left" v-else></i>
      </a>
    </li>
    <!-- 当前显示的分页列表 -->
    <li
      class="page-item"
      v-for="item in range(minPage, maxPage)"
      :key="item"
      :class="{active: value === item}"
    >
      <a class="page-link" @click="changePage(item)">{{item}}</a>
    </li>
    <!-- 后一页 -->
    <li
      class="paga-item next-page"
      :class="{disabled: value === totalPage, 'no-arrows': noArrows}" 
    >
      <a class="page-link" arial-label="Next" @click="nextPage">
      <!-- 文本内容 -->
        <template v-if="withText">
          Next
        </template>
        <i class="arrow-right" v-else></i>
      </a>
    </li>
  </ul>
</template>

props

props: {
  // 颜色主题
  type: {
    type: String,
    default: "primary",
    // 验证`type`的值
    validator: value => {
      return [
        "default",
        "primary",
        "info",
        "success",
        "danger"
      ].includes(value);
    }
  },
  // 是否带有文本内容
  withText: Boolean,
  // 箭头图标
  noArrows: Boolean,
  // 页码数
  pageCount: {
    type: Number,
    default: 0
  },
  // 每页显示的项数
  perPage: {
    type: Number,
    default: 0
  },
  // 总项数
  total: {
    type: Number,
    default: 0
  },
  // 当前页码的值
  value: {
    type: Number,
    default: 1
  }
}

data

data: {
  // 页码列表中显示的页码数量
  defaultPagesToDisplay: 5
}

computed

computed: {
  // 颜色主题
  paginationClass() {
    return `pagination-${this.type}`
  },
  // 总页码数
  toatalPages() {
    if (this.pageCount > 0) return this.pageCount;
    if (this.total > 0 ) {
      return Math.ceil(this.total / this.perPage);
    }
  },
  // 显示的页码按钮数量
  pagesToDisplay() {
    if (this.totalPages > 0 && this.totalPages < this.defaultPagesToDisplay) {
      return this.totalPages;
    } else {
      return this.defaultPagesToDisplay;
    }
  },
  // 页码列表中最小的页码数
  minPage() {
    if (this.value >= this.pagesToDisplay) {
      // 定义一个偏移量
      const pagesToAdd = Math.floor(this.pagesToDisplay / 2);
      // 假定的最大页码数 = 当前页码值 + 偏移量
      const newMaxPage = this.value + pagesToAdd;
      if (newMaxPage > this.totalPages) {
        return totalPages - this.pagesToDisplay + 1;
      } else {
        // 当前页码值始位处于页码列表的中间位置
        return this.value - pagesToAdd;
      }
    } else {
      // 当前页码值小于默认页码列表按钮数量时，最小页码数返回1
      return 1;
    }
  },
  // 页码列表中最大的页码数
  maxPage() {
    if (this.value >= this.pagesToDisplay) {
      const pagesToAdd = Math.floor(this.pagesToDisplay / 2);
      const newMaxPage = this.value + pagesToAdd;
      if (newMaxPage < this.totalPages) {
        return newMaxPage;
      } else {
        return totalPages;
      }
    } else {
      // 当前页码值小于默认页码列表按钮数量时，最大页码数返回显示的页码列表按钮数
      return this.pageToDisplay;
    }
  }
}

methods

methods: {
  // 页码列表数组
  range(min, max) {
    let arr =[];
    for (let i = min; i <= max; i++) {
      arr.push(i);
    }
    return arr;
  },
  // 跳转页码
  changePage(item) {
    this.$emit("input", item);
  },
  // 下一页
  nextPage() {
    if (this.value < this.totalPages) {
      this.$emit("input", this.value + 1);
    }
  },
  // 上一页
  prevPage() {
    if (this.value > 1) {
      this.$emit("input", this.value - 1);
    }
  }
}

最后

想要不断提高自己的技术水平，就不能只满足于写业务组件。在写像分页这种独立组件的过程中，也让我思考API的设计，以及功能复杂性的问题。无论是多么复杂的组件，大体上都是由prop，event，slot三部分组成。具体的实现，主要还是依靠基础的javascript的能力。 此前，我也仿照element写了radio和input组件。希望自己能坚持去写这些独立组件，去发现更大的世界。本文的分页组件源码在这儿。

这一周的主题是 ChatGPT 相关的内容。3月初，OpenAI 开放了 ChatGPT 的接口。这两周以来各种相关的应用如雨后春笋般冒出来。

其中的一些产品已经成为我每天必用。同时我也在思考如何利用这些工具来提升我的学习和工作效率。尤其是在用 chatPDF 看文章或者论文时，不停地提出问题，会让我的注意力更加集中。

使用过的产品

• chatPDF
• typingMind
• openai-translator
• roomGPT
• paul-graham-gpt

看的文章

• chatgpt-explained-a-guide-for-normies

前段时间在做一个 prompt engineering 的翻译。看完这篇文章终于明白了为什么需要使用 prompt 来控制 ChatGPT 的输出结果。

原理 A generative model is a function that can take a structured collection of symbols as input and produce a related structured collection of symbols as output

确定性（Deterministic） VS 随机性（stochastic）

关联关系（Relationship matters）

• 符号关系之间的多样性和复杂性
• 潜在空间 -> 可能输出结果的多维空间

概率分布（Probability distributions）

• 哪些方法可以改变 LLM 模型的概率分布
  • 训练（training）
  • 微调（Fine-tuning）
  • 人类反馈的强化学习（RLHF）

一些思考

学习到的技术

• paul-graham-gpt
  • 使用 embedding 来实现文本搜索 => 使用 cosSim 来计算相似度

export const cosSim = (A: number[], B: number[] ) =>
    {
        let dotproduct = 0
        let MA = 0
        let MB = 0
        for (let I i < A.length; i++) {
            dotproduct += A[i] * B[i]
            MA += A[i] * A[i]
            MB += B[i] * B[i]
        }
        MA = Math.sqrt(mA)
        MB = Math.sqrt(mB)
        const similarity = dotproduct / (MA * MB)
        return similarity
    }

• openai-translator
  • 使用 tauri 将 web 应用打包成桌面 APP

独立开发者的机会

• typingmind 的开发者在一周之内收益 $20000

读的文章

• The future of Chakra UI
• How to handle errors in React

产品

web3

ramper particle

AI

• segment anything

看的书

• 《打造超人大脑》
• 《思考快与慢》

一些思考

从看的两本书，来聊一下最近的一些思考。

《打造超人大脑》主要讲了三个主题，『输入』，『输出』，『持续进化』。看这本书的过程中，对于各个部分作者提出的一些方法，其实对我来讲都不算特别新鲜。更多的思考则是自己对过去学习的一些反思。无论是对于编程还是写作，感觉自己还是停留在『新手区』。

对于『输入』部分，日常我会通过 RSS 和公众号的订阅，以及 Twitter 和即刻上关注的一些『大牛』发的推文或者写的博客来完成。并且我会定期整理 Twitter 上的 likes，以及把看到的优质文章剪切到语雀——方便回顾。有的时候也会看一些文章提到的书。这部分我认为我做的还不错，因为总能发现一些高质量的文章以及第一手的行业资讯。

对于《输出》部分，显然我做的有很多不足。方式目前是通过写博客，发推文来完成。问题主要出现在拖延症，以及写文章效率太低。这本书里面讲了一些『轻松写作』和『持续写作』的方法。想要跳出新手区，这部分是我最需要提升的地方。

『持续进化』这个部分，书里面提到了『如何对写作上瘾』，『跨界学习』，『从零开始快速学会一门新的领域』。我认为这个部分是对于前两个部分能力的体现，更多的是一种选择。

《思考快与慢》这本书实际上很早就已经看过了。几年前我在 MOOC 上学习一门《日常思考与科学》的课程，里面很多的一些引用实例就是来源于这本书。书中有大量的例子来解释我们在生活中是如何做出判断和决策。

很多经典的书还是要反复的读，对于读书也要运用一些第一本书中提到的如何『输出』的方法。还有就是我也在思考如何借助 AI 工具提升效率，所谓的『第二大脑』。但是目前来讲，如果只看 AI 总结后的内容，就如同不去读书只是去看读后感一样，不过是假装让我们看起来很聪明而已。

阴雨天已经连绵了差不多两周的时间，这个夏天的雨季感觉比往年都要来的更早一些。上周末，本赛季的英超比赛也已经踢完了。曼城提前两轮便锁定了英超冠军，最后的收官之战早已悬念不再。

回顾一下本周做的一些事情：

工具

• databerry
• gamma
• yt-fts

最近在考虑如何动手实现一个可以训练自定义数据的 Bot，原理就是使用 OpenAI 的 API，LangchainJS 以及向量数据库来完成。Databerry 是个无代码的平台支持使用自定义数据来实现 ChatGPT Agent，总体使用体验还不错。但是免费版的限制太多了，还没来得及深度体验，额度几乎已经用完了。

上一周还参加了一个黑客松比赛，终于做了一把「全栈」开发——前端 + 智能合约 + PPT + 视频几乎都是由我一个人完成。其中 PPT 部分使用了 gamma 来做辅助。节省了我很多的时间，只需要把项目中 README 作为大纲丢到 gamma 中，它就能帮我完成 PPT 大体的框架。而且还有许多超棒的样式可以选择，想要修改布局也很方便。

yt-fts 是一个可以全文搜索 Youtube 频道中字幕的命令行工具。原理就是使用 yt-dlp 先下载该频道下所有视频的 subtitles 然后将其存到 sqlite 数据库中进行全文检索。最新的版本还支持使用 OpenAI embedings 来语义检索。

听的播客

• 代码之外第二期

这期播客请来了尤雨溪作为嘉宾。确实没有想到尤大的歌能唱的这么好听😂，听完了这期播客，我还特意去听了几遍方大同的《春风吹》。这期并没有聊具体的技术。而是分享了自己在新加坡的生活以及如何做决策等等。印象比较深刻的对话是——当谈到 Vue 成功的原因时，他说「可能技术和他水平相当或是超过自己的人有很多，但是他的不同是更能了解用户的需求」。还有就是时机，那个时候前端工程化才刚刚起步。

看的书

• 《额尔古纳河右岸》—— 迟子建

这本书描绘了鄂温克族百年的沧桑和生存现状。鄂温克族人世代居住的土地上，有与他们日夜相伴的驯鹿、树木、河流、月亮和清风。作者的文笔非常优美，记得在高中时期就经常在文本理解中遇到她的作品。

目前我只读完了第一章节，更多的感受就放在接下来的文章中谈吧。

读书

这段时间主要看了，《把自己作为方法》、《置身事内》和《额尔古纳河右岸》这三本书。关于读书的方法也有一些感悟——「没有必要强迫自己在特定的时间内把一本书读完」。对于读书，随机阅读可能会比做任务的方式给我带来更大的收获。

这是我今天在读《置身事内》这本书时做的摘录，内容还挺有意思。

很多语言（如英语）是有时态的，因此在讲到“过去”“现在”“未来”时，语法要改变，会让人产生一种“疏离感”，未来跟现在不是一回事，何必担心未来，活在当下就好。因此说这种语言的人储蓄率较低。很多语言（如汉语和德语）没有时态，“往日之我”“今日之我”“明日之我”绵延不断，因此人们储蓄率也较高。

之前通常是在 kindle 上读书，但是导出笔记比较麻烦。现在我已经迁移到了微信读书，配合 obsidian 的这个插件，导出笔记非常方便。并且微信读书也支持多端阅读。

文章

• Ticketing with Unlock Protocol at EthCC 2022

• 开发一个浏览器插件在第三天卖出 1000 元

这篇文章是关于 unlock 协议在 Ethcc 2022 的具体实践。

• 如何设计 NFT 门票系统
  1. 考虑参会者不同的角色
  2. 如何快速验证门票的有效性
• 解决的问题
  1. 阻止机器人购买
  2. 不可转让的 NFT 门票，防止黄牛炒作
  3. 会场内门票验证，确保门票真实性

播客

• AI Agent 智能体 真相和未来

• Chillchat

• 第五集|代码之外

这期关于 AI 的播客讨论了很多我感兴趣的话题，例如「AI 在游戏方面的创新进展」、「软件的世界会被怎样的改变」以及「开源的 LLama 2 如何刺激大模型创新」等。

Chillchat 是一对中外异地情侣探讨如何学习中文的播客。话题都是一些生活日常，从逆向思维角度，对于我学习英文也是很有帮助的。比如在这个播客中，经常会给出一些中文词汇，让对方说出对应的英文。此时我也在思考应当如何使用英文来表达。

音乐

• 《春游》—— 窦靖童

这张专辑中有好几首歌我都非常喜欢，在反复地听。《河流》、《烟花》、《橘子汽水》都是充满想象力和灵气的歌曲。此外这张专辑也是窦靖童的第一张中文专辑，从这十首歌曲中可以看到她对独立音乐创作的态度和理解。玩音乐，做实验来创造出自己的独属风格。

读书

这段时间主要看了两本书，《黄金时代》和《包法利夫人》。

之前看过王小波的两本书，一本是《沉默的大多数》，另外一本是他和李银河写的《爱你就像爱生命》。他的文字诙谐易懂，读起来毫不费劲。读他的书就像是和一个非常真诚直率幽默的人在聊天。

这本《黄金时代》我才刚开始读到第一部分，这是王二人生中的少年时代，充斥着非常多直接而坦率关于性的描写。

那一天我二十一岁，在我一生的黄金时代，我有好多奢望。我想爱，想吃，还想在一瞬间变成天上半明半暗的云。

至于《包法利夫人》，令我印象深刻的是作者的语言艺术。太多关于人物精雕细琢的描写了。

而且寡妇瘦括括的，牙又长，整年披一件小黑披肩，尖尖头搭在肩胛骨之间；骨头一把，套上袍子，就像剑入了鞘一样。

播客

下面的几段内容，摘选自我前两天听的播客[^1] 和之前收藏的一期播客[^2]。都是读者的来信，这种还未捅破窗户纸的朦胧情感读起来特别让人着迷。

未寄出的月光

是这样的，他说，还是喊你L吧。不知道为何要提笔写下这封，反正你也看不懂的信。情书对于写情书的人和读情书的人，哪个更重要？何况是我一个中年人要写一份悸动，不知从哪个时刻开始，妳在人群中变得耀眼，想尽回忆也找不到我的萌芽瞬间，但闭上眼睛，辗转反侧的却都是妳。一群人出去玩，妳总是担任导航的角色，所以每次坐扶梯，妳都站在最上面，而我总是跟在最后边，我赌妳会回头看，于是四目相对，我沦陷在妳的笑眼里。有次在路上发烧了，你搓了搓双手让自己变暖之后才轻扶我的额头，

每次聚餐你都坐在我旁边，还一口气吃完了我炒的贼辣的土豆丝。某次我鞠躬为你把我送回家表示感谢，你说日本人才会这么做，我说这是我们大中华礼仪之邦的最高谢意，于是两个人在地铁上开始互拜。无法加入闲聊的我在踩地上的枯叶，你问我在干什么，我说杀死一片枯叶，于是你也成了帮凶，还有什么猫，书，宫崎骏，恐流，三岛，再没什么了。毕竟我们只相处了两周而已，去年看了一部电影《过往人生》，从男主和女主恢复联系的那一刻起，我就期盼着一场久别重逢的亲吻，一场酣畅淋漓的性爱，总要发生点什么来献祭这样的感情，但什么都没有发生。这个空白把我搞得无地自容，因为我们之间终究还是发生了一点什么。离别前一晚，两个人的见面，你突如其来的邀请，交换人生碎片，又被每一个碎片吸引。冰激凌在夏夜里融化，空气里有一些甜腻，四点的月亮具有魔力，妖艳又神秘，你意犹未尽的所抱，我伪装平静的绽放，月亮抽出了双眼，秘密和不可告人的秘密。如今，我们在不同的地方仰望月亮，我也明白了一个人可以带着另一个再无联系的人继续生活。

生命中某个部分彻底改变了，你和夏天永远留在了SG，如果这一生还有机会再见，我也会用空白回应你，同时告诉你，那晚月色有多美，祝你好，比我好，想留在过去的S。

余光里的你

你好呀，LMS， 我认识你蛮久了，也在一次一次的偶然相遇中对你产生了一些特别的情意。第一次注意到你是在周老师的英语课堂上，你竞选课代表的发言，你叫LMS啊，好好听的名字。

当时对你的印象是你讲话很好听，是很清冷的男孩子，给我一种不一样的感觉。也是在这之后，我开始有意无意的关注到你。其实后来才意识到，在这之前，我也见到过你。体育课上，你分发号码符，跑完800米，到我面前问我要号码符。嘿，同学，把号码符给我。我印象里的你，当时是带着一抹笑容的。慢慢地回忆到妳，突然有印象妳参与过年级长竞选。妳一次次不经意地出现，在我信里留下了一次次印记。当时的我认为这种情愫只不过是一时兴起罢了。

可是后来，和妳见面的频次越来越少，妳的名字在日记本上出现的频次却越来越多。我开始频繁地期望与妳的见面。最近在公交车上遇到了你两次，我真的好激动，好开心，也写了些文字。那天在公交车上遇到他了，他像极了他，他像极了我印象中的他，自己着迷的他。后来，有很多时刻回味那天早晨。他在我斜前方的椅子上坐着，旁边女生的头恰好挡住了我望向他的视线，车一停一晃，模模糊糊地用余光看到他的身影，也不敢明目张胆看着脸。每次遇到之后都懊悔，怎么不多看一眼，还记得自己下车后故意放慢脚步，也等不到他走在我面前，当时只念着慢一点，再慢一点，快一点，快一点，今天也遇到了，快到学校才发现他也在这辆车上，本来已经做好遇不到他的准备了，一路都在吃早餐看风景，到师大地铁站，人走了一半，猛地抬起头望到了他，气质好像他，确认他的脸，看到他就好开心啊。在他后面下车，可是他走好慢，慢到我也这样走就好明显。擦肩到他面前的时候，我真的好拘谨。不管下次他走多慢，我也要跟着他的速度。每一次见面我都好欢喜，会怀念当时的你。我不自觉的心跳加速，都在跟自己反复确认着我对你的心意。

我笃定这是喜欢，我从来都不是一个足够自信勇敢的人，所以在是否向你表达心意这件事上，真的犹豫了很久很久，我想我就不要打扰到他的生活了吧，可是我真的好不甘心，不甘心还没尝试过就放弃，我想我不要欺骗自己，不要隐瞒这份真实存在的感情，所以我还是想试一下，今天可能有点冒昧了，对不起。

告白的意义

我想和你们分享我的初恋的故事，那是我单方向的、漫长的迄今唯一一次的喜欢。还是叫他Q吧，毕竟他在我的日记里一直都是这样出场的。

初中时，我们同校，家离得也不远，所以总搭同一辆公车。是在初二下春夏之交的时候开始关注他的（日记里开始出现他的名字缩写），他的学习成绩很好很好，是重点高中的苗子，而彼时我只是班级中上游的一员。

但，真正开始对他产生Crush的感觉却是在一瞬间。那是后来暗恋他五年的时间里我反复在笔记本上描述的一幕。那是个下雨天，隐隐约约传来春雷的声音，香樟树被雨水洗得发亮，空气里弥漫着樟树的冷香。我坐在公车后排，一眼扫到了路边等车的他。他撑着一把普通得再普通不过的蓝色格子伞，依旧低着头，背着他那塞满书的黑色书包，蓝色格纹衬衫，站在一棵香樟树下。我其实一直都没怎么看清过他的模样（一方面是因为那时候近视了，但我觉得戴眼镜不好看，所以不看书的时候都是不戴眼镜的，另一方面是因为我不敢直视他，即便在他和我聊天的时候，我都不敢把目光放在他的脸上太久，害怕会被他发现、会被别人发现自己的喜欢）。那时候我开始发了疯似的拼命做题，甚至低血糖昏倒在家里，我想和他考上同一所高中。我也开始偷偷写诗，写关于那天树下的那个少年，写雨水，写樟树，写我自己，写少年不知方向的未来。我还是每天看着车窗外的行道树发呆，但耳朵里装着的却不再只有风声。他的咳嗽声，他的脚步声，他的笑声……全部被我收藏。很快就是中考。但我还是没有告诉他那句“我喜欢你”。好在那个夏天里我收到了和他一样的录取通知书，那时候我以为我们还有机会常见面，可是没有。

高中学业繁忙，我在物理小球和磁场中晕头转向，在自卑的漩涡里原地打转。月考的成绩栏里他在前五十，而我却在四五百名徘徊。我依旧和初中一样，偷偷在每天的早操、放学的人群中寻找着他，却再没主动走上前和他说过一句话。两年，又过去了，直到高三，我才在一次聊天中第一次向我的好朋友聊起他，聊起日记本里描述过的一个个细小的有关他的瞬间。

这也许是因为我自己也清楚地知道能再见他的时日所剩无多了吧。“去告白吧，你很好看，又有才华，这么好，没必要自卑的！”（好朋友这么说我是因为我当时写的诗和写的小说获得了很多人的肯定，其它的是因为有滤镜存在哈哈哈哈。）犹犹豫豫，最后带着好朋友一起走到他的班级门口，可心跳得太厉害，说话也开始结巴，于是落荒而逃，躲在走廊拐角，扔给好朋友一封信，托她交给他。她以为那信里写的是告白，其实只有“好久不见”和“高考顺利”以及祝他“万事胜意”。其实，在那个时候，我就已经在和他告别了吧。你们是不是以为故事就在这里结束了啊，又或者有了一个大反转类似他也暗恋我或者我告白了最后在一起了啊哈哈哈哈哈，没有，都没有。

我自己为这场暗恋画了一个完美的句号，但句号那个时间超搞笑，是在大一清明节假期的晚上。那天晚上，我和好朋友躺在床上看恐怖片，看完快凌晨了还是睡不着，又开始聊起了他。也许是多巴胺上头了，或者是看恐怖片看得不清醒了，没多想就编辑了一大段文字发给了Q，完成了我预谋过三番两次的告白。是我变勇敢变自信了吗，也不是，只是我明白了告白的意义。不在乎结果，只是向他说明自己蛰伏多年的心意，终于能在一个凌晨，这样一个春天的夜晚，像记忆里的香樟树一样，在春天落下枯叶，迎来新叶。那一晚我并没有做梦，我睡得很安稳。睁开眼睛打开手机，没有意外，我被拒绝了。但他的回复很温柔，他感谢我对他的喜欢，他也确实不清楚我对他的心意。我们开始聊起过去，聊起现在。他祝我也能万事胜意。这样的告白就是我能给我自己最好的结局。我很感谢他的出现，让我慢慢变得更好，但我也很心疼暗恋里的自己，那些酸楚，那些眼泪，只有自己知道。但所幸，留下了那些雀跃时光，留下了那些文字，留下了那个香樟树下躲雨的少年，留下了如今这个坚韧又敏感的我。

[^1]: Vol.217 情人节特辑：爱是最小单位的共产主义 [^2]: 58 哎呀，爱呀，比花儿还美妙

读书

• 《一本书读懂财报》
• 《东京八平米》

阅读财会书籍的起因，是近期正值财报季，我在关注一些个股，希望对公司财报有更深层次的理解。得益于本科期间修过经济类课程的交叉学科背景，读起来并不费劲。整体而言，这本书通俗易懂，书中的比喻尤为精彩：它将「资产负债表」比作企业的“照相机”，定格的是某个时点的财务状况；而将「利润表」比作企业的“摄像机”，记录的则是某个时段的经营成果。

「八平米」是作者在东京暂住地的空间尺度，也是她生活的小宇宙。八平米很小，东京却很大。在小空间与大都市的张力之间，作者记录的虽是日常琐事，却充满温度，令人感同身受。这让我想起之前读过的《一个人的小繁华》——两本书的作者都是独自在东京打拼的女性，也都擅长在平凡的生活缝隙中，寻找属于自己的小确幸。

播客

• 英伟达、Sora 与 AI 的三种核心叙事逻辑 | 对谈莫傑麟
• 我们是情绪的主人，还是奴隶？和北大脑科学博士聊聊情绪与激素

这是一期非常精彩的 AI 播客。嘉宾们从应用探索、投资创业、竞争维度等多个视角，深入探讨了 AI 2.0 时代的特点与未来。其中最令我印象深刻的是，嘉宾用「球球大作战」这款游戏来类比创业公司与巨头在该领域的竞争关系，非常形象且耐人寻味。

这期内容干货满满，探讨了「多巴胺的奖赏机制」与「成瘾行为」的本质。核心观点在于：多巴胺编码的并非简单的“快乐”，而是“预期与现实之间的差值”。听完这期播客，我终于从脑科学的角度理解了那个心理学常识——「为什么降低预期往往能获得幸福」。

看的文章

• How Far Are We From Automating Front-End Engineering
• Vue Amsterdam
• 真的不可以在 React 组件里嵌套定义子组件吗

工具

• dub
• auto-animate

距离上一次写 blog 已经过去了两个多月之久。这段时间琐事很多，终于趁假期有时间对过去两个月做过的事情做下回顾。

MyShell

MyShell 是一个 Web3 + AI 的创作平台。最近我在上面创建了两个 Bot，初衷都是为了解决现实生活中的具体需求。

第一个是美食博主 Amy的数字分身。我很喜欢在 YouTube 或 B 站看 Amy 的美食 Vlog，她的视频多以中国美食为主题。我认为通过「谈论美食与文化」来练习英语口语，是一个非常有趣的切入点。

第二个是 Zoe Chinese，这是一个利用 Pro Config 配置的中文学习工具，主要提供语法分析及 HSK 备考模拟。这个想法源于我之前加入的一个 Discord 语言交换群组，我发现群里有很多中文初学者都在为 HSK 考试而苦恼，于是便有了这个工具。

• Amy in China
• Zoe Chinese

Ton

在去年的年度总结中，我提到了一篇文章 —— 社交和加密，Telegram 的下个十年。最近的这段时间 Ton 生态开始爆发，各大媒体以及开发者们也开始关注其生态系统，一些项目也推出了适配 Ton 生态的应用 —— TMA (Telegram Mini APP)。

• awesome-telegram-mini-apps

阅读

这段时间有相当一部分时间花在面试候选人。想要打造一个高效并且充满活力的技术团队，核心就是团队成员的组成。「如何在海量的简历中找到适合团队的候选人」的确不是个简单的问题，「出的面试题是否能够考察出候选人的真实能力」，「如何控制好面试流程使得过程更加高效」都是我在面试中遇到的问题。

结合《浏览器工作原理与实践》这本小册，最近把Inside look at modern web browser这个系列的文章重新看了一遍。

• 技术面试官识人手册
• 浏览器工作原理与实践

从几个问题开始

• 用户在地址栏输入 URL 后，浏览器导航到网页的流程是怎样的
• 渲染器进程的核心工作是什么？它如何将 HTML、CSS 和 JavaScript 转化为可视网页
• 作为一名 Web 开发者，有哪些工具和实践可以帮助我优化网页性能

多进程架构

操作系统之上的操作系统

graph LR
    subgraph Chrome_Browser ["Chrome Browser"]
        direction LR
        
        subgraph Browser_Process ["Browser Process"]
            UIThread[UI Thread]
            Network[Network]
            Storage[Storage]
        end
        
        subgraph Renderer_Process ["Renderer Process"]
            MainThread[Main Thread]
            WorkerThreads[Worker Threads]
            CompositorThread[Compositor Thread]
            RasterizerThread[Rasterizer Thread]
        end
        
        subgraph GPU_Process ["GPU Process"]
            GPUThread[GPU Thread]
        end

        subgraph Plugin_Process ["Plugin Process"]
            PluginThreads[Plugin Threads]
        end

        subgraph Extension_Process ["Extension Process"]
            ExtensionThreads[Extension Threads]
        end
        
        subgraph Utility_Process ["Utility Process"]
            UtilityTasks[Various Utility Tasks]
        end
    end

各个进程的作用

浏览器进程

• 核心协调者：浏览器进程是应用程序的“指挥中心”，负责协调其他进程，处理标签页以外的所有浏览器事务。
• 用户界面 (UI) 控制：它控制浏览器应用程序的“Chrome”部分，包括地址栏、书签以及前进和后退按钮。其中的 UI 线程 负责绘制这些浏览器按钮和输入字段
• 网络请求处理：浏览器进程中的 网络线程 专门负责与网络堆栈交互，从互联网接收数据，处理 DNS 查询、建立 TLS 连接等协议，并处理服务器重定向。它还会执行 SafeBrowsing 检查以防止用户访问恶意站点，以及跨域读取阻塞 (CORB) 检查以保护敏感的跨站点数据。
• 文件和存储访问：它处理浏览器中“不可见、特权”的部分，例如文件访问，由其内部的 存储线程 负责
• 导航流程管理：从用户在地址栏输入 URL 到页面开始渲染，整个导航流程由浏览器进程协调。它会寻找或启动一个渲染器进程来渲染网页，并通过 IPC (进程间通信) 提交导航
• Service Worker 识别：当导航请求传入时，网络线程会检查请求的域名是否与已注册的 Service Worker 作用域匹配。如果匹配，UI 线程会启动一个渲染器进程来执行 Service Worker 代码
• 输入事件处理：用户手势（如触摸或鼠标点击）首先由浏览器进程接收。由于标签页内的内容由渲染器进程处理，浏览器进程会将事件类型和坐标发送给渲染器进程

渲染进程

• 网页内容显示：渲染器进程控制着标签页内显示网站内容的全部区域
• 核心渲染工作：其核心任务是将 HTML、CSS 和 JavaScript 转换为用户可以交互的网页。这包括解析 HTML 构建 DOM、解析 CSS 计算样式、执行布局以确定元素的几何形状、生成绘制记录以及将页面分层并进行合成
• 主线程：渲染器进程的主线程处理大部分发送给用户的代码，包括 HTML 解析、样式计算、布局、生成绘制记录以及 JavaScript 执行
• 工作线程：如果使用了 Web Worker 或 Service Worker，部分 JavaScript 代码会由渲染器进程中的 工作线程 处理
• 合成器线程和栅格线程：为了高效平滑地渲染页面，渲染器进程内部还运行着 合成器线程 (Compositor thread) 和 栅格线程 (Raster threads)。合成器线程负责将页面分成层，栅格线程将这些层分解成图块并栅格化存储到 GPU 内存中，合成器线程再将它们合成一个帧
• Service Worker 执行：Service Worker 是运行在渲染器进程中的 JavaScript 代码

GPU 进程

• 处理 GPU 任务：它独立于其他进程处理 GPU 任务。将其分离为单独的进程是因为 GPU 会处理来自多个应用程序的请求并在同一表面上绘制它们。最终的合成器帧会发送到 GPU 进行显示

插件进程

• 控制插件：它控制网站使用的任何插件，例如 Flash

其他进程

• 扩展进程 (Extension Process)：处理浏览器扩展程序的功能
• 实用工具进程 (Utility Processes)：处理其他各种辅助任务

多进程架构的好处

• 提高稳定性：如果一个标签页变得无响应，只会影响该标签页所在的渲染器进程，而不会导致整个浏览器崩溃或所有标签页都无响应

• 增强安全性和沙盒化：操作系统提供了限制进程权限的机制，浏览器可以对渲染器进程等处理用户输入的进程进行沙盒化，限制它们对文件等特定功能的访问，从而提高了整体安全性。站点隔离 (Site Isolation) 功能进一步增强了安全性，它为每个跨站 iframe 运行一个独立的渲染器进程，是分离站点的最有效方式

• 服务化 (Servicification)：Chrome 正在将浏览器程序的各个部分作为服务运行。在强大硬件上，每个服务可以拆分为不同的进程以提供更高的稳定性；在资源受限设备上，这些服务可以整合到一个进程中以节省内存占用

相关文章

• Inside look at modern web browser

影音

• 《无人区》
• 《他乡的童年》

因为实在提不起看新电影的兴致，索性把《无人区》又重温了一遍。依稀记得上次看这部片子，还是在大二的某个午后。黄渤饰演的鹰贩子被傻子当头一锤、瞬间「领盒饭」的那一幕，充满了宁浩标志性的黑色幽默，也是整部电影里最令我难忘的画面之一。

我很着迷于这种荒诞感，宁浩早期的《疯狂的石头》和《疯狂的赛车》也深得其味。不过，自从在电影院看完《疯狂的外星人》后，那种惊艳感似乎就断了档，我也就再没看过他的其他作品了。

《他乡的童年》则是一部探讨不同文化背景下教育理念的纪录片，导演试图去回答「什么是好的教育」。我重点看了芬兰和日本篇：芬兰教育强调平等与自由，致力于呵护孩子的创造力；而日本则更侧重集体主义和纪律性。作为一个足球迷，我不由得联想到日本足球以严丝合缝的战术执行和团队协作著称——这或许与球员们从小接受的教育有着千丝万缕的联系。

游戏

• 《星之卡比——探索发现》

一款极具想象力且易上手的游戏，双人合作模式也非常有趣，很适合闲暇时光。

APP

• Miraa
• Follow

Dev

• mindsearch
• manim
• financial assistant
• memfree
  • mdreader
  • mindmap