前言

话不多说，先演示一下吧。大概功能描述就是，告诉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 将更符合你的需求。最终的选择应基于你的开发需求、项目规模以及团队的技术能力。建议通过实际代码尝试两者，根据你的具体场景做出最适合的选择。

前言

这篇文章跟大家一起聊聊打印优质日志的10条军规，希望对你会有所帮助。

第1条：格式统一

反例（管理看到会扣钱）：

log.info("start process");

log.error("error happen"); 

无时间戳，无上下文。

正解代码：

<!-- logback.xml核心配置 -->

<pattern>

    %d{yy-MM-dd HH:mm:ss.SSS} 

    |%X{traceId:-NO_ID} 

    |%thread 

    |%-5level 

    |%logger{36} 

    |%msg%n

</pattern>

在logback.xml中统一配置了日志的时间格式、tradeId，线程、等级、日志详情都信息。

日志的格式统一了，更方便点位问题。

第2条：异常必带堆栈

反例（同事看了想打人）：

try {

    processOrder();

} catch (Exception e) {

    log.error("处理失败"); 

}

出现异常了，日志中没打印任何的异常堆栈信息。

相当于自己把异常吃掉了。

非常不好排查问题。

正确姿势：

log.error("订单处理异常 orderId={}", orderId, e); // e必须存在！

日志中记录了出现异常的订单号orderId和异常的堆栈信息e。

第3条：级别合理

反面教材：

log.debug("用户余额不足 userId={}", userId); // 业务异常应属WARN

log.error("接口响应稍慢"); // 普通超时属INFO

接口响应稍慢，打印了error级别的日志，显然不太合理。

正常情况下，普通超时属INFO级别。

级别定义表：

第4条：参数完整

反例（让运维骂娘）：

log.info("用户登录失败");

上面这个日志只打印了“用户登录失败”这个文案。

谁在哪登录失败？

侦探式日志：

log.warn("用户登录失败 username={}, clientIP={}, failReason={}", 

    username, clientIP, "密码错误次数超限");

登录失败的业务场景，需要记录哪个用户，ip是多少，在什么时间，登录失败了，失败的原因是什么。

时间在logback.xml中统一配置了格式。

这样才方便快速定位问题：

第5条：数据脱敏

血泪案例：

某同事打印日志泄露用户手机号被投诉。

我在记录的日志中，需要对一下用户的个人敏感数据做脱敏处理。

例如下面这样：

// 脱敏工具类

public class LogMasker {

    public static String maskMobile(String mobile) {

        return mobile.replaceAll("(\\d{3})\\d{4}(\\d{4})", "$1****$2");

    }

}



// 使用示例

log.info("用户注册 mobile={}", LogMasker.maskMobile("13812345678"));

第6条：异步保性能

问题复现

某次秒杀活动中直接同步写日志，导致大量线程阻塞：

log.info("秒杀请求 userId={}, itemId={}", userId, itemId); 

高并发下IO阻塞。

致命伤害分析：

正确示范（三步配置法）

步骤1：logback.xml配置异步通道

<!-- 异步Appender核心配置 -->  

<appender name="ASYNC" class="ch.qos.logback.classic.AsyncAppender">  

    <!-- 不丢失日志的阈值：当队列剩余容量＜此值时，TRACE/DEBUG级别日志将被丢弃 -->  

    <discardingThreshold>0</discardingThreshold>  

    <!-- 队列深度：建议设为 (最大并发线程数 × 2) -->  

    <queueSize>4096</queueSize>  

    <!-- 关联真实Appender -->  

    <appender-ref ref="FILE"/>  

</appender>  

步骤2：日志输出优化代码

// 无需前置判断，框架自动处理  

log.debug("接收到MQ消息：{}", msg.toSimpleString()); // 自动异步写入队列  



// 不应做复杂计算后再打印（异步前仍在业务线程执行）  

// 错误做法：  

log.debug("详细内容：{}", computeExpensiveLog());  

流程图如下：

步骤3：性能关键参数公式

最大内存占用 ≈ 队列长度 × 平均单条日志大小  

推荐队列深度 = 峰值TPS × 容忍最大延迟(秒)  

例如：10000 TPS × 0.5s容忍 ⇒ 5000队列大小  

风险规避策略

第7条：链路追踪

混沌场景：

跨服务调用无法关联日志。

我们需要有链路追踪方案。

全链路方案：

// 拦截器注入traceId

MDC.put("traceId", UUID.randomUUID().toString().substring(0,8));



// 日志格式包含traceId

<pattern>%d{HH:mm:ss} |%X{traceId}| %msg%n</pattern>

可以在MDC中设置traceId。

后面可以通过traceId全链路追踪日志。

流程图如下：

第8条：动态调参

半夜重启的痛：

线上问题需要临时开DEBUG日志，比如：查询用户的某次异常操作的日志。

热更新方案：

@GetMapping("/logLevel")

public String changeLogLevel(

    @RequestParam String loggerName, 

    @RequestParam String level) {

    

    Logger logger = (Logger) LoggerFactory.getLogger(loggerName);

    logger.setLevel(Level.valueOf(level)); // 立即生效

    return "OK";

}

有时候我们需要临时打印DEBUG日志，这就需要有个动态参数控制了。

否则每次调整打印日志级别都需要重启服务，可能会影响用户的正常使用。

journey

    title 日志级别动态调整

    section 旧模式

        发现问题 --> 修改配置 --> 重启应用 --> 丢失现场

    section 新模式

        发现问题 --> 动态调整 --> 立即生效 --> 保持现场

第9条：结构化存储

混沌日志：

用户购买了苹果手机 订单号1001 金额8999

上面的日志拼接成了一个字符串，虽说中间有空格分隔了，但哪些字段对应了哪些值，看起来不是很清楚。

我们在存储日志的时候，需要做结构化存储，方便快速的查询和搜索。

机器友好式日志：

{

  "event": "ORDER_CREATE",

  "orderId": 1001,

  "amount": 8999,

  "products": [{"name":"iPhone", "sku": "A123"}]

}

这里使用了json格式存储日志。

日志中的数据一目了然。

第10条：智能监控

最失败案例：

某次用户开通会员操作，错误日志堆积3天才被发现，黄花菜都凉了。

我们需要在项目中引入智能监控。

ELK监控方案：

报警规则示例：

ERROR日志连续5分钟 > 100条 → 电话告警  

WARN日志持续1小时 → 邮件通知

总结

研发人员的三大境界：

最后的灵魂拷问：

下次线上故障时，你的日志能让新人5分钟定位问题吗？

最后说一句(求关注，别白嫖我)

如果这篇文章对您有所帮助，或者有所启发的话，帮忙关注一下我的同名公众号：苏三说技术，您的支持是我坚持写作最大的动力。

求一键三连：点赞、转发、在看。

关注公众号：【苏三说技术】，在公众号中回复：进大厂，可以免费获取我最近整理的10万字的面试宝典，好多小伙伴靠这个宝典拿到了多家大厂的offer。

