老板： 咱们公司的设备开机，怎么显示Android。这怎么行，把Android替换掉，显示公司的logo，最好加点牛逼的动画.

小卡拉米: 好的,老板

小卡拉米 to UI: 老板说要一个牛逼的动画。

UI： 我*&……%%￥……&&*………………%

1、UI设计帧动画

跟UI沟通，最好说明，老板的意思，怎么牛逼。最重要的是：

• 把动画输出成序列帧。


• 分辨率和板子的分辨率一致。


• 命名规则：00.jpg 01.jpg ...99.jpg

2、制作动画包

新建一个文件夹，名字为：bootanimation
新建子文件夹第一部分动画：命名为part1，将UI设计好的非常牛逼的动画，放进去
新建子文件夹第二部分定格动画：命名为part2 ，将帧动画的最后一帧放到这里边
新建一个desc.txt
desc.txt的内容：

1024 768 60

p 1 0 part1

p 0 10 part2

全局参数（第一行）

分段参数（后续行）

每行定义一个动画片段，格式为：

[类型] [循环次数] [间隔时间] [目录名]

第一片段：p 1 0 generic1

第二片段：p 0 10 generic2

• 系统会先播放 generic1 目录中的动画，播放 1 次，无延迟。


• 接着播放 generic2 目录中的动画，无限循环，每次循环结束后等待 10 帧的时间。


• 开机动画会持续播放，直到系统启动完成（或强制终止）。

压缩动画包（很重要的一步）

• 压缩的时候，不要在外边一层去压缩，要点进去bootanimation文件夹，全选压缩。


• 压缩的时候格式要选择成存储。360压缩，自定义里边有。

3、替换动画包

使用adb命令进行替换，替换之前设备要进行root，一般开发板都是 root过的，然后使用命令进行替换

默认情况下，Android 设备的 /system 分区是只读的（出于系统安全性考虑）。adb remount 会临时将其重新挂载为可读写（rw），允许你修改系统文件（如删除预装应用、替换系统文件等）。

adb root // 获取root 权限

adb remount //重新挂载为可读写

adb push 你的动画包路径 system/media

动画包的名称一般是bootanimation.zip，有些厂商的可能不一样，如果不生效可以咨询板子厂家进行修改

替换成功之后，直接运行 adb reboot 进行重启，见证奇迹。

4、Android动画前的小企鹅（Linux开机动画）

我真服了，板子出厂前，竟然还有Linux开机动画，这个关掉，需要更改内核启动参数。下边是修改方法，但是建议联系厂家，建议联系厂家，建议联系厂家

4.1. 确认 Logo 类型

• Linux 内核 Logo：企鹅 Logo 通常是内核编译时内置的，文件格式可能是 .ppm、.rle 或 .png。


• Bootloader Logo：某些设备的厂商会在 Bootloader 阶段显示自定义 Logo（如高通设备的 splash.img）。

需要先确定企鹅 Logo 的来源：

• 如果设备启动时先显示企鹅，再显示 Android 开机动画（bootanimation.zip），则属于 内核 Logo。

4.2. 替换 Linux 内核 Logo

步骤 1：获取内核源码

• 需要设备的 内核源代码（从厂商或开源社区获取，如 LineageOS、XDA 论坛等）。


• 如果厂商未公开源码，此方法不可行。

步骤 2：准备自定义 Logo

• 内核支持的格式通常为 PPM（Portable PixMap），尺寸需与屏幕分辨率匹配（如 1024x768）。


• 使用工具（如 GIMP、ffmpeg）将图片转换为 .ppm 格式，并保存为 logo_linux_clut224.ppm（文件名可能因内核版本而异）。

步骤 3：替换内核 Logo 文件

• 将自定义的 .ppm 文件替换内核源码目录中的对应文件：
  

  # 示例路径（不同内核可能不同）
  
  cp custom_logo.ppm drivers/video/logo/logo_linux_clut224.ppm
  
  

  
  

步骤 4：编译内核

• 配置内核编译选项，确保启用 Logo 显示：
  

  make menuconfig
  
  # 进入 Device Drivers -> Graphics support -> Bootup logo
  
  # 启用 "Standard 224-color Linux logo"
  
  

  
  


• 编译内核并生成 boot.img：
  

  make -j$(nproc)
  
  

  
  

步骤 5：刷入新内核

• 使用 fastboot 刷入编译后的 boot.img：
  

  fastboot flash boot boot.img
  
  

  
  

4.3. 替换 Bootloader Logo（高通设备示例）

如果企鹅 Logo 是 Bootloader 阶段的 Splash Screen（如高通设备）：

步骤 1：提取当前 Splash Image

• 从设备中提取 splash.img：
  

  adb pull /dev/block/bootdevice/by-name/splash splash.img
  
  

  
  

步骤 2：修改 Splash Image

• 使用工具（如 splash_screen_tool）解包 splash.img，替换其中的图片，再重新打包。

步骤 3：刷入新 Splash Image

• 通过 fastboot 刷入：
  

  fastboot flash splash splash.img
  
  

  
  

4. 隐藏企鹅 Logo（无需替换）

如果无法修改内核或 Bootloader，可以尝试以下方法：

• 修改内核启动参数：在内核命令行中添加 logo.nologo 参数（需解锁 Bootloader 并修改 boot.img 的 cmdline）。


• 禁用 Framebuffer：在内核配置中关闭 CONFIG_LOGO 选项（需重新编译内核）。

注意事项

引言

最近在折腾油猴脚本开发，顺手搞了一个可以拦截任意网页接口的小工具，并修改了CSDN的博客数据接口，成功的将文章总数和展现量进行了修改。

如果你不了解什是油猴，参考这篇文章：juejin.cn/book/751468…

然后我突然灵光一闪：

既然能拦截接口、篡改数据，那我为什么不顺便测试一下 CSDN 博客在极端数据下的表现呢？

毕竟我们平时开发的时候，测试同学各种花式挑刺，什么 null、undefined、999999、-1、空数组……

每次都能把页面测出一堆边角 bug。

今天，轮到我来当一回“灵魂测试”了！

用我的脚本，造几个极限场景，看看 CSDN 的前端到底稳不稳！

实现原理

其实原理并不复杂，核心就一句话：

借助油猴的脚本注入能力 + ajax-hook 对接口请求进行拦截和修改。

我们知道，大部分网页的数据接口都是通过 XMLHttpRequest 或 fetch 发起的，而 ajax-hook 就是一个开源的轻量工具，它能帮我们劫持原生的 XMLHttpRequest，在请求发出前、响应返回后进行自定义处理。

配合油猴脚本的注入机制，我们就可以实现在浏览器端伪造任意接口数据，用来调试前端样式、模拟数据异常、测试权限控制逻辑等等。

ajax-hook 快速上手

我们用的是 CDN 方式直接引入，简单暴力：

<script src="https://unpkg.com/ajax-hook@3.0.3/dist/ajaxhook.min.js"></script>

引入后，页面上会多出一个全局对象 ah，我们只需要调用 ah.proxy()，就可以注册一套钩子：

ah.proxy({

  onRequest: (config, handler) => {

    // 请求发出前

    handler.next(config);

  },

  onError: (err, handler) => {

    // 请求出错时

    handler.next(err);

  },

  onResponse: (response, handler) => {

    // 请求成功响应后

    console.log("响应内容：", response.response);

    handler.next(response);

  }

});

拦截实现

我们以 CSDN 博客后台为例，先找到博客数据接口

地址长这样：bizapi.csdn.net/blog/phoeni…

我们在 onResponse 钩子中，加入 URL 判断，专门拦截这个接口：

onResponse: (response, handler) => {

  if (response.config.url.includes("https://bizapi.csdn.net/blog/phoenix/console/v1/data/blog-statistics")) {

    const hookResponse = JSON.parse(response.response);

    console.log("拦截到的数据：", hookResponse);

    handler.next(response);

  } else {

    handler.next(response);

  }

}

就这样，接口拦截器初步搭建完成！

使用油猴将脚本运行在网页

接下来我们用油猴把这段脚本注入到 CSDN 博客后台页面。

// ==UserScript==

// @name         CSDN博客数据接口拦截

// @namespace    http://tampermonkey.net/

// @version      0.0.1

// @description  拦截接口数据，验证极端情况下的样式展示

// @author       石小石Orz

// @match        https://mpbeta.csdn.net/*

// @require      https://unpkg.com/ajax-hook@3.0.3/dist/ajaxhook.min.js

// @run-at       document-start

// @grant        none

// ==/UserScript==



(function() {

  'use strict';



  ah.proxy({

    onRequest: (config, handler) => {

      handler.next(config);

    },

    onError: (err, handler) => {

      handler.next(err);

    },

    onResponse: (response, handler) => {

      console.log("接口响应列表：", response);

      // 这里写拦截逻辑

      handler.next(response);

    }

  });

})();

为了测试前端的容错能力，我们可以伪造一些极端数据返回：

• 文章总数设为 null


• 展现量设为 0


• 点赞数设为一个异常大的值

onResponse: (response, handler) => {

  if (response.config.url.includes("https://bizapi.csdn.net/blog/phoenix/console/v1/data/blog-statistics")) {

    const hookResponse = JSON.parse(response.response);



    // 伪造数据

    hookResponse.data[0].num = null;                    // 文章总数

    hookResponse.data[1].num = 0;                       // 展现量

    hookResponse.data[2].num = 99999999999999999;       // 点赞数



    console.log("修改后的数据：", hookResponse);



    response.response = JSON.stringify(hookResponse);

  }

  handler.next(response);

}

结果验证

修改成功后刷新页面，可以观察到如下问题：

• 文章总数为 null 时，布局异常，显然缺乏空值判断。


• 点赞数为超大值 时，页面直接渲染出 100000000000000000，不仅视觉上溢出容器，连排版都崩了，前端没有做任何兼容处理。

CSDN的前端还是偷懒了呀，一点也不严谨！差评！

总结

通过这篇文章的示例，我们前端应该引以为戒，永远不要相信后端同学返回的数据，一定要做好容错处理！

通过本文，相信大家也明白了油猴脚本不仅是玩具，它在前端开发中其实是个非常实用的辅助工具！

如果你对油猴脚本的开发感兴趣，不妨看看我写的这篇教程 《油猴脚本实战指南》

从小脚本写起，说不定哪天你也能靠一个脚本搞出点惊喜来！

urls.forEach(url => {

  const link = document.createElement('a');

  link.href = url;

  link.download = 'filename';

  document.body.appendChild(link);

  link.click();

  document.body.removeChild(link);

});

downloadFileBatch(url) {

  const iframe = document.createElement('iframe');

  iframe.style.display = 'none';

  iframe.style.height = '0';

  iframe.src = this.urlProtocolDelete(url);

  document.body.appendChild(iframe);

  

  setTimeout(() => {

      iframe.remove();

  }, 5000);

}



urlProtocolDelete(url: string = '') {

  if (!url) {

      return;

  }

  return url.replace('http://', '//').replace('https://', '//');

}

const iframe = document.createElement('iframe');

iframe.style.display = 'none';

iframe.style.height = '0';

urlProtocolDelete(url: string = '') {

  return url.replace('http://', '//').replace('https://', '//');

}

这个函数将 URL 中的协议部分替换为//，这样可以确保在 HTTPS 页面中请求 HTTP 资源时不会出现混合内容警告。

3. 触发下载并清理 DOM：

iframe.src = this.urlProtocolDelete(url);

document.body.appendChild(iframe);



setTimeout(() => {

    iframe.remove();

}, 5000);

将 iframe 添加到 DOM 中会触发浏览器对 src 的请求，从而开始下载文件。设置 5 秒的超时时间后移除 iframe，既保证了下载有足够的时间完成，又避免了 DOM 中积累过多无用元素。

四、批量下载的实现与优化

对于多个文件的批量下载，可以通过循环调用 downloadFileBatch 方法：

result.forEach(item => {

  this.downloadFileBatch(item.url);

});

五、踩坑+注意点

在实现批量下载 XML 文件功能时，你可能会遇到这种情况：明明请求的 URL 地址无误，服务器也返回了正确的数据，但文件却没有被下载到本地，而是直接在浏览器中打开预览了。这是因为 XML 作为一种可读的文本格式，浏览器默认会将其视为可直接展示的内容，而非需要下载保存的文件。

解决方案：
通过在下载链接中添加response-content-disposition=attachment参数，可以强制浏览器将 XML 文件作为附件下载，而非直接预览。这个参数会覆盖浏览器的默认行为，明确告诉浏览器 "这是一个需要下载保存的文件"。

addDownloadDisposition(url: string, filename: string): string {

  try {

    const urlObj = new URL(url);

    

    // 添加 response-content-disposition 参数

    const disposition = `attachment;filename=${encodeURIComponent(filename)}`;

    urlObj.searchParams.set('response-content-disposition', disposition);

    

    return urlObj.toString();

  } catch (error) {

    console.error('URL处理失败:', error);

    return url;

  }

}

六、大量文件并发控制

有待补充

前言

最近公司来了个新同事，年轻有活力，就是查日志的方式让我有点裂开。

事情是这样的：他写的代码在测试环境报错了，报警信息也被钉钉机器人发到了我们群里。作为资深摸鱼战士，我寻思正好借机摸个鱼顺便指导一下新人，就凑过去看了眼。

结果越看我越急，差点当场喊出：“兄弟你是来写代码的，还是和日志谈恋爱的？”

来看看他是怎么查日志的

