引言

最近在折腾油猴脚本开发，顺手搞了一个可以拦截任意网页接口的小工具，并修改了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;

  }

}

六、大量文件并发控制

有待补充

🔍 一、什么是 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 也没问题，但在一些特殊场景（如代码压缩、兼容旧代码）仍然有用。

那是一个普通的周三早晨，我正对着产品经理刚丢过来的需求发呆——"在管理系统里加个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时代脱颖而出。

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

写在最后

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

我们最近刚把一个后台系统从 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？三个月重构项目教会我的事》

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

首次访问效果如下，点击立即更新会访问灰度版本。本地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 请求的行为。

一、 理解 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开发干货。

有一天，甲方打开一个后台管理的项目，说有点卡，不太满意，项目经理叫我优化，重新打包一下。

从输入地址 到 展示 首屏，最佳时间在 3秒内，否则，甲方挂脸，咱就有可能有被裁的风险，understand?

废话不多说，先来看一下怎么个优化法吧。

优化

✅ cdn

分析

用Webpack Bundle Analyzer分析依赖，安装webpack-bundle-analyzer打包分析插件：

# NPM

npm install --save-dev webpack-bundle-analyzer

# Yarn

yarn add -D webpack-bundle-analyzer

反正都是装，看着来。

配一下：

// vue.config.js 文件里。（没有就要新建一下）

const BundleAnalyzerPlugin = require('webpack-bundle-analyzer').BundleAnalyzerPlugin;

 

module.exports = {

  plugins: [

    new BundleAnalyzerPlugin()

  ]

}

打包

执行打包命令并查看分析

npm run build --report

打包结束后，会在项目根目录下生成dist文件。自动跳到127.0.0.1:8888（没有跳的话，手动打开dist文件夹下的report.html），这个网址就是打包分析报告。

占得比较大的块，就是Element UI组件库和echarts库占的空间比相对较大。

这就要考虑，第一，要按需，要啥再用啥，不要一股脑啥都装。按需安装，按需加载。

第二，考虑单独引入这些组件库的cdn，这样速度也会咔咔提升。

详细讲一下怎么搞cdn。

按需大家都知道，要啥再引入啥，再装啥。

比如element-ui，我要uninstall掉，然后呢，去引入cdn，不要装库了，用cdn。

去package.json里面看element-ui装了啥版本，然后看完之后，就npm uninstall element-ui卸载掉。

去cdn库里面去找https://www.staticfile.org/，(首先先说一下，要找免费的开放的那种，因为一般有的公司没有自家的cdn，没有自家的桶，有的话，直接把js文件地址拖上去，然后得到一个地址，这样也安全，也方便，但没有的话另说)。

样式库: https://cdn.staticfile.org/element-ui/2.15.12/theme-chalk/index.min.css 

组件库：https://cdn.staticfile.org/element-ui/2.15.12/index.min.js

然后去public/index.html入口文件中，去加入这个东西，像咱以前写原生一样引入就好,body里面引入js，head里面引入css。：

<head>

<link rel="stylesheet" href="https://cdn.staticfile.org/element-ui/2.15.12/theme-chalk/index.min.css">

</head>



<body>

<script src="https://cdn.staticfile.org/element-ui/2.15.12/index.min.js"></script>

</body>

所以这样子，就引入好了。接着在main.js里面，把之前import的所有element的样式删掉。

接着，vue.config.js的configureWebpack加个externals字段：

const BundleAnalyzerPlugin = require('webpack-bundle-analyzer').BundleAnalyzerPlugin;

 

module.exports = {

  plugins: [

    new BundleAnalyzerPlugin()

  ],

  externals: {

    'element-ui': 'ELEMENT' // key 是之前install下下来的包名，element-ui。value是全局变量名(ELEMENT)

  }

}

externals: Webpack 的 externals 配置用于声明某些依赖应该从外部获取，而不是打包到最终的 bundle 中。这样可以减小打包体积，前提是这些依赖已经在运行环境中存在。