第三阶段：验证与使用

其它事项

本地冗余还是同城冗余

对于 个人图床 （博客、笔记图片）这种场景，答案非常明确，请选择本地冗余 (LRS)

对于个人博客图片，本地冗余 (11个9) 的安全性已经远远溢出了。即使真的遇到极小概率的机房故障，阿里云通常也有修复手段。为了那几十块钱的图片去买“抗核弹级”的同城冗余，属于过度消费。

如果你实在不放心，就写个脚本定期把图片备份到其它平台即可。

防坑指南

特别注意：不要把 AccessKey 泄露给别人。

阿里云 OSS 是按量付费的，主要包含两部分：

如果你的图片是自己使用，比如Obsidian笔记，或者发布到公众号文章，那么问题不大。

比如老刘自己的Obsidian笔记只有几台电脑和手机同步使用，用量很小。

如果发布到公众号、csdn等平台也问题不大，因为各个平台都会抓取你的图片，发布的文章中使用的是平台的图片链接，而不是你自己的图片链接。

但是如果你是自建的个人博客，要注意一下访问量。

• 如果你的博客访问量非常巨大（每天几万），流量费会是一笔开支。对于普通个人博客，一年通常也就几十块钱。
• 可以在阿里云后台设置 “消费预警”，例如设置消费超过 10 元发短信通知，防止被恶意刷流量。

最后再说两句

折腾这么一圈，其实就为了一个目的：让写作回归写作本身。

我们花时间去配置图床、优化流程，不是为了成为工具大师，而是为了在灵感迸发的那一刻，不会因为图片上传失败这种破事而打断思路。

工具最好的状态，就是当你用它的时候，你根本感觉不到它的存在。

配置好 PicGo + 阿里云 OSS，把琐碎的技术细节丢给自动化工具，剩下的，就是尽情释放你的创造力了。

毕竟，内容，才是一切的王道。

如果看到这里的同学对客户端或者Flutter开发感兴趣，欢迎联系老刘，我们互相学习。

私信免费领老刘整理的《Flutter开发手册》，覆盖90%应用开发场景。

可以作为Flutter学习的知识地图。

—— laoliu_dev

尤记得上半年大家对 MCP 的狂热，遇人就会和我聊到 MCP。然而从落地使用上似乎不是这么个情况。社区里面流传着一句话：MCP 是一个开发者远超使用者的功能。那么 MCP 真的是世上最大骗局吗？

如果你是 AI 工具的用户（而不是开发者），这篇文章可能会从另一角度来尝试解释：为什么 MCP 这么火，但你用起来总觉得”没什么用”？Skills 为什么可能才是你真正需要的东西。

一、MCP：开发者的狂欢，用户的懵圈

MCP（Model Context Protocol）在 2024 年底由 Anthropic 发布，号称是 AI 领域的”USB-C”——一个标准化的协议，让 AI 可以连接各种外部工具。

听起来很美好。但现实是社区里充斥着对 MCP 的嘲讽，称其为”最大骗局”。

MCP 可能是唯一开发者比使用者还多的技术 开发者为什么吐槽 MCP 协议？

这意味着什么？

大量开发者在「研究」MCP，但真正能给用户用的工具少得可怜。

SDK 月下载量 9700 万次，Registry 增长 407%——开发者热情高涨。但作为用户，你打开 Claude 或 Cursor，想找个好用的 MCP 工具，大概率还是会失望。

这不是 MCP 的错。这是它的「基因」决定的。

二、协议的「基因」决定了谁受益

为什么 MCP 对用户不友好？也许答案藏在协议设计本身。

我们对比下 MCP 和 Skills（Agent Skills）两个协议的规范：

来源：modelcontextprotocol.io / agentskills.io

MCP 协议规定的是「开发者怎么写工具」——API 接口怎么定义、数据结构怎么传递、SDK 怎么集成。这些对开发者很重要，但普通用户根本不关心。

Skills 协议规定的是「AI 怎么用能力」——什么时候加载、怎么理解指令、如何执行任务。这些直接影响用户体验。

即使开发者来说，Skill 的上手成本也都远低于 MCP。甚至简单的 Skills，使用者可以在使用过程中无缝切换为开发者，边用边优化。

一句话总结：MCP 面向开发者，尽力优化了开发体验，在 Agent 如何使用这些工具上却没有给出太多指导；Skill 面向使用者，优化使用体验（包括成本），在 Agent 如何使用这些工具上给出了很多指导。

协议的设计目标，决定了谁能从中获益。

三、Skills 的杀手锏：渐进式披露

除了设计目标不同，Skills 还有一个技术上的优势：渐进式披露（Progressive Disclosure） 。

这是什么意思？用一个类比来解释：图书馆找书。

想象你去图书馆找资料：

MCP 方式：管理员把整个书架的书全搬到你面前。结果：信息过载，找不到重点 📚📚📚

Skill 方式：管理员先给你一本目录，你说要哪本再拿哪本。结果：精准高效 📋→📖

AI 的「脑容量」有限（Context Window）。

• 传统方式：一次性加载所有工具定义。假设有 100 个工具，可能占用几十万 tokens。


• Skill 方式：启动时只加载名称和描述（约 100 tokens/skill）。需要哪个，再加载哪个的详细指令。

根据 agentskills.io 官方规范：

• 元数据层：~100 tokens/skill


• 完整指令：建议 <5000 tokens

这意味着什么？100 个 Skills，启动时只需要约 10,000 tokens 的元数据。而不是一股脑塞进去几十万 tokens。

四、两者不是对手，是搭档

说了这么多 Skills 的好话，是不是意味着 MCP 没用了？不是。

MCP 和 Skills 解决的是不同层次的问题：

• MCP = 工具箱：定义了「能连接什么」——数据库、API、文件系统、第三方服务


• Skills = 使用手册：定义了「怎么聪明地用这些工具」——工作流程、最佳实践、按需加载

它们也可以结合使用：

用 Skills 的渐进式披露来管理 MCP 工具。

MCP 负责「连接」，Skills 负责「智慧」。组合是一个好的解决方案。

五、给用户的建议

结语

MCP 是最大骗局吗？不是。它也是一个优秀的开发者协议。

Skills 是救星吗？对用户来说，目前来说可能是的。

协议的设计目标，决定了谁能从中获益。 MCP 让开发者更容易写工具，Skills 让用户更容易用工具。

如果你是用户，别纠结 MCP 为什么”不好用”了。去看看 Skills 吧。

参考链接

• MCP 官方文档


• Agent Skills 官方规范


• Anthropic Skills 发布公告


• 开发者为什么吐槽 MCP 协议？

背景介绍

• 最近组内要做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"/>

1. 京东终面后，我在群里被恭喜了

2025年4月，京东HR在BOSS上找我，岗位写的是「iOS开发」，我心想这HR真他妈不专业，但还是回了句：「您好，我是前端，可以面试吗？」