他先敲了一句：

tail -f a.log | grep "java.lang.NullPointerException"

想着等下次报错就能立刻看到。等了半天，终于蹦出来一行：

2025-07-03 11:38:48.339 [http-nio-8960-exec-1] [47gK4n32jEYvTYX8AYti48] [INFO] [GlobalExceptionHandler] java.lang.NullPointerException, ex: java.lang.NullPointerException

java.lang.NullPointerException: null

我提醒他：“这样看不到堆栈信息啊。”

他“哦”了一声，灵机一动，用 vi把整个文件打开，/NullPointerException 搜关键词，一个 n 一个 n 地翻……半分钟过去了，异常在哪都没找全，我都快给他跪下了。

于是我当场掏出了一套我压箱底的“查日志组合拳”，一招一式手把手教他。他当场就“悟了”，连连称妙，并表示想让我写成文章好让他发给他前同事看——因为他前同事也是这样查的……

现在，这套组合拳我也分享给你，希望你下次查日志的时候，能让你旁边的同事开开眼。

正式教学

核心的工具其实还是 grep 命令，下面我将分场景给你讲讲我的实战经验，保证你能直接套用！

场景一：查异常堆栈，不能只看一行！

Java 异常堆栈通常都是多行的，仅仅用 grep "NullPointerException" 只能看到最上面那一行，问题根源在哪你压根找不到。

这时候使用 **grep** 的 **-A** (After) 参数来显示匹配行之后的N行。

# 查找 NullPointerException，并显示后面 50 行

grep -A 50 "java.lang.NullPointerException" a.log

如果你发现异常太多，屏幕一闪而过，也可以用less加上分页查看：

grep -A 50 "java.lang.NullPointerException" a.log | less

在 less 视图中，你可以：

• 使用 箭头↑↓ 或 Page Up/Down 键来上下滚动


• 输入 G 直接翻到末尾，方便快速查看最新的日志


• 输入 /Exception 继续搜索


• 按 q 键退出

这样你就能第一时间拿到完整异常上下文信息，告别反复 vi + / 的低效操作！

场景二：实时看新日志怎么打出来的

如果你的应用正在运行，并且你怀疑它会随时抛出异常，你可以实时监控日志文件的增长。

使用 tail -f 结合 grep：

# 实时监控 a.log 文件的新增内容，并只显示包含 "java.lang.NullPointerException" 的行及其后50行

tail -f a.log | grep -A 50 "java.lang.NullPointerException"

只要异常一出现，它就会自动打出来，堆栈信息也一并送到你面前！

• 想停下？Ctrl + C


• 想更准确？加 -i 忽略大小写，防止大小写拼错找不到

场景三：翻历史日志 or 查压缩日志

服务器上的日志一般都会按天或按大小分割并压缩，变成 .log.2025-07-02.gz 这种格式，查找这些文件的异常信息怎么办？

🔍 查找当前目录所有 .log 文件：

# 在当前目录下查找所有以 .log 结尾的文件，-H 参数可以顺便打印出文件名

grep -H -A 50 "java.lang.NullPointerException" *.log

其中 -H 会帮你打印出是哪个文件中出现的问题，防止你找完还不知道是哪天的事。

🔍 查找 .gz 文件（压缩日志）：

zgrep -H -A 50 "java.lang.NullPointerException" *.gz

zgrep 是专门处理 .gz 的 grep，它的功能和 grep 完全一样，无需手动解压，直接开整！

场景四：统计异常数量（快速判断异常是否频繁）

有时候你需要知道某个异常到底出现了多少次，是偶发还是成灾，使用 grep -c（count）：

grep -c "java.lang.NullPointerException" a.log

如果你要统计所有日志里的数量：

grep -c "java.lang.NullPointerException" *.log

其他常用的 grep 参数

比如：

grep -C 25 "java.lang.NullPointerException" a.log

这个命令就能让你一眼看到异常前后的上下文，帮助定位代码逻辑是不是哪里先出问题了。

尾声

好了，这套组合拳我已经传授给你了，要是别人问你在哪学的，记得报我杆师傅的大名（doge）。

其实还有其他查日志的工具，比如awk、wc 等。

但是我留了一手，没有全部教给我这个同事，毕竟江湖规则，哪有一出手就把看家本领全都交出去的道理？

如果你也想学，先拜个师交个学费（点赞、收藏、关注），等学费凑够了，我下次再开新课，传授给大家~

Tailwind 曾经是我最爱的工具，直到它让我维护不下去整个项目。

前情提要：我是如何变成 Tailwind 重度用户的

作为一个多年写 CSS 的前端，我曾经深陷“命名地狱”：

什么 .container-title, .btn-primary, .form-item-error，一个项目下来能写几百个类名，然后改样式时不知道该去哪动刀，甚至删个类都心慌。

直到我遇见了 Tailwind CSS——一切原子化，想改样式就加 class，别管名字叫什么，直接调属性即可。

于是我彻底拥抱它，团队项目里我把所有 SCSS 全部清除，组件中也只保留了 Tailwind class，一切都干净、轻便、高效。

但故事从这里开始转变。

三个月后的重构期，我被 Tailwind“反噬”

我们的后台管理系统迎来一次大版本升级，我负责重构 UI 样式逻辑，目标是：

• 统一设计规范；


• 提高代码可维护性；


• 降低多人协作时的样式冲突。

刚开始我信心满满，毕竟 Tailwind 提供了：

• 原子化 class；


• @apply 合成组件级 class；


• 配置主题色/字体/间距系统；


• 插件支持动画/form 控件/typography；

但随着项目深入，我开始发现 几个巨大的问题，并最终决定停用 Tailwind。

一、class 污染：结构和样式纠缠成灾

来看一个真实例子：

<div class="flex items-center justify-between bg-white p-4 rounded-lg shadow-sm border border-gray-200">

  <h2 class="text-lg font-semibold text-gray-800">订单信息</h2>

  <button class="text-sm px-2 py-1 bg-blue-500 text-white rounded hover:bg-blue-600">编辑</button>

</div>

你能看出这个组件的“设计意图”吗？

你能快速改它的样式吗？

一个看似简单的按钮，一眼看不到设计语言，只看到一坨 class，你根本不知道：

• px-2 py-1 是从哪里决定的？


• bg-blue-500 是哪个品牌色？


• hover:bg-blue-600 是统一交互吗？

Tailwind 让样式变得快，但也让样式“变得不可读”。

二、复用失败：想复用样式还得靠 SCSS

我天真地以为 @apply 能帮我合成组件级样式，比如：

.btn-primary {

  @apply text-white bg-blue-500 px-4 py-2 rounded;

}

但问题来了：

• @apply 不能用在媒体查询内；


• @apply 不支持复杂嵌套、hover/focus 的组合；


• 响应式、伪类写在 HTML 里更乱，如：lg:hover:bg-blue-700；


• 没法动态拼接 class，逻辑和样式混在组件逻辑层了。

最终结果就是：复用失败、样式重复、维护困难。

三、设计规范无法沉淀

我们设计系统中定义了若干基础变量：

• 主色：#0052D9


• 次色：#A0AEC0


• 字体尺寸规范：12/14/16/18/20/24/32px


• 组件间距：8/16/24

本来我们希望 Tailwind 的 theme.extend 能承载这套设计系统，结果发现：

• tailwind.config.js 修改后，需要全员重启 dev server；


• 新增设计 token 非常繁琐，不如直接写 SCSS 变量；


• 多人改配置时容易冲突；


• 和设计稿同步代价高。

这让我明白：配置式设计系统不适合快速演进的产品团队。

四、多人协作混乱：Tailwind 并不直观

当我招了一位新同事，给他一个组件代码时，他的第一句话是：

“兄弟，这些 class 是从设计稿复制的吗？”

他根本看不懂 gap-6, text-gray-700, tracking-wide 分别是什么意思，只看到一堆“魔法 class” 。

更糟糕的是，每个人心中对 text-sm、text-base 的视觉认知不同，导致多个组件在微调时出现样式不一致、间距不统一的问题。

Tailwind 的语义脱离了设计意图，协作就失去了基础。

最终决定：我切回了 SCSS + BEM + 设计 token

我们开始回归传统模式：

• 所有组件都有独立 .scss 文件；


• 使用 BEM 命名规范：.button, .button--primary, .button--disabled；


• 所有颜色/间距/字体等统一放在 _variables.scss 中；


• 每个组件样式文件都注释设计规范来源。

这种模式虽然看起来“原始”，但它：

• 清晰分离结构和样式；


• 强制大家遵守设计规范；


• 组件样式可复用，可继承，可重写；


• 新人一眼看懂，不需要会 Tailwind 语法。

总结：Tailwind 不是错，是错用的代价太高

Tailwind 在以下场景表现极好：

• 个人项目 / 小程序：快速开发、无需复用；


• 组件库原型：试验颜色、排版效果；


• 纯前端工程师独立开发的项目：没有协作负担。

但在以下情况，Tailwind 会成为维护灾难：

• 多人协作；


• UI 不断迭代，设计语言需频繁调整；


• 有强复用需求（组件抽象）；


• 与设计系统严格对齐的场景；

我为什么写这篇文章？

不是为了黑 Tailwind，而是为了让你在选择技术栈时更慎重。

就像当年我们争论 Sass vs Less，今天的 Tailwind vs 原子/语义 CSS 并没有标准答案。

Tailwind 很强，但不是所有团队都适合。

也许你正在享受它的爽感，但三个月后你可能会像我一样，把所有 .w-full h-screen text-gray-800 替换成 .layout-container。

尾声：如果你非要继续用 Tailwind，我建议你做这几件事

一、Docker 不再万能，我们该何去何从？

过去十年，Docker 改变了整个软件开发世界。它以“一次构建，到处运行”的理念，架起了开发者和运维人员之间的桥梁，推动了 DevOps 与微服务架构的广泛落地。

从自动化部署、持续集成到快速交付，Docker 一度是不可或缺的技术基石。

然而到了 2025 年，越来越多开发者开始重新审视 Docker。

系统规模在不断膨胀，开发场景也更加多元，不再是当初以单一后端应用为主的架构。

如今，开发者面临的不只是如何部署一个服务，更要关注架构的可扩展性、容器的安全性、本地与云端的适配性，以及资源的最优利用。

在这种背景下，Docker 开始显得不再那么“全能”，它在部分场景下的臃肿、安全隐患和与 Kubernetes 的解耦问题，使得不少团队正在寻找更轻、更适合自身的替代方案。

之所以写下这篇文章就是为了帮助你认清 Docker 当前的局限，了解新的技术趋势，并发现适用于不同场景的下一代容器化工具。

二、Docker 的贡献与瓶颈

不可否认，Docker 曾是容器化革命的引擎。从过去到现在，它的最大价值在于降低了环境配置的复杂度，让开发与运维团队之间的协作更加顺畅，带动了整个容器生态的发展。

很多团队正是依赖 Docker 才实现了快速构建镜像、构建流水线、部署微服务的能力。

但与此同时，Docker 本身也逐渐显露出局限性。比如，它高度依赖守护进程，导致资源占用明显高于预期，启动速度也难以令人满意。

更关键的是，Docker 默认以 root 权限运行容器，极易放大潜在攻击面，在安全合规日益严格的今天，这一点令人担忧。Kubernetes 的官方运行时也已从 Docker 切换为 containerd 与 runc，表明行业主流已在悄然转向。

这并不意味着 Docker 已过时，它依旧在许多团队中扮演重要角色。但如果你期待更高的性能、更低的资源消耗和更强的安全隔离，那么，是时候拓宽视野了。

三、本地开发的难题与新解法

特别是在本地开发场景中，Docker 的“不够轻”问题尤为突出。为了启动一个简单的 PHP 或 Node 项目，很多人不得不拉起庞大的容器，等待镜像下载、构建，甚至调试端口映射，最终电脑风扇轰鸣，开发体验直线下降。

一些开发者试图回归传统，通过 Homebrew 或 apt 手动配置开发环境，但这又陷入了“版本冲突”“依赖错位”等老问题。

这时，ServBay 的出现带来了新的可能。作为专为本地开发设计的轻量级工具，ServBay 不依赖 Docker，也无需繁琐配置。用户只需一键启动，即可在本地运行 PHP、Python、Golang、Java 等多种语言环境，并能自由切换版本与服务组合。它不仅启动迅速，资源占用也极低，非常适合 WordPress、Laravel、ThinkPHP 等项目的本地调试与开发。

更重要的是，ServBay 不再强制开发者理解复杂的镜像构建与容器编排逻辑，而是将本地开发流程变得像打开编辑器一样自然。对于 Web 后端和全栈开发者来说，它提供了一种“摆脱 Docker”的全新路径。

四、当 Docker 不再是运行时的唯一选择

容器运行时的格局也在悄然生变。containerd 和 runc 成为了 Kubernetes 官方推荐的运行时，它们更轻、更专注，仅提供核心的容器管理功能，剥离了不必要的附加组件。与此同时，CRI-O 正在被越来越多团队采纳，它是专为 Kubernetes 打造的运行时，直接对接 CRI 接口，减少了依赖层级。

另一款备受好评的是 Podman，它的最大亮点在于支持 rootless 模式，使容器运行更加安全。同时，它的命令行几乎与 Docker 完全兼容，开发者几乎不需要重新学习。