'element-ui': 'ELEMENT' 的含义

• 当你的代码中 import 'element-ui' 时，Webpack 不会打包 element-ui，而是会从全局变量 ELEMENT 中获取它。


• ELEMENT 是 element-ui 库通过 <script> 标签引入时，在全局（window）中暴露的变量名。
  
  例如，如果你在 HTML 中这样引入：
  

  <script src="https://unpkg.com/element-ui/lib/index.js"></script>
  
  

  
  那么 element-ui 会挂载到 window.ELEMENT 上。

为什么这样配置？

• 通常是为了通过 CDN 引入 element-ui（而不是打包它），从而优化构建速度和体积。


• 你需要确保在 HTML 中通过 <script> 提前加载了 element-ui，否则运行时 ELEMENT 会是 undefined。

<!-- HTML 中通过 CDN 引入 element-ui -->

<script src="https://unpkg.com/element-ui/lib/index.js"></script>

// webpack.config.js

module.exports = {

  externals: {

    'element-ui': 'ELEMENT' // 告诉 Webpack：import 'element-ui' 时，返回全局的 ELEMENT

  }

};

// 你的代码中依然可以正常 import（但实际用的是全局变量）

import ElementUI from 'element-ui';

// 相当于：const ElementUI = window.ELEMENT;

注意事项：

• 确保全局变量名（ELEMENT）和 element-ui 的 CDN 版本一致。不同版本的库可能有不同的全局变量名。


• 如果使用模块化打包（如 npm + Webpack 全量打包），则不需要配置 externals。

这里有的伙伴就说，我咋知道是ELEMENT，而不是element呢。

这里是这么找的：

直接在浏览器控制台检查
在 HTML 中通过 CDN 引入该库：

<script src="https://cdn.staticfile.org/element-ui/2.15.12/index.min.js"></script>

打开浏览器开发者工具（F12），在 Console 中输入：

console.log(window);

然后查找可能的全局变量名（如 ELEMENT、ElementUI 等）。

cdn配置之后，重新分析

npm run build --report

重新用cdn的去分析，

那么就很舒服了，也因此，这个就是cdn优化的方法。

✅ nginx gzip压缩

server {

        listen       8103;

        server_name  ************;

		# 开启gzip

	    gzip on;

	    # 进行压缩的文件类型。

	   	gzip_types text/plain application/javascript application/x-javascript text/css application/xml text/javascript application/x-httpd-php image/jpeg image/gif image/png;

	    # 是否在http header中添加Vary: Accept-Encoding，建议开启

	    gzip_vary on;

}

✅vue gzip压

安包：npm i compression-webpack-plugin@1.1.12 --save-dev

注意版本匹配问题。

vue配置，这段配置是 Webpack 构建中关于 Gzip 压缩 的设置，位于 config/index.js 文件中。:

//文件路径  config --> index.js

build: {

  productionGzip: true, // 启用生产环境的 Gzip 压缩

  productionGzipExtensions: ['js', 'css'], // 需要压缩的文件类型

}

为什么需要 Gzip？

• 优化性能：Gzip 压缩后的资源体积可减少 60%~70%，显著降低网络传输时间。


• 服务器支持：大多数现代服务器（如 Nginx、Netlify）会自动对静态资源进行 Gzip 压缩，但本地构建时提前生成 .gz 文件可以避免服务器实时压缩的开销。

✅ 按需加载路由

路由级代码分割（动态导入）

// 原写法

import About from './views/About.vue'



// 优化后写法

const About = () => import(/* webpackChunkName: "about" */ './views/About.vue')

• 首页只加载核心代码（home路由）


• about模块会在用户点击about路由时才加载


• 显著减少首屏加载资源体积

✅ 合理配置 prefetch策略

// vue.config.js