没想到就这么稀里糊涂面了五轮，终面见部门老大，聊得还行。面完群里几个「未来同事」加我微信，有人说「稳了，等offer吧」，我也觉得这次该轮到我了吧？

然后，就没有然后了。

HR说「流程中」，一等就是一个月。这一个月我啥也没干，就刷邮箱等消息，像个傻逼一样。

这时候我才懂范进——你以为自己中了，其实屁都没有。

2. 我这五年，就是一部「选择比努力重要」的失败史

① 2020年：1万块我就觉得牛逼了

毕业那年进了个区块链小公司，老板说转正给1万，我他妈高兴坏了——「我同学花两三万培训还找不到工作呢！」

现在看真是蠢。那时候滴滴应届生「白菜价」都20k了，我还在为1万沾沾自喜。

问题不是钱，是起点——你第一份工作在小公司，后面想进大厂，难如登天。

② 2021-2023年：被裁了才知道害怕

后来跳槽涨了50%，进了个中型公司，终于知道什么叫「团队协作」了。结果没两年公司不行了，领了几万块钱「毕业大礼包」。

2023年再找工作，行情已经烂了。我怕失业，涨了40%多又去了个小公司，继续写垃圾代码。

这时候我才明白：小公司呆久了，你的简历就废了。

③ 2025年：面京东，我才知道自己多菜

今年我认真准备了半年，八股文、项目难点、架构设计，甚至刷了LeetCode。面京东时，人家问「你们日活多少？QPS多少？」

我他妈哪知道？我们公司就几十个人用，需要个屁的高并发！

大厂要的是「大厂经验」，你没有，就是没有。

3. 我认命了，但你们别学我

我现在进了一家还算稳定的公司，薪资也还行，但心里明白——我这辈子可能都进不去大厂了。

不是我不努力，是一开始选错了。如果毕业就进大厂，现在跳槽随便涨50%。但在小公司呆过？难。

但有一点让我没完全废掉：我写技术博客

真的，这几年每次面试，人家都会问我博客上的东西。那些在小公司用不上的「高端技术」，我全靠自己折腾，写在博客里。

所以如果你也在小公司：

4. 最后说句实话

我知道你们想听「坚持就能进大厂」，但现实是——有些人就是没这个命。

我现在马上30岁了，五年经验，没大厂背景，以后更难。

前面卡技术经验，卡大厂背景，后面卡年龄限制，一开始没走好路，后面真的特别艰难

现在还背上了房贷，要结婚，要有小孩，后面压力更大，现在只想稳定一点 😭😭😭

但至少我还能写代码，还能靠技术吃饭。比起范进，我至少没疯。

最后贴几张图吧，就当看电子榨菜了

• 京东是真远，来回四个小时

• 不靠谱的面试

• 一直等不到的消息，我都感觉我问烦了
  


• 来自群友的关心，我当时已经是范进的心态了

• 别人的起点，或许就是你的终点

• 为什么拿京东说事

因为别的大厂也没约我面试，除了美团，小红书的外包 😭😭😭

• 新公司
  来新公司上班快一个月了，已经轻车熟路，同事关系处的不错，已经开始穿拖鞋了（你们应该知道这句话的含金量）

结束语

后面会更新一些，新的学习的技术，如果对面经感兴趣的，也可以单独写一篇半年的面试经历以及总结～

兄弟们，前天的瓜都吃了吗？🤣

说实话，作为一名还在写代码的打工仔，看到前天晚上快手那个热搜，我手里捧着的咖啡都不香了，后背一阵发凉。

12月22日晚上10点，正是流量最猛的时候，快手直播间突然失控。不是服务器崩了，而是内容崩了——大量视频像洪水一样灌进来。紧接着就是官方无奈的拔网线，全站直播强行关停。第二天开盘，股价直接跌了3个点。

这可不是普通的 Bug，这是P0 级中的 P0。

很多群里在传内鬼或者0day，但看了几位安全圈大佬（360、奇安信）的复盘，我发现这事儿比想象中更恐怖：这是一次教科书级别的黑产自动化降维打击。

今天不谈公关，咱们纯从技术角度复盘一下：假如这事儿发生在你负责的项目里，你的前端代码能抗住几秒？

当脚本比真人还多还快时？

这次事故最骚的地方在于，黑产根本不按套路出牌。

以前的攻击是 DDoS，打你的带宽，让你服务不可用。

这次是 Content DDoS（内容拒绝服务）。

1. 前端防线形同虚设

大家有没有想过，黑产是怎么把视频发出来的？

他们绝对不会坐在手机前，一个一个点开始直播。他们用的是群控、是脚本、是无头浏览器（Headless Browser）。

这意味着什么？

意味着你前端写的那些 if (user.isLogin)、那些漂亮的 UI 拦截、那些弹窗提示，在黑客眼里全是空气。他们直接逆向了你的 API，拿到了推流接口，然后几万个并发调用。

2. 审核系统被饱和式攻击

后端通常有人工+AI 审核。平时 QPS 是 1万，大家相安无事。

昨晚，黑产可能瞬间把 QPS 拉到了 100万。

云端 AI 审核队列直接爆了，人工审核员估计鼠标都点冒烟了也审不过来。一旦阈值被击穿，脏东西就流到了用户端。

那前端背锅了吗？

虽然核心漏洞肯定在后端鉴权和风控逻辑（大概率是接口签名泄露），但咱们前端作为 离黑客最近的一层皮，如果做得好，绝对能把攻击成本拉高 100 倍。

来，如果不幸遇到了这种自动化脚本攻击，咱们前端手里还有什么牌？🤔

别把 Sign 算法直接写在 JS 里！

很多兄弟写接口签名，直接在 request.js 里写个 md5(params + salt) 完事。

大哥，Chrome F12 一开，Sources 一搜，断点一打，你的盐（Salt）就裸奔了。

防范操作：直接上 WASM (WebAssembly)

把核心的加密、签名逻辑，用 C++ 或 Rust 写，编译成 .wasm 文件给前端调。

黑客想逆向 WASM？那成本可比读 JS 代码高太多了。这就是给他们设的第一道坎。

你的用户，可能根本不是人

黑产用的是脚本。脚本和真人的操作是有本质区别的。

不要只会在登录页搞个滑块，没用的，现在的图像识别早破了。

要在 关键操作（比如点击开始直播） 前，采集一波数据：

• 鼠标轨迹：真人的轨迹是曲线（贝塞尔曲线），脚本通常是直线。


• 点击间隔：脚本是毫秒级的固定间隔，人是有随机抖动的。

// 伪代码，简单的是不是人检测

function isHuman(events) {

    // 如果鼠标轨迹过于平滑或呈绝对直线 -> 机器人

    if (analyzeTrajectory(events) === 'perfect_linear') return false;

    // 如果点击时间间隔完全一致 -> 机器人

    if (checkTiming(events) === 'fixed_interval') return false;

    return true;

}

把这些行为数据打分，随着请求发给后端。分低的，直接拒绝推流。

既然防不住内鬼，那就给他打标