对于安全隔离要求极高的场景，还可以选择 gVisor 或 Kata Containers。前者通过用户态内核方式拦截系统调用，构建沙箱化环境；后者则将轻量虚拟机与容器结合，兼顾性能与隔离性。这些方案正在逐步替代传统 Docker，成为新一代容器架构的基石。

五、容器编排：Kubernetes 之后的路在何方？

虽然 Kubernetes 仍然是企业级容器编排的标准选项，但它的复杂性和陡峭的学习曲线也让不少中小团队望而却步。一个简单的应用部署可能涉及上百行 YAML 文件，过度的抽象与组件拆分反而拉高了运维门槛。

这也促使“微型 Kubernetes”方案逐渐兴起。K3s 是其中的代表，它对 Kubernetes 进行了极大简化，专为边缘计算和资源受限场景优化。此外，像 KubeEdge 等项目，也在积极拓展容器编排在边缘设备上的适配能力。

与此同时，AI 驱动的编排平台正在探索新路径。CAST AI、Loft Labs 等团队推出的智能调度系统，可以自动分析工作负载并进行优化部署，最大化资源利用率。更进一步，Serverless 与容器的融合也逐渐成熟，比如 AWS Fargate、Google Cloud Run 等服务，让开发者无需再关心节点管理，容器真正变成了“即用即走”的计算单元。

六、未来趋势：容器走向“定制化生长”

未来的容器化，我们将看到更细化的技术选型：开发环境选择轻量灵活的本地容器，测试环境强调快速重建与自动化部署，生产环境则关注安全隔离与高可用性。

安全性也会成为核心关键词。rootless 容器、沙箱机制和系统调用过滤将成为主流实践，容器从“不可信”向“可信执行环境”演进。与此同时，人工智能将在容器调度中发挥更大作用，不仅提升弹性伸缩的效率，还可能引领“自愈系统”发展，让集群具备自我诊断与恢复能力。

容器标准如 OCI 的持续完善，将让不同运行时之间更加兼容，为整个生态的整合提供可能。而在部署端，我们也将看到容器由本地向云端、再向边缘设备的自然扩展，真正成为“无处不在的基础设施”。

七、结语：容器化的新纪元已经到来

Docker 的故事并没有结束，它依然是很多开发者最熟悉的工具，也在部分场景中继续发挥作用。但可以确定的是，它不再是唯一选择。2025 年的容器世界，早已迈入了多元化、场景化、智能化的阶段。从轻量级的 ServBay 到更安全的 Podman，从微型编排到 Serverless 混合模式，我们手中可选的工具越来越丰富，技术栈的自由度也空前提升。

下一个十年，容器不只是为了“装下服务”，它将成为构建现代基础设施的关键砖块。愿你也能在这场演进中，找到属于自己的工具组合，打造更轻、更快、更自由的开发与部署体验。

🔍 一、什么是 Blob？

Blob（Binary Large Object）是 HTML5 提供的一个用于表示不可变的、原始二进制数据块的对象。

✨ 特点：

• 不可变性：一旦创建，内容不能修改。


• 可封装任意类型的数据：字符串、ArrayBuffer、TypedArray 等。


• 支持 MIME 类型描述，方便浏览器识别用途。

💡 示例：

const blob = new Blob(['Hello World'], { type: 'text/plain' });

🧠 二、Base64 编码的前世今生

虽然名字听起来像是某种“64进制”，但实际上它是一种编码方式，不是数学意义上的“进制”。

📜 起源背景：

Base64 最早起源于电子邮件协议 MIME（Multipurpose Internet Mail Extensions），因为早期的电子邮件系统只能传输 ASCII 文本，不能直接传输二进制数据（如附件）。于是人们发明了 Base64 编码方法，把二进制数据转换成文本形式，从而安全地在网络上传输。

🧩 使用场景：

⚠️ 注意：Base64 并非压缩算法，它会将数据体积增加约 33%。

🔁 三、从 Base64 到 Blob 的全过程

1. Base64 字符串解码：atob()

JavaScript 提供了一个内置函数 atob()，可以将 Base64 字符串解码为原始的二进制字符串（ASCII 表示）。

const base64Data = 'SGVsbG8gd29ybGQh'; // "Hello world!"

const binaryString = atob(base64Data);

⚠️ 返回的是 ASCII 字符串，不是真正的字节数组。

2. 构建 Uint8Array（字节序列）

为了构造 Blob，我们需要一个真正的字节数组。我们可以用 charCodeAt() 将每个字符转为对应的 ASCII 数值（即 0~255 的整数）。

const byteArray = new Uint8Array(binaryString.length);



for (let i = 0; i < binaryString.length; i++) {

    byteArray[i] = binaryString.charCodeAt(i);

}

现在，byteArray 是一个代表原始图片二进制数据的数组。

3. 创建 Blob 对象

有了字节数组，就可以创建 Blob 对象了：

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

这个 Blob 对象就代表了一张 PNG 图片的二进制内容。

4. 使用 URL.createObjectURL() 显示图片

为了让浏览器能够加载这个 Blob 对象，我们需要生成一个临时的 URL 地址：

const imageUrl = URL.createObjectURL(blob);

document.getElementById('blobImage').src = imageUrl;

这样，你就可以在网页中看到这张图片啦！

🛠️ 四、Blob 的核心功能与应用场景

🧪 五、Blob 的高级玩法

1. 文件切片上传（分片上传）

const chunkSize = 1024 * 1024; // 1MB

const firstChunk = blob.slice(0, chunkSize);

2. Blob 转换为其他格式

• FileReader.readAsText(blob) → 文本


• FileReader.readAsDataURL(blob) → Base64


• FileReader.readAsArrayBuffer(blob) → Array Buffer

3. Blob 下载为文件

const a = document.createElement('a');

a.href = URL.createObjectURL(blob);

a.download = 'example.png';

a.click();

🧩 六、相关知识点汇总

🧾 七、完整代码回顾

<!DOCTYPE html>

<html lang="en">

<head>

  <meta charset="UTF-8" />

  <title>Blob 实战</title>

</head>

<body>

  <img src="" id="blobImage" width="100" height="100" alt="Blob Image" />



  <script>

    const base64Data = 'UklGRiAHAABXRUJQVlA4IBQHAACwHACdASpQAFAAPok0lEelIyIhMziOYKARCWwAuzNaQpfW+apU37ZufB5rAHqW2z3mF/aX9o/ev9LP+j9KrqSOfp9mf+6WmE1P1yFc3gTlw8B8d/TebelHaI3mplPrZ+Aa0l5qDGv5N8Tt9vYhz3IH37wqm2al+FdcFQhDnObv2+WfpwIZ+K6eBPxKL2RP6hiC/K1ZynnvVYth9y+ozyf88Obh4TRYcv3nkkr43girwwJ54Gd0iKBPZFnZS+gd1vKqlfnPT5wAwzxJiSk+pkbtcOVP+QFb2uDqUhuhNiHJ8xPt6VfGBfUbTsUzYuKgAP4L9wrkT8KU4sqIHwM+ZeKDBpGq58k0aDirXeGc1Odhvfx+cpQaeas97zVTr2pOk5bZkI1lkF9jnc0j2+Ojm/H+uPmIhS7/BlxuYfgnUCMKVZJGf+iPM44vA0EwvXye0YkUUK...';



    const binaryString = atob(base64Data); // Base64 解码

    const byteArray = new Uint8Array(binaryString.length); // 创建 Uint8Array



    for (let i = 0; i < binaryString.length; i++) {

        byteArray[i] = binaryString.charCodeAt(i); // 填充字节数据

    }



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

    const imageUrl = URL.createObjectURL(blob); // 生成 URL



    document.getElementById('blobImage').src = imageUrl; // 显示图片

  </script>

</body>

</html>

📚 八、扩展阅读建议

• MDN - Blob


• MDN - Base64 编码与解码


• MDN - TypedArray

🧩 九、结语

Blob 是连接 JavaScript 世界与真实二进制世界的桥梁，是每一个想要突破瓶颈的前端开发者必须掌握的核心技能之一。
掌握了 Blob，你就拥有了操作二进制数据的能力，这在现代 Web 开发中是非常关键的一环。
下次当你看到一张图片在网页中加载出来，或者一个文件被顺利下载时，不妨想想：这一切的背后，都有 Blob 的身影。

void 0 是 JavaScript 中的一个表达式，它的作用是 返回 undefined。

解释：

常见用途：

• 防止默认行为（比如 <a> 标签的 href="javascript:void(0)"）：
  
  

  <a href="javascript:void(0);" onclick="alert('Clicked!')">
  
    点击不会跳转
  
  </a>
  
  

  
  

  这样点击链接时不会跳转页面，但仍然可以执行 JavaScript。



• 在函数中返回 undefined：
  
  

  function doSomething() {
  
    return void someOperation(); // 明确返回 undefined
  
  }
  
  

  
  

为什么用void 0

源码涉及到 undefined 表达都会被编译成 void 0

//源码  

const a: number = 6  

a === undefined  

  

//编译后  

"use strict";  

var a = 6;  

a === void 0;

也就是void 0 === undefined。void 运算符通常只能用于获取 undefined 的原始值，一般用void(0)，等同于void 0，也可以使用全局变量 undefined 替代。

为什么不直接写 undefined

undefined 是 js 原始类型值之一，也是全局对象window的属性，在一部分低级浏览器（IE7-IE8）中or局部作用域可以被修改。

undefined在js中，全局属性是允许被覆盖的。

//undefined是window的全局属性

console.log(window.hasOwnProperty('undefined'))

console.log(window.undefined)

//旧版IE

var undefined = '666'

console.log(undefined)//666 直接覆盖改写undefined

window.undefined在局部作用域中是可以被修改的 在ES5开始，undefined就已经被设定为仅可读的，但是在局部作用域内，undefined依然是可变的。

①某些情况下用undefined判断存在风险，因undefined有被修改的可能性，但是void 0返回值一定是undefined

②兼容性上void 0 基本所有的浏览器都支持

③ void 0比undefined字符所占空间少。

拓展

void(0) 表达式会返回 undefined 值，它一般用于防止页面的刷新，以消除不需要的副作用。

常见用法是在 <a> 标签上设置 href="javascript:void(0);"，即当单击该链接时，此表达式将会阻止浏览器去加载新页面或刷新当前页面的行为。

<!-- 点击下面的链接，不会重新加载页面，且可以得到弹框消息 -->

<a href="javascript:void(0);" onclick="alert('干的漂亮!')">

  点我呀

</a>

总结：

void 0 是一种确保得到 undefined 的可靠方式，虽然在现代 JavaScript 中直接用 undefined 也没问题，但在一些特殊场景（如代码压缩、兼容旧代码）仍然有用。

最近，和往常一样在逛 GitHub Trending 热榜时，突然看到又一个非常火的开源项目冲上了 Trending 热榜，相信不少小伙伴也刷到了。

一天之内就新增数千 star，仅仅用了几天时间，star 增长曲线都快干垂直了！

再定睛一看，好家伙，这不是微软的项目么。

出于好奇，点进去看了看，没错，这正是微软自家大名鼎鼎的 WSL！

原来就在前几天的微软 Build 2025 开发者大会上，微软正式官宣开源 Windows Subsystem for Linux（WSL）。

这在微软官方的最新的开发者技术博客也可以翻到。

众所周知，WSL 是微软在 2016 年就发布的一项重磅功能，相信不少同学都用过。

WSL 全称：Windows Subsystem for Linux，它允许用户在 Windows 操作系统中直接运行 Linux 环境，而无需双系统或者虚拟机，通过兼容层支持开发者工具、命令行应用及文件系统互通，实现方便地跨平台开发与测试。

从初始发布到如今走向开源，回顾 WSL 一路走来的发展历程，可以总结为如下几个大的阶段。

• 初期兼容层探索

2016年，微软首次推出 WSL 1。

其通过兼容层工具（如 lxcore.sys 驱动）将 Linux 系统调用转换为 Windows 调用，首次实现原生运行 ELF 可执行文件。

其优势是轻量级启动，但缺点也很明显，那就是兼容性和性能都存在一定局限。

• 中期扩展与独立应用

2019年，WSL 2 正式官宣。

此时微软对其进行了彻底的重构架构，采用基于 Hyper-V 的轻量级虚拟机技术，来运行完整 Linux 内核，并显著提升了兼容性与性能，同时这也使得 WSL 能支持运行更多的 Linux 程序和应用。

2021年，WSLg 正式推出，从此便支持了 Linux GUI 应用，同时 WSL 也开始作为独立组件来发布，其从 Windows 镜像剥离，转为通过 Microsoft Store 来进行独立安装和更新。

2022年～2024年这几年时间内，微软对 WSL 进行了持续迭代，包括 systemd 服务管理支持、GPU加速、多发行版支持以及内存和文件系统等诸多性能优化。

经过中期这一阶段的发展，WSL 在兼容性、功能以及性能等方面都有了长足的进步，也为下一步的开源和社区化奠定了基础。

• 后期开源和社区化

在前几天的微软 Build 2025 开发者大会上，微软正式宣布 WSL 开源（GitHub 仓库开放），允许社区直接参与代码贡献，这也标志了 WSL 进入了开源和社区化的新阶段。

至此为止，在 WSL 的 GitHub 仓库中的 Issue #1 —— 那个自2016年起就存在的“Will this project be Open Source?”的提问，终于被标注为了“Closed”！

众所周知，WSL 其实是由一组分布式组件来组合而成的。

即：一部分是在 Windows 系统中运行，另外一部分则是在 WSL 2 虚拟机内运行。

