前言

“分库分表这种架构模式会逐步的被淘汰！” 不知道在哪儿看到的观点

如果我们现在在搭建新的业务架构，如果说你们未来的业务数据量会达到千万 或者上亿的级别 还在一股脑的使用分库分表的架构，那么你们的技术负责人真的就应该提前退休了🙈

如果对未来的业务非常有信心，单表的数据量能达到千万上亿的级别，请使用NewSQL 数据库，那么NewSQL 这么牛，分布库分表还有意义吗？

今天虽然写的是一篇博客，但是更多的是抱着和大家讨论的心态来的，所以大家目前有深度参与分库分表，或者NewSQL 的都可以在评论区讨论！

什么是NewSQL

NewSQL 是21世纪10年代初出现的一个术语，用来描述一类新型的关系型数据库管理系统（RDBMS）。它们的共同目标是：在保持传统关系型数据库（如Oracle、MySQL）的ACID事务和SQL模型优势的同时，获得与NoSQL系统类似的、弹性的水平扩展能力

NewSQL 的核心理念就是 将“分库分表”的复杂性从应用层下沉到数据库内核层，对上层应用呈现为一个单一的数据库入口，解决现在 分库分表的问题；

分库分表的问题

分库分表之后，会带来非常多的问题；比如需要跨库联查、跨库更新数据如何保证事务一致性等问题，下面就来详细看看分库分表都有那些问题

选择TiDB还是采用mysql 分库分表的设计

数据量非常大，需要满足OLTP (Online Transactional Processing)、OLAP (Online Analytical Processing)、HTAP 且预算充足（分布式数据库的成本也是非常高的这一点非常的重要），并且是新业务新架构落地 优先推荐使用TiDB。
当然实际上选择肯定是需要多方面考虑的，大家有什么观点都可以在评论区讨论。

可以看看一个资深开发，深度参与TiDB项目，他对TiDB的一些看法：

1 什么是TiDB？

TiDB是PingCAP公司研发的开源分布式关系型数据库，采用存储计算分离架构，支持混合事务分析处理（HTAP） 。它与MySQL 5.7协议兼容，并支持MySQL生态，这意味着使用MySQL的应用程序可以几乎无需修改代码就能迁移到TiDB。

🚀目标是为用户提供一站式 OLTP (Online Transactional Processing)、OLAP (Online Analytical Processing)、HTAP 解决方案。TiDB 适合高可用、强一致要求较高、数据规模较大等各种应用场景。

官方文档：docs.pingcap.com/zh/tidb/dev…

TiDB五大核心特性

TiDB之所以在分布式数据库领域脱颖而出，得益于其五大核心特性：

• 一键水平扩容或缩容：得益于存储计算分离的架构设计，可按需对计算、存储分别进行在线扩容或缩容，整个过程对应用透明。


• 金融级高可用：数据采用多副本存储，通过Multi-Raft协议同步事务日志，只有多数派写入成功事务才能提交，确保数据强一致性。


• 实时HTAP：提供行存储引擎TiKV和列存储引擎TiFlash，两者之间的数据保持强一致，解决了HTAP资源隔离问题。


• 云原生分布式数据库：通过TiDB Operator可在公有云、私有云、混合云中实现部署工具化、自动化。


• 兼容MySQL 5.7协议和生态：从MySQL迁移到TiDB无需或只需少量代码修改，极大降低了迁移成本。

2 TiDB与MySQL的核心差异

虽然TiDB兼容MySQL协议，但它们在架构设计和适用场景上存在根本差异。以下是它们的详细对比：

2.1 架构差异

表1：TiDB与MySQL架构对比

2.2 性能表现对比

性能方面，TiDB与MySQL各有优势，主要取决于数据量和查询类型：

• 小数据量简单查询：在数据量百万级以下的情况下，MySQL的写入性能和点查点写通常优于TiDB。因为TiDB的分布式架构在少量数据时无法充分发挥优势，却要承担分布式事务的开销。


• 大数据量复杂查询：当数据量达到千万级以上，TiDB的性能优势开始显现。一张千万级别表关联查询，MySQL可能需要20秒，而TiDB+TiKV只需约5.57秒，使用TiFlash甚至可缩短到0.5秒。


• 高并发场景：MySQL性能随着并发增加会达到瓶颈然后下降，而TiDB性能基本随并发增加呈线性提升，节点资源不足时还可通过动态扩容提升性能。

2.3 扩展性与高可用对比

MySQL的主要扩展方式是一主多从架构，主节点无法横向扩展（除非接受分库分表），从节点扩容需要应用支持读写分离。而TiDB的存储和计算节点都可以独立扩容，支持最大512节点，集群容量可达PB级别。

高可用方面，MySQL使用增强半同步和MGR方案，但复制效率较低，主节点故障会影响业务处理[]。TiDB则通过Raft协议将数据打散分布，单机故障对集群影响小，能保证RTO（恢复时间目标）不超过30秒且RPO（恢复点目标）为0，真正实现金融级高可用。

2.4 SQL功能及兼容性

虽然TiDB高度兼容MySQL 5.7协议和生态，但仍有一些重要差异需要注意：

不支持的功能包括：

• 存储过程与函数


• 触发器


• 事件


• 自定义函数


• 全文索引（计划中）


• 空间类型函数和索引

有差异的功能包括：

• 自增ID的行为（TiDB推荐使用AUTO_RANDOM避免热点问题）


• 查询计划的解释结果


• 在线DDL能力（TiDB更强，不锁表支持DML并行操作）

3 如何选择：TiDB还是MySQL？

选择数据库时，应基于实际业务需求和技术要求做出决策。以下是具体的选型建议：

3.1 选择TiDB的场景

TiDB在以下场景中表现卓越：

3.2 选择MySQL的场景

MySQL在以下情况下仍是更合适的选择：

3.3 决策参考框架

为了更直观地帮助决策，可以参考以下决策表：

4 迁移注意事项

如果决定从MySQL迁移到TiDB，需要注意以下关键点：

5 总结

TiDB和MySQL是适用于不同场景的数据库解决方案，没有绝对的优劣之分。MySQL是优秀的单机数据库，适用于数据量小、架构简单的场景；数据量大了之后需要做分库分表。而TiDB作为分布式数据库，专注于解决大数据量、高并发、高可用性需求下的数据库瓶颈问题，但是成本也是非常的高

本人没有使用过NewSQL ，还望各位大佬批评指正