这次很多人怀疑是内部泄露了接口文档或密钥。说实话，这种事防不胜防。

但是，前端可以搞 盲水印。

在你的 Admin 管理后台、文档平台，加上肉眼看不见的 Canvas 水印（把员工 ID 编码进背景图的 RGB 微小差值里，具体大家自己去探索😖）。

一旦截图流出，马上就能解码出是哪个员工泄露的。威慑力 > 技术本身。

或者试试这个技巧 👉 如何用隐形字符给公司内部文档加盲水印?(抓内鬼神器🤣)

安全复盘

这次快手事件，其实就死在了一个逻辑上： 后端太信任通过了前端流程的请求。

我们写代码时常犯的错误：

• 前端校验过手机号格式了，后端不用校验了吧？


• 必须点了按钮才能触发这个请求，所以这个接口很安全。

大错特错！

2025 年了，兄弟们。在 Web 的世界里，不相信前端 才是保命法则。

任何从客户端发来的数据，都要默认它是有毒的。

之前我都发过类似的文章：为什么永远不要相信前端输入？绕过前端验证，只需一个 cURL 命令！

希望对你们有帮助👆

这次是快手，下次可能就是咱们的公司。

尤其是年底了，黑灰产也要冲业绩（虽然这个业绩有点缺德😖）。

建议大家上班时看看这几件事：

前端不只是画页面的，关键时刻，咱们也是安全防线的一部分。

别等到半夜被运维电话叫醒，那时候就真只能甚至想重写简历了🤣。

选择大于努力

友友们，我是卷福同学，上次写2024年终总结的时候还在武汉，谁能想到一年之后会在上海写2025的年终总结。今年下半年经历的事情比较多，总结来说就是，人生经历又丰富了

1.再次选择

去一线大城市闯荡人生还是留在武汉岁月静好呢？

1月

1月时候还在武汉国企里呢，彼时因为项目变少了，武汉人员要重新分配，没分到项目组的人要进资源池等候下一步安排。而我这个小组之前武汉是有2个人的，北京1个项目经理，给我分配了半个人的工时，另一个人直接让去资源池。关于这个项目经理，去年也写过吐槽的帖子。这个人在武汉的名声非常不好，就完全是对待牛马一样对待底下干活的人。

我想着以后的日子可能过得更难受，还不如直接进资源池算了。于是就和他说了，他倒也爽快，想着再从武汉随便捞个人进来呗，反正还有很多人没安排项目组的。没想到的是，他接连找了两个人，但是因为武汉的人都听说过他的名号，都表示不想去他的项目组。最后，他把项目给外包人员做了。武汉的人，宁愿待池子里，也不想跟着他干。。。

这让我想起以前上小学的时候，以前农村小学的老师，打学生都很厉害的。而打的原因不仅仅是因为调皮捣蛋，我那个班教数学的老师，就是其中打人最厉害的。上课的讲台两边会有两个座位嘛，每次她讲课的时候，都会从这两个座位的学生手里拿课后作业讲，要是讲的时候发现写错了，直接冲过去打头，提耳朵等等。有一次因为班上写错作业的人太多了，直接一节课没上，轮流上去扎马步。而我呢，又恰巧有一学期是坐在讲台旁边的座位，于是这学期每逢她的课必挨打，打到后面，居然在课上说，卷福坐在这，已经被我打肿了，你们再敢做错题试试。到第二学期开学的时候，大家选座位直接把前面两个位置空着了，有两个人宁愿在后面站着也不坐那位置。

我感觉是不是历史又一次重演了呢？

现在回头看，当时没继续跟着他的选择是对的。在武汉，也没有岁月静好啊。

再次选择

虽然5月份的时候拿了上海的offer，但是等真的要走的时候，还是会纠结的。就和刚毕业的时候去北京一样，一切都要重头开始了。走的那天，出租屋里只有个保洁阿姨在打扫卫生，就和我刚回武汉的时候一样。不同的是，上次阿姨说的是房子很快就打扫好了，这次说的是，祝老板以后去上海了发大财啊

2.沪漂

探索新事物

上海就是机会多啊，休息日都会出去逛逛，探索些新事物。想想来上海之后，去周边城市参加徒步、参加ChinaJoy漫展、看了开心麻花的话剧《疯狂理发店》、还有市区内的一些公园、大学、图书馆、动物园、演唱活动等等，生活非常丰富多彩。

• 徒步活动在小红书上找个团报就行，很多都是一天游，一半时间都在路上


• 漫展里的coser都美如画，非常适合集邮

3.第一次演讲

3月

今年参加的线下活动还比较多呢，3月份的时候受腾讯云社区的邀请去杭州参加线下的技术训练营活动，主要也是想趁机会多认识些大佬，说不定大佬招人，有内推机会。倒也认识了不少人，喵喵、小智，还有社区的泽敏姐。晚上一起吃饭交流的时候，泽敏姐说下次有机会让我上去演讲。当时只以为是说说而已，毕竟社区里大佬太多了

9月

9月份的时候收到社区的邀请，去深圳参加腾讯全球数字生态大会，作为讲师上去做分享。我是非常想去的，这样就能达成从学生到老师角色转变的目标，输入变输出。比较纠结的是分享什么内容比较好呢，想了一晚上，最后觉得分享自己用AI两年的经历、沉淀的一些使用心得体、还有变现方式会比较好。

现场的分享也是比较顺利，讲完下来的时候和小智老师沟通上台演讲体验，小智说我讲的非常干货，讲的很稳，刚才他自己讲的时候非常紧张，腿都在抖。我说，我也是啊，腿都在打颤，反而看你讲一点也不慌的样子。。。

第二天又和喵喵一起去腾讯数码大厦找泽敏姐，非常感谢泽敏姐的邀请，第一次到腾讯的大楼参观。期间见识到了超豪华的二次元工位，满墙的手办，非常震惊。

4.AI探索

选择适合自己的方向比较重要，2024年投入了很多时间在AI视频、绘画上，虽然也有涨粉嘛，但是变现不行，一年下来也就三位数的收益。今年主要在写作还有AI编程方向投入，因为换工作的原因，其实投入精力没去年那么多。反而收益还更多了，有四位数的收益。也产出了百万阅读的文章和10w+播放量的视频

出爆款的诀窍就是追热点，这是普通人出爆款最容易的方式了。比如年初的Deepseek，国庆期间的sora2，趁着刚出来热度最高的时候，随便写点东西或者做个视频，流量都非常好的。那像现在再去写Deepseek，流量肯定不如之前了。

11月

11月看到小智老师发的华为鸿蒙线下编程活动的信息，拉着在上海的一个前同事一起去参加玩玩，前同事是我在北京阿里工作时同组的，后来来了上海后，我居然在一个公交站碰到他了，也是十分震惊，居然在上海遇到曾在北京的前同事。鸿蒙的编程活动都是基础的操作，正好也买了Codebuddy的会员，用AI编程轻松解决了，拿到个小礼品

12月