module.exports = {

  chainWebpack: config => {

    // 移除prefetch插件

    config.plugins.delete('prefetch')

    

    // 或者更精细控制

    config.plugin('prefetch').tap(options => {

      options[0].fileBlacklist = options[0].fileBlacklist || []

      options[0].fileBlacklist.push(/myasyncRoute(.)+?\.js$/)

      return options

    })

  }

}

• 禁用prefetch：减少不必要的带宽消耗，但可能增加后续路由切换等待时间


• 启用prefetch：利用浏览器空闲时间预加载，提升用户体验但可能浪费带宽


• 折中方案：只对关键路由或高概率访问的路由启用prefetch

✅ splitChunks 将node_modules中的依赖单独打包

拆分vendor：将node_modules中的依赖单独打包

config.optimization.splitChunks({

 chunks: 'all',

 cacheGr0ups: {

   vendors: {

     name: 'chunk-vendors',

     test: /[\\/]node_modules[\\/]/,

     priority: -10,

     chunks: 'initial'

   }

 }

})

✅ 按需引入 lodash

import debounce from 'lodash/debounce'

用啥再引啥。

甲方笑了

打开首页闪电一进，完美ending！！！

散会啦😊

大家好，我是双越老师，也是 wangEditor 作者。

我正开发一个 Node 全栈 AIGC 知识库 划水AI，包括 AI 写作、多人协同编辑。复杂业务，真实上线，大家可以去注册试用，围观项目研发过程。

关于前端性能优化的困惑

前端性能优化是前度面试常考的问题，答案说来复杂，其实总结下来就是：减少或拆分资源 + 异步加载 现在都搞成八股文了，面试之前背诵一下。

还有缓存。

但纯前端的缓存其实作用不大，使用场景也不多，例如 Vue computed keep-alive，React useMemo 在绝大部分场景下都用不到。虽然面试的时候我们得说出来。

HTTP 缓存是网络层面的，操作系统和浏览器实现的，并不是前端实现的。虽然作为前端工程师要掌握这些知识，但大多数情况下并不需要自己亲自去配置。

实际工作中，其实绝大部分前端项目，代码量都没有非常大，不拆分代码，不异步加载也不会有太大的影响。

我这两年 1v1 评审过很多前端简历，大家都会有这样一个困惑：问到前端性能优化，感觉工作几年了，也没做什么优化，而且也想不出前端能做什么优化。

其实这是正常的，绝大部分前端项目、前端工作都不需要优化，而且从全栈角度看，前端能做的优化也很有限。

但面试是是面试，工作是工作。面试造火箭，工作拧螺丝，这个大家都知道，不要为此较真。

从全栈角度的性能优化

从我开发 划水AI 全栈项目的经历来看，一个 web 系统影响性能的诸多因素，按优先级排序：

第一是网络情况，服务器地理位置和客户端的距离，大型 web 系统在全国、全球各个节点都会部署服务器，还有 CDN DCDN EDGE 边缘计算等服务，都是解决这个问题。

第二是服务端的延迟，最主要的是 I/O 延迟，例如查询数据库、第三方服务等。

第三是 SSR 服务端渲染，一次性返回内容，尽量减少网络情况。

第四才是纯前端性能优化，使用 loading 提示、异步加载等。其实到了纯前端应该更多是体验优化，而不是性能优化。

网络

网络是最重要的一个因素，也是我们最不易察觉的因素，尤其初学者，甚至都没有独立发布上线过项目。

划水AI 之前部署在海外服务器，使用 Sentry 性能监控，TTFB 都超过 2s， FCP 接近 3s ，性能非常糟糕。

原因也很明显，代码无论如何优化，TTFB 时间慢是绕不过去的，这是网络层面的。

还有，之前 CDN 也是部署在香港的，使用站长工具做测试，会发现国内访问速度非常慢。