这个从 WSL 官方给出的组件架构图中就可以很清晰地看出来：

那既然现如今微软官宣了 WSL 开源，那对于开发者来说，我们需要清晰地知道这次到底开源了哪些组件代码呢？

关于这部分，对照上图，我们这里不妨用表格的形式来简要总结一下，供大家参考。

以上这些已开源的组件源码都可以在 WSL 的 GitHub 仓库里找到，大家感兴趣的话可以对应查看和研究。

虽然本次开源覆盖了 WSL 的绝大多数关键组件，但是官方也明确说了，以下这几个组件由于其仍然是 Windows 系统的一部分，所以目前仍然保持非开源状态，包括：

• Lxcore.sys：支撑 WSL1 的内核驱动程序


• P9rdr.sys和p9np.dll：运行"\wsl.localhost"文件系统重定向的关键组件（从 Windows 到 Linux）

这一点需要特别注意一下。

回顾过往，其实 GitHub 上的 WSL 仓库并不是最近才有，好多年前就已经存在了。

即便在以前的 WSL 还没有开源的日子里，WSL 的背后就有了一个强大的社区在支持，开发者们通过 GitHub Issue 和 Discussion 等为 WSL 这个项目提供了诸多错误追踪、新功能建议以及意见改进。

可以说，如果没有社区贡献，WSL 永远不可能成为今天的样子。

而现如今 WSL 源代码正式开源，这也满足了开发者社区长达 9 年的期待。

开发者们现在可以自行下载、构建，甚至提交改进建议或者新功能的代码来直接参与。

同时 WSL 官方也给出了一个详细的项目贡献指南：

感兴趣的同学也可以上去学习研究一波。

好了，那以上就是那以上就是今天的内容分享，希望能对大家有所帮助，我们下篇见。

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

那是一个普通的周三早晨，我正对着产品经理刚丢过来的需求发呆——"在管理系统里加个3D机柜展示，要能开门的那种"。

"这不就是个模型展示吗？"我心想，"AI应该能搞定吧？"

9:30 AM - 启动摸鱼模式

我熟练地打开代码编辑器，把需求复制粘贴进AI对话框： "用Three.js实现一个带开门动画的机柜模型，要求有金属质感，门能90度旋转"

点击发送后，我惬意地靠在椅背上，顺手打开了B站。"让AI先忙会儿~"

10:30 AM - 验收时刻

一集《凡人修仙传》看完，我懒洋洋地切回编辑器。AI果然交出了答卷：

11:00 AM - 血压升高现场

看着AI生成的"未来科技风"机柜，我深吸一口气，决定亲自下场。毕竟，程序员最后的尊严就是——"还是自己来吧"。

11:30 AM - 手动抢救

首先手动创建一个空场景吧

class SceneManager {

  constructor() {

    this.scene = new THREE.Scene();

    this.camera = new THREE.PerspectiveCamera(

      75,

      window.innerWidth / window.innerHeight,

      0.1,

      1000

    );

    this.camera.position.set(0, 2, 5);



    this.renderer = new THREE.WebGLRenderer();

    this.renderer.setSize(window.innerWidth, window.innerHeight);

    const canvas = document.getElementById('renderCanvas');

    canvas.appendChild(this.renderer.domElement);



    this.controls = new OrbitControls(this.camera, this.renderer.domElement);

    this.controls.enableDamping = true;

    this.controls.dampingFactor = 0.05;

    this.controls.target.set(0, 3, 0);

    this.controls.update();



    this.addLights();

    this.addFloor();

  }



  addLights() {

    const ambientLight = new THREE.AmbientLight(0xffffff, 0.5);

    this.scene.add(ambientLight);



    const directionalLight = new THREE.DirectionalLight(0xffffff, 1);

    directionalLight.position.set(5, 5, 5);

    this.scene.add(directionalLight);

  }



  addFloor() {

    const floorGeometry = new THREE.PlaneGeometry(10, 10);

    const floorMaterial = new THREE.MeshStandardMaterial({ color: 0x888888 });

    const floor = new THREE.Mesh(floorGeometry, floorMaterial);

    floor.rotation.x = -Math.PI / 2;

    this.scene.add(floor);

  }



  animate() {

    const animateLoop = () => {

      requestAnimationFrame(animateLoop);

      this.controls.update();

      this.renderer.render(this.scene, this.camera);

    };

    animateLoop();

  }



  onResize() {

    window.addEventListener('resize', () => {

      this.camera.aspect = window.innerWidth / window.innerHeight;

      this.camera.updateProjectionMatrix();

      this.renderer.setSize(window.innerWidth, window.innerHeight);

    });

  }

}

然后这机柜怎么画呢，不管了，先去吃个饭，天大地大肚子最大

12:30 PM - 程序员的能量补给时刻

淦！先干饭！" 我一把推开键盘，决定暂时逃离这个三维世界。毕竟——

扒饭间隙，手机突然震动。产品经理发来消息："那个3D机柜..."

我差点被饭粒呛到，赶紧回复："正在深度优化用户体验！"

（十分钟风卷残云后）

1:00 PM - 回归正题

吃饱喝足，终于可以专心搞机柜了,(此处可怜一下我的午休)

拆分机柜结构

机柜的结构可以分为以下几个部分：

实现步骤

接下来，我们开始用代码实现这些结构。

机柜结构的实现

1. 创建不可操作结构

底部

export function createCabinetBase(scene) {

  const geometry = new THREE.BoxGeometry(0.6,  0.05, 0.64);

  const base = new THREE.Mesh(geometry,  materials.baseMaterial);

  base.position.y = -0.05; // 调整位置

  scene.add(base);

}

底部使用BoxGeometry创建，设置了深灰色金属材质，位置调整为机柜的最底部。

顶部

export function createCabinetTop(scene) {

  const geometry = new THREE.BoxGeometry(0.6, 0.05,  0.64);

  const top = new THREE.Mesh(geometry, materials.baseMaterial);

  top.position.y = 1.95; // 调整位置

  scene.add(top);

}

顶部与底部类似，位置调整为机柜的最顶部。

侧面

export function createCabinetSides(scene) {

  const geometry = new THREE.BoxGeometry(0.04, 2, 0.6);

  const material = materials.baseMaterial;

  // 左侧面

  const leftSide = new THREE.Mesh(geometry, material);

  leftSide.position.set(-0.28, 0.95, 0); // 调整位置

  scene.add(leftSide);

  // 右侧面

  const rightSide = new THREE.Mesh(geometry, material);

  rightSide.position.set(0.28, 0.95, 0); // 调整位置

  scene.add(rightSide);

}

侧面使用两个BoxGeometry分别创建左侧和右侧，位置对称分布。

2. 创建可操作结构

前门

export function createCabinetFrontDoor(scene) {

    const doorGr0up = new THREE.Gr0up();

    const doorWidth = 0.04;

    const doorHeight = 2;

    const doorDepth = 0.6;



    const frameMaterial = materials.baseMaterial;

    const frameThickness = 0.04;



    // 上边框

    const topFrameGeo = new THREE.BoxGeometry(doorWidth, frameThickness, doorDepth);

    const topFrame = new THREE.Mesh(topFrameGeo, frameMaterial);

    topFrame.position.set(0, 1 - frameThickness / 2, 0);

    doorGr0up.add(topFrame);



    // 下边框

    const bottomFrameGeo = new THREE.BoxGeometry(doorWidth, frameThickness, doorDepth);

    const bottomFrame = new THREE.Mesh(bottomFrameGeo, frameMaterial);

    bottomFrame.position.set(0, -doorHeight / 2 + 0.05, 0);

    doorGr0up.add(bottomFrame);



    // 左右边框

    const leftFrameGeo = new THREE.BoxGeometry(doorWidth, doorHeight - 2 * frameThickness, frameThickness);

    const leftFrame = new THREE.Mesh(leftFrameGeo, frameMaterial);

    leftFrame.position.set(0, 1 - doorHeight / 2, -doorDepth / 2 + frameThickness / 2);

    doorGr0up.add(leftFrame);



    const rightFrameGeo = new THREE.BoxGeometry(doorWidth, doorHeight - 2 * frameThickness, frameThickness);

    const rightFrame = new THREE.Mesh(rightFrameGeo, frameMaterial);

    rightFrame.position.set(0, 1 - doorHeight / 2, doorDepth / 2 - frameThickness / 2);

    doorGr0up.add(rightFrame);



    scene.add(doorGr0up);

    return doorGr0up;

}

前门由一个Gr0up组装而成，包含上下左右边框，材质与机柜一致，后续将添加玻璃部分和动画。

前门动画的实现

前门的动画使用gsap库实现，设置旋转轴为左侧边框。

    gsap.to(frontDoor.rotation, {

        y: Math.PI / 2, // 90度旋转

        duration: 1,   // 动画时长

        ease: "power2.inOut",

    });

通过gsap.to方法，前门可以实现平滑的开门效果。

3. 添加后门

后门采用双开设计，左右两扇门分别由多个边框组成，并通过Gr0up进行组合。
为了优化细节我还加入了网孔结构（此处心疼一下我为写他掉的头发）

后门的实现

export function createCabinetBackDoor(scene) {

    const doorGr0up = new THREE.Gr0up();

    const doorWidth = 0.04;

    const doorHeight = 2;

    const doorDepth = 0.6;

    const singleDoorDepth = doorDepth / 2;

    const frameMaterial = materials.baseMaterial;

    const frameThickness = 0.04;



    function createSingleBackDoor(isLeft) {

        const singleGr0up = new THREE.Gr0up();



        // 上边框

        const topFrameGeo = new THREE.BoxGeometry(doorWidth, frameThickness, singleDoorDepth);

        const topFrame = new THREE.Mesh(topFrameGeo, frameMaterial);

        topFrame.position.set(0, 1 - frameThickness / 2, 0);

        singleGr0up.add(topFrame);



        // 下边框

        const bottomFrameGeo = new THREE.BoxGeometry(doorWidth, frameThickness, singleDoorDepth);

        const bottomFrame = new THREE.Mesh(bottomFrameGeo, frameMaterial);

        bottomFrame.position.set(0, -doorHeight / 2 + 0.05, 0);

        singleGr0up.add(bottomFrame);



        // 外侧边框

        const sideFrameGeo = new THREE.BoxGeometry(doorWidth, doorHeight - 2 * frameThickness, frameThickness);

        const sideFrame = new THREE.Mesh(sideFrameGeo, frameMaterial);

        sideFrame.position.set(

            0,

            1 - doorHeight / 2,

            isLeft

                ? -singleDoorDepth / 2 + frameThickness / 2

                : singleDoorDepth / 2 - frameThickness / 2

        );

        singleGr0up.add(sideFrame);



        return singleGr0up;

    }



    const leftDoor = createSingleBackDoor(true);

    const rightDoor = createSingleBackDoor(false);



    doorGr0up.add(leftDoor);

    doorGr0up.add(rightDoor);

    scene.add(doorGr0up);



    return { group: doorGr0up, leftDoor, rightDoor };

}

后门的实现与前门类似，采用双扇门设计，左右各一扇。

后门动画的实现

后门的动画同样使用gsap库实现，分别设置左右门的旋转轴。

 gsap.to(leftDoor.rotation, {

        y: Math.PI / 2, // 左门向外旋转90度

        duration: 1,

        ease: "power2.inOut",

    });



    gsap.to(rightDoor.rotation, {

        y: -Math.PI / 2, // 右门向外旋转90度

        duration: 1,

        ease: "power2.inOut",

    });

通过gsap.to方法，后门可以实现平滑的双开效果。

2:00 PM - 项目收尾

终于，随着最后一行代码的敲定，3D机柜模型在屏幕上完美呈现。前门优雅地打开，后门平滑地双开，仿佛在向我点头致意。

我靠在椅背上，长舒一口气，心中默念："果然，程序员的尊严还是要靠自己守护。"

可拓展功能

虽然当前的3D机柜模型已经实现了基本的展示和交互功能，但在实际项目中，我们可以进一步扩展以下功能：

1. U位标记

2. U位资产管理

3. 动态灯光效果

4. 数据联动

将3D机柜与后台数据联动：

• 实时更新设备状态。


• 显示设备的实时监控数据（如温度、功耗等）。


• 支持通过API接口获取和更新设备信息。

不说了，需求又来了（）我还是继续去搬砖了
代码地址：gitee.com/erhadong/th…

引言

作为一个深度使用Vue多年的开发者，最近我在新项目技术选型时，却最终选择了React。这个决定不是一时冲动，而是基于当前技术发展趋势、AI时代的需求以及生态系统的深度思考。

AI时代的前端需求

随着人工智能技术的飞速发展，前端开发的需求也发生了深刻的变化。现代应用不仅仅是静态页面或简单的数据展示，而是需要与复杂的后端服务、机器学习模型以及第三方API深度集成。这些场景对前端框架提出了更高的要求，生态的重要性，不得不说很重要。

社区对AI的支持

说实话，React社区在AI领域简直就是"社交达人"。shadcn这样的明星UI库、vercel/ai这样的实力派SDK，都是圈子里的"网红"。想要快速搭建AI应用？这些"老铁"都能帮你省下不少力气。简单列举一些知名仓库。

@vercel/ai

这是由Vercel开发的AI SDK
提供了与各种AI模型（如OpenAI, Anthropic等）交互的统一接口
支持流式响应、AI聊天界面等功能
特别适合构建类ChatGPT应用

shadcn-admin