年底了，AI破局俱乐部在深圳举办行动家大会，我看分享嘉宾和内容挺干货的，也报名跑去深圳参加了，到现场才发现，高手云集，天下英雄如过江之鲫。我把这次参会了解的东西整理了下：

• AIPPT.com ：赵充老师以肯德基为例分享做产品不要做全家桶，用户只想要个甜筒（不要做大而全的产品，而是在垂直领域找到需求，在单点，堵上一切）


• AI编程出海：老外付费意愿更强，大公司不愿意做的垂直小市场，才是个人最大的机会。remove.bg网站仅有去除背景这一项功能，流量却非常高


• 搜索流量比推荐流量更值钱：用户主动搜的，说明有明确需求。而平台推的，用户只是随便看看。获取搜索流量的方法：研究用户搜索的关键词，围绕关键词输出内容，时间久了，用户搜索这个关键词，自然就找到你了

活动分享的内容挺多的啊，这里就不继续写了。

同样的听课，结果可能完全不同，会场的1000人，参加完会回去后，可能大部分人就是感慨一下，然后继续原来的生活

5.相亲

离开武汉前，和大学同学聚餐，聊了下发现同学要准备去女方家提亲了，问对象是从哪里找的，说了个相亲软件。不过也很难，同学相亲了十几个女生，才和现在这个走到谈结婚这一步。知道了相亲软件（青藤）后，我来上海也开始了相亲之旅，到目前为止，还没有一个相上的，简单说下相亲的几个女生吧：

• 91年，初中老师。其实是在武汉相亲的，家里给介绍的。感觉年龄差的太大了，差不多5岁了，不过因为是家里介绍的，还是得见上一面。3月的时候，武大樱花还开着，便想去武大里逛逛聊聊。让她把身-份-证号发我，用校友通道预约。然后犹犹豫豫半天没有发我，说是个人隐私等等之类的，要自己预约。结果没约上，想再用校友通道时已经约满了，无奈只好约着去学校旁边一家冷锅鱼店吃饭好了，计划约的12点见面，我预估12点半应该能吃上饭（不知道为什么，武汉相亲的女生都迟到），没想到她直到1点多才到，迟到1个多小时，期间也就各种尬聊，回去后两人都没再发消息了，凉凉


• 93年，上海公务员。家里的亲戚介绍的，是我相亲过的最优秀的女生了。以前的高考文科状元，武大校友，长得像袁咏仪，聊天说话情商也很高。接触了一个月吧，期间也一起吃过饭，看过话剧。最后一次见面聊天说起她前男友，海归，年入百万，金融行业。长相没说啊，应该也不差，妥妥高富帅。我一听这条件，心里顿时凉凉，差距太大了。问起为什么分了呢，说是男的虽然有钱，但是不给女的花，什么事都要AA。就是网上那种观念：钱是给女人看的，不是给女人花的。这次聊完之后就结束了，又凉凉。


• 95年，幼师。在上海相亲的，青藤上找的，见面后感觉非常漂亮啊。不过性格比较强势，刚开始聊的还是开心的话题，突然画风一转，她就开始吐槽模式，吐槽支教的山里小学的领导等等，后半段全是听她吐槽，没再聊相亲的话题了。回去后又聊了几周，但是幼师可能时间太紧，也可能她同时聊的人太多，后面想再约见面就没时间了，于是凉凉


• 97年，互联网数据分析师。来上海后相亲的第一个女生，也是非常漂亮，加上好友，看了我动态后，说非常崇拜技术大佬（多写博客还是有好处的嘛），想请我吃饭。于是爽快赴约，期间聊分布式、高并发等等，最后吃完饭结束的时候，说感觉身高不够


• 00年，主业机械设计，副业自媒体。遇到同行了，聊天话题特别多，情绪价值拉满。约线下去CJ漫展玩，让她把身-份-证号发我来买票，本来还想着怎么解释说明的，下一秒就把身-份-证号和手机号发来了，没有任何犹豫。约好了早上9点半去会展中心，没想到她早早到我这边来等我一起过去，连零食和水都买好了。遂开心前往，妹子是第一次逛漫展，逛的非常开心。只不过回去后还是说了性格不合，只好当朋友了。后续还是保持联系，偶尔见面

这里列出不同年龄段的相亲女生，其他还有一些都是软件上匹配了没说话，或者说两句话就不继续聊了的。给兄弟们做个负面教材的参考啊，今年的相亲就到此为止，明年再说吧。。。

6.2026目标

最后不都得展望下未来吗，2026年你们又给自己制定了哪些目标和规划呢，我给自己定下的目标，希望明年都能做到

• 神山转山


• 樱花巡礼


• 新手上路


• 恰老外米

最后，感兴趣的朋友可以关注我的公众号:卷福同学

团队曾为一个订单状态显示问题加班至深夜：并非业务逻辑出错，而是前期封装的订单类过度隐藏核心字段，连获取支付时间都需多层调用，最终只能通过反射绕过封装临时解决，后续还需承担潜在风险。这一典型场景，正是 “乱封装” 埋下的隐患 —— 封装本是保障代码安全、提升可维护性的工具，但违背其核心原则的 “乱封装”，反而会让代码从 “易扩展” 走向 “高耦合”，成为开发流程中的阻碍。

一、乱封装的三类典型形态：偏离封装本质的错误实践

乱封装并非 “不封装”，而是未遵循 “最小接口暴露、合理细节隐藏” 原则，表现为三种具体形态，与前文所述的过度封装、虚假封装、混乱封装高度契合，且每一种都直接破坏代码可用性。

1. 过度封装：隐藏必要扩展点，制造使用障碍

为追求 “绝对安全”，将本应开放的核心参数或功能强行隐藏，仅保留僵化接口，导致后续业务需求无法通过正常途径满足。例如某文件上传工具类，将存储路径、上传超时时间等关键参数设为私有且未提供修改接口，仅支持默认配置。当业务需新增 “临时文件单独存储” 场景时，既无法调整路径参数，又不能复用原有工具类，最终只能重构代码，造成开发资源浪费。

反例代码：

// 文件上传工具类（过度封装）

public class FileUploader {

    // 关键参数设为私有且无修改途径

    private String storagePath = "/default/path";

    private int timeout = 3000;

    

    // 仅提供固定逻辑的上传方法，无法修改路径和超时时间

    public boolean upload(File file) {

        // 使用默认storagePath和timeout执行上传

        return doUpload(file, storagePath, timeout);

    }

    

    // 私有方法，外部无法干预

    private boolean doUpload(File file, String path, int time) {

        // 上传逻辑

    }

}

问题：当业务需要 "临时文件存 /tmp 目录" 或 "大文件需延长超时时间" 时，无法通过正常途径修改参数，只能放弃该工具类重新开发。

正确做法：暴露必要的配置接口，隐藏实现细节：

public class FileUploader {

    private String storagePath = "/default/path";

    private int timeout = 3000;

    

    // 提供修改参数的接口

    public void setStoragePath(String path) {

        this.storagePath = path;

    }

    