文档的多人协同编辑，之前总是不稳定重新连接。我之前一直以为是代码哪里写错了，一直没找到原因，后来发现是网络不稳定的问题。因为协同编辑服务当时是部署在亚马逊 AWS 新加坡的服务器。

这两天我刚刚把 划水AI 服务迁移到国内，访问速度从感知上就不一样了，又快又稳定。具体的数据我还在跟踪中，需要持续跟踪几天，过几天统计出来再分享。

服务端响应速度

首先是数据库查询速度，这是最常见的瓶颈。后端程序员都要熟练各种数据库的优化手段，前端不一定熟练，但要知道有这么回事。

现在 划水AI 数据库用的是 Supabase 服务，是海外服务器。国内目前还没有类似的可替代服务，所以暂时还不能迁移。

所以每次切换文档，都会有 1s 左右的 loading 时间，体验上也说的过去。比用之前的 AWS 新加坡服务器要快了很多。

其次是第三方服务的速度，例如 AI 服务的接口响应速度，有时候会比较慢，需要等待 3s 以上。

但 deepseek 网页版也挺慢的，也得 loading 2-3s 时间。ChatGPT 倒是挺快，但我们得用中转服务，这一中转又慢了。

还有例如登录时 GitHub 验证、发送邮件验证等，这个目前也不快，接下来我会考虑改用短信验证码的方式来登录。

第三方服务的问题是最无解的。

SSR 服务端渲染

服务端获取数据，直接给出结果，或者判断跳转页面（返回 302），而不是前端 ajax 获取数据再做判断。

后者再如何优化，也会比前者多一步网络请求，50-100ms 是少不了的。前端压缩、拆分多少资源也填不上这个坑。

纯前端性能优化

面试中常说的性能优化方式，如 JS 代码拆分、异步组件、路由懒加载等，可能减少的就是几十 KB 的数据量，而这几十 KB 在现代网络速度和 CDN 几乎感知不出来。

而且还有 HTTP 缓存，可能第一次访问时候可能慢一点点，再次访问时静态资源使用缓存，就不会再影响速度。

最后还有压缩，网络请求通常采用 GZIP 压缩，可把资源体积压缩到 1/3 大小。例如，你把 JS 减少了 100kb，看似优化了很多，但实际在网络传输的时候压缩完只有 30kb ，还不如一个图片体积大。

而有时候为了这些优化反而把 webpack 或 vite 配置的乱七八糟的，反而增加了代码复杂度，容易出问题。

但前端可以做很多体验优化的事情，例如使用 loading 效果和图片懒加载，虽然速度还一样，但用户体验会更好，使用更流畅。这也是有很大产品价值的。

最后

一个 web 系统的性能瓶颈很少会出现在前端，前端资源的速度问题在网络层面很好解决。所以希望每一位前端开发都要有全栈思维，能站在全栈的角度去思考问题和解决问题。

有兴趣的同学可关注 划水AI 项目，Node 全栈 AIGC 知识库，复杂项目，真实上线。

前言

在这篇技术博客中，我将详细解析一个流行的卡片展开效果实现方案，这个效果在GitHub最受欢迎的50个项目中占有一席之地。我们将从布局、CSS样式到JavaScript交互进行全面讲解。

让我们先来瞅瞅大概的动画效果吧🚀🚀🚀

项目概述

这个项目展示了一组卡片，默认状态下所有卡片均匀分布，当用户点击某个卡片时，该卡片会展开显示更多内容，同时其他卡片会收缩。这种交互方式在图片展示、产品特性介绍等场景非常实用。

HTML结构分析

构建一个初始的框架可以用一行代码解决：.container>(.qq-panel>h3.qq-panel__title)*5，然后其他的背景属性什么的慢慢加