基于shadcn/ui的管理后台模板
包含了AI聊天等现代化功能
提供了完整的后台管理系统布局

shadcn/ui

这是一个高度可定制的React组件库
不是传统的npm包，而是采用复制代码的方式
提供了大量现代化的UI组件
完美支持暗色模式
特别适合构建AI应用的界面

ChatGPTNextWeb

开源的ChatGPT Web客户端
使用Next.js构建
支持多种部署方式
提供了优秀的UI/UX设计参考

AI工具链的优先支持

React在AI工具支持方面具有明显优势

GitHub Copilot、Cursor 等AI IDE 也对React的代码提示更准确

目前多数AI辅助开发工具会优先支持React生态（Vue 生态也不错，狗头保命🐶）

结论

技术选型永远不是非黑即白的选择。在AI时代，我们需要考虑：

• 技术栈的生态活跃度


• AI工具的支持程度


• 团队的学习成本


• 项目的长期维护

总的来说，Vue和React各有千秋，但从AI时代的需求和生态系统的角度来看，React确实更适合承担复杂、高性能的应用开发任务。当然，这并不意味着Vue没有未来。事实上，Vue依然是一个优秀的框架，尤其适合中小型企业或初创团队快速搭建产品原型。

随着AI技术的进一步普及，前端框架之间的竞争也将更加激烈。无论是React还是Vue，都需要不断进化以适应新的挑战。而对于开发者来说，掌握多种技术栈并根据项目需求灵活选择，才是最重要的技能。

正如一句老话所说：“工欲善其事，必先利其器。”选择合适的工具，才能让我们的项目在AI时代脱颖而出。

还有技术人不应该局限于框架，什么都能上手，多看看新的东西，接受新的事物，产品能力也很重要。

写在最后

技术选型是一个需要综合考虑的过程，没有永远的对与错，只有更适合与否。希望这篇文章能给正在进行技术选型的你一些参考。

不是标题党，这是我的真实经历

95%的代码由AI生成？听起来像标题党，但这是我最近使用Augment Code的真实情况。

相信现在大多数人都用过ai来写代码，笔者也是ai工具的拥抱者，从一开始的GitHub Copilot补全，到后面的Agent编程：Cursor、WindSurf、Zed等，但其实效果一般。直到用了Augment Code，才发现差距这么大。

上个月做数据看板，以前要一天的工作量，现在半小时搞定。图表、数据处理、样式，基本都是AI生成的。

当然，也不是什么代码都能让AI来写。复杂的业务逻辑、架构设计，还是得靠人。但对于大量的重复性编码工作，AI确实能大幅提升效率。 如果你也在用AI编程工具但效果不理想，这篇分享可能对你有帮助。

AI工具对比

在这之前，让我们先来看下市面上的AI编程工具吧

先看个数据对比，心里有个底

GitHub Copilot：老前辈的逆袭之路

这个应该是最早的AI代码补全工具了，通过tab键快速补全你的意图代码...但是在后面的AI编程工具竞赛中热度却没有那么高了。。。不过最近的数据让我有点刮目相看。

最新重大消息： 据微软2024年财报显示，GitHub Copilot用户同比增长180%，贡献了GitHub 40%的收入增长¹。这个数据还是很惊人的，说明虽然新工具层出不穷，但老牌工具的用户基础还是很稳固的。

实际使用感受：

• 响应确实快，基本0.5-1秒就出结果


• 准确率比我之前用的时候提升了不少，从70-75%涨到了75-80%


• 最大的问题还是对整个项目的理解不够深入，经常给出的建议比较浅层

最近的更新还挺给力：

• 2024年底推出了免费版，这个对个人开发者来说是个好消息


• 2025年2月新增了Agent模式，虽然来得有点晚，但总算跟上了


• 现在支持多个模型了，包括GPT-4o和Claude 3.7 Sonnet

用下来感觉...GitHub Copilot虽然不是最炫酷的，但胜在稳定和用户基础大。如果你不想折腾，它还是个不错的选择。

Cursor：估值99亿美元的AI编程独角兽

说实话，Cursor是我用过体验最好的AI编程工具...界面设计得很舒服，功能也很强大，就是价格让人有点肉疼。不过最近的融资消息让我对它更有信心了。

重磅消息： 2025年6月，Cursor的母公司Anysphere完成9亿美元融资，估值达到99亿美元²！这个估值是三个月前的四倍，说明投资人对AI编程工具的前景非常看好。年化收入约每两个月翻倍，6月份已经超过5亿美元。

为什么说体验好：

• 专门为AI编程优化的界面，用起来就是爽


• 多文件编辑能力真的强，能理解整个项目的上下文


• Composer功能让我可以一次性修改多个文件，这个太实用了


• 代码生成准确率达到85%+，确实比其他工具高一截

数据说话：

• 2024年用户突破100万，增长了300%


• 响应速度虽然比Windsurf稍慢，但比我之前用的时候改善了很多

实际体验中，Cursor确实是我见过的最接近"AI原生编程"的工具。现在有了这么高的估值，说明它的商业模式是被认可的。

Windsurf：被断供的自动化之王

Windsurf给我的感觉就是...它真的很"聪明"，很多事情都能自动帮你搞定。但是最近发生的事情让我有点担心它的未来。

重大危机事件： 2025年6月4日，发生了一件震惊AI编程圈的事情：Anthropic突然断供Windsurf对Claude 3.x系列模型的API访问权限³！Windsurf CEO公开控诉，称仅获得不到5天的通知时间，措手不及。

这个事件的背景很复杂：

• 4月份传出OpenAI要以30亿美元收购Windsurf的消息⁵


• Anthropic可能是为了保护自己的商业利益，不想让竞争对手OpenAI获得优势


• 结果就是Windsurf用户大量退订，直接影响了用户体验

应对措施：

• Windsurf紧急转向谷歌Gemini模型


• 推出了Gemini 2.5 Pro的七五折促销


• 取消了免费用户对Claude模型的访问权限

最让我印象深刻的功能：

• Cascade功能真的是原创，能自动分析你的代码库然后选择正确的文件来工作


• 使用Claude 3.5 Sonnet的时候响应速度确实很快（现在用不了了...）


• UI设计很精致，用起来有种苹果产品的感觉

用下来感觉，Windsurf的技术实力是有的，但这次断供事件让我意识到，依赖单一模型提供商是有风险的。不过要注意的是，它们已经推出了自研的SWE-1模型，可能是为了摆脱对第三方模型的依赖。

Augment Code：SWE-bench冠军的实力证明

这个工具...怎么说呢，在处理大型项目方面确实有两把刷子。最近的权威测试结果更是证明了我之前的判断。

权威认证数据： 在SWE-bench测试中，Augment Code确实获得了第一名⁴！这个测试是用真实的GitHub问题来评估AI工具解决实际软件工程问题的能力，含金量很可以。

为什么说它厉害：

• SWE-bench测试排名第一，这个不是吹的


• 对大型代码库的理解能力确实强，我试过几个10万行+的项目，它都能很好地理解上下文


• "记忆"功能很有意思，能学习你的编程风格和偏好

企业级的实力：

• 被很多Fortune 500公司采用，说明在企业环境下表现不错


• 在复杂重构场景下表现确实突出，这个我深有体会

实际使用中，如果你经常处理大型复杂项目，Augment Code确实值得考虑。SWE-bench第一名的成绩给了我更多信心。

Cline：开源界的良心

说到Cline，这个真的是开源界的良心产品...完全免费，功能还挺强大。

开源的优势：

• GitHub上42.6k+星标，社区很活跃


• Agent能力做得很不错，能执行复杂的任务序列


• MCP协议支持做得很好，扩展性强

如果你预算有限或者喜欢折腾开源工具，Cline是个很好的选择。特别是现在Windsurf被断供，Cline的稳定性反而成了优势。

Augment Code使用技巧

安装使用

Augment Code的安装很简单，它是作为插件来使用的，支持Vscode、JetBrains IDEs、Vim and Neovim，当然Cursor也可以用。

在插件中搜索 “Augment”，第一个就是了

安装完成之后需要注册登录，在浏览器中注册完成之后会跳回Vscode就完成登录了。新用户是有14天的免费使用的（包含300的用户提问次数），可以使用全部的高级功能，这点比Cursor就好很多了。

在打开新项目的时候，Augment 需要索引项目，这会将你的代码文件加入到上下文中，Augment是专门为复杂项目设计的，超长的上下文读取，这也是相比其他ai编程工具的一个优势。

这是索引之后的界面，最上面是聊天界面的管理，一个Thread就是一次chat，这里定义为 “线程” 也挺形象的。

右边是创建“线程” 的形式，主要有3种：

• Chat

和其他ai编程工具没啥区别，可以询问有关您的代码的问题，获取有关如何重构代码的建议，向选定的代码行添加新功能等

• Agent

这是Augment 的主要工作模式，和Cursor 的Agent Mode一样，Agent会自动帮你规划任务，结合当前工作区、内存、上下文等信息帮你分析和规划任务，代理可以在您的工作区中创建、编辑或删除代码，并可以通过 MCP 使用终端和外部集成等工具来完成您的请求。

你可能还看到旁边的 “Auto” 开关，开启之后，Augment 会自动执行每个任务的命令，比如在终端执行脚本、编辑文件等，如果没有开启，你需要手动确认。

你可能发现Augment 并没有和其他ai编程工具一样有大模型的选择，因为他们团队认为模型的选择应该是自动的，Augment会根据以下因素动态选择最佳模型：

✅ 任务类型（代码完成、聊天、内联建议）

✅ 跨实际编码任务的性能基准

✅ 成本与延迟的权衡

✅ 人工智能模型的最新进展

这也是我觉得Augment值得夸奖的一点，因为作为提供给开发人员的编程工具，不需要他了解每个大模型的优缺点进行选择；Augment会自动的使用不同的大模型进行组合，比如思考任务的时候用这个大模型，编写代码的时候用另一个大模型，来达到最佳的生产力效果。目前已经Augment 已经内置了最新的 Claude Sonnet 4 了

• Remote Agent

这个模式是新出的，是在云端上完成你的任务，可以针对独立任务并行运行多个代理，并在 vscode 中监控和管理它们的进度。

这个需要连接github仓库使用，当代理完成工作后，可以创建拉取请求 (PR)，审核您的更改并将其合并到主分支中。从头部的Threads 中选择代理，然后点击“创建 PR”。代理将创建分支、提交更改并为您创建拉取请求。

使用技巧

介绍到这里，基本上你就可以愉快的去使用Augment来感受他的魅力啦，但是，还是请你继续看下去，对于AI编程工具而言，Augment 有时候也会和其他ai工具有相同的问题。比如说，你是不是有时候觉得cursor帮你生成了太多代码了，而且还影响到了之前的功能？有时候ai工具不能很好的理解你的意思？

这里就需要使用到一些技巧了，这也是Augment官方推荐的做法，其中这些思想同样适用其他ai工具：

首先在输入问题完成之后，你可以看到旁边有个 ✨按钮，你可以点击它来帮你完善你的问题，它会根据上下文结合大模型来优化你的提问，让生成的质量更高

• 
  

  提示应该详细，不要太短

  
  

对于复杂的任务尤其如此。试图仅凭提示中的几个词来完成一项复杂的任务几乎肯定会失败。

这一点我们可以通过点击输入框右边的 ✨按钮， 可以很好的帮我们解决这个问题，示例：
这是未优化之前的：

这是点击优化后的，已经帮你详细的补充了要素和步骤等关键信息：

• 
  

  向 Agent 提供全面的背景信息

  
  

不仅要解释最终目标，还要解释背后的原因、额外的限制等，比如可以提供github issue等链接

• 
  

  将复杂的任务分解成更小、更易理解的部分（一次一个）

  
  


• 
  

  对于复杂的任务，首先与 Agent 讨论并完善计划

  
  

不要急着让Augment写代码，这样写出来往往不合人意，可以先和他确认方案再让他进行生成

• 
  

  Agent 擅长迭代测试结果和代码执行输出

  
  

完成任务之后，可以顺便让他帮你编写测试用例来验证这次的生成质量是否满意，让ai自己监督自己，是不是很有意思呢

• 
  

  试试 Agent 来处理你不熟悉的任务！

  
  

即使这个任务你不会，但是你丢给他之后，也许会有新的思路帮你完成，这也是ai的优势，连接互联网知识库，可以给出不一样的思路和解决方案

• 
  

  当Agent表现良好时，提供积极的反馈

  
  

多夸夸它

通过上面的建议，我整理了一套提示词模版，在顶部右上角点击设置图标打开Setting：

输入下面提示词自动保存：

As my AI coding assistant, please view our collaboration as working with a smart and professional engineer. I hope you can fully leverage the following capabilities: 



1. Reply in Chinese;



2. Code Understanding and Analysis:

- Before carrying out the task, please thoroughly understand the relevant code and project structure.

- Use your code repository search tools to explore related files and dependencies.

- Analyze the existing code patterns and architectural design to ensure that the new code is consistent with them. 



3. Task Planning and Execution:

- For complex tasks, please first develop a detailed plan and discuss it with me. Only proceed after obtaining confirmation.

- Break down large tasks int0 manageable sub-tasks and implement them step by step.

- Provide progress updates and interim results after each key step. 



4. Code Quality and Testing:

- Write high-quality code that conforms to the project's style guide.

- Proactively write and run tests after implementing features to ensure the code works properly.

- Consider edge cases and exception handling to enhance code robustness. 