    public void setTimeout(int timeout) {

        this.timeout = timeout;

    }

    

    // 保留核心功能接口

    public boolean upload(File file) {

        return doUpload(file, storagePath, timeout);

    }

2. 虚假封装：形式化隐藏细节，未实现数据保护

表面通过访问控制修饰符（如private）隐藏变量，也编写getter/setter方法，但未在接口中加入必要校验或逻辑约束，本质与 “直接暴露数据” 无差异，却增加冗余代码。以订单类为例，将orderStatus（订单状态）设为私有后，setOrderStatus()方法未校验状态流转逻辑，允许外部直接将 “已发货” 状态改为 “待支付”，违背业务规则，既未保护数据完整性，也失去了封装的核心价值。

反例代码：

// 订单类（虚假封装）

public class Order {

    private String orderStatus; // 状态：待支付/已支付/已发货

    

    // 无任何校验的set方法

    public void setOrderStatus(String status) {

        this.orderStatus = status;

    }

    

    public String getOrderStatus() {

        return orderStatus;

    }

}



// 外部调用可随意修改状态，违背业务规则

Order order = new Order();

order.setOrderStatus("已发货");

order.setOrderStatus("待支付"); // 非法状态流转，封装未阻止

问题：允许状态从 "已发货" 直接变回 "待支付"，违反业务逻辑，封装未起到数据保护作用，和直接用 public 变量没有本质区别。

正确做法：在接口中加入校验逻辑：

public class Order {

    private String orderStatus;

    

    public void setOrderStatus(String status) {

        // 校验状态流转合法性

        if (!isValidTransition(this.orderStatus, status)) {

            throw new IllegalArgumentException("非法状态变更");

        }

        this.orderStatus = status;

    }

    

    // 隐藏校验逻辑

    private boolean isValidTransition(String oldStatus, String newStatus) {

        // 定义合法的状态流转规则

        return (oldStatus == null && "待支付".equals(newStatus)) ||

               ("待支付".equals(oldStatus) && "已支付".equals(newStatus)) ||

               ("已支付".equals(oldStatus) && "已发货".equals(newStatus));

    }

}

3. 混乱封装：混淆职责边界，堆砌无关逻辑

将多个独立功能模块强行封装至同一类或组件中，未按职责拆分，导致代码耦合度极高。例如某项目的 “CommonUtil” 工具类，同时包含日期转换、字符串处理、支付签名校验三类无关功能，且内部逻辑相互依赖。后续修改支付签名算法时，误触日期转换模块的静态变量，导致多个依赖该工具类的功能异常，排查与修复耗时远超预期。

反例代码：

// 万能工具类（混乱封装）

public class CommonUtil {

    // 日期处理

    public static String formatDate(Date date) { ... }

    

    // 字符串处理

    public static String trim(String str) { ... }

    

    // 支付签名（与工具类无关）

    public static String signPayment(String orderNo, BigDecimal amount) {

        // 使用了类内静态变量，与其他方法产生耦合

        return MD5.encode(orderNo + amount + secretKey);

    }

    

    private static String secretKey = "default_key";

}

问题：当修改支付签名逻辑（如替换加密方式）时，可能误改 secretKey，导致日期格式化、字符串处理等无关功能异常，排查难度极大。

正确做法：按职责拆分封装：

// 日期工具类

public class DateUtil {

    public static String formatDate(Date date) { ... }

}



// 字符串工具类

public class StringUtil {

    public static String trim(String str) { ... }

}



// 支付工具类

public class PaymentUtil {

    private static String secretKey = "default_key";