<div class="container">

      <div class="qq-panel qq-panel_active" style="background-image: url('https://images.unsplash.com/photo-1558979158-65a1eaa08691?ixlib=rb-1.2.1&ixid=eyJhcHBfaWQiOjEyMDd9&auto=format&fit=crop&w=1350&q=80')">

        <h3 class="qq-panel__title">Explore The World</h3>

      </div>

      <div class="qq-panel" style="background-image: url('https://images.unsplash.com/photo-1572276596237-5db2c3e16c5d?ixlib=rb-1.2.1&ixid=eyJhcHBfaWQiOjEyMDd9&auto=format&fit=crop&w=1350&q=80')">

        <h3 class="qq-panel__title">Wild Forest</h3>

      </div>

      <div class="qq-panel" style="background-image: url('https://images.unsplash.com/photo-1507525428034-b723cf961d3e?ixlib=rb-1.2.1&ixid=eyJhcHBfaWQiOjEyMDd9&auto=format&fit=crop&w=1353&q=80')">

        <h3 class="qq-panel__title">Sunny Beach</h3>

      </div>

      <div class="qq-panel" style="background-image: url('https://images.unsplash.com/photo-1551009175-8a68da93d5f9?ixlib=rb-1.2.1&ixid=eyJhcHBfaWQiOjEyMDd9&auto=format&fit=crop&w=1351&q=80')">

        <h3 class="qq-panel__title">City on Winter</h3>

      </div>

      <div class="qq-panel" style="background-image: url('https://images.unsplash.com/photo-1549880338-65ddcdfd017b?ixlib=rb-1.2.1&ixid=eyJhcHBfaWQiOjEyMDd9&auto=format&fit=crop&w=1350&q=80')">

        <h3 class="qq-panel__title">Mountains - Clouds</h3>

      </div>

</div>

• 使用BEM命名规范（Block Element Modifier）命名类名


• 卡片背景图片通过内联样式设置，便于动态更改


• 初始状态下第一个卡片有qq-panel_active类，这个类是用来区分有没有点击的，初始状态下，只有第一张卡片是被点击的

CSS样式详解

全局重置与基础设置

* {

    margin: 0;

    padding: 0;

    box-sizing: border-box;

}

• *选择器应用于所有元素


• 重置margin和padding为0，消除浏览器默认样式差异

box-sizing: border-box 让元素尺寸计算更符合直觉：

1. 传统模式 (content-box) ：
   
   
   
   
   • width: 100px 仅指内容宽度
   
   
   • 实际占用宽度 = 100px + padding + border
   
   
   • 容易导致布局溢出
   
   
   
   


2. border-box模式：
   
   
   
   
   • width: 100px 包含内容、padding和border
   
   
   • 实际占用宽度就是设定的100px
   
   
   • 内容区自动收缩：内容宽度 = 100px - padding - border
   
   
   
   

为什么更直观：

• 你设想的100px就是最终显示的100px


• 不需要做加减法计算实际占用空间


• 特别适合响应式布局（百分比宽度时不会因padding而溢出）
  这就是为什么现代CSS重置通常首选border-box。

弹性布局与居中

body {

    display: flex;

    align-items: center;

    justify-content: center;

    height: 100vh;

    overflow: hidden;

}

• display: flex将body设置为弹性容器


• align-items: center垂直居中（交叉轴方向）


• justify-content: center水平居中（主轴方向）


• height: 100vh使body高度等于视窗高度


• overflow: hidden隐藏溢出内容，防止滚动条出现

注意：

1. vh单位：1vh等于视窗高度的1%，100vh就是整个视窗高度。这是响应式设计中常用的相对单位。


2. justify-content ：现在是水平居中，但其实是主轴的方向居中，align-items就是另一个方向的居中(这两个方向相互垂直)，通过flex-direction属性可以改变主轴的方向。(可以参考博客：告别浮动！Flexbox弹性布局终极指南引言)

容器样式

.container {

    display: flex; /* 弹性布局 */

    width: 90vw; /* 宽度 90% 视窗宽度 */

}

• 再次使用flex布局，使子元素排列在一行