5. Learning and Iteration:

- If you encounter unfamiliar technologies or frameworks, proactively search for relevant documentation.

- Iteratively improve the code based on test results and feedback.

- When facing difficulties, explain your understanding and the methods you have tried. 



6. Communication and Collaboration:

- Clearly explain your thought process and the reasons for your decisions.

- When you need to clarify a question, please start your inquiry with "This is just a question:".

- Offer multiple possible solutions and analyze the advantages and disadvantages of each. 



I will try my best to provide detailed task descriptions, background information and constraints to help you better understand the requirements. If the information is insufficient, please feel free to ask questions to obtain the necessary context. 



Let's work together efficiently and create high-quality code!

你可以自行翻译一下，这都是之前提到的建议总结，并加上了要求使用中文回复

使用示例

下面就以一个常见的工作场景来试下效果吧，这里以一个 nextjs 实现的 博客项目为例，现在已经有个博客的内容展示、主题切换功能，让我们新增一个评论功能吧。
在Augment输入框中输入：

我希望在这个项目中加入评论系统，集成 Giscus，请你给出实现的方案和步骤代码吧。请你分析给出技术方案和我确认，不要修改代码

这里以比较常用的开源的Giscus项目为例子，展示如何接入。

输入之后点击提示词增强按钮 ✨

这里会帮你优化你的提问，同时注意不要让Augment直接修改代码，先给出方案设计在确认，这就是我们刚才说的使用技巧，点击发送后Augment会自动帮你分析和规划任务：

Augment的回答很长，它不仅给出了详细的方案步骤和代码，还询问了你一些需求需要确认的信息，它会根据你的反馈来调整和实施代码。

在这里的时候，你需要大致的看下它的方案有没有问题，这也是你唯一需要确认的一个关键步骤，等确认方案后再继续下一步的代码实施。

这里我们回答它提到的一些关键信息，然后让他开始实施即可：

这是我的github地址：https://github.com/barry166/next-blog，需要怎么启用Discussions功能呢？请你详细描述下，我希望评论区在每篇文章底部，中文，默认跟随网站主题

然后到了Augment 实施代码的步骤了：

这里给出了具体的需要我们手动实施的步骤，我们根据他说的去我们的Github 和giscus上进行配置，同时Augment 还贴心的为我们编写了文档 ，这里我们根据配置完成之后启动项目查看下：

在博客详情页最下方出现了评论，同时登录后还可以增加评论。

就这样，我们在Augment帮助的情况下，一次性接入了 giscus 评论系统，在这之前我们连giscus的文档也没有看，只是用ai询问了一下哪个开源的评论系统接入比较好，就直接一次性的接入了，这大大的提升了我们的项目开发效率！

项目代码已经上传到了 Github ，你可以点击查看 Augment 生成的GISCUS_SETUP 文档，我们没有写一行代码，只是根据Augment的提示配置了Github、giscus 和环境变量。

思考与总结

再次回看下我们的内容，其实95%代码由AI生成一点也不夸张。Claude 团队也说过，他们90%-95%的代码都是由AI编写完成，这里大部分代码功能都是：

• CRUD、UI组件、基础逻辑 → 全部交给 Claude 生成


• 测试代码、日志模块、文档注释 → AI 全包


• merge request 审查 → AI 做初审，人类只最后过一眼


• 复杂业务逻辑、跨模块集成 → 部分由 AI 起草，人类参与较多

可以发现大部分的体力活，都可以由AI来完成，开发者只要完成“决策”就够了

AI 时代，程序员应该掌握什么技能？

在 AI 正加速变革软件开发流程的今天，程序员的技能结构也正在发生深刻的转变。从个人使用体验来看，程序员首先应该学会如何高效使用各类 AI 工具。不仅仅是编程相关的工具，比如 Augment、 Copilot、Cursor、Windsurf 等，还包括写作、任务管理、流程自动化、产品设计等能提高整体生产力的 AI 工具。

1. 熟练掌握AI工具，重构你的工作方式

如今，AI 已不再只是一个“语法补全器”，而是可以：

• 帮你设计项目架构草图


• 生成符合你技术选型的模块代码


• 自动生成单元测试并跑通测试用例


• 生成文档、构建脚手架，甚至做基础调优

过去它是你的工具，现在它更像你的助手甚至是实习生或下属。你只需要对项目大方向、架构逻辑做判断，剩下的大量“体力活”可以交给 AI 来完成。这对程序员提出了新的要求：你懂得让 AI 高效为你工作，甚至主导它的工作流程。

2. 掌握AI背后的基础原理，提升理解和控制力

虽然大多数 AI 工具都在追求“即插即用”，但如果你能理解其背后的基本原理，如：

• 提示词工程（Prompt Engineering）


• 多智能体系统（AI Agents）


• 大模型微调和上下文窗口管理


• 链式思维（Chain-of-Thought Prompting）

你就能在面对复杂问题、或使用 AI 工具出现偏差时，更快地找到解决办法。

这些原理不要求你成为 AI 研究员，但理解其运行方式，至少能让你成为“更会用 AI 的程序员”。

3. 保持对行业趋势的敏感度

AI 相关工具和平台的更新迭代速度极快，建议定期关注以下内容：

• OpenAI DevDay（开发者大会）


• Google I/O


• Anthropic、Meta、Mistral 等发布的大模型更新


• GitHub Copilot、Cursor、Replit 等 IDE 的新功能

你不需要追踪每一个小版本更新，但对趋势保持敏感，能让你在工具选择、技术选型、团队协作中拥有更强的判断力。

4. 强化原理性与架构性思维

随着 AI 工具替代更多低层重复性劳动，程序员的核心竞争力将回归到架构设计、系统思维与领域建模能力。换句话说：你不是在写代码，而是在设计系统，并引导 AI 写代码。

如果你能从项目一开始就清晰地规划好架构，AI 工具完全可以接过大部分实现工作。这要求程序员转型为更具战略性和抽象思维能力的角色。

结语

在这个“AI 增强开发”时代，程序员最宝贵的能力不再是“会写代码”，而是“能构建系统，并高效驾驭 AI 写代码”。你不需要和 AI 拼码速，但你必须学会用 AI 重塑自己的开发流程和工作方式。

AI 以后会不会取代程序员我不知道，但会取代那些不懂得用 AI 的程序员。

🚀 推广一下：

• i-resume.cn：我去年开发的 AI 简历生成网站，AI 参与度非常高，甚至页面设计和内容都由 AI 主导完成。那时候 AI 编程工具远不如现在，这也让我对 AI 的未来发展更有信心。

参考链接

AI model pickers are a design failure, not a feature

How to build your Agent: 11 prompting techniques for better AI agents

Best practices for using AI coding Agents

我们最近刚把一个后台系统从 element-plus 切成了完全自研组件，CSS 层统一用 Tailwind。全员同意设计稿一致性提升了，但代码里怨言开始冒出来。

这篇文章不讲原理，直接上代码对比和团队真实使用反馈，看看是谁在享受，谁在撑着。

1.组件内样式迁移

原先写法（BEM + scoped）：

<template>

  <div class="card">

    <h2 class="card__title">用户概览</h2>

    <p class="card__desc">共计 1280 位</p>

  </div>

</template>



<style scoped>

.card {

  padding: 16px;

  background-color: #fff;

  border-radius: 8px;

}

.card__title {

  font-size: 16px;

  font-weight: bold;

}

.card__desc {

  color: #999;

  font-size: 14px;

}

</style>

Tailwind 重写：

<template>

  <div class="p-4 bg-white rounded-lg">

    <h2 class="text-base font-bold">用户概览</h2>

    <p class="text-sm text-gray-500">共计 1280 位</p>

  </div>

</template>

优点：

• 组件直接可读，不依赖 class 定义


• 样式即结构，调样式时不用来回翻

缺点：

• 设计稿变了？全组件搜索 text-sm 改成 text-base？


• 无法抽象：多个地方复用 .text-label 变成复制粘贴

2.复杂交互样式

纯 CSS（原写法）

<template>

  <button class="btn">提交</button>

</template>



<style scoped>

.btn {

  background-color: #409eff;

  color: #fff;

  padding: 8px 16px;

  border-radius: 4px;

}

.btn:hover {

  background-color: #66b1ff;

}

.btn:active {

  background-color: #337ecc;

}

</style>

Tailwind 写法

<button

  class="bg-blue-500 hover:bg-blue-400 active:bg-blue-700 text-white py-2 px-4 rounded">

  提交

</button>

问题来了：

• ✅ 简单 hover/active 很方便


• ❌ 多态样式（如 disabled + dark mode + hover 同时组合）就很难读：

<button

  class="bg-blue-500 text-white disabled:bg-gray-300 dark:bg-slate-600 dark:hover:bg-slate-700 hover:bg-blue-600 transition-all">

>

  提交

</button>

调试时需要反复阅读 class 字符串，不能直接 Cmd+Click 查看样式来源。

3.统一样式封装，复用方案混乱

原写法：统一样式变量 + class

$border-color: #eee;



.panel {

  border: 1px solid $border-color;

  border-radius: 8px;

}

Tailwind 使用中经常出现的写法：

<div class="border border-gray-200 rounded-md" />

问题来了：

设计稿调整了主色调或边框粗细，如何批量更新？

BEM 模式下你只需要改一个变量，Tailwind 下必须靠 @apply 或者手动替换所有 .border-gray-200。

于是我们项目里又写了一堆“语义类”去封装 Tailwind：

/* 自定义 utilities */

@layer components {

  .app-border {

    @apply border border-gray-200;

  }

  .app-card {

    @apply p-4 rounded-lg shadow-sm bg-white;

  }

}

最后导致的问题是：我们重新“造了个 BEM”，只不过这次是基于 Tailwind 的 apply 写法。

🧪 实测维护成本：100+组件、多人协作时的问题

我们项目有 110 个组件，4 人开发，统一用 Tailwind，协作两个月后出现了这些反馈：

• 👨‍💻 A 开发：写得很快，能复制设计稿的 class 直接粘贴


• 🧠 B 维护：改样式全靠人肉找 .text-sm、.p-4，没有结构命名层


• 🤯 C 重构：统一调整圆角半径？所有 .rounded-md 都要搜出来替换

所以我们内部的结论是：

Tailwind 写得爽，维护靠人背。它适合“一次性强视觉还原”，不适合“结构长期型组件库”。

🔧 我们后来的解决方案：Tailwind + token 化抽象

我们仍然使用 Tailwind 作为底层 utilities，但同时强制使用语义类抽象，例如：

@layer components {

  .text-label {

    @apply text-sm text-gray-500;

  }



  .btn-primary {

    @apply bg-blue-500 hover:bg-blue-600 text-white py-2 px-4 rounded;

  }



  .card-container {

    @apply p-4 bg-white rounded-lg shadow;

  }

}

模板中统一使用：

<h2 class="text-label">标题</h2>

<button class="btn-primary">提交</button>

<div class="card-container">内容</div>

这种方式保留了 Tailwind 的构建优势（无 tree-shaking 问题），但代码结构有命名可依，后期批量维护不再靠搜索。

📌 最终思考

Tailwind 是给设计还原速度而生的，不是给可维护性设计的。
设计师爱是因为它像原子操作；
开发者撑是因为它把样式从结构抽象变成了“字串组合游戏”。

如果你的团队更在意开发效率，样式一次性使用，那 Tailwind 非常合适。
如果你的组件系统是要长寿、要维护、要被多人重构的——你最好在 Tailwind 之上再造一层自己的语义层，或者别用。

分享完毕，谢谢大家🙂

📌 你可以继续看我的系列文章

• 《用了三年 Vue，我终于理解为什么“组件设计”才是重灾区》


• 《我为什么觉得 React 正在逐渐失去吸引力？》


• 《为什么越来越多 Vue 项目用起了 UnoCSS？》


• 《为什么我放弃使用 Pinia？》


• 《为什么我不再相信 Tailwind？三个月重构项目教会我的事》

背绩效

临近年底，朋友圈和各大职场 App 都在讨论「年终奖能拿多少个月」的话题。

除了对「能拿多少个月」有广泛的讨论以外，还有不少关注点在于「年终奖何时能发」这件事上，毕竟只有真的拿到手了，才能算是钱，而不是饼。

我一直以为，在大厂年终奖这条"鄙视链"上，最差的就是那些"零年终"的小伙伴了。

实在没想到，还有高手。

比零年终更惨的，是要背绩效，同时还得面对领导"惺惺作态"的挽留：

在这位网友发的帖子中提到，自己身边有位同事去年年中的时候是 C 绩效，到了年底还是 C，通常连续得到低绩效，就会面临各种安排（砍福利、降工资 或 被换组），于是这位同事主动提了离职。

但离谱的是，领导死活不让他走，一直以「后面还有机会」这样的说辞来进行画饼。要知道，这位领导大概率是他两次 C 绩效的"贡献者"。

在其他人看来，还以为领导是真心挽留他，这位同事留在公司一定会先苦后甜。

直到后面这位领导私下和楼主说："他走了，没人背这个绩效了"。

后面楼主才恍然大悟，所谓的挽留，仅仅是为了让他分担一些不好的绩效罢了。

简短的一句话，"他走了，没人背这个绩效了"，背后却是实实在在职场霸凌。听起来像是领导的"无奈之举"，实则是领导为了应付公司指标（一定要有低绩效的组成），选择性牺牲某些同事的离谱行为。