    public static String signPayment(String orderNo, BigDecimal amount) { ... }

}

二、乱封装的核心危害：从开发效率到系统稳定性的双重冲击

乱封装的危害具有 “隐蔽性” 和 “累积性”，初期可能仅表现为局部开发不便，随业务迭代会逐渐放大，对系统造成多重影响。

1. 降低开发效率，增加需求落地成本

乱封装会导致接口设计与业务需求脱节，当需要调用核心功能或获取关键数据时，需额外编写适配代码，甚至重构原有封装。例如某报表功能需获取订单原始字段用于统计，但前期封装的订单查询接口仅返回加工后的简化数据，无法满足需求，开发团队只能协调原封装者新增接口，沟通与开发周期延长，直接影响项目进度。

2. 破坏系统可扩展性，引发连锁故障

未预留扩展点的乱封装，会让后续功能迭代陷入 “牵一发而动全身” 的困境。某项目的缓存工具类未设计 “缓存过期清除” 开关，当业务需临时禁用缓存时，只能修改工具类源码，却因未考虑其他依赖模块，导致多个功能因缓存逻辑变更而异常，引发线上故障。这种因封装缺陷导致的扩展问题，会随系统复杂度提升而愈发严重。

3. 提升调试难度，延长问题定位周期

内部细节的无序隐藏，会让问题排查失去清晰路径。例如某支付接口返回 “参数错误”，但封装时未在接口中返回具体错误字段，且内部日志缺失关键信息，开发人员需逐层断点调试，才能定位到 “订单号长度超限” 的问题，原本十分钟可解决的故障，耗时延长数倍。

三、避免乱封装的实践原则：回归封装本质，平衡安全与灵活

避免乱封装无需复杂的设计模式，核心是围绕 “职责清晰、接口合理” 展开，结合前文总结的经验，可落地为两大原则。

1. 按 “单一职责” 划分封装边界

一个类或组件仅负责一类核心功能，不堆砌无关逻辑。例如用户模块中，将 “用户注册登录”“信息修改”“地址管理” 拆分为三个独立封装单元，通过明确的接口交互（如用户 ID 关联），避免功能耦合。这种拆分方式既能降低修改风险，也让代码结构更清晰，便于后续维护。

2. 接口设计遵循 “最小必要 + 适度灵活”

• 最小必要：仅暴露外部必须的接口，隐藏内部实现细节（如工具类无需暴露临时变量、辅助函数）；

• 适度灵活：针对潜在变化预留扩展点，避免接口僵化。例如短信发送工具类，核心接口sendSms(String phone, String content)满足基础需求，同时提供setTimeout(int timeout)方法允许调整超时时间，既隐藏签名验证、服务商调用等细节，又能应对不同场景的参数调整需求。

某商品管理项目的封装实践可作参考：商品查询功能同时提供两个接口 —— 面向前端的 “分页筛选简化接口” 和面向后端统计的 “完整字段接口”，既满足不同场景需求，又未暴露数据库查询逻辑，后续数据库表结构调整时，仅需维护内部实现，外部调用无需改动，充分体现了合理封装的价值。

结语

封装的本质是 “用合理的边界保障代码安全，用清晰的接口提升开发效率”，而非 “为封装而封装”。开发过程中，需避免过度追求形式化封装，也需警惕功能堆砌的混乱封装，多从后续维护、业务扩展的角度权衡接口设计。毕竟，好的封装是开发的 “助力”，而非 “阻力”—— 下次封装前，不妨先思考：“这样的设计，会不会给后续埋下隐患？”

提到 Stack Overflow 论坛，提到那个橙色的栈溢出图标，相信程序员和开发者们都再熟悉不过了。

还记得半年前，我曾经写过一篇文章，分享了一个有关 Stack Overflow 论坛的变化趋势图，从曲线走势来看，当时那会就已经非常不容乐观，每月新问题数量处于快速锐减之中。

但是现在时间来到 2026 年了，你猜怎么着？

结果是，趋势进一步走低，现在每个月新问题数据甚至还不如 18 年前 Stack Overflow 刚诞生那会的水平。

老规矩，我们还是直接看趋势图和具体数据吧。

这是最新的 Stack Overflow 论坛变化趋势图，表示的是从 2008 年社区刚上线开始，一直到 2026 年的今天，这 18 年时间里，Stack Overflow 社区每个月新问题个数的变化趋势。

怎么样？大家看完这张图有没有什么感触？

这张图清晰地展示出了 Stack Overflow 编程社区在这 18 年间所经历的增长、繁荣、高光以及跌落的趋势。

可以看到，从 2008 年到 2014 年这前 6 年的时间，Stack Overflow 一路高歌，渐入佳境，基本都在稳步增长。

而从 2014 年到 2022 年这中间的 8 年时间，虽说图中曲线呈震荡变化状态，但总体都是处于高位趋势，这也是 Stack Overflow 社区的繁荣时刻。

从数据上来看，Stack Overflow 最高光的顶峰时刻出现在 2020 年，尤其是 2020-05-01 这个时间节点，数据来到了 302381，这也是数值的最顶峰。

而从趋势图中也可以很明显地看出，自 2022 年底开始，Stack Overflow 社区日渐式微，开始出现回落之势。

那一年的年底科技圈发生了什么事情，相信大家都记忆犹新，没错，那就是 OpenAI 正式发布了 ChatGPT。

再后面几年的故事，相信大家也都非常清楚了，AI 大模型飞速迭代，AI 类产品和 AI 知识引擎更是百花齐放，层出不穷。

与此同时，传统的搜索引擎和知识社区也受到了不小的冲击。

其实到了 2025 年，Stack Overflow 的数据就已经跌回到 15 年前的水平了。

而如今时间来到了 2026 年，再看看最近这几个月 Stack Overflow 的数据，更是让人瞠目结舌：

没错，数据已经跌到甚至不如 18 年前社区刚上线那会的水平。

至此，Stack Overflow 社区基本上是彻底凉了。

这时候也不禁想起了那张网图。

聊起 Stack Overflow 社区的诞生，那还要追溯到 2008 年。

两位在软件开发领域很有影响力的博主，分别是 Jeff Atwood（知名博客 Coding Horror 的作者）和 Joel Spolsky（Fog Creek 创始人，《Joel on Software》作者），他们发现了一个行业痛点：即程序员在遇到技术难题时，很难从网络上找到准确、高质量的解决方案。

当时的搜索结果往往充斥着无效信息，知识分散且低效，或者某些技术网站虽然在搜索中排名很高，但真正有用的答案却被藏在注册墙或者付费墙后面，用户体验感极差。

基于对技术社区深刻的理解和对现有状况的不满，于是这两位技术布道者一拍即合，决定联手，打造一个专属于程序员的问答圣地。

他们的目标很明确：创建一个以内容质量为核心、通过社区协作来解决问题的平台。

于是在 2008 年，Stack Overflow 项目启动了。

同年 7 月，网站开始了小范围的内部测试，邀请了一批种子用户来打磨产品和机制。

两个月后，Stack Overflow 网站正式面向公众开放。

Stack Overflow 的上线如同一股清流，迅速在开发者群体中引起了轰动，同时 Stack Overflow 也成功地将全球的程序员凝聚在一起，让知识的分享与获取变得前所未有的高效。

就这样，一个旨在解决技术难题的网站，最终成为了无数开发者赖以生存的“第二搜索引擎”和技术问答社区。

由于其巨大的成功，Stack Overflow 后来还衍生出一系列产品，巅峰时期的它拥有 180+ 子站，而且涵盖了从编程到数学、物理等众多领域的问答社区。

然而，即便是这样一个全球顶级的技术社区，如今，也难逃被 AI 冲击和洗礼的命运。

于是我也开始回想，我自己这几年在互联网上检索信息的方式，似乎在不知不觉中发生了变化。

现在遇到问题，我好像已经不怎么喜欢使用传统搜索引擎和技术社区了，而是会习惯性地转向各种 AI 工具和智能助手，同时信息的处理和交互范式也完全变了。

我们还以编程写代码为例。

以前当我们在写代码调试运行出现错误但折腾半天也不知所以的时候，大家会怎么做？

相信不少同学和我一样，也是首先复制这段报错信息到搜索引擎中进行检索，然后根据搜索引擎吐出来的搜索结果，自己逐个点进去筛选有用的信息。

而当我们一旦在搜索结果里看到了 Stack Overflow 相关网页时，直觉一般会告诉我们，离问题解决应该不远了。

要是在搜索引擎里实在找不到解决问题的方法，那我们就只能去类似 Stack Overflow 这样的编程社区里进行发帖求助了，然后等待问题被查看和回答。

这是在 AI 大模型还没有爆发之前，大家所普遍采用的一个解决问题的办法，总结起来就是这样：

• 遇到问题 → 搜索引擎 → Stack Overflow 链接 → 改代码调试 → 解决问题。

或者这样：

• 遇到问题 → 实在搜索无果 → 发帖 → 等待回答

但现在，随着 AI 技术和工具的发展，事情就变了。

我们可以直接甩给 AI 工具一个问题或者一段信息，AI 工具便会自动理解你的意图，并开始深度思考、收集信息、整理逻辑、分析总结、加工输出，最后直接把生成的答案或解决问题的办法呈现在你的眼前。

而且现在 AI Coding 工具如此强大，从遇到问题到解决问题，甚至都不需要跳出 IDE，问题就可以被完美解决。

所以相比去 Stack Overflow 上发帖子、搜问题、筛答案，AI 引擎无论在时间效率，还是知识维度的扩展上都给了这些传统技术社区以降维打击。

传统搜索引擎往往依赖于关键词匹配和链接分析，因此对于用户问题的理解往往有所欠缺，而 AI 大模型则能够深度理解语言含义和上下文，理解问题的真正意图。

而且 AI 大模型的分析理解能力、整合能力以及推理能力，这些都是传统知识社区和搜索引擎往往所欠缺的东西。

同时 AI 大模型能阅读、理解并整合数据中不同维度的海量知识，并能在此基础上来进行进一步的推理、分析、总结、泛化，这在如今的信息爆炸的时代来说是一种巨大的价值。

所以从这个角度来看，AI 大模型引擎并不是搜索引擎的简单升级版，而是一种全新的信息处理和交互范式。

当然，把 Stack Overflow 衰落的全部原因都归结于 AI 其实也不太公平。

即便不谈 AI 的因素，从大家的反馈来看，近年来 Stack Overflow 社区氛围的下坡路也是其衰落的一个不可忽略的因素。

比如很多初学者的问题经常会由于问题太基础或者格式不对而被下架，另外不少同学反馈 Stack Overflow 上戾气也不小，包括还能看到对新人小白冷嘲热讽，以及老用户之间的斗气争吵等等，这些都会慢慢磨灭大家的热情以及社区的技术氛围。

所以各种内外因素加在一起，再来看如今 Stack Overflow 的这般发展趋势，也就不足为奇了。

那面对 AI 大模型这波浪潮的席卷和冲击，不少传统的搜索引擎和知识社区都开始了转型升级，并积极拥抱 AI。

包括像 Stack Overflow 他们自己也搞了一个 Overflow AI，其中包含了一套基于他们自己的历史内容和知识库所打造的 GenAI 工具。

从「检索工具」进化到「智能助手」，这是不少现技术社区和知识引擎正在经历的蜕变之路。

这两年 AI 大模型领域的发展速度相信大家都有目共睹了，技术迭代进化更是远超预期。

可以预见的是，未来的信息检索和交互方式一定还会进一步高效、精准和智能，而对此我们也可以拭目以待。

好了，那以上就是今天的内容分享了，感谢大家的阅读，我们下篇见。

注：本文在GitHub开源仓库「编程之路」 github.com/rd2coding/R… 中已经收录，里面有我整理的6大编程方向(岗位)的自学路线+知识点大梳理、面试考点、我的简历、几本硬核pdf笔记，以及程序员生活和感悟，欢迎star。

大家好，我是 一颗烂土豆。

最近在数据可视化领域进行了一些探索，基于 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);

};