众所周知，新生代的ui框架(如：kotlin，swift，flutter，鸿蒙）都已经抛弃了XML这类的结构化数据标记语言改为使用声明式UI

只有web端还没有支持此类ui语法，此次我开发的ovsjs为前端也带来了此类声明式UI语法的支持，语法如下

项目地址

github.com/alamhubb/ov…

语法插件地址：

marketplace.visualstudio.com/items?itemN…

新语法如下：

我认为更强的地方是我的新设计除了为前端带来了声明式UI，还支持了 #{ } 不渲染代码块的设计，支持在 声明式UI中编写代码，这样UI和逻辑之间的距离更近，维护更方便，抽象组件也更容易

对比kotlin，swift，flutter，鸿蒙语法如下：

kotlin的语法

import kotlinx.browser.*

import kotlinx.html.*

import kotlinx.html.dom.*



fun main() {

    document.body!!.append.div {

        h1 {

            +"Welcome to Kotlin/JS!"

        }

        p {

            +"Fancy joining this year's "

            a("https://kotlinconf.com/") {

                +"KotlinConf"

            }

            +"?"

        }

    }

}

swiftUI的语法

import SwiftUI



struct ContentView: View {

    var body: some View {

        VStack(spacing: 16) {

            Text("Hello SwiftUI")

                .font(.largeTitle)

                .fontWeight(.bold)



            Text("Welcome to SwiftUI world")



            Button("Click Me") {

                print("Button clicked")

            }

        }

        .padding()

    }

}

flutter的语法

class MyApp extends StatelessWidget {

  const MyApp({super.key});



  @override

  Widget build(BuildContext context) {

    return MaterialApp(

      home: Scaffold(

        body: Center(

          child: Column(

            mainAxisSize: MainAxisSize.min,

            children: [

              const Text(

                "Hello Flutter",

                style: TextStyle(fontSize: 28, fontWeight: FontWeight.bold),

              ),

              const SizedBox(height: 12),

              const Text("Welcome to Flutter world"),

              const SizedBox(height: 16),

              ElevatedButton(

                onPressed: () {

                  print("Button clicked");

                },

                child: const Text("Click Me"),

              )

            ],

          ),

        ),

      ),

    );

  }

}

鸿蒙 arkts

@Entry

@Component

struct Index {

  @State message: string = 'Hello ArkUI'



  build() {

    Column() {

      Text(this.message)

        .fontSize(28)

        .fontWeight(FontWeight.Bold)



      Text('Welcome to HarmonyOS')

        .margin({ top: 12 })



      Button('Click Me')

        .margin({ top: 16 })

        .onClick(() => {

          console.log('Button clicked')

        })

    }

    .padding(20)

  }

}

原理实现

简述一下实现原理，就是通过parser支持了新语法，然后将新语法转义为 iife包裹的vue的h函数

为什么要iife包裹

因为要支持不渲染代码块

ovs图中的代码对应的编译后的代码是这样的

import {defineOvsComponent} from "/@fs/D:/project/qkyproject/test-volar/ovs/ovs-runtime/src/index.ts";

import {$OvsHtmlTag} from "/@fs/D:/project/qkyproject/test-volar/ovs/ovs-runtime/src/index.ts";

import {ref} from "/node_modules/.vite/deps/vue.js?v=76ca4127";

export default defineOvsComponent(props => {

  const msg = "You did it!";

  let count = ref(0);

  const timer = setInterval(() => {

    count.value = count.value + 1;

  },1000);

  return $OvsHtmlTag.div({class:'greetings',onClick(){

    count.value = 0;

  }},[

    $OvsHtmlTag.h1({class:'green'},[msg]),

    count,

    $OvsHtmlTag.h3({},[

      "You've successfully created a project with ",

      $OvsHtmlTag.a({href:'https://vite.dev/',target:'_blank',rel:'noopener'},['Vite']),

      ' + ',

      $OvsHtmlTag.a({href:'https://vuejs.org/',target:'_blank',rel:'noopener'},['Vue 3']),

      ' + ',

      $OvsHtmlTag.a({href:'https://github.com/alamhubb/ovsjs',target:'_blank',rel:'noopener'},['OVS']),

      '.'

    ])

  ]);

});

parser是我自己写的，抄了 chevortain 的设计，写了个subhuti，支持定义peg语法

github.com/alamhubb/ov…

slimeparser，支持es2025语法的parser，基于subhuti，声明es2025语法就行

github.com/alamhubb/ov…

然后就是ovs继承slimeparser，添加了ovs的语法支持，并且在ast生成的时候将代码转为vue的渲染函数，运行时就是运行的vue的渲染函数的代码，所以完美支持vue的生态

感兴趣的可以试试，入门教程

github.com/alamhubb/ov…

由于本人能力有先，文中存在错误不足之处，请大家指正，有对新语法感兴趣的欢迎留言和我交流

你有没有经历过这样的场景？点击“上传头像”，选了一张照片，页面却毫无反应——没有提示，没有图像，只有一个静默的按钮。你开始怀疑：是没选上？网速慢？还是系统出错了？于是你犹豫要不要再点一次，甚至直接关掉页面。

而如果在你选择文件的瞬间，一张清晰的缩略图立刻出现在眼前，哪怕后端还在处理，你也会安心地等待下去。

不是用户没耐心，而是他们需要一点“确定性”来支撑等待的理由。

图片预览，正是那个微小却关键的信号：你的操作已被接收，一切正在按预期进行。

得到程序正在运行的信号之后用户才会有等待的欲望。

今天，我们就来亲手实现一个图片预览功能。
先思考：要让一张用户选中的本地图片显示在网页上，我们到底需要做些什么？

第一步：我们要显示图片，那肯定得有个 <img> 标签吧？

没错。想在页面上看到图片，最直接的方式就是用 <img :src="xxx" />。但问题来了：用户刚从电脑里选了一张照片，这张照片还在他本地硬盘上，还没传到服务器，也没有公开 URL。那 src 该填什么？

这时候你可能会想：“能不能把这张本地文件直接塞进 src？”

答案是：不能直接塞 File 对象，但——我们可以把它“变成”一个 URL。

第二步：用户选了图，我们怎么拿到它？

通常我们会用 <input type="file" accept="image/*"> 让用户选择图片。在 Vue 中，为了能“拿到”这个 input 元素本身（而不仅仅是它的值），我们会用到 ref。

<input 

  type="file" 

  ref="uploadImage" 

  accept="image/*"

  @change="updateImageData"

/>

这里，ref="uploadImage" 就像给这个 input 贴了个标签。之后在 script 里，我们就能通过 uploadImage.value 拿到它的真实 DOM 引用。

于是，在 updateImageData 函数里，我们可以这样取到用户选中的文件：

const input = uploadImage.value;

const file = input.files[0]; // 用户选的第一张图

注意：不是 input.file，而是 input.files —— 这是一个常见的笔误，也是很多初学者卡住的地方。

第三步：有了 File 对象，怎么变成 <img> 能识别的 src？

现在我们手里有一个 File 对象，但它不能直接赋给 img.src。我们需要把它转成一种浏览器能直接渲染的格式。

这时候，FileReader 就登场了。

const reader = new FileReader();

reader.readAsDataURL(file);

readAsDataURL 会把文件内容读取为一个 Data URL，格式类似：

data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAA...

这串字符串可以直接作为 <img> 的 src！是不是很巧妙？

那什么时候能拿到这个结果呢？FileReader 是异步的，所以我们监听它的 onloadend 事件：

reader.onloadend = (e) => {

  imgPreview.value = e.target.result; // 这就是 Data URL

}

而我们的模板中早已准备好了一个 <img>：

<img :src="imgPreview" alt="" v-if="imgPreview" />

当 imgPreview 有值时，图片就自动显示出来了！

完整逻辑串起来

把这些碎片拼在一起，整个流程就清晰了：

这整个过程完全在前端完成，不需要上传到服务器，也不依赖任何第三方库——只用了浏览器原生 API 和 Vue 的响应式系统。

最后：完整实例

在vue中实现图片预览的完整代码及效果

1. 引言：设计系统的“寒武纪大爆发”与 Arco 的陨落

在 2019 年至 2021 年间，中国前端开发领域经历了一场前所未有的“设计系统”爆发期。伴随着企业级 SaaS 市场的崛起和中后台业务的复杂度攀升，各大互联网巨头纷纷推出了自研的 UI 组件库。这不仅是技术实力的展示，更是企业工程化标准的话语权争夺。在这一背景下，字节跳动推出了 Arco Design，这是一套旨在挑战 Ant Design 霸主地位的“双栈”（React & Vue）企业级设计系统。

Arco Design 在发布之初，凭借其现代化的视觉语言、对 TypeScript 的原生支持以及极具创新性的“Design Lab”设计令牌（Design Token）管理系统，迅速吸引了大量开发者的关注。它被定位为不仅仅是一个组件库，而是一套涵盖设计、开发、工具链的完整解决方案。然而，就在其社区声量达到顶峰后的短短两年内，这一曾被视为“下一代标准”的项目却陷入了令人费解的沉寂。

截至 2025 年末，GitHub 上的 Issue 堆积如山，关键的基础设施服务（如 IconBox 图标平台）频繁宕机，官方团队的维护活动几乎归零。对于数以万计采用了 Arco Design 的企业和独立开发者而言，这无疑是一场技术选型的灾难。

本文将深入剖析 Arco Design 从辉煌到停摆的全过程。我们将剥开代码的表层，深入字节跳动的组织架构变革、内部团队的博弈（赛马机制）、以及中国互联网大厂特有的“KPI 开源”文化，为您还原整件事情的全貌。

2. 溯源：Arco Design 的诞生背景与技术野心

要理解 Arco Design 为何走向衰败，首先必须理解它诞生时的宏大野心及其背后的组织推手。Arco 并不仅仅是一个简单的 UI 库，它是字节跳动为了解决特定业务线极其复杂的后台需求而孵化的产物。

2.1 “务实的浪漫主义”：差异化的产品定位

Arco Design 在推出时，鲜明地提出了“务实的浪漫主义”这一设计哲学。这一口号的提出，实际上是为了在市场上与阿里巴巴的 Ant Design 进行差异化竞争。

• Ant Design 的困境：作为行业标准，Ant Design 以“确定性”著称，其风格克制、理性，甚至略显单调。虽然极其适合金融和后台管理系统，但在需要更强品牌表达力和 C 端体验感的场景下显得力不从心。


• Arco 的切入点：字节跳动的产品基因（如抖音、TikTok）强调视觉冲击力和用户体验的流畅性。Arco 试图在中后台系统中注入这种基因，主张在解决业务问题（务实）的同时，允许设计师发挥更多的想象力（浪漫）。

这种定位在技术层面体现为对 主题定制（Theming） 的极致追求。Arco Design 并没有像传统库那样仅仅提供几个 Less 变量，而是构建了一个庞大的“Design Lab”平台，允许用户在网页端通过可视化界面细粒度地调整成千上万个 Design Token，并一键生成代码。这种“设计即代码”的早期尝试，是 Arco 最核心的竞争力之一。

2.2 组织架构：GIP UED 与架构前端的联姻

Arco Design 的官方介绍中明确指出，该系统是由 字节跳动 GIP UED 团队 和 架构前端团队（Infrastructure FrontEnd Team） 联合推出的。这一血统注定了它的命运与“GIP”这个业务单元的兴衰紧密绑定。

2.2.1 解密 GIP：通用信息平台 (General Information Platform)

GIP 全称为 General Information Platform（通用信息平台）。这是字节跳动早期的核心业务支柱，主要包含以下以“图文与中长视频”为核心的信息分发产品：

• 今日头条：字节跳动的起家之作，智能推荐资讯平台。


• 西瓜视频：中长视频平台。


• 番茄小说：免费网文阅读平台。

2.2.2 业务对技术的反哺与制约

GIP 的业务特点是高信息密度。今日头条的内容审核后台、广告投放系统（早期巨量引擎）、创作者管理平台（头条号后台）都需要处理海量的文本数据和复杂的表格操作。因此，Arco Design 从诞生起就带有浓重的“B 端中后台”基因，强调紧凑、理性和高效率，这正是为了服务于 GIP 庞大的内部系统需求。

在 2019-2020 年，GIP 仍是公司的绝对核心与营收主力。Arco Design 的推出，实际上是字节跳动“长子”（头条系）试图确立公司内部技术标准的一次有力尝试。

2.3 黄金时代的技术堆栈

在 2021 年左右，Arco Design 的技术选型是极具前瞻性的，这也是它能迅速获得 5.5k Star 的原因之一：

• 全链路 TypeScript：所有组件均采用 TypeScript 编写，提供了优秀的类型推导体验，解决了当时 Ant Design v4 在某些复杂场景下类型定义不友好的痛点。


• 双框架并进：@arco-design/web-react 和 @arco-design/web-vue 保持了高度统一的 API 设计和视觉风格。这对于那些技术栈不统一的大型公司极具吸引力，意味着设计规范可以跨框架复用。


• 生态闭环：除了组件库，Arco 还发布了 arco-cli（脚手架）、Arco Pro（中后台模板）、IconBox（图标管理平台）以及 Material Market（物料市场）。这表明团队不仅是在做一个库，而是在构建一个类似 Salesforce Lightning 或 SAP Fiori 的企业级生态。

然而，正是这种庞大的生态铺设，为日后的维护埋下了巨大的隐患。当背后的组织架构发生震荡时，维持如此庞大的产品矩阵所需的资源将变得不可持续。

3. 停摆的证据：基于数据与现象的法医式分析

尽管字节跳动从未发布过一份正式的“Arco Design 停止维护声明”，但通过对代码仓库、社区反馈以及基础设施状态的深入分析，我们可以断定该项目已进入实质性的“脑死亡”状态。

3.1 代码仓库的“心跳停止”

对 GitHub 仓库 arco-design/arco-design (React) 和 arco-design/arco-design-vue (Vue) 的提交记录分析显示，活跃度在 2023 年底至 2024 年初出现了断崖式下跌。

3.1.1 提交频率分析

虽然 React 版本的最新 Release 版本号为 2.66.8（截至文章撰写时），但这更多是惯性维护。

• 核心贡献者的离场：早期的高频贡献者（如 sHow8e、jadelike-wine 等）在 2024 年后的活跃度显著降低。许多提交变成了依赖项升级（Dependabot）或极其微小的文档修复，缺乏实质性的功能迭代。


• Vue 版本的停滞：Vue 版本的状态更为糟糕。最近的提交多集中在构建工具迁移（如迁移到 pnpm）或很久以前的 Bug 修复。核心组件的 Feature Request 长期无人响应。

3.1.2 积重难返的 Issue 列表

Issue 面板是衡量开源项目生命力的体温计。目前，Arco Design 仓库中积累了超过 330 个 Open Issue。

• 严重的 Bug 无人修复：例如 Issue #3091 “tree-select 组件在虚拟列表状态下搜索无法选中最后一个” 和 Issue #3089 “table 组件的 default-expand-all-rows 属性设置不生效”。这些都是影响生产环境使用的核心组件 Bug，却长期处于 Open 状态。


• 社区的绝望呐喊：Issue #3090 直接以 “又一个没人维护的 UI 库” 为题，表达了社区用户的愤怒与失望。更有用户在 Discussion 中直言 “这个是不是 KPI 项目啊，现在维护更新好像都越来越少了”。这种负面情绪的蔓延，通常是一个项目走向终结的社会学信号。

3.2 基础设施的崩塌：IconBox 事件

如果说代码更新变慢还可以解释为“功能稳定”，那么基础设施的故障则是项目被放弃的直接证据。

• IconBox 无法发布：Issue #3092 指出 “IconBox 无法发布包了”。IconBox 是 Arco 生态中用于管理和分发自定义图标的 SaaS 服务。这类服务需要后端服务器、数据库以及运维支持。


• 含义解读：当一个大厂开源项目的配套 SaaS 服务出现故障且无人修复时，这不仅仅是开发人员没时间的问题，而是意味着服务器的预算可能已经被切断，或者负责运维该服务的团队（GIP 相关的基建团队）已经被解散。这是项目“断供”的最强物理证据。

3.3 文档站点的维护降级

Arco Design 的文档站点虽然目前仍可访问，但其内容更新已经明显滞后。例如，关于 React 18/19 的并发特性支持、最新的 SSR 实践指南等现代前端话题，在文档中鲜有提及。与竞争对手 Ant Design 紧跟 React 官方版本发布的节奏相比，Arco 的文档显得停留在 2022 年的时光胶囊中。

4. 深层归因：组织架构变革下的牺牲品

Arco Design 的陨落，本质上不是技术失败，而是组织架构变革的牺牲品。要理解这一点，我们需要将视线从 GitHub 移向字节跳动的办公大楼，审视这家巨头在过去三年中发生的剧烈动荡。

4.1 战略重心的转移：从“头条”到“抖音”

2021 年底至 2024 年，字节跳动进行了多次大规模的组织架构调整。其中最关键的变化是战略重心从图文资讯（今日头条）全面转向短视频与直播（抖音/TikTok）以及后来的 AI 大模型。

• GIP 的边缘化：随着移动互联网进入存量时代，今日头条和西瓜视频的用户增长见顶，战略地位从“增长引擎”退化为“现金牛”甚至“存量维持”业务。


• 资源的抽离：GIP UED 和相关前端团队面临缩编或重组。维护 Arco Design 这样一套庞大的开源系统需要持续的人力投入。当母体部门本身都在进行“去肥增瘦”时，一个无法直接带来商业增量的开源 KPI 项目，自然成为了裁员的首选目标。

4.2 内部赛马机制：Arco Design vs. Semi Design

字节跳动素以“APP 工厂”和“内部赛马”文化著称。这种文化不仅存在于 C 端产品中，也渗透到了技术基建领域。Arco Design 的停摆，很大程度上是因为它在与内部竞争对手 Semi Design 的博弈中败下阵来。

4.2.1 Semi Design 的崛起

Semi Design 是由 抖音前端团队 与 MED 产品设计团队 联合推出的设计系统。

• 出身显赫：与 GIP 不同，Semi Design 背靠的是字节跳动的绝对核心——抖音。抖音前端团队拥有极其充裕的资源和稳固的业务地位。


• 技术路线之争：Semi Design 在架构上更为先进，采用了 Foundation/Adapter 模式，实现了逻辑与渲染分离，能以更低的成本适配不同框架。同时，Semi 深度集成了 D2C（Design-to-Code）工具链，更符合公司对 AI 和人效的追求。

4.2.2 为什么 Arco 输了？

在资源整合期，公司高层显然不需要维护两套功能高度重叠的企业级 UI 库。

• 业务绑定：Semi Design 宣称服务了内部 10 万+ 用户和近千个平台产品，深度嵌入在抖音的内容生产与运营流中。


• 结局：随着 GIP 业务权重的下降和团队的调整，Arco Design 失去了维护的资源，而 Semi Design 成为了事实上的内部标准。

4.3 中国大厂的“KPI 开源”陷阱

Arco Design 的命运也折射出中国互联网大厂普遍存在的“KPI 开源”现象。

• 晋升阶梯：在阿里的 P7/P8 或字节的 2-2/3-1 晋升答辩中，主导一个“行业领先”的开源项目是极具说服力的业绩。因此，很多工程师或团队 Leader 会发起此类项目，投入巨大资源进行推广（刷 Star、做精美官网）。


• 晋升后的遗弃：一旦发起人成功晋升、转岗或离职，该项目的“剩余价值”就被榨干了。接手的新人往往不愿意维护“前人的功劳簿”，更愿意另起炉灶做一个新的项目来证明自己。


• Arco 的轨迹：Arco 的高调发布（2021年）恰逢互联网泡沫顶峰。随着 2022-2024 年行业进入寒冬，晋升通道收窄，维护开源项目的 ROI（投入产出比）变得极低，导致项目被遗弃。

5. 社区自救的幻象：为何没有强有力的 Fork？

面对官方的停摆，用户自然会问：既然代码是开源的（MIT 协议），为什么没有人 Fork 出来继续维护？调查显示，虽然存在一些零星的 Fork，但并未形成气候。

5.1 Fork 的现状调查

通过对 GitHub 和 Gitee 的检索，我们发现了一些 Fork 版本，但并未找到具备生产力的社区继任者。

• vrx-arco：这是一个名为 vrx-arco/arco-design-pro 的仓库，声称是 "aro-design-vue 的部分功能扩展"。然而，这更像是一个补丁集，而不是一个完整的 Fork。它主要解决特定开发者的个人需求，缺乏长期维护的路线图。


• imoty_studio/arco-design-designer：这是一个基于 Arco 的表单设计器，并非组件库本身的 Fork。


• 被动 Fork：GitHub 显示 Arco Design 有 713 个 Fork。经抽样检查，绝大多数是开发者为了阅读源码或修复单一 Bug 而进行的“快照式 Fork”，并没有持续的代码提交。

5.2 为什么难以 Fork？

维护一个像 Arco Design 这样的大型组件库，其门槛远超普通开发者的想象。

因此，社区更倾向于迁移，而不是接盘。

6. 用户生存指南：现状评估与迁移策略

对于目前仍在使用 Arco Design 的团队，局势十分严峻。随着 React 19 的临近和 Vue 3 生态的演进，Arco 将面临越来越多的兼容性问题。

6.1 风险评估表

6.2 迁移路径推荐

方案 A：迁移至 Semi Design（推荐指数：⭐⭐⭐⭐）

如果你是因为喜欢字节系的设计风格而选择 Arco，那么 Semi Design 是最自然的替代者。

• 优势：同为字节出品，设计语言的命名规范和逻辑有相似之处。Semi 目前维护活跃，背靠抖音，拥有强大的 D2C 工具链。


• 劣势：API 并非 100% 兼容，仍需重构大量代码。且 Semi 主要是 React 优先，Vue 生态支持相对较弱（主要靠社区适配）。

方案 B：迁移至 Ant Design v5/v6（推荐指数：⭐⭐⭐⭐⭐）

如果你追求极致的稳定和长期的维护保障，Ant Design 是不二之选。

• 优势：行业标准，庞大的社区，Ant Gr0up 背书。v5 版本引入了 CSS-in-JS，在定制能力上已经大幅追赶 Arco 的 Design Lab。


• 劣势：设计风格偏保守，需要设计师重新调整 UI 规范。

方案 C：本地魔改（推荐指数：⭐）

如果项目庞大无法迁移，唯一的出路是将 @arco-design/web-react 源码下载到本地 packages 目录，作为私有组件库维护。

• 策略：放弃官方更新，仅修复阻塞性 Bug。这需要团队内有资深的前端架构师能够理解 Arco 的源码。

7. 结语与启示

Arco Design 的故事是现代软件工程史上的一个典型悲剧。它证明了在企业级开源领域，康威定律（Conway's Law） 依然是铁律——软件的架构和命运取决于开发它的组织架构。

当 GIP 部门意气风发时，Arco 是那颗最耀眼的星，承载着“务实浪漫主义”的理想；当组织收缩、业务调整时，它便成了由于缺乏商业造血能力而被迅速遗弃的资产。对于技术决策者而言，Arco Design 的教训是惨痛的：在进行技术选型时，不能仅看 README 上的 Star 数或官网的精美程度，更要审视项目背后的组织生命力和维护动机。

目前来看，Arco Design 并没有复活的迹象，社区也没有出现强有力的接棒者。这套组件库正在数字化浪潮的沙滩上，慢慢风化成一座无人问津的丰碑。

你有没有在写前端的时候，突然迷糊了：

• 为啥这张图片能直接 src="https://xxx.jpg" 就能展示？


• 为啥有时候图片是乱七八糟的一串 Base64？


• 有的还整出来个 Blob，看不懂但好像很高级？


• 有时还来个 ArrayBuffer，这又是哪位大哥？


• 最离谱的是：我本地图片路径写进去，怎么就不生效？

这些，其实都和“图像在前端的存在形式”有关。今天咱们就像唠家常一样，一口气整明白这几个常见的前端图像形式，用最接地气的方式讲明白，配上实例、场景分析，帮你彻底建立系统认知！

一、网络 URL：最熟悉的那张脸

<img src="https://example.com/image.jpg" />

这就是我们最常见的方式：网络地址。

📦 本质上是啥？

一个 HTTP(S) 请求，浏览器去服务器上拉图片回来。

👍 优点：

• 用起来最简单，能连网就能显示


• 浏览器会缓存，提高加载效率


• 图片不占你的 HTML 或 JS 文件大小

👎 缺点：

• 依赖网络，断网就 GG


• 跨域可能出问题（特别是 canvas 想处理图片时）


• 没法离线用

🧩 常见场景：

• 图床、CDN 图片


• 用户头像、商品封面等动态内容

二、本地 URL（相对路径）：常被坑的老兄

<img src="./images/logo.png" />

听起来像本地文件，实际上也是被打包进项目的资源文件路径。

⚙️ 本质上是啥？

开发时是相对路径，生产环境通常会被 Webpack、Vite 等构建工具“处理成”一个真实可访问的路径，比如 dist/assets/logo.abcd1234.png。

👀 你可能踩过的坑：

• 路径写错，或者构建工具没配置资源处理，图片加载失败


• 静态服务器没开，直接打开 HTML 无法访问文件（浏览器出于安全考虑禁止 file 协议访问）

💡 使用建议：

• 放到 public 目录，或者使用 import 静态资源方式处理


• 建议使用构建工具配置 alias 简化路径

三、Base64：字节转码“图片串”

<img src="data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAA..." />

这是把图片数据编码成 Base64 的字符串，直接塞进 HTML 或 JS 文件里。

🔬 本质上是啥？

Base64 是一种将二进制数据编码成 ASCII 字符串的方式。

✅ 优点：

• 免请求！嵌入式图片，一起打包进页面


• 没有跨域问题


• 非常适合小图标、loading 动画、SVG

❌ 缺点：

• 体积暴涨，大概比原图多 33%


• 可读性差，不利于维护


• 页面初始加载变慢

🧩 常见场景：

• CSS background-image


• 富文本编辑器中的粘贴图像


• 邮件嵌入图像

四、Blob：文件对象，前端造图必备

const blob = new Blob([arrayBuffer], { type: 'image/png' });

const url = URL.createObjectURL(blob);

img.src = url;

这是处理文件流时常见的一种格式。

🔍 本质上是啥？

Blob 是浏览器提供的一种二进制大对象，可以把它看作 JS 里的“文件”。

💪 优点：

• 可由 JS 动态生成，支持下载、预览、上传


• 可控制 MIME 类型，灵活性强


• 可以通过 URL.createObjectURL() 生成临时地址

📉 缺点：

• 是内存对象，页面刷新就没了


• 不能跨页面共享（临时的）

🧩 常见场景：

• 前端截图（canvas.toBlob()）


• 文件上传预览


• 后台生成图片后前端下载

五、ArrayBuffer / Uint8Array：最低层的图像数据表示

fetch('image.jpg')

  .then(res => res.arrayBuffer())

  .then(buffer => {

    // 可以转为 blob 或 base64 再显示

  });

这是最底层的图像数据，直接以字节数组的形式存在。

🧠 本质上是啥？

ArrayBuffer 是一段原始的内存区域，常用于处理二进制数据，Uint8Array 是对它的视图（读取用）。

🧰 常见用途：

• 图像处理（比如 AI 模型的图片输入）


• 自定义图片加载器（如通过 WASM 解码）


• 二进制传输协议

🔄 转换方式：

• 转为 Blob：new Blob([buffer])


• 转为 Base64：btoa(String.fromCharCode(...new Uint8Array(buffer)))

🔄 图像形式转换总结表格

🧠 最后的总结：选哪种图像形式？

• ✅ 展示外部图 → 用 URL


• ✅ 项目图标/静态资源 → 本地路径


• ✅ 上传/预览/截图 → Blob


• ✅ 处理图像数据 → ArrayBuffer


• ✅ 小图或嵌入内容 → Base64

掌握这些图像“存在形式”，不仅能帮你写出更高效、稳定的代码，更能在项目中灵活切换，游刃有余！

如果你觉得这篇有点帮助，别忘了点个赞或者收藏一下～

0. 先抛结论，再吵不迟

结论：

• 极致性能/SSG/Edge → fetch 已足够；


• 企业级、需要全局拦截、上传进度 → Axios 仍值得；


• 二者可共存：核心链路与首页用 fetch，管理后台用 Axios。

1. 3 kB 到底贵不贵？

2026 年 1 月，HTTP Archive 最新采样（Chrome 桌面版）显示：

• 中位 JS 体积 580 kB，3 kB 似乎“九牛一毛”；


• 但放到首屏预算 100 kB 的站点（TikTok 推荐值），3 kB ≈ 3 % 预算，再加 120 ms 阻塞，LCP 直接从 1.5 s 飙到 1.62 s，SEO 评级掉一档。

“ bundle 每 +1 kB，4G 下 FCP +8 ms”——Lighthouse 2025 白皮书。

2. 把代码拍桌上：差异只剩这几行

下面 4 个高频场景，全部给出“可直接复制跑”的片段，差异一目了然。

2.1 自动 JSON + 错误码

// Axios：零样板

const {data} = await axios.post('/api/login', {user, pwd});



// fetch：两行样板

const res = await fetch('/api/login', {

  method:'POST',

  headers:{'Content-Type':'application/json'},

  body:JSON.stringify({user, pwd})

});

if (!res.ok) throw new Error(res.status);

const data = await res.json();

争议：

• Axios 党：少写两行，全年少写 3000 行。


• fetch 党：gzip 后 3 kB 换两行？ESLint 模板一把就补全。

2.2 超时 + 取消

// Axios：内置

const source = axios.CancelToken.source();

setTimeout(() => source.cancel('timeout'), 5000);

await axios.get('/api/big', {cancelToken: source.token});



// fetch：原生 AbortController

const ctl = new AbortController();

setTimeout(() => ctl.abort(), 5000);

await fetch('/api/big', {signal: ctl.signal});

2025 之后 Edge/Node 22 已全支持，AbortSignal.timeout(5000) 一行搞定：

await fetch('/api/big', {signal: AbortSignal.timeout(5000)});

结论：语法差距已抹平。

2.3 上传进度条

// Axios：progress 事件

await axios.post('/upload', form, {

  onUploadProgress: e => setProgress(e.loaded / e.total)

});



// fetch：借助 `xhr` 或 `ReadableStream`

// 2026 仍无原生简易方案，需要封装 `xhr` 才能拿到 `progress`。

结论：大文件上传场景 Axios 仍吊打 fetch。

2.4 拦截器（token、日志）

// Axios：全局拦截

axios.interceptors.request.use(cfg => {

  cfg.headers.Authorization = `Bearer ${getToken()}`;

  return cfg;

});



// fetch：三行封装

export const $get = (url, opts = {}) => fetch(url, {

  ...opts,

  headers: {...opts.headers, Authorization: `Bearer ${getToken()}`}

});

经验：拦截器一旦>2 个，Axios 顺序地狱频发；fetch 手动链式更直观。

3. 实测！同一个项目，两套 bundle

测试场景

• React 18 + Vite 5，仅替换 HTTP 层；


• 构建目标：es2020 + gzip + brotli；


• 网络：模拟 4G（RTT 150 ms）;


• 采样 10 次取中位。

数据来自 rebrowser 2025 基准 ；阻塞时间差异与 51CTO 独立测试吻合 。

4. 什么时候一定要 Axios？

5. 共存方案：把 3 kB 花在刀刃上

// core/http.js

export const isSSR = typeof window === 'undefined';

export const HTTP = isSSR || navigator.connection?.effectiveType === '4g'

  ? { get: (u,o) => fetch(u,{...o, signal: AbortSignal.timeout(5000)}) }

  : await import('axios');   // 动态 import，只在非 4G 或管理后台加载

结果：

• 首屏 0 kB；


• 管理后台仍享受 Axios 拦截器；


• 整体 bundle 下降 7 %，LCP −120 ms。

6. 一句话收尸

2026 年的浏览器，fetch 已把“缺的课”补完：取消、超时、Node 原生、TypeScript 完美。

3 kB 的 Axios 不再是“默认”，而是“按需”。

上传进度、深链拦截、老浏览器——用 Axios；

其余场景，让首页飞一把，把 120 ms 还给用户。

在写前端的时候，我们实现的比较多的一些基础交互，比如折叠面板、弹窗、输入提示、进度条或颜色选择等等，会不得不引入 JavaScript。

但其实，HTML 自己也内置了不少功能强大的原生标签，它们开箱即用、语义清晰，还能大幅减少 JS 的代码量。

下面介绍 5 个冷门但实用的 HTML 标签。

1. <details> 和 <summary> - 可折叠内容

替代： 手风琴效果、折叠面板、FAQ部分

<details>

  <summary>点击查看详情</summary>

  <p>隐藏的内容，无需JS实现展开/收起</p>

</details>

实现效果：

使用场景

• FAQ 折叠面板


• 设置项分组展开


• 移动端“查看更多”区域

注意事项

• 默认是关闭状态；添加 open 属性可默认展开：<details open>


• 可通过 CSS 的 details[open] 选择器定制展开样式


• 支持键盘操作（Enter/Space 触发），无障碍友好

2. <dialog> - 原生对话框

替代：div模拟模态框 + 背景遮罩 + 关闭逻辑

<dialog id="modal">

  <p>这是原生弹窗</p>

  <button onclick="document.getElementById('modal').close()">关闭</button>

</dialog>

<button onclick="document.getElementById('modal').showModal()">打开弹窗</button>

实现效果：

使用场景

• 确认提示框


• 登录/注册弹窗


• 临时信息展示

注意事项

• .showModal() 会自动创建半透明遮罩（可通过 ::backdrop 自定义）


• .show() 是非模态显示（不锁定背景）


• 聚焦自动管理：打开时聚焦第一个可聚焦元素，关闭后焦点返回触发按钮


• 兼容性：Chrome/Firefox/Edge 支持良好；Safari 15.4+ 支持；IE 不支持

3. <datalist> - 输入建议列表

替代：监听input事件 + 动态生成下拉列表

<input list="browsers" placeholder="选择或输入浏览器">

<datalist id="browsers">

  <option value="Chrome">

  <option value="Firefox">

  <option value="Safari">

</datalist>

实现效果：

使用场景

• 搜索建议（非强制选项）


• 表单字段预填（如城市、产品名）


• 快速输入辅助

注意事项

• 用户仍可输入不在列表中的值（与 <select> 不同）


• 浏览器会自动根据输入过滤匹配项


• 移动端会调出带建议的软键盘（部分浏览器支持）

4. <meter> & <progress> - 进度指示器

替代：div模拟进度条 + JS更新宽度

<!-- 已知范围内的标量值（如磁盘使用率） -->

<meter min="0" max="100" value="70">70%</meter>



<!-- 任务完成进度（如文件上传） -->

<progress value="50" max="100">50%</progress>

实现效果：

使用场景

• 搜索建议（非强制选项）


• 表单字段预填（如城市、产品名）


• 快速输入辅助

注意事项

• 用户仍可输入不在列表中的值（与 <select> 不同）


• 浏览器会自动根据输入过滤匹配项


• 移动端会调出带建议的软键盘（部分浏览器支持）

5. <input type="color"> - 颜色选择器

替代：自定义颜色选择器UI + 色值转换逻辑

<input type="color" value="#ff0000">

实现效果：

使用场景

• 主题配色设置


• 图表颜色配置


• 设计工具中的拾色功能

注意事项

• 返回值始终为 小写 7 位十六进制（如 #ff5733）


• 移动端会调出系统级颜色选择器


• 无法自定义 UI，但可通过 ::-webkit-color-swatch 微调样式（有限）

总结

• <details> / <summary>：实现折叠内容


• <dialog>：原生弹窗，自带遮罩和焦点管理


• <datalist>：输入建议选择


• <meter> / <progress>：进度展示无需手动计算宽度


• <input type="color">：系统级颜色选择器开箱即用

这些原生 HTML 标签虽然不太起眼，但用好它们，不仅能省去大量 JavaScript 逻辑，还能让页面更语义化、更友好。

本文首发于公众号：程序员大华，专注分享前后端开发的实战笔记。关注我，少走弯路，一起进步！

在前端开发中，“生成唯一 ID” 是高频需求 —— 从列表项标识、表单临时存储，到数据缓存键值，都需要一个 “绝对不重复” 的标识符。但看似简单的需求下，藏着很多容易踩坑的实现方式，稍有不慎就会引发数据冲突、逻辑异常等问题。

今天我们就来拆解常见误区，带你掌握真正可靠的唯一 ID 生成方案。

一、为什么 “唯一 ID” 比想象中难？

唯一 ID 的核心要求是 “全局不重复”，但前端环境的特殊性（无状态、多标签页、高并发操作），让很多看似合理的方案在实际场景中失效。

下面两种常见实现，其实都是 “伪唯一” 陷阱。

❌ 误区 1：时间戳 + 随机数（Date.now() + Math.random()）

很多开发者会直觉性地将 “时间唯一性” 和 “随机唯一性” 结合，写出这样的代码：

// 错误示例：看似合理的“伪唯一”方案

function generateNaiveId() {

  // 时间戳转36进制（缩短长度）+ 随机数截取

  return Date.now().toString(36) + Math.random().toString(36).substr(2);

}

// 示例输出：l6n7f4v2am50k9m7o4

这种方案的缺陷在高并发场景下会暴露无遗：

• 时间戳精度不足：Date.now() 的精度是毫秒级（1ms），如果同一毫秒内调用多次（比如循环生成、高频接口回调），ID 的 “时间部分” 会完全重复；


• 伪随机性风险：Math.random() 生成的是 “非加密级随机数”，其算法可预测，在短时间内可能生成重复的序列，进一步增加冲突概率。

结论：仅适用于低频次、非核心场景（如临时展示用 ID），绝对不能用于生产环境的核心数据标识。

❌ 误区 2：全局自增计数器

另一种思路是维护一个全局变量自增，看似能保证 “有序唯一”：

// 错误示例：自增计数器方案

let counter = 0;

function generateIncrementId() {

  return `id-${counter++}`;

}

// 示例输出：id-0、id-1、id-2...

但在浏览器环境中，这个方案的缺陷更致命：

• 无状态丢失：页面刷新、路由跳转后，counter 会重置为 0，之前的 ID 序列会重复；


• 多标签页冲突：用户打开多个相同页面时，每个页面的 counter 都是独立的，会生成完全相同的 ID（比如两个页面同时生成 id-0）。

结论：浏览器环境中几乎毫无实用价值，仅能用于单次会话、单页面的临时标识。

二、王者方案：一行代码实现绝对唯一 —— crypto.randomUUID()

既然简单方案不可靠，我们需要借助浏览器原生提供的 “加密级” 能力。crypto.randomUUID() 就是 W3C 标准推荐的官方解决方案，彻底解决 “唯一 ID” 难题。

1. 用法：一行代码搞定

crypto 是浏览器内置的全局对象（无需引入任何库），专门提供加密相关能力，randomUUID() 方法可直接生成符合 RFC 4122 v4 规范 的 UUID（通用唯一标识符）：

// 正确示例：生成绝对唯一ID

const uniqueId = crypto.randomUUID();

// 示例输出：3a6c4b2a-4c26-4d0f-a4b7-3b1a2b3c4d5e

2. 为什么它是 “绝对唯一” 的？

crypto.randomUUID() 的可靠性源于三个核心优势：

• 极低碰撞概率：v4 UUID 由 122 位随机数构成，组合数量高达 2^122（约 5.3×10^36），相当于 “在地球所有沙滩的沙粒中，选中某一颗特定沙粒” 的概率，实际场景中碰撞概率趋近于 0；


• 加密级随机性：基于 “密码学安全伪随机数生成器（CSPRNG）”，随机性远优于 Math.random()，无法被预测或破解，避免恶意伪造重复 ID；


• 跨环境兼容：生成的 UUID 是全球通用标准格式（8-4-4-4-12 位字符），前端、后端（Node.js、Java 等）、数据库（MySQL、MongoDB）都能直接识别，无需格式转换。

3. 兼容性：覆盖所有现代环境

crypto.randomUUID() 的支持范围已经非常广泛，完全满足绝大多数新项目需求：

• 浏览器：Chrome 92+、Firefox 90+、Safari 15.4+（2022 年及以后发布的版本）；


• 服务器：Node.js 14.17+（LTS 版本均支持）；


• 框架：Vue 3、React 18、Svelte 等现代框架无任何兼容性问题。

三、兼容性兜底方案（针对旧环境）

如果需要兼容旧浏览器（如 IE11）或低版本 Node.js，可以使用第三方库 uuid（轻量、无依赖），其底层逻辑与 crypto.randomUUID() 一致：

安装依赖：

npm install uuid

# 或 yarn add uuid

使用方式：

// 旧环境兜底方案

import { v4 as uuidv4 } from 'uuid';

const uniqueId = uuidv4();

// 示例输出：同标准UUID格式

四、总结：唯一 ID 生成的 “最佳实践”

对于 2023 年后的新项目，直接使用 crypto.randomUUID() 即可 —— 一行代码、零依赖、绝对可靠，彻底告别 “ID 重复” 的烦恼！

前言

话不多说，先演示一下吧。大概功能描述就是，告诉AI“添加日历，今天下午五点到六点，我要去万达吃饭”，然后AI自动将日程同步到日历。

准备工作

开发这个日程助理需要用到MCP、Mac（mac的日历能力）、Windsurf（运行mcp）。技术栈是Typescript。

思路

基于MCP我们可以做很多。关于这个日程助理，其实也是很简单一个尝试，其实就是再验证一下我对MCP的使用。因为Siri的原因，让我刚好有了这个想法，尝试一下自己搞个日程助理。关于MCP可以看我前面的分享
# 前端的AI路其之一： MCP与Function Calling# 前端的AI路其之二：初试MCP Server 。

我的思路如下： 让大模型理解一下我的意图，然后执行相关操作。这也是我对MCP的理解（执行相关操作）。因此要做日程助理，那就很简单了。首先搞一个脚本，能够自动调用mac并添加日历，然后再包装成MCP，最后引入大模型就ok了。顺着这个思路，接下来就讲讲如何实现吧

实现

第一步：在mac上添加日历

这里我们需要先明确一个概念。mac上给日历添加日程，其实是就是给对应的日历类型添加日程。举个例子

左边红框其实就是日历类型，比如我要添加一个开发日程，其实就是先选择"开发"日历，然后在该日历下添加日程。因此如果我们想通过脚本形式创建日程，其实就是先看日历类型存在不存在，如果存在，就在该类型下添加一个日程。

因此这里第一步，我们先获取mac上有没有对应的日历，没有的话就创建一个。

1.1 查找日历

参考文档 mac查找日历

假定我们的日历类型叫做 日程助手。 这里我使用了applescript的语法，因为JavaScript的方式我这运行有问题。

import { execSync } from 'child_process';



function checkCalendarExists(calendarName) {



    const   Script = `tell application "Calendar"

	set theCalendarName to "${calendarName}"

	set theCalendar to first calendar where its name = theCalendarName

end tell`;





  // 执行并解析结果

  try {

    const result = execSync(`osascript  -e '${Script}'`, { 

      encoding: 'utf-8',

      stdio: ['pipe', 'pipe', 'ignore'] // 忽略错误输出

    });



    console.log(result);

    return true;

  } catch (error) {

    console.error('检测失败:', error.message);

    return false;

  }

}



// 使用示例

const calendarName = '日程助手';

const exists = checkCalendarExists(calendarName);

console.log(`日历 "${calendarName}" 存在:`, exists ? '✅ 是' : '❌ 否');

附赠检验结果

现在我们知道了怎么判断日历存不存在，那么接下来就是，在日历不存在的时候创建日历

1.2 日历创建

参考文档 mac 创建日历

import { execSync } from 'child_process';





// 创建日历

function  createCalendar(calendarName) {

    const script = `tell application "Calendar"

        make new calendar with properties {name:"${calendarName}"}

    end tell`;



    try {



        execSync(`osascript -e '${script}'`, { 

            encoding: 'utf-8',

            stdio: ['pipe', 'pipe', 'ignore'] // 忽略错误输出

        });



        return true;

    } catch (e) {

        console.log('create fail', e)

        return false;

    }

}



// 检查日历是否存在

function checkCalendarExists(calendarName) {

    ....

}



// 使用示例

const calendarName = '日程助手';

const exists = checkCalendarExists(calendarName);

console.log(`日历 "${calendarName}" 存在:`, exists ? '✅ 是' : '❌ 否');



if (!exists) {

  const res =    createCalendar(calendarName);



  console.log(res ? '✅ 创建成功' : '❌ 创建失败')

}

运行结果

接下来就是第三步了，在日历“日程助手”下创建日程

1.3 创建日程

import { execSync } from 'child_process';



// 创建日程

function createCalendarEvent(calendarName, config) {



    const script = `var app = Application.currentApplication()

    app.includeStandardAdditions = true

    var Calendar = Application("Calendar")

     

    var eventStart = new Date(${config.startTime})

    var eventEnd = new Date(${config.endTime})

     

    var projectCalendars = Calendar.calendars.whose({name: "${calendarName}"})

    var projectCalendar = projectCalendars[0]

    var event = Calendar.Event({summary: "${config.title}", startDate: eventStart, endDate: eventEnd, description: "${config.description}"})

    projectCalendar.events.push(event)

    event`



    try {

        console.log('开始创建日程');

        execSync(`  osascript -l JavaScript -e '${script}'`, { 

            encoding: 'utf-8',

            stdio: ['pipe', 'pipe', 'ignore'] // 忽略错误输出

        });

        console.log('✅ 日程添加成功');

    } catch (error) {

        console.error('❌ 执行失败:', error);

    }



}



// 创建日历

function  createCalendar(calendarName) {

   ....

}



// 检查日历是否存在

function checkCalendarExists(calendarName) {



 ...

}

这里我们完善一下代码

import { execSync } from 'child_process';



function handleCreateEvent(config) {

    const calendarName = '日程助手';

    const exists = checkCalendarExists(calendarName);

    // console.log(`日历 "${calendarName}" 存在:`, exists ? '✅ 是' : '❌ 否');



    if (!exists) {

        const createRes =  createCalendar(calendarName);



        console.log(createRes ? '✅ 创建日历成功' : '❌ 创建日历失败')



        if (createRes) {

            createCalendarEvent(calendarName, config)

        }

    }  else {

        createCalendarEvent(calendarName, config)

    }

}



// 创建日程

function createCalendarEvent(calendarName, config) {



    const script = `var app = Application.currentApplication()

    app.includeStandardAdditions = true

    var Calendar = Application("Calendar")

     

    var eventStart = new Date(${config.startTime})

    var eventEnd = new Date(${config.endTime})

     

    var projectCalendars = Calendar.calendars.whose({name: "${calendarName}"})

    var projectCalendar = projectCalendars[0]

    var event = Calendar.Event({summary: "${config.title}", startDate: eventStart, endDate: eventEnd, description: "${config.description}"})

    projectCalendar.events.push(event)

    event`



    try {

        console.log('开始创建日程');

        execSync(`  osascript -l JavaScript -e '${script}'`, { 

            encoding: 'utf-8',

            stdio: ['pipe', 'pipe', 'ignore'] // 忽略错误输出

        });

        console.log('✅ 日程添加成功');

    } catch (error) {

        console.error('❌ 执行失败:', error);

    }



}



// 创建日历

function  createCalendar(calendarName) {

    const script = `tell application "Calendar"

        make new calendar with properties {name:"${calendarName}"}

    end tell`;



    try {



        execSync(`osascript -e '${script}'`, { 

            encoding: 'utf-8',

            stdio: ['pipe', 'pipe', 'ignore'] // 忽略错误输出

        });



        return true;

    } catch (e) {

        console.log('create fail', e)

        return false;

    }

}



// 检查日历是否存在

function checkCalendarExists(calendarName) {



    const   Script = `tell application "Calendar"

	set theCalendarName to "${calendarName}"

	set theCalendar to first calendar where its name = theCalendarName

end tell`;





  // 执行并解析结果

  try {

    const result = execSync(`osascript  -e '${Script}'`, { 

      encoding: 'utf-8',

      stdio: ['pipe', 'pipe', 'ignore'] // 忽略错误输出

    });



    return true;

  } catch (error) {

    return false;

  }

}





// 运行示例



const eventConfig = {

    title: '团队周会',

    startTime: 1744183538021,

    endTime: 1744442738000,

    description: '每周项目进度同步',

};



handleCreateEvent(eventConfig)

运行结果

这就是一个完善的，可以直接在终端运行的创建日程的脚本的。接下来我们要做的就是，让大模型理解这个脚本，并学会使用这个脚本

第二步： 定义MCP

基于第一步，我们已经完成了这个日程助理的基本功能，接下来就是借助MCP的能力，教会大模型知道有这个函数，以及怎么调用这个函数

// 引入 mcp

import { McpServer } from "@modelcontextprotocol/sdk/server/mcp.js";

import { StdioServerTransport } from "@modelcontextprotocol/sdk/server/stdio.js";

import { z } from "zod";



// 声明MCP服务

const server = new McpServer({

    name: "mcp_calendar",

    version: "1.0.0"

  });



...

// 添加日历函数 也就是告诉大模型 有这个东西以及怎么用

server.tool("add_mac_calendar", '给mac日历添加日程, 接受四个参数  startTime, endTime是起止时间（格式为YYYY-MM-DD HH:MM:SS） title是日历标题  description是日历描述', { startTime: z.string(), endTime: z.string(), title: z.string(), description: z.string() },

async ({ startTime, endTime, title, description }) => {

    const res =  handleCreateEvent({

        title: title,

        description: description,

        startTime: new Date(startTime).getTime(),

        endTime: new Date(endTime).getTime()

      });

      return {

        content: [{ type: "text", text: res ? '添加成功' : '添加失败' }]

      }

})





// 初始化服务

const transport = new StdioServerTransport();

await server.connect(transport);

这里附上完整的ts代码

import { McpServer } from "@modelcontextprotocol/sdk/server/mcp.js";

import { StdioServerTransport } from "@modelcontextprotocol/sdk/server/stdio.js";

import { execSync } from 'child_process';

import { z } from "zod";





export interface EventConfig {

    // 日程标题

  title: string;

  // 日程开始时间 毫秒时间戳

  startTime: number;

  // 日程结束时间 毫秒时间戳

  endTime: number;

//   日程描述

  description: string;

}



const server = new McpServer({

    name: "mcp_calendar",

    version: "1.0.0"

  });



function handleCreateEvent(config: EventConfig) {

    const calendarName = '日程助手';

    const exists = checkCalendarExists(calendarName);

    // console.log(`日历 "${calendarName}" 存在:`, exists ? '✅ 是' : '❌ 否');



    let res = false;



    if (!exists) {

        const createRes =  createCalendar(calendarName);



        console.log(createRes ? '✅ 创建日历成功' : '❌ 创建日历失败')



        if (createRes) {

           res = createCalendarEvent(calendarName, config)

        }

    }  else {

        res = createCalendarEvent(calendarName, config)

    }



    return res

}



// 创建日程

function createCalendarEvent(calendarName: string, config: EventConfig) {



    const script = `var app = Application.currentApplication()

    app.includeStandardAdditions = true

    var Calendar = Application("Calendar")

     

    var eventStart = new Date(${config.startTime})

    var eventEnd = new Date(${config.endTime})

     

    var projectCalendars = Calendar.calendars.whose({name: "${calendarName}"})

    var projectCalendar = projectCalendars[0]

    var event = Calendar.Event({summary: "${config.title}", startDate: eventStart, endDate: eventEnd, description: "${config.description}"})

    projectCalendar.events.push(event)

    event`



    try {

        console.log('开始创建日程');

        execSync(`  osascript -l JavaScript -e '${script}'`, { 

            encoding: 'utf-8',

            stdio: ['pipe', 'pipe', 'ignore'] // 忽略错误输出

        });

        console.log('✅ 日程添加成功');



        return true

    } catch (error) {

        console.error('❌ 执行失败:', error);

        return false

    }



}



// 创建日历

function  createCalendar(calendarName: string) {

    const script = `tell application "Calendar"

        make new calendar with properties {name:"${calendarName}"}

    end tell`;



    try {



        execSync(`osascript -e '${script}'`, { 

            encoding: 'utf-8',

            stdio: ['pipe', 'pipe', 'ignore'] // 忽略错误输出

        });



        return true;

    } catch (e) {

        console.log('create fail', e)

        return false;

    }

}



// 检查日历是否存在

function checkCalendarExists(calendarName: string) {



    const   Script = `tell application "Calendar"

	set theCalendarName to "${calendarName}"

	set theCalendar to first calendar where its name = theCalendarName

end tell`;





  // 执行并解析结果

  try {

    const result = execSync(`osascript  -e '${Script}'`, { 

      encoding: 'utf-8',

      stdio: ['pipe', 'pipe', 'ignore'] // 忽略错误输出

    });



    return true;

  } catch (error) {

    return false;

  }

}





server.tool("add_mac_calendar", '给mac日历添加日程, 接受四个参数  startTime, endTime是起止时间（格式为YYYY-MM-DD HH:MM:SS） title是日历标题  description是日历描述', { startTime: z.string(), endTime: z.string(), title: z.string(), description: z.string() },

async ({ startTime, endTime, title, description }) => {

    const res =  handleCreateEvent({

        title: title,

        description: description,

        startTime: new Date(startTime).getTime(),

        endTime: new Date(endTime).getTime()

      });

      return {

        content: [{ type: "text", text: res ? '添加成功' : '添加失败' }]

      }

})



const transport = new StdioServerTransport();

await server.connect(transport);

第三步： 导入Windsurf

在前文已经讲过如何引入到Windsurf，可以参考前文# 前端的AI路其之二：初试MCP Server ，这里就不过多赘述了。 其实在build之后，完全可以引入其他支持MCP的软件基本都是可以的。

接下来就是愉快的调用时间啦。

总结

这里其实是对前文# 前端的AI路其之二：初试MCP Server 的再次深入。算是大概讲明白了Tool方式怎么用，MCP当然不止这一种用法，后面也会继续输出自己的学习感悟，也欢迎各位大佬的分享和指正。

祝好。

这是一个平平无奇的音乐App Vooh，你可以在里面搜索歌曲，添加播放列表，播放音乐。

你可以滑动返回上一级页面，就像任何一个普通的App那样。

你可以流畅地展开音乐播放面板，看着歌词随着播放时间滚动。

当然，你也可以在电脑端，或者iPad上使用这个App。

而它与App的唯一不同，在于安装它不需要下载庞大的安装文件，只需要一个链接。音乐播放器Vooh的本体，只是一个网页。

作为一个诞生了好几年的老技术，PWA（Progressive Web Application）自诞生以来一直都不温不火，Google对它的愿景是最终所有的网页都能做到和App一致的体验，但直到现在，它都像是一道可有可无的饭后甜点。对于网页来说，即用即走似乎是它与生俱来的诅咒，用户既没有将Web安装到桌面的必要，也没有这个耐心，毕竟对于网络延迟增加1秒都可能导致访问量降低80%的地狱难度模式的网页用户生态而言，让一个浏览器用户点击一个陌生的“Install as application”的按钮简直是天方夜谭。尽管它就在那里，但乐于尝试的人似乎总是寥寥无几。既然PWA和纯网页能做的事情相差无几，那为什么还要浪费桌面空间增加一个以后可能再也不会使用的图标呢？

我一直认为，PWA应该朝着更像App的方向努力，才能体现出它的价值。然而，目前的许多PWA，看起来只是把普通的网页做成了全屏，与在浏览器中的体验别无二致，做不出差异化，用户自然没有动力去安装PWA，PWA那些听起来十分美好的特性便成了空中楼阁，无源之水，这个名字也越来越将从人们的视野中慢慢淡去。

如何才能让PWA更像APP，这是一个问题。毕竟浏览器的交互逻辑和原生App相比，有着很大的区别，用户早已习惯了移动浏览器中的前进后退，页面加载时的白屏，以及几乎不存在的手势交互，似乎在说，没关系，这就是网页，它做到这个份上已经足够了。然而，若要把这份体验带到模仿原生App的PWA中去，那势必将迎来用户预期低落的反噬，连这样那样的交互体验都没有，还能叫App？

为了了解目前的PWA究竟能做到何种地步，我开发了Vooh，一个竭尽可能模仿原生App实现的PWA音乐播放器。它尽力实现了一个原生App应该具备的一切交互细节，包括页面间自然的动画过渡，跟手的手势交互，为触屏优化的样式细节等等，我尽可能将它的每个细节都尽可能地做到与App别无二致，就是为了探索Web能力的极限。而在这之后，我也打算将Vooh的实现原理整理出来，并且准备逐步将之前的做过的项目“App化”，来一窥Google期待的未来，究竟是什么样子。

无处不在的过渡动画

尽管Vue，React以及原生CSS都提供了方便的方式实现过渡动画，但是对于大多数网页来说，一个Loading动画可能就是整个页面里动画最多的地方了。这对于网页来说的确无关紧要，毕竟用户们早已习惯了浏览器里生硬的切换效果，没有成体系的交互反馈，以及突然消失出现的页面区域。尽管在许多成熟组件库慢慢开始注重交互动画的优化之后，这样的情况在慢慢改善，但是依然难以改变用户的刻板印象。因此，为用户的预期提供动画反馈是伪装成原生App的一个关键步骤，否则，缺少反馈的使用体验会一下子将用户安装和使用PWA的欲望拉得很低。

除去老生常谈的按钮悬浮、按下时的动画，页面间的过渡动画也是不可缺少的一环。如果你仔细观察iOS的Tab页面，就能发现在切换Tab的时候，也会有细微的不易察觉的缩放淡出渐变，正是这种细致入微的动画组成了iOS App丝滑体验中重要的一部分。

表单组件的动画效果也很重要，Vooh尽可能地使用了iOS风格的表单组件，例如Button，Switch等，以贴合用户的日常视觉体验。

手势交互

手势是网页与App的重要差异点，一般来说，很少会有网页支持用户的滑动返回，长按呼出菜单等复杂的手势操作，而这正是让你的PWA丝般顺滑的关键。

需要注意的是，由于大部分移动浏览器和JS本身单线程的限制，手势交互依赖监听器的执行速度，而很难跑满设备屏幕的帧率上限，尤其是iOS设备上，开启低电量模式的情况下，监听器的帧率可能只有不到30 FPS，肉眼可见的卡顿。目前为止，也没有看到任何浏览器厂商有关于优化手势交互的提案，手势交互就像一道横亘在网页与App之间的鸿沟，没有丝毫跨越的可能，只能尽可能地模仿。

离线访问

没有哪个用户能接受打开App时整个页面全部消失无法操作，APP的最大优点就是离线可用，好在Service Worker的推出让这一点不再是问题，通过Service Worker对网页资源进行缓存，可以实现在低网速甚至离线环境下，也能继续使用PWA，就像真正的App那样。

然而不幸的是，在iOS设备上，Service Worker离线缓存不再可用，开启飞行模式或者关闭网络连接后将无法访问任何网页，包括已经安装在桌面上的PWA，

偶遇现代IE厂商，拼尽全力无法战胜。

细节之外的细节

而Vooh在这些基础能力之外，还增加了许多其他的细节设计，让整个App在模仿原生App时更进一步。

1，存储占用管理

在移动设备上，PWA与App的存储占用是分隔开的，而且往往要经过十分复杂的步骤才能看到PWA的实际空间占用，因此对于音乐播放器这种高度依赖本地资源的应用来说，一个显而易见的存储占用管理系统能有效缓解用户的存储焦虑。

2，接入系统播放器

隆重介绍Media Session API，它能让JS直接接入系统播放器控件，即使在后台也可以允许用户通过系统自带的播放器控制媒体的播放，例如下一曲、播放暂停等，在iOS设备上，还能直接适配灵动岛，这下谁还能分辨谁是原生App。

3，深色模式

在Apple等手机厂商的推动下，大部分的App都已经适配深色模式，而网页对于深色模式的适配比起App要更为简单，毕竟CSS实在是太灵活了，Vooh当然也做了适配，在不同的模式下都能完美贴合系统的主体模式。

为了提升Vooh与其他原生播放器的（根本不存在的）竞争力，我也煞费苦心地加入了许多的细节，来让用户有真正使用它的动力，例如根据歌曲封面动态取色，自动识别的滚动歌词等，希望能让它在用户的手机桌面上多待一段时间。

未竟之事

不过，即使是做到了这个地步，PWA的能力始终是有极限的。有些App轻易能做到的事，对于PWA而言犹如天堑一般遥不可及，包括但不限于：

1，后台活动

在移动设备上，网页也好，PWA也好，基本上没有任何后台活动能力，甚至上面提到的Media Session API，在iOS上顶多也只最多能支持后台播放1～2首歌曲，然后就会被强行停止，更不用说后台导航，推送通知这种活在梦里的API了，这方面浏览器天生就是残废，未来也看不到有任何改进的可能，因此在开发PWA时，一定要远离这些方向。在js都能跑虚拟机，剪视频的当下，Web开发者们推送一条通知的希冀却只能在另一个平行时空实现了。

2，跳转到PWA

据说Andriod Chrome支持使用PWA来打开特定的链接，不过在iOS上就别想了。

3，触感反馈

同样，Web也只能使用早已被淘汰的Vibrate，细腻的振动反馈和Taptic Engine对网页来说也是天方夜谭。

4，调用原生功能

还有无数浩如烟海的功能是PWA完全无法实现的，例如系统级的音量调节，亮度调节等，我能理解这是浏览器对恶意网站的限制，但这也确实极大限制了Web的发展，比如奠定了Web安全基础的跨域限制，如今成为了许多大型Web应用的掣肘。我由衷地希望某天浏览器能制定一个更宽松的PWA标准，例如安装到桌面后能提供更多的权限，提供一个无跨域限制的fetch代替品等等，然而即使对Web上心如Google，也没有考虑过这个方向的可能性。JS正在和越来越宽松的宿主环境（Tuari，Electron）一步步蚕食着原生GUI开发的领地，而它的发源地，浏览器却只能被所谓的安全性限制，成为一个只负责播放动画的花瓶。

总结

正如所说，一切能由javascript实现的终将会用javascript实现。如今，越来越多的平台小程序，快应用，乃至于H5套壳的App越来越多，随着浏览器性能的进一步提升，Web能做到的事越来越多，但是Web的交互性却并没有随着javascript的繁荣而被重视起来，受限于javascript的单线程特性，要完全模拟App的使用体验还是有一定的差距，一个劲地往原生体验上靠，有时也并不一定是最好的选择，Vooh的出现只是给了开发者们一个可能的方向，Web的轻量，优秀的可触达性与PWA有机结合，才是Web的发展方向。同时也希望各家浏览器厂商们能加快适配新的Web特性，能够让程序们在写代码时少掉一些头发，便是最大的善事了

如果对Vooh的实现方式有兴趣的话，欢迎关注我的专栏或者博客，后续的代码也会一并开源，涉及到音乐版权相关，目前的Vooh只开放了2首免费无版权音乐的使用，代码也不会涉及版权相关的领域。

作者：陈盛靖

一、背景

业务群里面经常反馈，视频播放卡顿，视频播放总是停留在某一时刻就播放不了了。后面经过排查，发现这是因为弱网导致的。然而，用户数量众多，隔三差五总有人在群里反馈，有时问题一时半会好不了，用户就会怀疑不是网络，而是我们的系统问题。因此，我们希望能在弱网的时候展示提示，这样用户体验会更友好，同时也能减少一定的客诉。

二、现状分析

我们使用的播放器是chimee(http://www.chimee.org/index.html)。遗憾的是，chimee并没有视频播放卡顿自动展示loading的功能，不过我们可以通过其插件能力，来编写一个自定义video-loading的插件。

三、方案设计

使用NetworkInformation

常见的方法就是我们通过设定一个标准，然后检测用户设备的网络速度，在到达一定阈值时展示弱网提示。这里需要确定一个重要的点：什么情况下才算弱网？

我们的应用是h5，这里我们可以使用window对象中的NetworkInformation(developer.mozilla.org/zh-CN/docs/…)，我们可以通过浏览器的debug工具，打印window.naviagtor.connection，这个对象内部就存储着网络信息：

其中各个属性含义如下表所示：

其中，我们可以通过effectiveType判断当前网络的大体情况，并且可以拿到一个预估的网络带宽(downlink)。我们可以通过监听onchange事件，在网络变差的时候，展示对应的弱网提示。

这个方案的优点是：

• 浏览器环境原生支持


• 实现相对简单

但缺点却十分明显：

• 网络状态变化非实时

effectiveType的变化可能是分钟级别的，对于短暂的网络波动，状态没办法做更精细的把控

• 存在兼容性问题

对于不同一些主流浏览器不支持，例如Firefox、Safari等

• 不同设备间存在差异

不同的设备和浏览器，由于其差异，在不同的网络情况下，视频的播放情况是不一样的，如果我们固定一个标准，可能会导致在不同设备下，同一个网络速度，有人明明正常播放视频，但是却提示网络异常，这样用户会感到疑惑。

那有没有更好的方法呢？

监听Video元素事件

chimee底层也是在html video上进行的二次封装，我们可以在插件的生命周期中，拿到对应的video元素节点。而在video标签中，存在这样两个事件：waiting和canplay。

其事件描述如下图所示：

当视频播放卡顿时，会触发waiting事件；而当视频播放恢复正常时，会触发canplay事件。只要监听这两个事件，我们就可以实现对应的功能了。

四、功能拓展

我们知道，现在大多数网站的视频在提示弱网的时候，都会展示当前设备的网络速度是多少。因此我们也希望在展示对应的信息。那么怎么实现网络速度的检测呢？

一个简单的方法是，我们可以通过获取一张固定大小的图片资源(不一定是图片，也可以是别的类型的资源），并统计请求该资源的请求速度，从而计算当前网络的带宽是多少。当然，图片大小要尽可能小一点，一是为了节省用户流量，二是为了避免在网络不好的情况下，图片请求太慢导致一直计算不出来。

具体代码如下：

funtion calculateSpeed() {

  // 图片大小772Byte

  const fileSize = 772;

  // 拼接时间戳，避免缓存

  const imgUrl = `https://xxx.png?timestamp=${new Date().getTime()}`;



  return new Promise((resolve, reject) => {

    let start = 0;

    let end = 1000;

    let img = document.createElement('img');

    start = new Date().getTime();

    img.onload = function (e) {

        end = new Date().getTime();

        // 计算出来的单位为 B/s

        const speed = fileSize / (end > start ? end - start : 1000) * 1000;

        resolve(speed);

    }

    img.src = imgUrl;

  }).catch(err => { throw err });

}

function translateUnit(speed) {

  if(speed === 0) return '0.00 B/s';

  if(speed > 1024 * 1024) return `${(speed / 1024 / 1024).toFixed(2)} MB/s`;

  if(speed > 1024) return `${(speed / 1024).toFixed(2)} KB/s`;

  else return `${speed.toFixed(2)} B/s`;

}

我们可以通过setInterval来轮询调用该函数，从而实时展示当前网络情况。系统流程图如下：

五、总结

我们可以通过Chrome浏览器开发者工具中的Network中的网络配置来模拟弱网情况

具体效果如下：

成功实现视频弱网提示，完结撒花🎉🎉🎉🎉🎉🎉。

我正在开发 DocFlow，它是一个完整的 AI 全栈协同文档平台。该项目融合了多个技术栈，包括基于 Tiptap 的富文本编辑器、NestJs 后端服务、AI 集成功能和实时协作。在开发过程中，我积累了丰富的实战经验，涵盖了 Tiptap 的深度定制、性能优化和协作功能的实现等核心难点。

如果你对 AI 全栈开发、Tiptap 富文本编辑器定制或 DocFlow 项目的完整技术方案感兴趣，欢迎加我微信 yunmz777 进行私聊咨询，获取详细的技术分享和最佳实践。

在前端开发中，撤销和重做功能是提升用户体验的重要特性。无论是文本编辑器、图形设计工具，还是可视化搭建平台，都需要提供历史操作的回退和前进能力。这个功能看似简单，但实现起来需要考虑性能、内存占用、用户体验等多个方面。

在构建富文本编辑器时，Tiptap 和 ProseMirror 是两个常见的技术选择。两者都强大且灵活，但它们在设计理念、易用性、扩展性等方面存在差异。对于开发者来说，选择合适的工具对于项目的成功至关重要。本文将深入探讨两者的异同，并通过实际代码示例帮助你理解它们的差异，从而根据具体需求做出决策。

ProseMirror 的优势与挑战

ProseMirror 是一个 JavaScript 库，用于构建复杂的富文本编辑器。它的设计非常底层，提供了一个高效且灵活的文档模型，开发者可以完全控制编辑器的行为和界面。ProseMirror 本身并不提供任何 UI 或组件，而是一个核心库，开发者需要自行实现具体的编辑器功能。

作为一个底层框架，ProseMirror 允许开发者完全控制编辑器的各个方面，包括文档结构、输入行为、UI 样式等。它提供了丰富的 API，可以处理复杂的编辑需求，如数学公式、代码块、图片、链接等。开发者可以为几乎任何功能编写插件，并且可以在已有插件的基础上进行二次开发。基于虚拟 DOM 的设计，使其在大文档和复杂结构下能够提供较高的性能。

然而，由于其底层设计，ProseMirror 的 API 复杂，学习曲线陡峭。开发者需要深入理解其文档模型、事务管理、节点和视图的关系。由于不提供任何 UI 组件，开发者需要从零开始构建编辑器的界面和交互，配置和初始化过程也较为复杂，需要手动处理许多底层逻辑。

ProseMirror 基础使用示例

首先需要安装必要的包：

npm install prosemirror-state prosemirror-view prosemirror-model prosemirror-schema-basic prosemirror-schema-list prosemirror-commands

创建一个基本的 ProseMirror 编辑器需要配置 schema、state 和 view：

import { EditorState } from "prosemirror-state";

import { EditorView } from "prosemirror-view";

import { Schema, DOMParser } from "prosemirror-model";

import { schema } from "prosemirror-schema-basic";

import { addListNodes } from "prosemirror-schema-list";

import { exampleSetup } from "prosemirror-example-setup";



// 扩展基础 schema，添加列表支持

const mySchema = new Schema({

  nodes: addListNodes(schema.spec.nodes, "paragraph block*", "block"),

  marks: schema.spec.marks,

});



// 创建编辑器状态

const state = EditorState.create({

  schema: mySchema,

  plugins: exampleSetup({ schema: mySchema }),

});



// 创建编辑器视图

const view = new EditorView(document.querySelector("#editor"), {

  state,

});

如果需要添加自定义命令，比如一个格式化工具条，需要手动实现：

import { toggleMark } from "prosemirror-commands";

import { schema } from "prosemirror-schema-basic";



// 创建加粗命令

const toggleBold = toggleMark(schema.marks.strong);



// 手动创建工具栏按钮

function createToolbar(view) {

  const toolbar = document.createElement("div");

  toolbar.className = "toolbar";



  const boldBtn = document.createElement("button");

  boldBtn.textContent = "Bold";

  boldBtn.onclick = () => {

    toggleBold(view.state, view.dispatch);

    view.focus();

  };



  toolbar.appendChild(boldBtn);

  return toolbar;

}

ProseMirror 自定义插件示例

创建一个自定义插件需要理解 ProseMirror 的插件系统：

import { Plugin } from "prosemirror-state";



// 创建一个字符计数插件

function characterCountPlugin() {

  return new Plugin({

    view(editorView) {

      const counter = document.createElement("div");

      counter.className = "char-counter";



      const updateCounter = () => {

        const text = editorView.state.doc.textContent;

        counter.textContent = `字符数: ${text.length}`;

      };



      updateCounter();



      return {

        update(view) {

          updateCounter();

        },

        destroy() {

          counter.remove();

        },

      };

    },

  });

}



// 使用插件

const state = EditorState.create({

  schema: mySchema,

  plugins: [characterCountPlugin(), ...exampleSetup({ schema: mySchema })],

});

Tiptap 的便捷开发

Tiptap 是基于 ProseMirror 构建的富文本编辑器框架，它简化了 ProseMirror 的复杂性，提供了现成的 UI 组件和更易于使用的 API。Tiptap 旨在让开发者能够快速实现丰富的富文本编辑器，同时保持较高的灵活性和扩展性。

Tiptap 提供了简洁的 API，开发者不需要深入学习 ProseMirror 的底层概念即可实现基本的富文本编辑功能。它通过封装 ProseMirror 的复杂性，使得开发过程更加直观和简便。开箱即用的 UI 组件，如文本格式化、列表、图片插入等，极大地方便了开发者的使用，减少了开发时间。清晰的文档和活跃的开源社区，也为开发者提供了良好的支持和资源。虽然 Tiptap 进行了封装，但它仍然保留了 ProseMirror 的插件系统，开发者可以根据需要定制功能，并且可以轻松地集成其他插件。此外，Tiptap 可以与 Yjs 或其他 CRDT 库结合，支持实时协作编辑功能，这是 ProseMirror 本身不具备的特性。

不过，由于 Tiptap 封装了 ProseMirror 的很多底层功能，灵活性相对较低。对于一些需要极高自定义的需求，Tiptap 可能不如 ProseMirror 灵活。虽然在大多数情况下性能良好，但在处理超大文档或复杂操作时，性能可能不如直接使用 ProseMirror。

Tiptap 基础使用示例

Tiptap 的安装和使用相对简单：

npm install @tiptap/react @tiptap/starter-kit @tiptap/pm

在 React 中使用 Tiptap：

import { useEditor, EditorContent } from "@tiptap/react";

import StarterKit from "@tiptap/starter-kit";



function TiptapEditor() {

  const editor = useEditor({

    extensions: [StarterKit],

    content: "<p>Hello World!</p>",

  });



  if (!editor) {

    return null;

  }



  return (

    <div>

      <div className="toolbar">

        <button

          onClick={() => editor.chain().focus().toggleBold().run()}

          disabled={!editor.can().chain().focus().toggleBold().run()}

          className={editor.isActive("bold") ? "is-active" : ""}

        >

          Bold

        </button>

        <button

          onClick={() => editor.chain().focus().toggleItalic().run()}

          disabled={!editor.can().chain().focus().toggleItalic().run()}

          className={editor.isActive("italic") ? "is-active" : ""}

        >

          Italic

        </button>

        <button

          onClick={() => editor.chain().focus().toggleBulletList().run()}

          className={editor.isActive("bulletList") ? "is-active" : ""}

        >

          Bullet List

        </button>

      </div>

      <EditorContent editor={editor} />

    </div>

  );

}

Tiptap 的 Vue 版本同样简洁：

<template>

  <div>

    <div class="toolbar">

      <button

        @click="editor.chain().focus().toggleBold().run()"

        :disabled="!editor.can().chain().focus().toggleBold().run()"

        :class="{ 'is-active': editor.isActive('bold') }"

      >

        Bold

      </button>

      <button

        @click="editor.chain().focus().toggleItalic().run()"

        :class="{ 'is-active': editor.isActive('italic') }"

      >

        Italic

      </button>

    </div>

    <editor-content :editor="editor" />

  </div>

</template>



<script>

import { useEditor, EditorContent } from "@tiptap/vue-3";

import StarterKit from "@tiptap/starter-kit";



export default {

  components: {

    EditorContent,

  },

  setup() {

    const editor = useEditor({

      extensions: [StarterKit],

      content: "<p>Hello World!</p>",

    });



    return { editor };

  },

};

</script>

Tiptap 扩展功能示例

Tiptap 支持多种扩展，添加图片功能非常简单：

import Image from "@tiptap/extension-image";

import { useEditor, EditorContent } from "@tiptap/react";

import StarterKit from "@tiptap/starter-kit";



function EditorWithImage() {

  const editor = useEditor({

    extensions: [

      StarterKit,

      Image.configure({

        inline: true,

        allowBase64: true,

      }),

    ],

  });



  const addImage = () => {

    const url = window.prompt("图片URL");

    if (url) {

      editor.chain().focus().setImage({ src: url }).run();

    }

  };



  return (

    <div>

      <button onClick={addImage}>添加图片</button>

      <EditorContent editor={editor} />

    </div>

  );

}

创建自定义扩展也很直观：

import { Extension } from "@tiptap/core";

import { Plugin } from "prosemirror-state";



const CharacterCount = Extension.create({

  name: "characterCount",



  addProseMirrorPlugins() {

    return [

      new Plugin({

        view(editorView) {

          const counter = document.createElement("div");

          counter.className = "char-counter";



          const updateCounter = () => {

            const text = editorView.state.doc.textContent;

            counter.textContent = `字符数: ${text.length}`;

          };



          updateCounter();



          return {

            update(view) {

              updateCounter();

            },

            destroy() {

              counter.remove();

            },

          };

        },

      }),

    ];

  },

});



// 使用自定义扩展

const editor = useEditor({

  extensions: [StarterKit, CharacterCount],

});

Tiptap 实时协作示例

Tiptap 与 Yjs 集成实现实时协作非常简单：

npm install yjs y-prosemirror @tiptap/extension-collaboration @tiptap/extension-collaboration-cursor

import { useEditor, EditorContent } from "@tiptap/react";

import StarterKit from "@tiptap/starter-kit";

import Collaboration from "@tiptap/extension-collaboration";

import CollaborationCursor from "@tiptap/extension-collaboration-cursor";

import * as Y from "yjs";

import { WebrtcProvider } from "y-webrtc";



// 创建 Yjs 文档和提供者

const ydoc = new Y.Doc();

const provider = new WebrtcProvider("room-name", ydoc);



function CollaborativeEditor() {

  const editor = useEditor({

    extensions: [

      StarterKit,

      Collaboration.configure({

        document: ydoc,

      }),

      CollaborationCursor.configure({

        provider,

      }),

    ],

  });



  return <EditorContent editor={editor} />;

}

从代码看差异

让我们通过实现一个带工具栏的编辑器来对比两者的代码复杂度：

在 ProseMirror 中，需要手动管理所有状态和命令：

import { EditorState, Plugin } from "prosemirror-state";

import { EditorView } from "prosemirror-view";

import { schema } from "prosemirror-schema-basic";

import { toggleMark } from "prosemirror-commands";



const state = EditorState.create({ schema });



const toolbarPlugin = new Plugin({

  view(editorView) {

    const toolbar = document.createElement("div");

    toolbar.className = "toolbar";



    const boldBtn = document.createElement("button");

    boldBtn.textContent = "B";

    boldBtn.onclick = (e) => {

      e.preventDefault();

      const { state, dispatch } = editorView;

      const command = toggleMark(schema.marks.strong);

      if (command(state, dispatch)) {

        editorView.focus();

      }

    };



    toolbar.appendChild(boldBtn);

    document.body.insertBefore(toolbar, editorView.dom);



    return {

      destroy() {

        toolbar.remove();

      },

    };

  },

});



const view = new EditorView(document.querySelector("#editor"), {

  state: EditorState.create({

    schema,

    plugins: [toolbarPlugin],

  }),

});

而在 Tiptap 中，相同的功能实现更加简洁：

const editor = useEditor({

  extensions: [StarterKit],

});



return (

  <div>

    <button

      onClick={() => editor.chain().focus().toggleBold().run()}

      className={editor.isActive("bold") ? "is-active" : ""}

    >

      B

    </button>

    <EditorContent editor={editor} />

  </div>

);

如何做出选择

选择 Tiptap 还是 ProseMirror，关键在于项目需求和开发团队的技术能力。

如果你的目标是快速构建一个功能丰富、用户友好的富文本编辑器，且不希望花费过多时间在底层细节上，Tiptap 是一个理想的选择。它提供了简洁的 API 和现成的 UI 组件，可以快速启动和开发。如果你的编辑器需要一些定制功能，但不需要完全控制每个底层细节，Tiptap 提供了足够的灵活性，同时保持了开发的简便性。如果需要实现多人实时协作，Tiptap 内建的对 Yjs 等库的支持可以简化实现过程。

如果你需要完全控制编辑器的行为、界面和性能，ProseMirror 提供了更高的自由度。它适合那些有特定需求的项目，比如自定义文档结构、输入行为或非常复杂的编辑操作。在处理非常大的文档或需要极高性能的场景下，ProseMirror 能提供更好的优化和性能。如果你的项目需要完全自定义插件，或者你想对编辑器进行深度定制，ProseMirror 提供了更高的灵活性。

性能考虑

对于大文档处理，ProseMirror 提供了更细粒度的控制：

// ProseMirror 中可以精确控制更新

const state = EditorState.create({

  schema,

  plugins: [

    // 可以精确控制哪些插件启用

    // 可以自定义更新逻辑

    new Plugin({

      state: {

        init() {

          return {};

        },

        apply(tr, value) {

          // 自定义状态更新逻辑

          return value;

        },

      },

    }),

  ],

});

而 Tiptap 虽然性能良好，但在极端场景下可能不如直接使用 ProseMirror 优化：

// Tiptap 的性能优化选项

const editor = useEditor({

  extensions: [StarterKit],

  editorProps: {

    attributes: {

      class:

        "prose prose-sm sm:prose lg:prose-lg xl:prose-2xl mx-auto focus:outline-none",

    },

    // 可以传递 ProseMirror 的原生配置

  },

  // 但仍然受到封装层的限制

});

生态系统和社区支持

Tiptap 拥有丰富的扩展生态系统：

# Tiptap 官方扩展

npm install @tiptap/extension-image

npm install @tiptap/extension-link

npm install @tiptap/extension-table

npm install @tiptap/extension-code-block-lowlight

npm install @tiptap/extension-placeholder

npm install @tiptap/extension-character-count

npm install @tiptap/extension-typography

而 ProseMirror 的插件需要通过 prosemirror-* 包系列来获取，或者自己实现。官方提供了基础插件，但高级功能需要社区插件或自行开发。

实际项目场景建议

对于博客平台、内容管理系统、笔记应用等常见场景，Tiptap 通常是最佳选择。它的快速开发和丰富的功能足以满足大多数需求。代码示例展示了如何在几分钟内搭建一个功能完整的编辑器。

对于需要特殊文档结构（如学术论文编辑器、代码编辑器、专业排版工具）或对性能有极致要求的场景，ProseMirror 提供了必要的底层控制能力。但需要投入更多时间学习其 API 和概念。

如果你的团队时间有限，或者希望快速迭代，Tiptap 是明智的选择。如果团队有富文本编辑器开发经验，或者有充足时间进行深度定制，ProseMirror 可以带来更高的灵活性和性能。

总结

Tiptap 是一个基于 ProseMirror 的富文本编辑器框架，适合需要快速开发、易用且功能丰富的场景。它封装了 ProseMirror 的复杂性，让开发者能够专注于业务逻辑，而无需关心底层实现细节。通过本文的代码示例可以看出，Tiptap 的 API 设计更加直观，学习曲线平缓，适合大多数项目需求。

ProseMirror 则是一个底层框架，适合那些需要完全控制文档结构、编辑行为和性能优化的高级开发者。它更灵活，但学习曲线较陡峭，适合复杂或定制化需求较强的项目。从代码示例中可以看到，使用 ProseMirror 需要处理更多的底层细节，但同时也获得了更高的控制权。

如果你的项目需要快速构建编辑器并具备一定的自定义能力，Tiptap 是一个更为理想的选择。而如果你的项目需要完全的定制化和高性能处理，ProseMirror 将更符合你的需求。最终的选择应基于你的开发需求、项目规模以及团队的技术能力。建议通过实际代码尝试两者，根据你的具体场景做出最适合的选择。

背景介绍

• 最近组内要做0-1的新ai产品, 招我进来就是负责这个ai产品,启动的时候这个季度就剩下两个月了,天天开会对齐进度,一个月就已经把基础版本给做完了,想要接入到现有的业务上面,时间方面就特别紧张,技术选型怎么说呢, leader用ai写了一个版本 我们在现有的代码进行二次开发这样, 全栈next.js 要学习的东西太多了 又没有前端基础,没有ai coding很难完成任务(十几分钟干完我一天的工作 claude4.5效果还不错 进度推的特别快), 自从trae下架了claude,后面就一直cursor claude 4.5了。
  
  
  
  
  • nextjs+ts+tailwindcss+shadcn ui现在是mvp套餐，startup在梭哈，时间就是生产力哪需要那么多差异化样式直接一把，有的💰才开始做细节，你会发现慢慢也💩化了。
  
  
  • Nextjs 是全栈框架 可以很快把一个MVP从零到一完整跑起来。 你要是抬杠说什么高并发负载均衡啥的，你的用户数量真多到需要考虑性能的时候，你已经不需要自己考虑了(小红书看到的一段话 挺符合场景的)
  
  
  • next.js 写后端 确实比较轻量 只能做一些curd的操作 socket之类的不太合适 其他api 还是随便开发 给我的感受就是前端能够直接操作db，前后端仓库可以不分离，业务逻辑还是一定要分离的 看看开源的next.js 项目的架构设计结构是怎么样的 学习/模仿/改造。
  
  
  • 语言只是工具，适合最重要，技术没有银弹
  
  
  
  


• nextjs.org/ github.com/vercel/next…
  

项目的时间线

项目从启动到这周 大概是5周的时间

• 10/28-10/31 Week 1
  
  
  
  • 项目初始化/需求讨论/设计文档/
  
  
  • 后端next.js, typescript技术熟悉 项目运行/调试
  
  
  • 基础框架搭建 设计表结构ddl, 集成mysql, 编写crud接口阶段
  
  
  
  


• 11/03-11/07 Week 2
  
  
  
  • 产品PRD 提供
  
  
  • xxxx等表设计
  
  
  
  


• 11/10-11/14 Week 3
  
  
  
  • xxxxx 基本功能完结
  
  
  • @xxxx 讲解项目结构/规范
  
  
  
  


• 11/17-11/21 Week 4
  
  
  
  • 首页样式/逻辑 优化
  
  
  • 集成统一登录调研
  
  
  • 部署完成
  
  
  
  


• 11/24-11/28 Week 5
  
  
  
  • 服务推理使用Authorization鉴权 对内接口使用Cookies (access_token) 鉴权 开发
  
  
  • xxxx 表设计表设计 逻辑开发
  
  
  • xxx设计 设计开发
  
  
  • 联调xxxx
  
  
  
  

5周时间 功能基本完成了 剩下的就是部署到线上 进行场景实践了

前端技术栈

• Next.js 14：选择 App Router 架构，支持服务端渲染和 API Routes


• TypeScript 5.4：强类型语言提升代码质量和可维护性


• React 18：利用并发特性和 Suspense 提升用户体验


• Zustand：轻量级状态管理，替代 Redux 降低复杂度


• Ant Design + Radix UI：组件库组合，平衡美观性和可访问性

React + TypeScript react.dev/

• 优势：类型安全：TypeScript 提供编译时类型检查，减少运行时错误 ✅ 组件化开发：高度可复用的组件设计 ✅ 生态成熟：丰富的第三方库和工具链 ✅ 开发体验：优秀的 IDE 支持和调试工具


• 劣势： ❌ 学习曲线：TypeScript 对新手有一定门槛 ❌ 编译时间：大型项目编译可能较慢 ❌ 配置复杂：类型定义需要额外维护

UI 组件方案 Ant Design + Radix UI 混合方案

• 优势： ✅ 快速开发：Ant Design 提供完整的企业级组件 ✅ 无障碍性：Radix UI 提供符合 WAI-ARIA 标准的组件 ✅ 定制灵活：Radix UI 无样式组件便于自定义 ✅ 中文支持：Ant Design 对中文界面友好


• 劣势： ❌ 包体积大：两个 UI 库增加了打包体积 ❌ 样式冲突：需要注意两个库的样式隔离❌ 维护成本：需要同时维护两套组件系统

Tailwind CSS

• 优势： ✅ 开发效率高：原子化类名，快速构建 UI ✅ 体积优化：生产环境自动清除未使用的样式 ✅ 一致性：设计系统内置，确保视觉一致 ✅ 响应式：便捷的响应式设计工具


• 劣势： ❌ 类名冗长：HTML 可能变得难以阅读 ❌ 学习成本：需要记忆大量类名 ❌ 非语义化：类名不直观反映元素意义

ant design x

ahooks

后端技术栈

• Prisma 6.18：现代化 ORM，类型安全且支持 Migration


• MySQL：成熟的关系型数据库，满足复杂查询需求


• Redis (ioredis) ：高性能缓存，支持多种数据结构


• Winston：企业级日志系统，支持日志轮转和结构化输出


• Zod：运行时类型验证，保障 API 数据安全

Next.js API Routes

• 优势： ✅ 统一代码库：前后端在同一项目中 ✅ 类型共享：TypeScript 类型可在前后端复用 ✅ 开发效率：无需配置跨域、代理等 ✅ 部署简单：单一应用部署


• 劣势： ❌ 扩展性限制：无法独立扩展后端服务 ❌ 性能瓶颈：Node.js 单线程可能成为瓶颈 ❌ 微服务困难：不适合复杂的微服务架构

Prisma ORM

• 优势： ✅ 类型安全：自动生成 TypeScript 类型 ✅ 迁移管理：声明式 schema，易于版本控制 ✅ 查询性能：生成优化的 SQL 查询 ✅ 关系处理：直观的关系查询 API ✅ 多数据库支持：支持 MySQL、PostgreSQL、SQLite 等


• 劣势： ❌ 复杂查询：某些复杂 SQL 可能需要原始查询 ❌ 生成代码体积：生成的 client 文件较大 ❌ 版本升级：大版本升级可能需要迁移

踩坑记录

主要是记录一些开发过程中踩坑 和设计问题

• node js 项目 jean部署


• 自定义配置/dockerfile配置 没有类似项目参考 健康检查问题 加上环境变量配置多环境 一步一步


• next.js 中 用middleware进行接口拦截鉴权 里面有prisma path import 直接出现了Edge Runtime 异常 自定义auth 解决


• npm build 项目 踩坑


• 静态渲染流程 动态api 警告 强制动态渲染


• 其他组件 document 不支持build问题


• 保存多场景模式+构建版本管理第一版考虑的太少了，发现有问题 后面又重构了一版本


• xxx日志目前还没有接入 要不就是日志文件 要不就是console.log 目前看日志的方式是去容器化运行日志看了 后续集群部署就比较麻烦了


• ant design 版本降低到6.0以下 ant-design x 用不了2.0.0 的一些对话组件

Next.js实践的项目记录

苏州 trae friends线下黑客松 📒

• 去Trae pro-Solo模式 苏州线下hackathon一趟, 基本都是一些独立开发者，一人一公司，三个小时做出一个产品用Trae-solo coder模式，不得不说trae内部集成的vercel部署很丝滑 react项目一键deploy访问 完全不用关系域名服务器, solo模式其实就是混合多种model使用进行输出 想要的效果还是得不断的调试 thiking太长，对于前后端分离项目 也能够同时关联进行思考规划。


• 1点多到4点 coding时间 从0-1生成项目 使用trae pro solo模式 就3个小时 做不了什么大的东西 那就做个日语50音的网站呗 现场酒店的网基本用不了 我数据也很卡 用的旁边干中学老师的热点 用next.js tailwindcss ant design deepseek搭建的网页 够用了 最后vercel部署 trae自带集成 挺方便的 solo模式还是太慢了 接受不了 网站地址是 traekanastudio1ssw.vercel.app/ 功能就是假名+ai生成例句和单词 我都没有路演 最后拿优秀奖可能是我部署了吧 大部分人没部署 优秀奖就是卫衣了 蹭了一天的饭加零食 爽吃


• http://www.xiaohongshu.com/explore/692… 小红书当时发的帖子 可以领奖品

Typescript的AI方向 langchain/langgraph支持ts

• 最近在看的ts的ai框架 发现langchain 是支持ts的, langchain-chat 主要是使用langchain+langgraph 对ts进行实践 traechat-apps4y6.vercel.app/


• 部署还踩坑了 MCP 在 Vercel 上不生效是因为 Vercel 是 serverless 环境，不支持运行持久的子进程。让我帮你解决这个问题：


• 主要是对最近项目组内要用的到mcp/function call 进行实践操作 使用modelscope 上面开源的mcp进行尝试 使用vercel进行部署。


• 最近看到小红书上面的3d 粒子 圣诞树有点火呀，自己也尝试下 效果很差 自己弄的提示词 可以去看看帖子上的提示词去试试 他们都是gemini pro 3玩的 我也去弄个gemini pro 3 账号去玩玩。


• 还有一个3d粒子 跟着音乐动的的效果 下面的提示词可以试试

帮我构建一个极简科幻风格的 3D 音乐可视化网页。

视觉上参考 SpaceX 的冷峻美学，全黑背景，去装饰化。核心是一个由数千个悬浮粒子组成的‘生命体’，它必须能与声音建立物理连接：低音要像心脏搏动一样冲击屏幕，高音要像电流一样瞬间穿过点阵。

重点实现一种‘ACID 流体’视觉引擎：让粒子表面的颜色不再是静态的，而是像两种粘稠的荧光液体一样，在失重环境下互相吞噬、搅拌、流动，且流速由音乐能量驱动。

• docs.langchain.com/oss/javascr…


• http://www.modelscope.ai/home


• vercel.com


• http://www.modelscope.ai/mcp

ai方向 总结

• a2a解决的是agent之间如何配合工作的问题 agent card定义名片 名称 版本 能力 语言 格式 task委托书 通信方式http 用户 客户端是主控 接受用户需求 制定具体任务 向服务器发出需求 任务分发 接受响应 服务器是各类部署好的agent 遵循一套结构化模式


• mcp 解决的llm自主调用功能和工具问题


• mcp 是解决 function call 协议的碎片化问题，多 agent 主要是为了做上下文隔离


• 比如说手机有一个system agent 然后各个app有一个agent，用户语音输入买咖啡，然后system agent调用瑞幸agent 这样就是非侵入式 让app暴露系统a2a接口，感觉比mcp要更合理一点，不是单纯让app暴露tools，系统agent只需要做路由


• 而且有一点我觉得挺有意思的，就是自己的agent花的token是自己的钱，如果自己的agent找别人的agent，让它执行任务啥的，花的不就是别人的钱……


• Dify：更像宜家的模块化家具，提供可视化工作流、预置模板，甚至支持“拖拽式”编排AI能力。比如，你想做一
  个智能客服，只需在界面里连接对话模型、知识库和反馈按钮，无需写一行代码

python 和ts 在ai上面的比较

• Python 依然是 AI 训练和科研的王者，PyTorch、TensorFlow、scikit-learn 这些生态太厚实了，训练大模型你离不开它。


• TS 在底层 AI 能力上还没那么能打，GPU 加速、模型优化这些，暂时还得靠 Python 打底。


• Python 搞理论和模型，TypeScript卷体验和交付

个人学习记录

主要还是前端和ai方面的知识点学习的比较多吧

• Typescript 语法基础+进阶 / Next.js 开发指南/React 开发指南


• ahooks 组件 使用 ahooks.js.org/zh-CN/hooks…


• ant design x 使用 ant-design-x.antgroup.com/components/…


• prisma orm框架 +mysql github.com/prisma/pris…


• dotenv 读取配置文件 github.com/dotenvx/dot…


• fastmcp 项目构建使用 原理


• Agent2Agent google协议内部详情
  
  
  
  • github.com/MarkTechSta…
  
  
  • github.com/a2aproject/…
  
  
  • a2a-protocol.org/latest/topi…
  
  
  
  


• swagger.io/specificati… OpenAPI 规范 一个 OpenAPI 描述（OAD）可以由一个 JSON 或 YAML 文档组成


• github.com/yossi-lee/s… 根据Swagger3规范，一键将Web服务转换为MCP


• http://www.jsonrpc.org/specificati… JSON-RPC 是一种无状态、轻量级的远程过程调用（RPC）协议


• github.com/agno-agi/ag… 多智能体框架


• roadmap.sh/ai-engineer ai工程师的roadmap 很全


• github.com/ChromeDevTo… *可以集成到cursorz中 *AI 能够直接控制和调试真实的 Chrome 浏览器


• http://www.nano-banana.ai/ Nano Banana Pro (V2) 文生图 图生图


• aistudio.google.com/prompts/new… gemini ai studio

Vibe Coding

• 先叠甲, 我没有前端的开发经验，第一次写前端项目，项目里面90%的前端代码都是ai 生成的，能够让你一个不会前端的同学也快速完成mvp版本/需求任务。我虽然很推ai coding 很喜欢用, 即时反馈带来的成就感, 但是对于生成的代码是不是屎山 大概率可能是了, 因为前期 AI速度快，制造屎山的速度更快。无论架构设计多优秀，也难避免屎山代码的宿命: 需求一直在变，你的架构设计是针对老的需求，随着新的需求增加，老的架构慢慢的就无法满足了，需要重构。


• 一起开发的前端同事都说ai生成那些样式互相影响了,样式有tailwindcss 有自定义的css 每个模块又有不同 大概率出问题 有冲突，就是💩山。


• 最大的开发障碍就是内心的偏见 不愿意放弃现在所擅长的东西 带着这份偏见不愿意去学习

对于ai coding 的话 用过trae-pro/cursor/qoder/copilot/codex等等 最终还是cursor claude 4.5用的最舒服

• 基本一周一个cursor pro账号 买号都花了快1k了。

You have used up your included usage and are on pay-as-you-go which is charged based on model API rates. You have spent $0.00 in on-demand usage this month.

• 最后就是需要学好英语 前端的技术文档都是英文的 虽然有中文的翻译版本, 但没有自己直接去看官方的强 难免有差异， 我现在都是用插件进行web翻译去看的 很累。


• 现在时间是凌晨 11/30/02:36 喝了两瓶酒。这个周末我要重温甜甜的恋爱 给我也来一颗药丸 给时间是时间 让过去过去, 年底想去日本跨年了

Vue 开发者可能都注意到，UnoCSS 的讨论频率越来越高。它不像 Tailwind 那样有营销声势，不像 Windi 那样起得早，却在 2024 年之后逐渐“渗透”进越来越多的 Vue 项目中。很多团队从 Tailwind、Windi CSS、SCSS 等方案“迁徙”到了 UnoCSS。看似只是换了个工具，实际上却是一种更深层次的开发范式迁移。

为什么 UnoCSS 会被 Vue 项目偏爱？它到底解决了哪些问题？又会引发哪些新的思维变化？这篇文章，我们来拆开 UnoCSS 背后的真实诱因。

🎯 UnoCSS 到底是什么？一句话不够解释

如果你只把 UnoCSS 理解为“一个类 Tailwind 的原子化 CSS 工具”，那你可能漏掉了它真正颠覆的部分。

UnoCSS 是一个：

• 即写即用的原子 CSS 引擎，没有预定义 class（tailwind.config.js？你可以不用）


• 即时编译（on-demand generation） ，不扫描模板、不打包 CSS 文件，运行时动态生成样式表


• 支持任意规则组合，语义可扩展，能自动拼装 hover:bg-red-500/30 md:rounded-xl 这种复杂 class


• 插件式运行机制，样式规则 = 插件，想加功能不用改源码

简单说：UnoCSS 就像是原子 CSS 界的「Vite」，更轻，更快，更灵活。

🧩 Vue 项目迁移 UnoCSS 的几个主要诱因

1. 开箱即用，没有冗余配置

Tailwind 开发中一个不成文的痛点是配置文件维护成本：你几乎必须写一堆 tailwind.config.js 来扩展自己的颜色、字体、断点。

而 UnoCSS 有个“离谱”的特性：

你甚至可以不用写 config 文件。

举例：

<div class="text-lg font-bold text-[#3a7afe] hover:opacity-80">

颜色？随便写 HEX。你想用 shadow-[0_0_12px_rgba(0,0,0,0.2)]？它也认。基本告别 theme.extend。

这对 Vue 项目尤其友好 —— 组件就是 class 的封装，不需要额外定义 token。

2. 它更像 JS，而不是传统 CSS 工具

UnoCSS 本质上是一组「语法规则 + 解析器」，所有东西都是基于插件机制动态生成的。这点非常 Vue-ish。

比如你想扩展 btn-primary：

rules: [

  ['btn-primary', 'px-4 py-2 rounded bg-blue-500 text-white']

]

配合 Vue + Script Setup，甚至可以做到“功能指令式”的组件：

<button class="btn-primary hover:bg-blue-600">提交</button>

这是 Tailwind 无法比拟的灵活度，尤其当你想跨多个组件“语义复用”样式，而又不想搞复杂的 SCSS。

3. Vue SFC 中语法体验更佳

UnoCSS 不依赖 Preflight，不污染全局，也不会把所有 class 编译成一大坨 CSS 文件。

更关键的是，在 Vue SFC 中，它可以配合原子类的组合器变得非常语义化。

<div class="grid grid-cols-[1fr_auto] gap-4 items-center sm:(grid-cols-1 gap-2)">

括号组合、嵌套媒体查询、状态嵌套，全都写在 class 中，无需管理额外 CSS 文件，非常适合组件化开发。

4. 和 Vue 生态绑定更深

UnoCSS 的创作者之一是 Anthony Fu，也就是 VueUse、Vitesse、Vitest 的作者。

换句话说：UnoCSS 是为 Vue 项目天生设计的原子 CSS 工具，生态协同、理念统一。

你可以在 VitePress、Nuxt、Vitesse、VueUse 所有项目中一键集成 UnoCSS，毫不费力。插件如 @unocss/nuxt、@unocss/vite 也都官方维护，集成体验比 Tailwind 更丝滑。

📉 传统方案的反衬：你为什么“受够了 Tailwind”

• 写多了 text-sm text-neutral-700 font-medium leading-relaxed tracking-wide，你会厌烦堆 class


• 为了统一样式，你又开始封装 btn、card、tag 等组件，但 Tailwind 里没法抽离 class 成变量


• 你想写一些自由样式（如text-[rgba(0,0,0,0.75)]），却必须配置 tailwind.config.js，开发体验断层

UnoCSS 这时候就像一口“无限制自助餐”：你想吃什么，厨房就给你端上来。

🧪 真正让它爆红的项目：Nuxt 生态

Nuxt 3 和 UnoCSS 简直天作之合。

如果你用 Nuxt，安装 UnoCSS 就一行命令：

npm i -D @unocss/nuxt

甚至不需要配置，直接写：

<template>

  <section class="text-center text-4xl text-gradient from-pink-500 to-yellow-500">

    Hello, UnoCSS

  </section>

</template>

想封装组件？直接写 variant 和 shortcuts，体验跟设计 token 一样自然：

shortcuts: {

  'btn': 'px-4 py-2 font-bold rounded',

  'btn-primary': 'btn bg-blue-500 text-white hover:bg-blue-600'

}

🧠 真正带来的范式转变

UnoCSS 不只是工具上的优化，它还改变了我们使用 CSS 的方式：

• 从维护样式表 → 动态生成样式


• 从配置颜色 → 直接在组件中定义 token


• 从 class 管理 → 到语义表达

传统做法是围绕“命名”，而 UnoCSS 更像是在写“表达式”。这种范式变化，决定了它会逐渐成为 Vue 项目的原子化首选。

📌 使用 UnoCSS 时的真实建议

• 如果你的项目刚启动，用 UnoCSS 会极大加快开发速度


• 如果你在维护大型 Vue 项目，建议先从局部引入，避免和 Tailwind 冲突


• 如果你对设计规范要求较高，UnoCSS 支持 theme、rules、shortcuts 构建完全定制化体系


• 建议启用 VSCode 插件，否则开发体验会下降

✅为什么 UnoCSS 会流行？

因为它比 Tailwind 更轻，比 Windi 更快，比 SCSS 更灵活。而且，它是为 Vue 项目量身定制的。

不再“配置样式”，而是“表达样式”；不再围着类名转，而是围着组件转。

UnoCSS 不只是一个工具，而是一种更贴近 Vue 哲学的“开发语言”。

设计小姐姐： “搞一下这样的回弹效果，你行不行？”

我：“行！直接梭哈 50 行 keyframes + transform + 各种百分比，搞定 ”

设计小姐姐：“太硬（撇嘴），不够 Q 弹（鄙视）”

我：(裂开)

隔壁老王：这么简单你都不行，我来一行贝塞尔 cubic-bezier(0.3, 1.15, 0.33, 1.57) 秒了😎

设计小姐姐：哇哦！（兴奋）好帅！（星星眼🌟）好Q弹！（一脸崇拜😍）

我：“？？？”

🧠 一、为什么一行贝塞尔就能“Duang”起来？

1️⃣ cubic-bezier 是什么？

在 CSS 动画里，我们经常写：

transition: all 0.5s ease;

但其实 ease、linear、ease-in-out 这些都只是封装好的贝塞尔曲线。

底层原理是：

cubic-bezier(x1, y1, x2, y2)

这四个参数定义了时间函数曲线，控制动画速度的变化。

• x：时间轴（必须在 0～1 之间）


• y：数值轴（可以超出 0～1！）

👉 当 y 超过 1 或小于 0 时，动画值就会冲过终点再回弹，

这就是“回弹感”的核心。

2️⃣ 回弹的本质：过冲 + 衰减

想象一个球掉下来：

• 过冲：球落地时会压扁（超出终点）


• 回弹：然后反弹回来，再逐渐稳定

在动画中，这个“过冲”就是 y>1 的部分，

而“回弹”就是曲线回到 y=1 的过程。

🧪 二、一行贝塞尔的魔法

✅ 火箭发射

<div class="bounce">🚀发射！</div>



<style>

.bounce {

 transition: transform 0.8s cubic-bezier(0.68, -0.55, 0.27, 1.55);

}

.bounce:hover {

 transform: translateY(-500px);

}

</style>

💡 参数解析：

• y1 = -0.55 → 先轻微反向缩小


• y2 = 1.55 → 再冲过头 55%，最后回弹到原位

🧩 四、常用贝塞尔参数

🧰 五、调试神器推荐

• 🎨 cubic-bezier.com
  
  拖动手柄实时预览动画，复制参数一键搞定。


• ⚙️ easings.net
  
  收录各种 easing 函数（含物理弹簧、阻尼等）。

你好，我是木亦。我不知道你是否了解过 WebRTC（Web Real - Time Communication），但不得不承认，WebRTC 凭借其无需安装插件、支持浏览器间直接通信的显著优势，已成为实现网页端视频通话的不二之选。对于前端开发者而言，深入掌握 WebRTC 实现视频通话的开发流程，能够为用户打造出更加丰富多元、即时高效的互动体验。这篇文章将会向你介绍使用 WebRTC 实现视频通话的开发步骤。

一、项目初始化

在开启开发之旅前，首要任务是创建一个全新的前端项目。你可以借助常见的项目初始化工具，像create-react-app（适用于 React 项目）、vue-cli（适用于 Vue 项目），或者直接创建一个简洁的 HTML 页面。

使用 create-react-app 初始化项目

npx create-react-app webrtc-video-call

cd webrtc-video-call

使用 vue-cli 初始化项目

npm install - g @vue/cli

vue create webrtc-video-call

cd webrtc-video-call

如果选择直接创建 HTML 页面，其基本结构如下：

<!DOCTYPE html>

<html lang="en">

  <head>

    <meta charset="UTF - 8">

    <title>WebRTC Video Call</title>

  </head>

  <body>

    <!-- 后续添加视频通话相关元素 -->

  </body>

</html>

二、引入 WebRTC 库

WebRTC 作为现代浏览器的内置功能，无需额外引入第三方库。在编写 JavaScript 代码时，可直接调用 WebRTC 提供的 API。

检测浏览器支持

if ('RTCPeerConnection' in window && 'RTCSessionDescription' in window && 'navigator.mediaDevices' in window) {

  // 浏览器支持WebRTC

  console.log('WebRTC is supported');

} else {

  console.log('WebRTC is not supported in this browser');

}

通过上述代码，可快速判断当前浏览器是否支持 WebRTC，确保开发工作在兼容的环境下进行。

三、获取媒体设备权限

实现视频通话的第一步，是获取用户摄像头和麦克风的使用权限。

使用 navigator.mediaDevices.getUserMedia ()

const constraints = {

  video: true,

  audio: true

};

navigator.mediaDevices.getUserMedia(constraints)

  .then((stream) => {

    // 成功获取媒体流，可用于视频显示

    const videoElement = document.createElement('video');

    videoElement.srcObject = stream;

    videoElement.autoplay = true;

    document.body.appendChild(videoElement);

  })

  .catch((error) => {

    console.error('Error accessing media devices:', error);

  });

在这段代码中，constraints对象明确指定了需要获取视频和音频权限。getUserMedia()方法返回一个 Promise，当操作成功时，会返回包含媒体流的stream对象，随后便可将其绑定到video元素上，实现本地视频的实时显示。

四、建立对等连接

WebRTC 通过 RTCPeerConnection 对象建立对等连接，实现双方媒体数据的高效传输。

创建 RTCPeerConnection 对象

// 创建RTCPeerConnection对象

const peerConnection = new RTCPeerConnection({

  iceServers: [

    { urls:'stun:stun.l.google.com:19302' }

  ]

});

这里借助了 STUN（Session Traversal Utilities for NAT）服务器辅助建立连接，stun.l.google.com:19302是 Google 提供的公共 STUN 服务器，能有效帮助穿越网络地址转换（NAT）设备。

处理 ICE 候选

在连接建立过程中，处理 ICE（Interactive Connectivity Establishment）候选至关重要，这有助于寻找到最佳的连接路径。

peerConnection.onicecandidate = (event) => {

  if (event.candidate) {

    // 将ICE候选发送给对方

    // 这里需要实现发送逻辑，例如通过信令服务器

    console.log('ICE candidate:', event.candidate);

  }

};

当有 ICE 候选生成时，需及时将其发送给对方，实际应用中通常借助信令服务器完成这一操作。

交换 SDP（Session Description Protocol）

SDP 用于详细描述媒体会话的各项参数，双方需交换 SDP 以协商媒体格式、编解码方式等关键信息。

// 创建Offer

peerConnection.createOffer()

  .then((offer) => {

    return peerConnection.setLocalDescription(offer);

  })

  .then(() => {

    // 将本地的SDP发送给对方

    // 这里需要实现发送逻辑，例如通过信令服务器

    console.log('Local SDP:', peerConnection.localDescription);

  })

  .catch((error) => {

    console.error('Error creating offer:', error);

  });

// 接收对方的SDP并设置为远程描述

peerConnection.setRemoteDescription(new RTCSessionDescription(receivedSDP))

  .then(() => {

    // 接收对方的Offer后，创建Answer

    return peerConnection.createAnswer();

  })

  .then((answer) => {

    return peerConnection.setLocalDescription(answer);

  })

  .then(() => {

    // 将本地的Answer发送给对方

    // 这里需要实现发送逻辑，例如通过信令服务器

    console.log('Local SDP (Answer):', peerConnection.localDescription);

  })

  

  .catch((error) => {

    console.error('Error setting remote description or creating answer:', error);

  });

这部分代码展示了创建 Offer、设置本地描述、发送本地 SDP，以及接收对方 SDP 并创建 Answer、设置本地描述、发送本地 Answer 的完整流程。

五、显示远程视频

当双方成功建立连接并完成 SDP 交换后，便可接收对方的媒体流，实现远程视频的显示。

监听 track 事件

peerConnection.ontrack = (event) => {

  const remoteVideoElement = document.createElement('video');

  remoteVideoElement.srcObject = event.streams[0];

  remoteVideoElement.autoplay = true;

  document.body.appendChild(remoteVideoElement);

};

一旦接收到对方的媒体流，ontrack事件就会被触发，此时将接收到的媒体流绑定到新创建的video元素上，即可实时显示远程视频画面。

六、信令服务器的作用与实现

在 WebRTC 视频通话中，信令服务器承担着交换 SDP 和 ICE 候选等关键信息的重要职责。尽管 WebRTC 实现了媒体数据的直接传输，但信令的交互仍需借助服务器来完成。

信令服务器的选择

可选用 WebSocket、Socket.IO 等技术搭建信令服务器。以 Socket.IO 为例，搭建一个简易信令服务器的步骤如下：

npm install socket.io

简单的 Socket.IO 信令服务器示例

const io = require('socket.io')(3000);

io.on('connection', (socket) => {

  socket.on('offer', (offer) => {

    // 这里可以实现将offer转发给目标客户端

    console.log('Received offer:', offer);

  });

  socket.on('answer', (answer) => {

    // 这里可以实现将answer转发给目标客户端

    console.log('Received answer:', answer);

  });

  socket.on('ice - candidate', (candidate) => {

    // 这里可以实现将ice - candidate转发给目标客户端

    console.log('Received ice - candidate:', candidate);

  });

});

在前端代码中，需引入 Socket.IO 客户端库，并精心编写与服务器的通信逻辑，实现将 SDP 和 ICE 候选发送至服务器，以及从服务器接收对方的 SDP 和 ICE 候选。

WebRTC 实现视频通话的前端开发涵盖多个关键环节，从项目初始化、获取媒体设备权限，到建立对等连接、交换 SDP 和 ICE 候选，再到显示远程视频和搭建信令服务器。通过逐步掌握这些核心步骤，前端开发者能够构建出功能完备的视频通话应用，为用户提供流畅、实时的视频通信体验。在实际开发过程中，还需依据具体需求和应用场景，对代码进行优化与扩展，以充分满足多样化的业务需求。

5@2x.png" loading="lazy" src="https://www.imgeek.net/uploads/article/20260118/718ea69cb7313b0faba4510956153837.jpg"/>

大家好，我是 一颗烂土豆。

最近在数据可视化领域进行了一些探索，基于 Vue 3 和 Three.js 开发了一款轻量级的 3D 图表库 —— raychart.js。

今天不谈晦涩的代码实现，主要和大家分享一下这个项目的设计初衷、目前进展以及未来的规划。

💻 在线体验：chart3js.netlify.app/

🌟 愿景 (Vision)

在实际开发中，我们往往面临两难的选择：要么使用传统的 2D 图表库（如 ECharts）通过“伪 3D”来实现效果，但缺乏立体感和自由视角；要么直接使用 Three.js 从零撸，成本高且难以复用。

chart3 的诞生就是为了解决这个问题，它的核心愿景是：

🚀 现状 (Current Status)

目前项目处于快速迭代阶段，核心引擎已经搭建完毕，并实现了一套可视化的配置系统。你可以通过 在线 Demo 实时调整参数并预览效果。

已支持的功能特性：

• 基础图表组件：
  
  
  
  • 📊 3D 柱状图 (Bar3D)：支持多系列、不同颜色的柱体渲染。
  
  
  
  

• 🥧 3D 饼图 (Pie3D)：支持扇区挤出高度、标签展示。

* 📈 3D 折线图 (Line3D)：支持管状线条渲染。

* 🌌 3D 散点图 (Scatter3D)：支持三维空间的数据点分布。

• 可视化配置系统：
  
  
  
  • 数据源 (Data)：支持静态数据配置。
  
  
  • 主题与配色 (Theme)：内置多套配色方案，支持自定义默认颜色。
  
  
  • 坐标系 (Coordinate)：可实时调整网格的宽度、深度、高度，以及各轴线、刻度、网格线的显示与隐藏。
  
  
  • 材质系统 (Material)：这是 3D 图表的灵魂。支持实时调节透明度、粗糙度 (Roughness)、金属度 (Metalness)，轻松实现玻璃、金属等质感。
  
  
  • 灯光系统 (Lighting)：支持环境光和方向光的强度与位置调节，营造氛围感。
  
  
  • 交互 (Interaction)：支持鼠标悬停高亮、HTML 标签 (Label) 自动跟随。
  
  
  
  

📅 待实现的任务 (Roadmap)

为了让 chart3 真正成为生产可用的图表库，后续还有很多有趣的工作要做：

• 高级图表开发：
  
  
  
  • 🌊 3D 曲面图 (Surface 3D)：用于展示复杂的三维函数或地形数据（目前 Demo 中显示为“待开发”）。
  
  
  • 🗺️ 3D 地图 (Map 3D)：支持 GeoJSON 数据的三维挤出渲染。
  
  
  
  


• 性能优化：
  
  
  
  • 引入 InstancedMesh 技术，大幅提升大数据量（如 10w+ 散点或柱体）下的渲染性能。
  
  
  
  


• 动画系统：
  
  
  
  • 实现图表的入场动画（如柱子升起、饼图展开）。
  
  
  • 数据更新时的平滑过渡动画。
  
  
  
  


• 工程化与文档：
  
  
  
  • 完善 API 文档和使用指南。
  
  
  • 提供 NPM 包发布，方便项目集成。
  
  
  
  

🤝 结语

这个项目是我对“数据可视化 x 3D”的一次尝试。

让我们一起把数据变得更酷一点！

你好呀，我是歪歪。

前两天不是发了这篇《可怕，看到一个如此冷血的算法。》嘛。

文章中有这样的一个链接：

我当时放这个链接的目的是为了方便大家直达吃瓜现场。

但是，由于这个帖子最终被证实是假的，所以被官方给“夹”了：

幸好，原文本来就不长，所以我在我的文章中把原文全部给截下来了。

也算是以另外一种形式保留了吃瓜现场。

如果这个“爆料”的帖子再长一点，按照我的习惯，我可能就不会把整个帖子搬运过来了，只会留取我认为关键的部分。

但是这种“我认为关键的部分”是非常主观的，有的人就是想看原贴长什么样，但是原贴又被删除了，怎么办？

我教你一招，老好用了。

时间胶囊

在万能的互联网上，有这样一个仿佛是时间胶囊一般存在的神奇的网站：

archive.org/

这个网站是叫做"互联网档案馆"（Internet Archive），于 1996 年成立的非营利组织维护的网站。

自 1996 年以来，互联网档案库与世界各地的图书馆和合作伙伴合作，建立了一个人类在线历史的共享数字图书馆。

这个网站有一个非常宏大的愿景：

捕捉大小不一的网站，从突发新闻到被遗忘的个人页面，使它们能够为子孙后代保持可访问性。

所以里面收藏了的内容有免费书籍、电影、软件、音乐、网站等。

截至目前，该网站收集了这么多的数据：

其中网站的数量是最多的，有 1T，超过 1T 的时候，官方还发文庆祝了一下：

这个 1T 中的 T 指的是什么呢？

Trillion。

一个非常小众的词汇啊，歪师傅也不认识，所以我去查了一下：

这个图片上一眼望去全是 0。

1 Trillion 就是 1,000,000,000,000

反正是数不过来了。

感觉成都都没有这么多 0。

这个网站怎么用呢？

很简单。

拿前面 reddit 中被“夹”了的帖子举例。

我不是给了吃瓜现场的链接嘛。

你把链接往“时光机”的这个地方一粘：

你就会看到这个有一个时间轴的页面：

把鼠标浮到有颜色的日期上，就能看到各个时间点的页面快照了。

颜色越深代表那一天的快照越多：

比如，我们看一下这个网站收集到的第一个快照：

点进去，就是我们要找的吃瓜现场。

发帖后的两小时就被收集到了，速度还是挺快的。

从数据上看，这个时候已经有 3.7k 个点赞和 255 个评论，已经有要起飞的预兆了。

换个时间的快照，还可以看到点赞和评论的数据变化，比如发帖一天后：

点赞量已经是 71k，评论数来到了 3.8K，直接就是一个起飞的大动作。

这里只是用这个帖子举个例子。

再举一个例子。

也是我的真实使用场景。

有一次我在研究平滑加权轮询负载均衡策略算法为什么是平滑的。

和各类 AI 讨论了半天，它们也给出了各种参考文献。

我在其中一个参考文献中看到了这样一个链接：

tenfy.cn/2018/11/12/…

我知道这个链接的内容就是我要找的内容，但是这个链接跳转过去已经是 404 了：

于是，时间胶囊就派上用场了。

我直接把这个链接扔它：

找到了这个网页在 2019 年 12 月 10 日的快照：

通过这种方式就找到了原本已经被 404 的网页内容。

在看一些时间比较久远的文章的时候，参考链接打不开的情况，还是比较常见的。

所以这个方式是我最常用的一个场景。

此外，还有另外一个场景，就是偶尔去怀旧一下。

比如，中文互联网的一滴眼泪：天涯论坛。

这是 20 年前，2006 年 1 月的天涯论坛首页，一股浓烈的早期互联网风格：

在图片的右下角你还能看到“2006 天涯春晚”的字样。

另外，你不要觉得这只是一个静态页面。

里面的部分链接还是可以正常跳转的。

比如，这个链接：

点进去，你可以看到最最古早的一种直播形式：文字直播。

2006 年 1 月 2 日，《武林外传》开播。

天涯这个文字直播的时间是 2006 年 1 月 19 日，《武林外传》当时正在全国热播。

天涯网友在这个页面下提出自己关于《武林外传》的问题，作为天涯的知名写手，宁财神本人会选择部分问题进行回复。

我截取了几个我觉得有意思的回复：

这种行为这算不算是官方剧透了？

当年祝无双这个角色是真的不让人讨喜啊。幸好当时的网络还不发达，不然我觉得真有可能“网爆祝无双”。

DVD，一个多么具有年代感的词。

写文章的时候，我本来是想截几张图就走的，最多五分钟搞定。

结果我竟然一页页的翻完了这个帖子，看完之后才发现在这个帖子里面待了半个多小时。

时间过的还是很快的。

站在 2026 年，看 2006 的帖子，中间有 20 年的光阴。

但是就像是 2006 年佟掌柜对要给她干二十年工才能还清债务的小郭说的那样：不要怕，二十年快得很，弹指一挥间。

前几天小郭在微博上还回应了正式赎身这个梗。

去了六里桥、去了同福夹道、去了左家庄站、还去了祥蚨瑞，最后在人来人往的北京街头，一个猝不及防的回眸：

这是我的童年回头看了我一眼。

十几岁的不了解佟掌柜的这句话，三十出头了，一下就理解了：20 年，真的很快呀。

看到 2006 年的天涯的时候，我依稀想起了一些当年的往事。

那个时候我才 12 岁，看电视剧是真的在电视机上看，我还记得家里的电视机都是这样的“大屁股”电视机：

还记得《武林外传》每集开始，唱主题曲的时候，电视上面会显示一个电脑的桌面：

所以每次开头的时候，我就会叫表妹过来，对她说：你看，我等下把电视变成电脑。

那个时候表妹才 7 岁，我这个 12 岁的哥哥当然是把她唬的一愣一愣的。

那个时候电脑也还是一个稀奇的物品，虽然是乡下的学校，但是也还是有一个微机室，去微机室上课必须要带鞋套的那种。

所以 2006 年的天涯，我肯定是没有看过的，但是在 2026 年看到 2006 的天涯，我还是想起了很多童年往事。

对了，前几天才给表妹过完 27 岁的生日：

看着这张照片，再想起 7 岁时那个相信哥哥可以把电视变成电脑给她看《武林外传》的妹妹。

“二十年快得很，弹指一挥间”。

你说这不叫时间胶囊，叫什么？

再看一下 10 年前，2016 年 1 月 1 日的天涯，彼时的天涯可以说是如日中天，非常多的网友天天泡在论坛里面，谈古论今，激扬文字。

这是那天的天涯首页截图：

热帖榜第一的是一个关于纯电动汽车的帖子，我进去看了一下：

这个帖子的点击量是 10w，有 816 个回复。

可见这确实是当时的一个非常热门的话题。

按照作者的观点，纯电汽车代替燃油汽车，还很长的路要走。

站在 10 年后的今天，其实我们已经知道答案了。

但是，当我看到这个回复的时候，我还是佩服天涯网友的眼光：

除了天涯，还可以考古很多其他的网站。

比如，B 站：

从 2011 年开始有了网页快照，我随便点开一看，满满的历史感：

而这是 2016 年，10 年前的 B 站首页：

当时还有一个专门的鬼畜区：

而这里的一些视频甚至还是可以播放的。

比如这个“启蒙作品”：

现在在 B 站有 160w 的播放：

在这个视频的评论区，你能找到大量来“考古”的人：

二十年都弹指一挥间了，别说区区十年了。

从 B 站怀旧完成后，随便，我也去磨房、马蜂窝、穷游网看了一圈，随便选了 2012 年到 2016 年间的一些页面，感谢它们陪我度过了一整个美好的大学生活。

是我当时认识、感知、体验这个的广阔世界的一个重要窗口。

感谢磨房 4 年的陪伴：

感谢马蜂窝 4 年的陪伴：

感谢穷游网 4 年的陪伴：

如果你也有想要寻找的记忆，可以尝试在这个网站上去找一找。

存档

既然已经聊到“archive”了，那就顺便再分享一个“archive.today”。

archive.ph/

这个网站和前面的“互联网档案馆”最大的一个差异是“互联网档案馆”是它主动去做“网页快照”，什么时候做，什么页面做，并不一定。

而“archive.today”是一个你可以去主动存档的网站。

比如，还是说回 reddit 上的那个帖子。

帖子下面有这样的一个回复：

这个回复中的超链接就是回复者找到的关于这个“爆料”是 AI 生成的证据。

点过去是这样的：

他提供的是一个网页存档。

为什么他要这么做呢？

你想想，如果他提供一个原始链接，但是这个原始链接突然有一天找不到了，岂不是很尴尬？

但是先在“archive.today”上存档一下，然后把这个存档后的链接贴出来，就稳当多了。

以后你要保存证据的话，你就可以使用这个网站。

另外，这个网站还有一个骚操作。

反而是骚操作让这个网站的打开率更高一点。

国外的一些网站可能有些文章是要付费才能看到的。

比如纽约时报：

但是，如果你一不小心把付费文章的链接贴在这个网站上去搜索。

有一些“好事之人”已经帮你把文章在这个网站上做了快照了，这些人可以称之为“赛博菩萨”，因为这些“菩萨”，你就可能看到免费的原文了：

在这里叠个甲啊，偶尔看到一两篇的话可以这样操作一下，就当时是试看了。

如果经常要看的话，还是充点钱吧。

对了，多说一句，上面提到的神奇的网站既然叫做时光胶囊，还有一些赛博菩萨，这些魔法世界中才有的东西，那肯定需要你会对应的魔法咒语才能访问到。如果你不会魔法，强行访问，那你肯定要撞到墙上。

1. 前言

2025 年是 Web 开发的分水岭。

之前 Web 开发领域一直发展迅速，几乎每天都有新的工具和框架涌现。

但到了 2025 年，这种发展速度直接呈指数级增长。

之所以有这种变化，很大程度上是因为 AI 工具的高效性，它们直接将生产力提升了 3 倍！

想想几年前，我们还在争论 GitHub Copilot 这样的 AI 工具是否可靠，如今，AI 已经能构建完整的全栈应用程序了！。

这也让不少人担忧，AI 是否真的能取代我们。

站在 2026 年的门槛上，让我们一起看看，今年会有哪些真正影响你我的技术趋势。

注意：这不是那种“5 年以后”的远景预测，而是今年你就有可能遇到的实实在在的变化。

2. AI 优先开发

AI 工具已经不再试一个简单的代码补全工具，它已经成为开发的核心组成部分。

开发人员更像是架构师的角色，监督 AI 智能体工作。毕竟 AI 智能体已经可以根据 Figma URL 或自然语言提示搭建完整的功能框架。

AI 也在重塑开发者探索和理解代码的方式。

团队不再需要手动阅读庞大的代码库，利用 AI 直接可以解释不熟悉的逻辑、追踪数据流并发现边缘 case。这极大地缩短了新用户上手时间，也让大型项目更易于操作。

因此，采用 AI 优先开发的团队将减少在机械性工作上花费的时间，而将更多精力投入到项目架构、用户体验的优化上。

这些工具虽然不能编写完美的代码，但它们会改变开发人员的精力投入方向。

3. 元框架成为默认设置

还记得当年选技术栈时的纠结吗？

路由用哪个？打包工具选什么？状态管理怎么办？

现在，这些问题都有了一个标准答案：用 Next.js 或 Nuxt 就完了。

因为这些元框架就是一个“全家桶套餐”，把你需要的所有东西都打包好了。

路由、数据获取、缓存、渲染策略、API 接口……统统内置。很多时候，后端就是前端项目里的一个文件夹。

AI 工具的兴起也加速了这一转变。现在大多数生成式 UI 构建器默认都会生成元框架项目。Vercel 自家的构建器 v0 就是一个很好的例子：开箱即用，直接输出 Next.js 应用程序。

对开发者来说，这是个好消息，意味着你可以把更多精力放在业务逻辑上，而不是纠结工具链的选择。

4. 前端开发 TanStack 化

虽然元框架提供了结构，但 TanStack 套件（查询、路由、表格、表单）已成为逻辑层的实际标准。

从最早的 TanStack Query（以前叫 React Query）处理数据获取和缓存，到现在的 Table、Form、Router、Store……它几乎覆盖了前端开发的方方面面。

2025 年，TanStack 又推出了 DB、AI 等新工具，从库升级成了一个完整生态。

TanStack 最大的优势就是框架无关、实用至上。

无论你用 React、Vue 还是其他框架，TanStack 都能无缝接入。而且它的设计理念很务实，解决的都是开发中的实际痛点。

TanStack 俨然成为前端界的“瑞士军刀”。

5. TypeScript + 服务端函数，告别传统后端

TypeScript 已经是标配，2026 年还在写 JavaScript 多少有些过时了。

而且随着服务端函数和托管后端的流行，前端和后端的界限将越来越模糊。

举个例子：

使用 tRPC，你可以在前端直接调用后端函数，而且类型完全同步。不需要手写 API 文档，不需要维护接口定义，改了后端，前端自动感知。

这就好比以前你要写信寄到邮局，现在直接打电话——即时、准确、零误差。

6. React 编译器越来越普及

还记得为了优化性能，到处写 useMemo、useCallback、React.memo 的日子吗？

React 编译器（React Compiler）在 2025 年 10 月发布 v1.0 后，已经开始大规模应用。它能在构建时自动处理性能优化，你只管写清晰的代码，编译器帮你搞定优化。

就像相机的自动对焦——以前要手动调，现在按快门就行。

如今 Next.js 16、Vite、Expo 等主流工具已经内置了 React 编译器。

创建新项目时，它就是默认配置的一部分。

这对新手特别友好。不用纠结性能问题，专注于功能实现就好，代码也更简洁易读。

7. 边缘计算开始普遍

以前部署应用，服务器可能在北京，广州的用户访问就慢半拍。

边缘计算的核心思路是：让代码跑在离用户最近的节点上。

你在上海？就用上海的服务器。你在成都？就用成都的。延迟大幅降低，响应速度更快。

而且现代框架的很多特性——比如服务端函数、流式响应——天生就适合边缘部署。再加上 AI 工具（像 v0、Lovable）一键生成边缘应用，这个趋势已经不是“要不要”的问题，而是“什么时候”的问题。

到 2026 年，边缘部署会成为默认选项。作为开发者，你需要习惯在设计时就考虑边缘环境的特点。

8. CSS：原生能力回归，实用工具辅助

原生 CSS 这些年在不断进化。

容器查询、层叠样式表、CSS 变量、现代颜色函数……这些新特性让 CSS 的表达能力大幅提升。

于是现在的趋势变成了混合使用：传统的实用类负责快速搭建，原生 CSS 负责精细控制。

比如特定样式以 CSS 变量的形式表示，变体和主题通过 layers 和选择器来处理，而不再依赖构建时处理。

9. React 安全性提升

202025 年，React 生态爆出了不少安全漏洞，比如 Next.js 中间件漏洞和 React2Shell。

这是因为前端承担的责任越来越重。

以前前端就负责展示，安全问题是后端的事。

现在 React 应用要处理身份验证、数据访问、业务逻辑……攻击面大大增加。

所以 2026 年预计框架会推出更多“防御性默认设置”，防止开发者犯错。

静态分析工具会更智能，开发时就能发现潜在安全隐患。框架和安全扫描器的集成会更紧密。

10. 结论

2026 年的前端开发，核心变化是角色转变。

你不再是“写代码的人”，而是“协调资源的人”。

AI 帮你写重复代码，编译器帮你优化性能，框架帮你搭好架构……

你要做的，是把精力放在更重要的事情上：

• 理解用户需求


• 设计系统架构


• 把控产品质量


• 优化用户体验

技术在进步，工具在演化，但解决问题的能力和对用户的关注——这些才是永远不会过时的核心竞争力。

2026 年，我们不是被工具取代，而是在工具的帮助下，做更有价值的事。

我是冴羽，10 年笔耕不辍，专注前端领域，更新了 10+ 系列、300+ 篇原创技术文章，翻译过 Svelte、Solid.js、TypeScript 文档，著有小册《Next.js 开发指南》、《Svelte 开发指南》、《Astro 实战指南》。

欢迎围观我的“网页版朋友圈”，关注我的公众号：冴羽（或搜索 yayujs） ，每天分享前端知识、AI 干货。

多标签页实时消息同步方案：SSE + BroadcastChannel 完美解决！

你是否遇到过这样的问题：
用户同时打开多个标签页，每个标签页都建立了独立的 WebSocket 连接，导致服务器压力大、消息重复推送、资源浪费？本文将分享一个优雅的解决方案，通过 SSE + BroadcastChannel 的组合，实现单连接、多标签页实时消息同步，既节省资源又提升用户体验。

适用场景

推荐使用：

• 实时消息推送：系统通知、用户消息、业务提醒等


• 数据同步：多标签页状态同步、购物车同步、表单数据同步


• 任务状态更新：后台任务进度、数据处理状态、导出任务完成通知


• 系统公告：全局消息广播、系统维护通知、版本更新提示

实际案例：

在我们的 BI 系统中，该方案成功应用于：

• 消息中心：实时推送系统消息和业务通知


• 任务管理：后台数据处理任务的状态更新和完成通知（如素材批量上传任务）


• 国际化同步：多语言配置的实时更新

国际化同步这块配合 apollo 的配置中心实现多语言配置更新发布后，系统会无感自动实时更新翻译，超级爽

不推荐使用：

• 高频双向通信：如实时聊天、游戏等，建议使用 WebSocket


• 大量数据传输：如文件传输、大数据同步，建议使用 HTTP 轮询或分页


• 跨域通信：需要使用 postMessage 或其他跨域方案

前言

如果不想了解技术背景可点击直接跳转到实现方案👇

初衷

在现代 Web 应用中，实时消息推送、任务状态更新等是常见的需求。然而，当用户同时打开多个标签页时，如何确保消息能够正确同步到所有标签页，同时避免重复连接和资源浪费，是一个值得深入探讨的技术问题。

本文基于实际项目经验，分享如何通过 SSE（Server-Sent Events） 和 BroadcastChannel API 的组合方案，实现高效的多标签页实时消息同步。该方案不仅解决了单标签页消息推送的问题，还优雅地处理了多标签页场景下的连接管理和消息分发。

问题背景

多标签页消息同步的挑战

在实际业务场景中，我们遇到了以下问题：

场景一：用户打开多个标签页

当用户同时打开多个标签页访问同一个应用时，如果每个标签页都建立独立的 SSE 连接，会导致：

• 服务器资源浪费（多个长连接）


• 消息重复推送（每个标签页都收到相同消息）


• 用户体验不一致（不同标签页消息状态不同步）

打开多页签若系统采用 HTTP 1.0/1.1 协议，用户每打开一个页面就会建立一个长连接；当打开的标签页数量超过 6 个时，受浏览器并发连接数限制，第七个及之后的标签页将无法正常加载，出现卡顿。

场景二：标签页关闭与重连

当某个标签页关闭时，如果该标签页持有唯一的 SSE 连接，其他标签页将无法继续接收消息。需要：

• 检测连接断开


• 自动在其他标签页重新建立连接


• 保证消息不丢失

场景三：消息去重与状态同步

多个标签页需要：

• 避免重复显示相同的消息通知


• 保持消息已读/未读状态同步


• 统一更新 UI 状态（如未读消息数）

传统方案的局限性

技术选型

为什么选择 SSE

SSE（Server-Sent Events） 是 HTML5 标准中的一种服务器推送技术，具有以下优势：

// SSE 基本使用

const eventSource = new EventSource('/api/sse');

eventSource.onmessage = (event) => {

  console.log('收到消息:', event.data);

};