• width: 90vw容器宽度为视窗宽度的90%，留出边距

卡片基础样式

.qq-panel {

    height: 80vh; /* 高度 80% 视窗高度 */

    border-radius: 50px; /* 圆角 50px */

    color: #fff; /* 字体颜色 */

    cursor: pointer; /* 鼠标指针 */

    margin: 10px; /* 外边距 */

    position: relative; /* 相对定位 */

    flex: 1; /* 弹性布局 1 */

    transition: all 0.7s ease-in; /* 过渡效果 */

}

• height: 80vh卡片高度为视窗高度的80%


• border-radius: 50px大圆角效果，现代感更强


• flex: 1所有卡片平均分配剩余空间，这个是相对的，如果有一个盒子是flex:2，那么这个盒子就是其他盒子的两倍，后面会看到，点击的盒子(div)是其他的5倍

transition: all 0.7s ease-in 是CSS过渡效果的简写属性，分解来看：

1. 作用范围：
   
   
   
   • all表示监听元素所有可过渡属性的变化
   
   
   • 也可指定特定属性如opacity, transform
   
   
   
   


2. 时间控制：
   
   
   
   • 0.7s表示过渡持续700毫秒
   
   
   • 时间长短影响动画节奏感（0.3s-1s最常用）
   
   
   
   


3. 缓动函数：
   
   
   
   • ease-in表示动画"慢入快出"
   
   
   • 其他常见值：
     
     
     
     • ease-out（快入慢出）
     
     
     • ease-in-out（慢入慢出）
     
     
     • linear（匀速）
     
     
     
     
   
   
   
   


4. 延迟时间:
   
   
   
   • 其实后面还有一个值，如：transition: opacity 0.3s ease-in 0.4s;所示，这里的0.4s表示动画不会立即执行，而是等待 0.4 秒后才开始。
   
   
   
   

提示：过渡属性应写在元素的默认状态，而非:hover等伪类中

卡片标题样式

.qq-panel__title {

    font-size: 24px; /* 字体大小 */

    position: absolute; /* 绝对定位 */

    bottom: 20px; /* 底部 20px */

    left: 20px; /* 左边 20px */

    opacity: 0; /* 不透明度 */

}

• 使用绝对定位将标题固定在卡片左下角


• 初始opacity: 0使标题不可见

激活状态卡片样式

.qq-panel_active {

    flex: 5; /* 弹性布局 5 */

}



.qq-panel_active .qq-panel__title {

    opacity: 1; /* 不透明度 */

    transition: opacity 0.3s ease-in 0.4s; /* 过渡效果 */

}

• flex: 5激活的卡片占据更多空间（是普通卡片的5倍）


• 标题显示（opacity: 1）并有单独的过渡效果


• transition: opacity 0.3s ease-in 0.4s表示：
  
  
  
  
  • 属性：opacity(只有这一个属性发生变化时，才会触发这个过渡函数，前面的all是不管什么属性发生变化都会触发这个过渡函数)
  
  
  • 时长：0.3秒
  
  
  • 缓动函数：ease-in
  
  
  • 延迟：0.4秒（让卡片展开动画先进行）
  
  
  
  

JavaScript交互逻辑

//获取所有卡片元素

const panels = document.querySelectorAll('.qq-panel');



panels.forEach(panel => {

    // JS 是事件机制的语言

    panel.addEventListener('click', () => {

        // 移除所有的 active 类

        removeActiveClasses(); // 模块化

        panel.classList.toggle('qq-panel_active');

    });

});



function removeActiveClasses() {

    panels.forEach(panel => {

        panel.classList.remove('qq-panel_active');

    })

}

设计要点总结

这个项目展示了如何用简洁的代码实现优雅的交互效果，核心在于对CSS弹性布局和过渡动画的熟练运用。通过分析这个案例，我们可以学习到现代前端开发中许多实用的技巧和设计理念。