为什么选择 BroadcastChannel

BroadcastChannel API 是 HTML5 提供的跨标签页通信方案：

// BroadcastChannel 基本使用

const channel = new BroadcastChannel('my-channel');

channel.postMessage({ type: 'MESSAGE', data: 'Hello' });

channel.onmessage = (event) => {

  console.log('收到广播:', event.data);

};

组合方案的优势

将 SSE 和 BroadcastChannel 结合，可以实现：

• 单连接管理：只有一个标签页建立 SSE 连接


• 消息广播：SSE 接收的消息通过 BroadcastChannel 同步到所有标签页


• 连接恢复：标签页关闭时，其他标签页自动接管连接


• 状态同步：所有标签页的消息状态保持一致

实现方案

整体架构设计

sequenceDiagram

    participant Server as 服务器端

    participant TabA as 标签页 A<br/>(主连接)

    participant BC as BroadcastChannel

    participant TabB as 标签页 B<br/>(从连接)



    Note over TabA: 初始化阶段

    TabA->>TabA: 检查是否有 SSE 连接

    alt 无连接

        TabA->>Server: 建立 SSE 连接

        Server-->>TabA: 连接成功

    end



    Note over Server,TabB: 消息接收阶段

    Server->>TabA: 推送消息 (SSE)

    TabA->>TabA: 处理消息<br/>(更新状态、显示通知)

    TabA->>BC: 广播消息

    BC->>TabB: 同步消息

    TabB->>TabB: 处理消息<br/>(更新状态、显示通知)



    Note over TabA,TabB: 连接管理阶段

    TabA->>TabA: 标签页关闭

    TabA->>BC: 发送关闭信号

    BC->>TabB: 通知连接关闭

    TabB->>TabB: 关闭旧连接

    TabB->>Server: 重新建立 SSE 连接

    Server-->>TabB: 连接成功

核心流程

注意这里服务端接入 SSE 的时候可以设置同一用户下只保持一个活跃连接即可，历史连接丢弃超时会自动断开

核心实现

1. SSE 连接封装

首先，我们需要封装一个支持重连和错误处理的 SSE 连接工具：

import { EventSourcePolyfill } from 'event-source-polyfill';

import util from '@/libs/util';

import Setting from "@/setting";



const MAX_RETRY_COUNT = 3;

const RETRY_DELAY = 3000;



const create = (url, payload) => {

  let retryCount = 0;



  const connect = () => {

    const token = util.cookies.get("token")

    if(!token){

      return

    }



    const eventSource = new EventSourcePolyfill(

      `${Setting.request.apiBaseURL}${url}`,

      {

        headers: {

          token: util.cookies.get("token"),

          pageUrl: window.location.pathname,

          userId: util.cookies.get("userId"),

        },

        heartbeatTimeout: 28800000, // 8小时心跳超时

      }

    );



    eventSource.addEventListener("open", function (e) {

      console.log('SSE连接成功');

      retryCount = 0; // 重置重试次数

    });



    eventSource.addEventListener("error", function (err) {

      console.error('SSE连接错误:', err);



      if (retryCount < MAX_RETRY_COUNT) {

        retryCount++;

        console.log(`尝试重新连接 (${retryCount}/${MAX_RETRY_COUNT})...`);

        setTimeout(() => {

          eventSource.close();

          connect();

        }, RETRY_DELAY);

      } else {

        console.error('SSE连接失败，已达到最大重试次数');

        eventSource.close();

      }

    });



    return eventSource;

  };



  return connect();

}



export default {

  create

}

关键点解析：

• 使用 EventSourcePolyfill 支持自定义 headers（原生 EventSource 不支持）


• 实现自动重连机制，最多重试 3 次


• 设置心跳超时时间，防止长时间无响应导致连接假死


• 在 headers 中传递 token 和页面信息，便于服务端识别和路由

2. BroadcastChannel 封装

创建一个简洁的 BroadcastChannel 工具类：

export const createBroadcastChannel = (channelName: string) => {

  const channel = new BroadcastChannel(channelName);

  return {

    channel,

    sendMessage(data: any) {

      channel.postMessage(data);

    },

    receiveMessage(callback: (data: any) => void) {

      channel.onmessage = (event) => {

        callback(event.data);

      };

    },

    closeChannel() {

      channel.close();

    },

  };

};

设计说明：

• 封装成工厂函数，便于创建多个通道（消息通道、连接管理通道）


• 提供简洁的 API：发送消息、接收消息、关闭通道


• 支持传递任意类型数据（对象、数组等）

3. SSE 连接管理

实现单例模式的 SSE 连接管理：

import sseRequest from "@/plugins/request/sse";

import store from "@/store";



export const fetchSSE = (payload?: { [key: string]: string }) => {

  const eventSource = sseRequest.create("/sse/connect", {

    ...payload

  });

  return eventSource;

};



export const initSSEEvent = async () => {

  console.log('sse-init');

  // 检查是否已经有实例在当前标签页中创建，可用于项目中获取实例方法用

  let eventSource = (store.state as any).admin.request.sseEvent;



  if (!eventSource) {

    // 如果没有实例，则创建一个新的

    eventSource = fetchSSE();

    // 存储到 Vuex 中

    store.commit('admin/request/SET_SSE_EVENT', eventSource);

  }



  return eventSource;

};