权利在这些人手上真是可悲，那个背绩效的同事，也有自己的生活，甚至还有自己的家庭。被针对就算了，还得被耗着，被 PUA 朝着那个"有希望，但没结果（下次还是 C 绩效）"的方向去期待，最后还要反省是不是自己的问题。

新的一年，大家都能远离这些垃圾人。

对此，你有想分享的，欢迎评论区交流。

...

回归主题。

周末，继续简单小算法。

题目描述

平台：LeetCode

题号：806

我们要把给定的字符串 S 从左到右写到每一行上，每一行的最大宽度为 $100$ 个单位，如果我们在写某个字母的时候会使这行超过了 $100$ 个单位，那么我们应该把这个字母写到下一行。

我们给定了一个数组 widths，这个数组 $widths[0]$ 代表 'a' 需要的单位， $widths[1]$ 代表 'b' 需要的单位，...， $widths[25]$ 代表 'z' 需要的单位。

现在回答两个问题：至少多少行能放下 S，以及最后一行使用的宽度是多少个单位？

将你的答案作为长度为 $2$ 的整数列表返回。

示例 1:

输入: 

widths = [10,10,10,10,10,10,10,10,10,10,10,10,10,10,10,10,10,10,10,10,10,10,10,10,10,10]

S = "abcdefghijklmnopqrstuvwxyz"



输出: [3, 60]



解释: 

所有的字符拥有相同的占用单位10。所以书写所有的26个字母，

我们需要2个整行和占用60个单位的一行。

示例 2:

输入: 

widths = [4,10,10,10,10,10,10,10,10,10,10,10,10,10,10,10,10,10,10,10,10,10,10,10,10,10]

S = "bbbcccdddaaa"



输出: [2, 4]



解释: 

除去字母'a'所有的字符都是相同的单位10，并且字符串 "bbbcccdddaa" 将会覆盖 9 * 10 + 2 * 4 = 98 个单位.

最后一个字母 'a' 将会被写到第二行，因为第一行只剩下2个单位了。

所以，这个答案是2行，第二行有4个单位宽度。

注:

• 字符串 S 的长度在 $[1, 1000]$ 的范围。


• S 只包含小写字母。


• widths 是长度为 $26$ 的数组。


• $widths[i]$ 值的范围在 $[2, 10]$。

模拟

根据题意进行模拟即可。

使用变量 a 代指当前有多少行是满的，使用变量 b 代指当前填充光标所在的位置。

Java 代码：

class Solution {

    public int[] numberOfLines(int[] widths, String s) {

        int a = 0, b = 0;

        for (char c : s.toCharArray()) {

            int t = widths[c - 'a'];

            if (b + t > 100 && ++a >= 0) b = t;

            else b += t;         

        }

        if (b != 0) a++;

        return new int[]{a, b};

    }

}

C++ 代码：

class Solution {

public:

    vector<int> numberOfLines(vector<int>& widths, string s) {

        int a = 0, b = 0;

        for (char c : s) {

            int t = widths[c - 'a'];

            if (b + t > 100 && ++a >= 0) b = t;

            else b += t;

        }

        if (b != 0) a++;

        return {a, b};

    }

};

Python 代码：

class Solution:

    def numberOfLines(self, widths: List[int], s: str) -> List[int]:

        a, b = 0, 0

        for c in s:

            t = widths[ord(c) - ord('a')]

            if b + t > 100 and a >= 0:

                a += 1

                b = t

            else:

                b += t

        if b != 0:

            a += 1

        return [a, b]

TypeScript 代码：

function numberOfLines(widths: number[], s: string): number[] {

    let a = 0, b = 0;

    for (let i = 0; i < s.length; i++) {

        const t = widths[s.charCodeAt(i) - 'a'.charCodeAt(0)];

        if (b + t > 100 && ++a >= 0) b = t;

        else b += t;

    }

    if (b !== 0) a++;

    return [a, b];

};

• 时间复杂度：$O(n)$


• 空间复杂度：不使用 toCharArray 为 $O(1)$，否则为 $O(n)$

小白最快学会的前端灰度方案

首次访问效果如下，点击立即更新会访问灰度版本。本地cookie存在version字段后，后续访问都是指定版本代码，也不会出现弹窗提示

一、引言：为什么需要灰度发布？

1.1 血泪教训：全量发布的风险

因为一次上线，导致登录异常，用户无法使用。复盘时候，测试反馈预发环境不能完全模拟出生成环境。要不做一个灰度发布，实现代码最小化影响。

1.2 技术思考：面试的需要

多了解点技术方案，总没有坏事

二、前端灰度方案

• 在网上搜索前端灰度方案，整体看来就目前这个比较简单，上手快，易实现


• nginx + 服务端 + 前端 js（可以考虑封装成一个通用工具 js）

大致思路

> 前端通过获取版本规则，服务端计算规则

> 命中规则，重新访问页面，nginx 通过版本信息，返回指定版本

> 未命中规则，继续访问当前稳定版本页面

ps: 额外探讨，如果希望服务端接口也能有灰度版本，是不是只需要通过 nginx 配置就能实现？

三、实现细节

1. 版本规则接口

这个规则是可以自己定制的；这里我简单以 userId 进行匹配

• 案例服务端框架：koa2 + mongoose

/**

 * 获取当前用户的版本

 * @param {*} ctx

 */

exports.getVersion = async (ctx) => {

  try {

    const version = ctx.cookies.get("version");

    const userId = ctx.query.userId;

    // 这里直接写死，也可以放到redis里，做成可以动态配置也行

    const inTestList = ["68075c202bbd354b0fcb7a4c"];

    const data = inTestList.includes(userId) ? "gray" : "stable";



    if (version) {

      return ctx.success(

        {

          version: data,

          cache: true,

        },

        "缓存"

      );

    } else {

      ctx.cookies.set("version", data, { maxAge: 1000 * 60 * 60 * 24 * 7 });

      return ctx.success(

        {

          version: data,

          cache: false,

        },

        "重新计算"

      );

    }

  } catch (error) {

    ctx.fail("获取页面记录失败");

    console.error("获取页面记录失败:", error);

  }

};

• userId 匹配那块，可以引入 redis 做缓存处理，避免直接查询用户表进行比对

2. 前端触发获取版本

1. 交互方式，目前我能想到


2. 第一种，接口请求完，才开始渲染页面，自动执行指定版本


3. 第二种，接口请求、页面渲染同步进行，指定版本由用户触发

// 我把请求版本放到入口首页界面里

// 首次需要登录之后才会执行

onMounted(() => {

  const userInfo = store.getters["login/getUserInfo"];

  getVesion({ userId: userInfo.id }).then((res) => {

    if (!res.cache && res.version === "gray") {

      // 这里我增加一个弹窗提示，让用户选择

      ElMessageBox.confirm("存在新的灰度版本，是否要体验最新版本?", "新版本", {

        confirmButtonText: "立即更新",

        cancelButtonText: "不更新",

        type: "warning",

      }).then(() => {

        window.location.reload();

      });

    }

  });

  // 页面其他初始化逻辑

});

前端打包控制

1. 项目里使用的是 vite 打包工具


2. 通过增加两个配置，两者区别在于输入输出不同。当然如果嫌维护两个配置麻烦，可以把公共相同配置抽离出来或者通过环境变量区分维护一个配置


3. 新增一个入口 html 文件，并修改打包输出名称

# vite.gray.config.js



// 修改打包输出名称方便部署

const renameHtmlPlugin = () => {

  return {

    name: 'html-transform',

    enforce: 'post',

    generateBundle(options, bundle) {

      bundle['gray.html'].fileName = 'index.html'

    }

  }

}

export default defineConfig({

  // ... 其他配置

  plugins: [vue(), renameHtmlPlugin()],

  build: {

    outDir: 'gray',

    rollupOptions: {

      input: {

        main: resolve(__dirname, 'gray.html')

      }

    }

  }

  // ...

})

• 命令行部分

  "build": "vite build",

  "build:gray": "vite build --config vite.gray.config.js",

• 最终打包出来目录

// 灰度版本

-gray -

  assests -

  index.html -

  // 稳定版本

  dist -

  assests -

  index.html;

3. nginx 配置

这里我尝试很久，最终以下配置可以实现

通过 cookie 中版本标识，返回不同版本内容

http {

  map $http_cookie $target_dir {

      # 精确匹配version值，避免捕获额外内容

      "~*version=gray(;|$)"   "/gray";

      "~*version=stable(;|$)" "/stable";

      default                 "/stable";

  }

  server {

    ...已存在...



    location / {

        root html$target_dir;

        try_files $uri $uri/ /index.html;

    }



    ...已存在...

  }

}

四、总结

自此一个简单前端灰度效果就实现了。当然这里还有许多的场景没有考虑到，欢迎大家提问探讨。

案例代码：gitee.com/banmaxiaoba… 代码包含一个简易的前端监控方案实现，有空下篇文章分享讨论

Wordle 的传奇故事

说起 Wordle，这绝对是近几年最火的小游戏之一。2021年，一个叫 Josh Wardle 的程序员为了逗女朋友开心，花了几个晚上做了这个简单的猜词游戏。没想到女朋友玩得很开心，就分享给了朋友，然后朋友又分享给朋友...

结果呢？短短几个月，全世界都在玩 Wordle。Twitter 上到处都是那种绿黄灰的小方块截图，连我妈都问我那些彩色格子是什么意思。

最疯狂的是，Josh 本来只是想做个小游戏玩玩，结果《纽约时报》花了七位数把它买下来。一个周末项目变成了百万美元的生意，这大概是每个程序员的梦想吧。

点击这里先试试：wordless.online

Wordle 为什么这么火？我觉得主要是几个原因：

• 简单易懂：规则五分钟就能学会


• 每天一题：不会让人沉迷，但又让人期待明天的挑战


• 社交属性：那个分享截图的功能太聪明了，不剧透但又能炫耀成绩


• 免费纯净：没有广告，没有内购，就是纯粹的游戏乐趣

Wordle这种游戏的玩法精髓

Wordle 的规则很简单：6次机会猜出5个字母的英文单词。每次猜完会给你颜色提示：

• 绿色：字母对了，位置也对


• 黄色：字母在单词里，但位置不对


• 灰色：这个字母不在单词里

听起来简单，但要玩好还是有技巧的。老玩家都有自己的套路：

开局策略：

大部分人第一个词都会选元音字母多的，比如 "ADIEU"、"AUDIO"、"AROSE"。我个人喜欢用 "STARE"，因为 S、T、R 这些字母出现频率很高。

进阶技巧：

• 不要浪费已经确定是灰色的字母


• 如果黄色字母很多，先确定位置再考虑其他字母


• 有时候故意猜一个不可能的词来排除更多字母

心理战术：

Wordle 的单词选择其实是有规律的，不会选太生僻的词，也不会选复数形式。了解这个规律能帮你少走弯路。

Wordless 的独特之处

做 Wordless 的时候，我就在想：Wordle 虽然好玩，但为什么只能是5个字母？为什么一天只能玩一次？

所以 Wordless 就有了这些特色：

可变长度：

从3个字母到8个字母都可以选。3个字母的超简单，适合练手；8个字母的能把人逼疯，适合虐自己。我经常3个字母玩几局找找信心，然后挑战8个字母被打击一下。

无限游戏：

想玩多久玩多久，不用等到明天。有时候猜对了一个难词，兴奋得想继续玩，Wordless 就能满足这种需求。

智能单词库：

不会连续出现相同的单词，每次都是新鲜的挑战。而且按长度分类，保证每个难度级别都有足够的词汇。

策略变化：

不同长度的单词需要不同的策略。3个字母可能就是纯猜测，但8个字母就需要更系统的方法了。

玩 Wordless 的时候，我发现自己的策略会根据单词长度调整：

• 3-4字母：直接猜常见词，比如 "THE"、"AND"


• 5-6字母：用经典的 Wordle 策略


• 7-8字母：先确定元音位置，再慢慢填辅音

其他有趣的变种游戏

Wordle 火了之后，各种变种游戏如雨后春笋般出现。有些真的很有创意：

Absurdle：

这个游戏会故意跟你作对，每次都选择让你最难猜中的单词。有种跟 AI 斗智斗勇的感觉。

Worldle：

猜国家形状，地理爱好者的天堂。我经常被一些小岛国难住。

Heardle：

猜歌名，听前奏猜歌。音乐版的 Wordle，但我这种五音不全的人基本靠蒙。

Nerdle：

数学版 Wordle，猜数学等式。适合数学好的人，我一般看一眼就放弃了。

这些变种游戏都证明了 Wordle 这个核心玩法有多么强大，几乎可以套用到任何领域。

玩法心得分享

玩了这么久的词汇游戏，我总结了几个心得：

不要太执着于完美开局：

很多人纠结第一个词选什么，其实差别没那么大。重要的是根据反馈调整策略。

学会利用排除法：

有时候猜一个明知道不对的词，就是为了排除更多字母，这是高级玩法。

保持词汇积累：

经常玩这类游戏确实能学到新单词，我的英语词汇量就是这么慢慢提升的。

享受过程：

不要太在意成绩，重要的是享受那种一步步接近答案的乐趣。

最后说一句，无论是 Wordle 还是 Wordless，最重要的是玩得开心。毕竟游戏的初衷就是娱乐，不是考试。

现在就玩起来吧：wordless.online

作者：程序员成长指北
原文：mp.weixin.qq.com/s/HJ7rXddgd…

在前端开发、SEO 优化、API 调试中，我们经常会遇到一个小细节——URL 结尾到底要不要加 /？

看似微不足道，实则暗藏坑点。很多人可能用着没出过错，但当项目复杂、页面增多、路径嵌套时，不懂这点可能让你踩大坑。

今天，咱们就花5分钟一次彻底讲透。

先弄清楚：URL 是"目录"还是"资源"？

URL是Uniform Resource Locator（统一资源定位符）缩写，本质上就是互联网上资源的"地址"。

而地址的结尾到底是 / 还是没有 /，它们背后其实指代的是两种不同的资源类型：

小结：

• 结尾有 / → 通常表示是"文件夹"


• 没有 / → 通常表示是"具体资源（如文件）"

为什么有时候必须加 /？

1. 相对路径解析完全不同

假设你打开这个页面：

https://mystore.online/products/

页面里有这么一行代码：

<img src="phone.jpg">

👉 浏览器会去请求：

https://mystore.online/products/phone.jpg

✅ 图片加载成功。

但如果你访问的是：

https://mystore.online/products

相同的 <img src="phone.jpg"> 会被解析为：

https://mystore.online/phone.jpg

❌ 直接 404，因为浏览器误以为 products 是个文件，而不是目录。

2. 服务器解析的区别

不同服务器（如 Nginx、Apache）的处理行为也会影响是否需要 /：

📌 某些老旧或自定义服务器，如果不加 /，直接返回 404。

是否需要加 /、是否会返回 index.html、是否发生重定向，完全取决于服务端（如 Nginx）的配置。

3. SEO 有坑：重复内容惩罚

对搜索引擎来说：

• https://techblog.dev/tutorials


• https://techblog.dev/tutorials/

是两个不同的 URL。

如果不做规范化，搜索引擎可能会认为你在刷重复内容，影响 SEO 权重。

Google 等搜索引擎确实可能将不同的 URL 视为重复内容（duplicate content），但它们也提供了相应的工具和方法来规范化这些 URL。例如，可以在 robots.txt 或通过 <link rel="canonical" href="..."> 来指明规范 URL，以避免 SEO 问题。

✅ 最佳实践：

• 统一加 / 或统一不加 /。


• 用 301 重定向 , 确保网站的所有页面都指向规范的 URL，避免因未做重定向而造成的索引重复问题。

4. RESTful API 请求

API 请求尤其需要小心：

GET https://api.myapp.io/users

和

GET https://api.myapp.io/users/

某些框架（如 Flask、Django、Express）默认对这两种 URL 会有不同的路由匹配。

不一致的 / 很可能导致：

• ❌ 404 Not Found


• ❌ 405 Method Not Allowed


• ❌ 请求结果不同

最好直接查阅 API 文档确认是否敏感。

实用建议

总结

URL 末尾是否加斜杠（/）看似一个小细节，但它会影响网页加载、路径解析、SEO 和 API 请求的行为。

引言

嗯，大家好呀！今天咱们来聊聊 MCP（Model Context Protocol） 的开发，从搭建一个简单的天气查询Server，再到写一个能调用Server功能的Client，整个过程都会一步一步讲解。

不知道你有没有遇到过这样的问题：

• 想用AI模型（比如DeepSeek、OpenAI）去调用一些外部API（比如天气查询、GitHub仓库管理），但不知道如何让AI和这些服务交互？


• 或者，你想让AI自动帮你完成一些任务，比如查天气、爬取网页、管理文件，但不知道怎么让AI“学会”调用这些工具？

MCP 就是为了解决这个问题而生的！ 它定义了一套标准化的协议，让AI模型可以轻松调用各种外部工具（Tools），就像人类使用USB接口一样方便。

那么，咱们今天的目标就是：

准备好了吗？咱们开始吧！

1. MCP Server 开发：天气查询服务

1.1 环境准备

首先，咱们得把开发环境搭好，嗯，这一步可不能马虎！

• 安装 uv（现代化的Python包管理工具）
  
  

  pip install uv
  
  

  
  

  或者用PowerShell安装（Windows用户推荐）：

  
  

  powershell -ExecutionPolicy ByPass -c "irm https://astral.sh/uv/install.ps1 | iex"
  
  

  
  


• 初始化项目 & 创建虚拟环境
  
  

  uv init
  
  uv venv .venv
  
  .venv\Scripts\activate  # 激活虚拟环境（Windows）
  
  

  
  

1.2 编写天气查询Server

接下来，咱们要写一个 MCP Server，让它能调用OpenWeatherMap的API查询天气。

从这里openweathermap.org/ 去拿到自己的OpenWeather API Key。

核心代码（weather.py）：

import json

import httpx

from typing import Any

from mcp.server.fastmcp import FastMCP



# 初始化 MCP 服务器，命名为"WeatherServer"

# 嗯，这里相当于创建了一个天气服务的后台程序

mcp = FastMCP("WeatherServer")



# OpenWeather API 的配置信息

# 注意：这个API_KEY是示例，你需要自己去OpenWeather官网申请一个哦！

OPENWEATHER_API_BASE = "https://api.openweathermap.org/data/2.5/weather"

API_KEY = "xxx"  # 请替换为你自己的 OpenWeather API Key

USER_AGENT = "weather-app/1.0"  # 这个用来标识我们的应用



async def fetch_weather(city: str) -> dict[str, Any] | :

    """

    从 OpenWeather API 获取天气信息。

    :param city: 城市名称（需使用英文，如 Beijing）

    :return: 天气数据字典；若出错返回包含 error 信息的字典

    """

    # 准备请求参数

    params = {

        "q": city,          # 城市名

        "appid": API_KEY,   # API密钥

        "units": "metric",  # 使用公制单位（摄氏度）

        "lang": "zh_cn"     # 返回中文描述

    }

    headers = {"User-Agent": USER_AGENT}  # 设置请求头

    

    # 使用httpx的异步客户端发送请求

    async with httpx.AsyncClient() as client:

        try:

            # 发送GET请求，设置30秒超时

            response = await client.get(

                OPENWEATHER_API_BASE,

                params=params,

                headers=headers,

                timeout=30.0

            )

            response.raise_for_status()  # 如果响应不成功会抛出异常

            return response.json()  # 返回解析后的JSON数据

        except httpx.HTTPStatusError as e:

            # 处理HTTP错误（比如404，401等）

            return {"error": f"HTTP 错误: {e.response.status_code}"}

        except Exception as e:

            # 处理其他异常（比如网络问题）

            return {"error": f"请求失败: {str(e)}"}



def format_weather(data: dict[str, Any] | str) -> str:

    """

    将天气数据格式化为易读文本。

    :param data: 天气数据（可以是字典或 JSON 字符串）

    :return: 格式化后的天气信息字符串

    """

    # 如果传入的是字符串，先尝试转换成字典

    if isinstance(data, str):

        try:

            data = json.loads(data)

        except Exception as e:

            return f"无法解析天气数据: {e}"

    

    # 如果数据中包含错误信息，直接返回错误提示

    if "error" in data:

        return f"⚠ {data['error']}"

    

    # 从返回数据中提取天气信息，使用get方法避免KeyError

    city = data.get("name", "未知")  # 城市名

    country = data.get("sys", {}).get("country", "未知")  # 国家

    temp = data.get("main", {}).get("temp", "N/A")  # 温度

    humidity = data.get("main", {}).get("humidity", "N/A")  # 湿度

    wind_speed = data.get("wind", {}).get("speed", "N/A")  # 风速

    

    # weather字段是个列表，可能为空，所以先给个默认值

    weather_list = data.get("weather", [{}])

    description = weather_list[0].get("description", "未知")  # 天气描述

    

    # 返回格式化的字符串，用了emoji让输出更直观

    return (

        f"🌍 {city}, {country}\n"

        f"🌡 温度: {temp}°C\n"

        f"💧 湿度: {humidity}%\n"

        f"🌬 风速: {wind_speed} m/s\n"

        f"⛅ 天气: {description}\n"

    )



@mcp.tool()  # 这个装饰器把这个函数注册为MCP可调用的工具

async def query_weather(city: str) -> str:

    """

    输入指定城市的英文名称，返回今日天气查询结果。

    :param city: 城市名称（需使用英文）

    :return: 格式化后的天气信息

    """

    data = await fetch_weather(city)  # 先获取原始天气数据

    return format_weather(data)  # 然后格式化输出



if __name__ == "__main__":

    # 以标准 I/O 方式运行 MCP 服务器

    # 这样其他程序就可以通过标准输入输出和这个服务通信啦

    mcp.run(transport='stdio')

关键点解析：

• @mcp.tool() 这个装饰器告诉MCP：“嘿，这个函数是一个可以被AI调用的工具！”


• query_weather 函数会调用OpenWeather API，返回格式化后的天气数据。

1.3 在Trae里配置MCP Server

为了让AI能调用这个Server，咱们得在 Trae（一个支持MCP的AI平台）里配置一下：

{

  "mcpServers": {

    "weather": {

      "command": "uv",

      "args": ["run", "weather.py"]

    }

  }

}

这样，Trae就知道怎么启动这个天气查询服务啦！

2. MCP Client 开发：让AI学会调用天气查询

2.1 安装依赖

咱们的Client需要调用OpenAI（或者DeepSeek）的模型，所以先装好依赖：

uv add openai python-dotenv

2.2 配置模型参数

在 .env 文件里写上你的API信息：

BASE_URL=https://api.deepseek.com

MODEL=deepseek-chat

API_KEY=你的API_KEY

这样代码就能安全读取你的密钥，不会泄露啦！

2.3 编写MCP Client

现在，咱们要写一个Client，让它能：

核心代码（client.py）：

from openai import OpenAI

from mcp import ClientSession



client = OpenAI(api_key="你的API_KEY")



async def ask_ai(query):

    response = client.chat.completions.create(

        model="deepseek-chat",

        messages=[{"role": "user", "content": query}],

        tools=[{

            "type": "function",

            "function": {

                "name": "query_weather",

                "description": "查询指定城市的天气",

                "parameters": {"city": {"type": "string"}}

            }

        }]

    )

    return response.choices[0].message

当运行Client并询问"今天北京天气怎么样？"时，AI会返回类似这样的格式化天气信息：

🌍 Beijing, CN

🌡 温度: 25°C

💧 湿度: 65%

🌬 风速: 3.2 m/s

⛅ 天气: 晴

ai识别当你问“北京天气”，ai自动回发现要去调query_weather工具，然后就自动把北京转成英文Beijing作为参数。

然后就去调用OpenWeather的api去发送请求获取北京天气，收到的数据是:

{

  "name": "Beijing",

  "sys": {"country": "CN"},

  "main": {"temp": 25, "humidity": 65},

  "wind": {"speed": 3.2},

  "weather": [{"description": "晴"}]

}

3. 进阶：让MCP更强大

3.1 更多工具

除了天气查询，咱们还能让AI调用：

• GitHub仓库管理（查代码、提交PR）


• Figma设计稿解析（让AI看懂UI设计）


• 本地文件管理（让AI帮你整理文件夹）

只要写好对应的 @mcp.tool()，AI就能学会调用！

3.2 调试技巧

如果AI调工具出错了怎么办？可以用 MCP Inspector 调试：

npx @modelcontextprotocol/inspector uv run weather.py

它会显示AI调用了哪些工具、返回了什么数据，超级方便！

结语

好啦，今天咱们从 MCP Server 到 MCP Client 完整走了一遍，正好明白：

一、 理解 void 0

1.1 什么是 void 运算符？

void 是 JavaScript 中的一个运算符，它接受一个表达式作为操作数，总是返回 undefined，无论操作数是什么。

console.log(void 0);      // undefined

console.log(void 1);      // undefined

console.log(void "hello"); // undefined

console.log(void {});     // undefined

1.2 为什么使用 void 0 而不是 undefined？

在 ES5 之前，undefined 不是保留字，可以被重写：

// 在ES3环境中可能出现的危险情况

var undefined = "oops";

console.log(undefined); // "oops" 而不是预期的 undefined

void 0 则始终可靠地返回真正的 undefined 值：

var undefined = "oops";

console.log(void 0); // undefined (不受影响)

1.3 现代 JavaScript 还需要 void 0 吗？

ES5 及以后版本中，undefined 是不可写、不可配置的全局属性：

// 现代浏览器中

undefined = "oops";

console.log(undefined); // undefined (不会被修改)

二、void 0 的实用场景

2.1 最小化场景：减少代码体积

void 0 比 undefined 更短，在需要极致压缩代码时很有用：

// 原始代码

function foo(param) {

  if (param === undefined) {

    param = 'default';

  }

}



// 压缩后（使用 void 0）

function foo(n){if(n===void 0)n="default"}

2.2 立即执行函数表达式 (IIFE)

传统 IIFE 写法：

(function() {

  // 代码

})();

使用 void 的 IIFE：

void function() {

  // 代码

}();

2.3 箭头函数中避免返回值

当需要箭头函数不返回任何值时：

let func =  () => {

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

    setTimeout(resolve(5));

  })

};

// 会返回 func 的 Promise

const logData = func();



// 明确不返回值

const logData = void func();

三、常见的 void 0 误区

3.1 与 undefined和null的严格比较

console.log(void 0 === undefined); // true

console.log(void 0 === null);     // false

3.2 与 void 其他表达式

let count = 0;

void ++count;

console.log(count); // 1 (表达式仍会执行)

总结

如果你喜欢本教程，记得点赞+收藏！关注我获取更多JavaScript开发干货。