在前端开发中，大屏适配一直是个让人头疼的问题。领导总是要求大屏既要不留白，又要不变形，还要没有滚动条。这看似简单的要求，实际却压根不可能。今天，我们就来聊聊大屏适配的四种常见模式，以及如何根据实际需求选择合适的方案。

一、大屏适配的困境

在大屏项目中，适配问题几乎是每个开发者都会遇到的挑战。屏幕尺寸的多样性、设计稿与实际屏幕的比例差异，都使得适配变得复杂。而领导的“既要...又要...还要...”的要求，更是让开发者们感到无奈。不过，我们可以通过合理选择适配模式来尽量满足这些需求。

二、四种适配模式

在大屏适配中，常见的适配模式有以下四种：

（以下截图中模拟视口1200px*500px和800px*600px，设计稿为1920px*1080px）

1. 拉伸填充（fill）

• 特点：内容会被拉伸变形，以完全填充视口框。这种方式可以确保视口内没有空白区域，但可能会导致内容变形。


• 适用场景：适用于对内容变形不敏感的场景，例如全屏背景图。

2. 保持比例（contain）

• 特点：内容保持原始比例，不会被拉伸变形。如果内容的宽高比与视口不一致，会在视口内出现空白区域（黑边）。这种方式可以确保内容不变形，但可能会留白。


• 适用场景：适用于需要保持内容原始比例的场景，例如视频或图片展示。

3. 滚动显示（scroll）

• 特点：内容不会被拉伸变形，当内容超出视口时会添加滚动条。这种方式可以确保内容完整显示，但用户需要滚动才能查看全部内容。


• 适用场景：适用于内容较多且需要完整显示的场景，例如长列表或长文本。

4. 隐藏超出（hidden）

• 特点：内容不会被拉伸变形，当内容超出视口时会隐藏超出部分。这种方式可以避免滚动条的出现，但可能会隐藏部分内容。


• 适用场景：适用于内容较多但不需要完整显示的场景，例如仪表盘。

三、为什么不能同时满足所有要求？

这四种适配模式各有优缺点，但它们在逻辑上是相互矛盾的。具体来说：

• 不留白：要求内容完全填充视口，没有任何空白区域。这通常需要拉伸或缩放内容以适应视口的宽高比。


• 不变形：要求内容保持其原始宽高比，不被拉伸或压缩。这通常会导致内容无法完全填充视口，从而出现空白区域（黑边）。


• 没滚动条：要求内容完全适应视口，不能超出视口范围。这通常需要隐藏超出部分或限制内容的大小。

这三个要求在逻辑上是相互矛盾的：

• 如果内容完全填充视口（不留白），则可能会变形。


• 如果内容保持原始比例（不变形），则可能会出现空白区域（留白）。


• 如果内容超出视口范围，则需要滚动条或隐藏超出部分。

四、【fitview】插件快速实现大屏适配

fitview 是一个视口自适应的 JavaScript 插件，它支持多种适配模式，能够快速实现大屏自适应效果。

github地址：github.com/pbstar/fitv…

在线预览：pbstar.github.io/fitview

以下是它的基本使用方法：

配置

• el: 需要自适应的 DOM 元素


• fit: 自适应模式，字符串，可选值为 fill、contain（默认值）、scroll、hidden


• resize: 是否监听元素尺寸变化，布尔值，默认值 true

安装引入

npm 安装

npm install fitview

esm 引入

import fitview from "fitview";

cdn 引入

<script src="https://unpkg.com/fitview@[version]/lib/fitview.umd.js"></script>

使用示例

<div id="container">

  <div style="width:1920px;height:1080px;"></div>

</div>

const container = document.getElementById("container");

new fitview({

  el: container,

});

五、总结

大屏适配是一个复杂的问题，不同的项目有不同的需求。虽然不能同时满足“不留白”“不变形”和“没滚动条”这三个要求，但可以通过合理选择适配模式来尽量满足大部分需求。在实际开发中，我们需要根据项目的具体需求和用户体验来权衡，选择最合适的适配方案。

在选择适配方案时，fitview 这个插件可以提供很大的帮助。它支持多种适配模式，能够快速实现大屏自适应效果。如果你正在寻找一个简单易用的适配工具，fitview 值得一试。你可以通过 npm 安装或直接使用 CDN 引入，快速集成到你的项目中。

希望这篇文章能帮助你更好地理解和选择大屏适配方案。如果你有更多问题或建议，欢迎在评论区留言。

作为一名前端开发者，我们一定都遇到过这样的需求：实现一个占满整个屏幕的欢迎页、弹窗蒙层或者一个 fixed 定位的底部菜单。

直觉告诉我们，这很简单，给它一个 height: 100vh 就行了。

.fullscreen-element {

    height: 100vh;

    width: 100%;

    color: #000;

    display: flex;

    justify-content: center;

    align-items: center;

    font-size: 10em;

    background-color: #fff;

}

在PC端预览，完美！然而，当你在手机上打开时，可能会看到下面这个令人抓狂的场景：

明明是 100vh，为什么会超出屏幕高度？这个烦人的滚动条到底从何而来？

如果你也曾为此抓耳挠腮，那么恭喜你，这篇文章就是你的“终极答案”。今天，我将带你彻底搞懂 100vh 在移动端的“坑”，并为你介绍当下最完美的解决方案。

1. 问题根源：移动端动态变化的“视口”

要理解问题的本质，我们首先要明白 vh (Viewport Height) 单位的定义：1vh 等于视口高度的 1%。

在PC端，浏览器窗口大小是相对固定的，所以 100vh 就是浏览器窗口的可见高度，这没有问题。

但在移动端，情况变得复杂了。为了在有限的屏幕空间里提供更好的浏览体验，手机浏览器（尤其是Safari和Chrome）的地址栏和底部工具栏是动态变化的。

• 初始状态：当你刚进入页面时，地址栏和工具栏是完全显示的。


• 滚动时：当你向下滚动页面，这些UI元素会自动收缩，甚至隐藏，以腾出更多空间展示网页内容。

关键点来了：大多数移动端浏览器将 100vh 定义为“最大视口高度”，也就是当地址栏和工具栏完全收起时的高度。

这就导致了：

在页面初始加载、地址栏还未收起时，100vh 的实际计算高度 > 屏幕当前可见区域的高度。

于是，那个恼人的滚动条就出现了。

2. “过去式”的解决方案：JavaScript 动态计算

在很长一段时间里，前端开发者们只能求助于 JavaScript 来解决这个问题。思路很简单：通过 window.innerHeight 获取当前可见视口的高度，然后用它来动态设置元素的 height。

JavaScript

function setRealVH() {

  const vh = window.innerHeight * 0.01;

  document.documentElement.style.setProperty('--vh', `${vh}px`);

}



// 初始加载时设置

window.addEventListener('load', setRealVH);

// 窗口大小改变或旋转屏幕时重新设置

window.addEventListener('resize', setRealVH);

然后在 CSS 中这样使用：

CSS

.fullscreen-element {

  height: calc(var(--vh, 1vh) * 100);

}

这个方案的缺点显而易见：

• 性能开销：监听 resize 事件过于频繁，可能会引发性能问题。


• 逻辑耦合：纯粹的样式问题却需要JS来解决，不够优雅。


• 时机问题：执行时机需要精确控制，否则可能出现闪烁。

虽然能解决问题，但这绝不是我们想要的“终极方案”。

3. “现在时”的终极解决方案：CSS动态视口单位

谢天谢地，CSS 工作组听到了我们的呼声！为了解决这个老大难问题，CSS Values and Units Module Level 4 引入了一套全新的动态视口单位。

它们就是我们今天的“主角”：

• svh (Small Viewport Height): 最小视口高度。对应于地址栏和工具栏完全展开时的可见高度。


• lvh (Large Viewport Height): 最大视口高度。对应于地址栏和工具栏完全收起时的高度（这其实就等同于旧的 100vh）。


• dvh (Dynamic Viewport Height): 动态视口高度。这是最智能、最实用的单位！它的值会随着浏览器UI元素（地址栏）的出现和消失而动态改变。

所以，我们的终极解决方案就是：

CSS

.fullscreen-element {

  height: 100svh; /* 如果你希望高度固定，且永远不被遮挡 */

  /* 或者，也是我最推荐的 */

  height: 100dvh; /* 如果你希望元素能动态地撑满整个可见区域 */

}

使用 100dvh，当地址栏收起时，元素高度会平滑地增加以填满屏幕；当地址栏滑出时，元素高度又会平滑地减小。整个过程如丝般顺滑，没有任何滚动条，完美！

浏览器兼容性

你可能会担心兼容性问题。好消息是，从2023年开始，所有主流现代浏览器（Safari, Chrome, Edge, Firefox）都已经支持了这些新的视口单位。

(数据截至2025年6月，兼容性已非常好)

可以看到，兼容性已经非常理想。除非你需要支持非常古老的浏览器版本，否则完全可以放心地在生产环境中使用。

告别 100vh 的时代

让我们来快速回顾一下：

当需要实现移动端全屏布局时，请大胆地告别 100vh，拥抱 100dvh！

原文：Alexander Belanger - 2025.06.03

如同地球上几乎所有人一样，过去的几个月里，我们也一直在关注着 Agent 的发展。

特别值得一提的是，我们观察到 Agent 的采用推动了我们编排平台的增长，这让我们对哪些技术栈和框架——或者干脆没有框架——在此领域表现良好有了一些见解。

我们看到的一个更有趣的现象是混合技术栈的激增：一个典型的 Next.js 或 FastAPI 后端，搭配着一个用 Go 语言编写的 Agent，甚至在非常早期阶段就如此。

作为一名长期的 Go 语言开发者，这着实令人兴奋；下面我将解释为何我认为这将成为未来更普遍的做法。

什么是 Agent？

这里的术语有些混乱，但通常我指的是一个在循环中执行的进程，该进程对其执行路径中的下一步操作拥有一定的自主权。这与预定义的执行路径（例如定义为有向无环图的一组步骤，我们称之为工作流）形成对比。Agent 通常包含一个基于最大深度或满足某个条件（如“测试通过”）的退出条件。

当 Agent 开始规模化（即：拥有实际用户）时，它们通常具有一些共同特征：

让我们将这一系列特征转化为对运行时的要求。为了限定问题范围，假设我们正在处理一个在远程执行的 Agent，而非在用户本地机器上（尽管 Go 对于分发本地 Agent 也是一个绝佳选择）。在远程执行的情况下，为每次 Agent 执行运行一个单独的容器成本会高得惊人。因此，在大多数情况下（尤其是当我们的 Agent 主要是简单的 I/O 和 LLM 调用时），我们最终会得到大量并发运行的轻量级进程。每个进程可以处于特定状态（例如，“搜索文件中”、“生成代码中”、“测试中”）。请注意，不同 Agent 执行的状态顺序可能并不相同。

这种包含许多并发、长时间运行进程的系统，与大约十年前的传统 Web 架构截然不同。在传统架构中，对服务器的请求处理速度要快得多，使用一些缓存、高效的处理程序和 OLTP 数据库就能高效地服务数千名日活用户。

事实证明，这种架构转变非常适合 Go 语言的并发模型、依赖通道（channel）进行通信、集中的取消机制以及围绕 I/O 构建的工具链。

高并发性

让我们从最明显的一点开始——Go 拥有极其简单且强大的并发模型。创建一个新的 goroutine 所需的内存和时间成本非常低，因为每个 goroutine 只有 2KB 的预分配内存。

这实际上意味着你可以同时运行许多 goroutine 而开销很小，并且它们在底层运行在多个操作系统线程上，能够利用服务器中的所有 CPU 核心。这一点非常重要，因为如果你碰巧在某个 goroutine 中执行非常消耗 CPU 的操作（比如反序列化一个大型 JSON 结构），其影响会比你使用单线程运行时（如 Node.js）要小（在 Node.js 中，你需要为阻塞线程的操作创建 worker 线程或子进程），或者比使用 Python 的 async/await 也要好。

这对于 Agent 意味着什么？因为 Agent 的运行时间比典型的 Web 请求长得多，所以并发性就成为了一个更关键的问题。在 Go 中，相比于在 Python 中为每个 Agent 运行一个线程，或者在 Node.js 中为每个 Agent 运行一个 async 函数，你受到为每个 Agent 生成一个 goroutine 的限制要小得多。再加上较低的基础内存占用和编译成单一二进制文件的特点，在轻量级基础设施上同时运行数千个并发 Agent 执行变得异常简单。

通过通信共享内存

对于那些不了解的人，Go 语言有一个常见的习语：不要通过共享内存来通信；相反，通过通信来共享内存。

在实践中，这意味着不需要尝试跨多个并发进程同步内存内容（这是使用类似 Python 的 multithreading 库时的常见问题），每个进程可以通过在通道（channel）上获取和释放对象来获得该对象的所有权。这样做的效果是，每个进程只在拥有对象所有权时关心该对象的本地状态，而其他时候不需要协调所有权——无需互斥锁（mutex）！

老实说——在我编写过的大多数 Go 程序中，我使用等待组（wait groups）和互斥锁（mutexes）的次数往往比使用通道（channels）更多，因为这样通常更简单（这也符合 Go 社区的建议），并且只有一个地方需要并发访问数据。

但是，在建模 Agent 时，这种范式非常有用，因为 Agent 通常需要异步响应用户或其他 Agent 发来的消息，并且将应用程序实例视为一个 Agent 池来思考是很有帮助的。

为了更具体说明，让我们编写一些示例代码来表示 Agent 循环的核心逻辑：

// 注意：在真实世界的例子中，我们需要一种机制来优雅地

// 关闭循环并防止通道关闭；

// 这是一个简化示例。

func Agent(in <-chan Message, out chan<- Output, status chan<- State) {

    internal := make(chan Message, 10) // 内部缓冲区大小为 10 的通道



    for {

        select {

        case msg := <-internal: // 从内部通道读取消息

            processMessage(msg, internal, out, status)

        case msg := <-in: // 从外部输入通道读取消息

            processMessage(msg, internal, out, status)

        }

    }

}



func processMessage(msg Message, internal chan<- Message, out chan<- Output, status chan<- State) {

    result := execute(msg) // 执行消息处理

    status <- State{msg.sessionId, result.status} // 发送状态更新



    if next := result.next(); next != nil { // 获取下一步消息（如果有）

        internal <- next // 将下一步消息发送到内部通道

    }



    out <- result // 发送处理结果

}

(请注意，<-chan 表示接收者只能从通道读取，而 chan<- 表示接收者只能向通道写入。)

这个 Agent 是一个长时间运行的进程，它等待消息到达 in 通道，处理消息，然后异步地将结果发送到 out 通道。status 通道用于发送关于 Agent 状态的更新，这对于监控或向用户发送增量结果很有用；而 internal 通道用于处理 Agent 的内部循环。例如，内部循环可以实现下图中的“直到测试通过”循环：

尽管我们使用 for 循环来运行 Agent，但该 Agent 的实例在消息之间不需要维护任何内部状态。它本质上是一个无状态归约器，其决策执行路径的下一步操作不依赖于某些内部状态。重要的是，这意味着任何 Agent 实例都能够处理下一条消息。这也允许 Agent 在消息之间使用持久化边界，例如将消息写入数据库或消息队列。

使用 context.Context 的集中取消机制

还记得 Agent 执行成本很高吗？假设一个用户触发了一个价值 10 美元的执行任务，但突然改变主意并点击“停止生成”——为了节省成本，你希望取消这次执行。

事实证明，在 Node.js 和 Python 中取消长时间运行的工作极其困难，原因有很多：

幸运的是，Go 采用 context.Context 使得取消工作变得轻而易举，因为绝大多数库都预期并尊重这种模式。即使某些库不支持：由于 Go 只有一种并发模型，因此有像 goleak 这样的工具，可以更容易地检测出泄漏的 goroutine 和有问题的库。

丰富的标准库

当你开始使用 Go 时，你会立即注意到 Go 的标准库非常丰富且质量很高。它的许多部分也是为 Web I/O 构建的——比如 net/http、encoding/json 和 crypto/tls——这些对于 Agent 的核心逻辑非常有用。

Go 还有一个隐含的假设：所有 I/O 在 goroutine 内部都是阻塞的——再次强调，因为 Go 只有一种方式运行并发工作——这鼓励你将业务逻辑的核心编写为直线式程序。你不需要担心用 await 包装每个函数调用来将执行推迟给调度器。

与 Python 对比：库开发者需要考虑 asyncio、多线程（multithreading）、多进程（multiprocessing）、eventlet、gevent 以及其他一些模式，几乎不可能同等地支持所有并发模型。因此，如果你用 Python 编写 Agent，你需要研究每个库对你所采用的并发模型的支持情况，并且如果你的第三方库不完全支持你想要的模式，你可能需要采用多种模式。

（Node.js 的情况要好得多，尽管 Bun 和 Deno 等其他运行时的加入增加了一些不兼容的层面。）

性能剖析（Profiling）

由于其有状态性（statefulness）和大量长时间运行的进程，Agent 似乎特别容易出现内存泄漏和线程泄漏。Go 在 runtime/pprof 中提供了出色的工具，可以使用堆（heap）和分配（alloc）配置文件找出内存泄漏的来源，或者使用 goroutine 配置文件找出 goroutine 泄漏的来源。

额外优势：LLM 擅长编写 Go 代码

由于 Go 语法非常简单（一个常见的批评是 Go 有点“啰嗦”）并且拥有丰富的标准库，LLM 非常擅长编写符合 Go 语言习惯的代码。我发现它们在编写表格测试（table tests）方面尤其出色，这是 Go 代码库中的一种常见模式。

Go 工程师也往往反对框架（anti-framework），这意味着 LLM 不需要跟踪你使用的是哪个框架（或框架的哪个版本）。

不足之处

尽管有以上诸多好处，仍然有很多理由让你可能不会选择 Go 来开发你的 Agent：

随着人工智能技术的不断发展，图像处理应用已经在医疗影像分析、自动驾驶、视频监控等领域得到广泛应用。TensorFlow.js 是 Google 开源的机器学习库 TensorFlow 的 JavaScript 版本，能够让开发者在浏览器中运行机器学习模型，在前端应用中轻松实现图像分类、物体检测和姿态估计等功能。本文将介绍如何使用 TensorFlow.js 在纯前端环境中实现这三项任务，并帮助你构建一个智能图像处理应用。

什么是 TensorFlow.js？

TensorFlow.js 是一个能够让开发者在前端直接运行机器学习模型的 JavaScript 库。它允许你无需将数据发送到服务器，便可以在浏览器中运行模型进行推理，这不仅减少了延迟，还可以更好地保护用户的隐私数据。通过 TensorFlow.js，前端开发者能够轻松实现图像分类、物体检测和姿态估计等功能。

TensorFlow.js 的应用非常广泛，尤其是在一些实时交互和隐私敏感的场景下，例如 医疗影像分析、自动驾驶 和 智能监控。在这些领域，前端模型推理能够提升响应速度，并且避免将用户的数据上传到服务器，从而保护用户的隐私。

要开始使用 TensorFlow.js，你需要安装相关的模型库。以下是你需要安装的 npm 包：

npm install @tensorflow/tfjs

npm install @tensorflow-models/mobilenet

npm install @tensorflow-models/coco-ssd

npm install @tensorflow-models/posenet

加载预训练模型

在 TensorFlow.js 中，加载预训练模型非常简单。首先，确保 TensorFlow.js 已经准备好，然后加载所需的模型进行推理。

// 导入

import * as tf from '@tensorflow/tfjs'

// 加载

tf.ready(); // 确保 TensorFlow.js 准备好

用户上传图片

为了使用这些模型进行推理，我们需要让用户上传一张图片。以下是一个处理图片上传的代码示例：

const handleImageUpload = async (event) => {

  const file = event.target.files[0]

  if (file) {

    const reader = new FileReader()

    reader.onload = async (e) => {

      imageSrc.value = e.target.result

      await runModels(e.target.result)

    }

    reader.readAsDataURL(file)

  }

}

图像分类：识别图片中的物体

图像分类是计算机视觉中的基本任务，目的是将输入图像归类到某个类别中。例如，我们可以用图像分类模型识别图像中的“猫”还是“狗”。

使用预训练模型进行图像分类

TensorFlow.js 提供了多个预训练模型，MobileNet 是其中一个常用的图像分类模型。它是一个轻量级的卷积神经网络，适合用来进行图像分类。接下来，我们通过 MobileNet 实现一个图像分类功能：

const mobilenetModel = await mobilenet.load()

const predictions = await mobilenetModel.classify(image)

classification.value = `分类结果: ${predictions[0].className}, 信心度: ${predictions[0].probability.toFixed(3)}`

这段代码实现了图像分类。我们加载 MobileNet 模型，并对用户上传的图像进行推理，最后返回图像的分类结果。

物体检测：找出图像中的所有物体

物体检测不仅仅是识别图像中的物体是什么，还需要标出它们的位置，通常用矩形框来框住物体。Coco-SSD 是一个强大的物体检测模型，能够在图像中检测出多个物体并标出它们的位置。

使用 Coco-SSD 进行物体检测

const cocoModel = await cocoSsd.load();

const detectionResults = await cocoModel.detect(image);

objects.value = detectionResults.map((prediction) => ({

  class: prediction.class,

  bbox: prediction.bbox,

}));

通过 Coco-SSD 模型，我们可以检测图像中的多个物体，并标出它们的位置。

绘制物体的边界框

为了更直观地展示检测结果，我们可以在图像上绘制出物体的边界框：

// 绘制物体检测边界框

const drawObjects = (detectionResults, image) => {

  nextTick(() => {

    const ctx = objectCanvas.value.getContext('2d')

    const imageWidth = image.width

    const imageHeight = image.height

    objectCanvas.value.width = imageWidth

      objectCanvas.value.height = imageHeight

      ctx.clearRect(0, 0, objectCanvas.value.width, objectCanvas.value.height)

      ctx.drawImage(image, 0, 0, objectCanvas.value.width, objectCanvas.value.height)

      // 绘制边界框

      detectionResults.forEach((prediction) => {

        const [x, y, width, height] = prediction.bbox

        ctx.beginPath()

        ctx.rect(x, y, width, height)

        ctx.lineWidth = 2

        ctx.strokeStyle = 'green'

        ctx.stroke()

        // 添加标签

        ctx.font = '16px Arial'

        ctx.fillStyle = 'green'

        ctx.fillText(prediction.class, x + 5, y + 20)

      })

  })

}

这段代码通过绘制边界框来标出检测到的物体位置，同时在边界框旁边显示物体类别。

姿态估计：识别人体的关键点

姿态估计主要是识别人类的身体部位，例如头部、手臂、腿部等。通过这些关键点，我们可以了解一个人当前的姿势。TensorFlow.js 提供了 PoseNet 模型来进行姿态估计。

使用 PoseNet 进行姿态估计

// 加载 PoseNet 模型

const posenetModel = await posenet.load()

const poseResult = await posenetModel.estimateSinglePose(image, {

  flipHorizontal: false

})

​

// 人体关键点

pose.value = poseResult.keypoints.map((point) => `${point.part}: (${point.position.x.toFixed(2)}, ${point.position.y.toFixed(2)})`)

PoseNet 模型会估计图像中人物的关键点，并返回每个关键点的位置。

绘制姿态估计骨架图

const drawPose = (keypoints, image) => {

  nextTick(() => {

    const ctx = canvas.value.getContext('2d')

    const imageWidth = image.width

    const imageHeight = image.height

    canvas.value.width = imageWidth

      canvas.value.height = imageHeight

      ctx.clearRect(0, 0, canvas.value.width, canvas.value.height)

      // 绘制图像

      ctx.drawImage(image, 0, 0, canvas.value.width, canvas.value.height)

      const scaleX = canvas.value.width / image.width

      const scaleY = canvas.value.height / image.height

      // 绘制关键点并标记名称

      keypoints.forEach((point) => {

        const { x, y } = point.position

        const scaledX = x * scaleX

        const scaledY = y * scaleY

        ctx.beginPath()

        ctx.arc(scaledX, scaledY, 5, 0, 2 * Math.PI)

        ctx.fillStyle = 'red'

        ctx.fill()

        // 标记点的名称

        ctx.font = '12px Arial'

        ctx.fillStyle = 'blue'

        ctx.fillText(point.part, scaledX + 8, scaledY)

      })

      // 连接骨架

      const poseConnections = [

        ['leftShoulder', 'rightShoulder'],

        ['leftShoulder', 'leftElbow'],

        ['leftElbow', 'leftWrist'],

        ['rightShoulder', 'rightElbow'],

        ['rightElbow', 'rightWrist'],

        ['leftHip', 'rightHip'],

        ['leftShoulder', 'leftHip'],

        ['rightShoulder', 'rightHip'],

        ['leftHip', 'leftKnee'],

        ['leftKnee', 'leftAnkle'],

        ['rightHip', 'rightKnee'],

        ['rightKnee', 'rightAnkle'],

        ['leftEye', 'rightEye'],

        ['leftEar', 'leftShoulder'],

        ['rightEar', 'rightShoulder']

      ]

      poseConnections.forEach(([partA, partB]) => {

        const keypointA = keypoints.find((point) => point.part === partA)

        const keypointB = keypoints.find((point) => point.part === partB)

        if (keypointA && keypointB && keypointA.score > 0.5 && keypointB.score > 0.5) {

          const scaledX1 = keypointA.position.x * scaleX

          const scaledY1 = keypointA.position.y * scaleY

          const scaledX2 = keypointB.position.x * scaleX

          const scaledY2 = keypointB.position.y * scaleY

          ctx.beginPath()

          ctx.moveTo(scaledX1, scaledY1)

          ctx.lineTo(scaledX2, scaledY2)

          ctx.lineWidth = 2

          ctx.strokeStyle = 'blue'

          ctx.stroke()

        }

      })

  })

}

这段代码通过 PoseNet 返回的人体关键点信息，绘制人体姿态的骨架图，帮助用户理解图像中的人物姿势。

总结

通过 TensorFlow.js，我们可以轻松地将图像分类、物体检测和姿态估计等功能集成到前端应用中，无需依赖后端计算，提升了应用的响应速度并保护了用户隐私。在本文中，我们介绍了如何使用 MobileNet、Coco-SSD 和 PoseNet 等预训练模型，在前端实现智能图像处理应用。无论是开发图像识别应用还是增强现实应用，TensorFlow.js 都是一个强大的工具，值得前端开发者深入学习和使用。

你知道网易有多少个前端项目吗？

超过 1000 个代码仓库、200+子应用、每天发布300次。

如果没有一套微前端治理系统，项目早炸了。

今天就来带你拆解网易微前端架构的核心——基座 + 动态加载 + 权限隔离 + 独立发布。

一、网易为什么早早就用上了微前端？

因为早年起就有大量频道、游戏门户、社区运营、CMS后台等：

• 功能多样、团队独立


• 迭代频繁、部署不可等待


• 技术栈各异：Vue2、Vue3、React、甚至还有 jQuery...

👇于是他们选择了模块化能力最强的方案：微前端架构（Micro Frontends）

二、整体架构图（网易实战版）

三、主子应用通信怎么做？（网易方案）

网易没有用 qiankun，而是基于内部封装的微前端 SDK，核心原理类似。

// 主应用提供通信桥

window.__MICRO_APP_EVENT_BUS__ = new EventTarget()



// 子应用监听事件

window.__MICRO_APP_EVENT_BUS__.addEventListener('global-refresh', () => {

  window.location.reload()

})



// 主应用触发事件

window.__MICRO_APP_EVENT_BUS__.dispatchEvent(new Event('global-refresh'))

👉这种方式：

• 不侵入框架（Vue/React 通吃）


• 不耦合代码，只用浏览器原生事件系统

四、部署与权限如何统一管理？

网易配套了一整套“发布平台 + 权限系统”，做到：

五、实战代码：子应用注册和加载

// 主应用注册子应用（JSON 配置化）

const microAppList = [  {    name: 'content-manage',    entry: 'https://cdn.xxx.com/apps/content-manage/index.html',    activeRule: '/content'  },  {    name: 'user-center',    entry: 'https://cdn.xxx.com/apps/user-center/index.html',    activeRule: '/user'  }]



// 动态加载示例（简化版）

function loadMicroApp(appConfig) {

  const iframe = document.createElement('iframe')

  iframe.src = appConfig.entry

  iframe.style = 'width:100%;height:100%;border:none'

  document.getElementById('micro-container').appendChild(iframe)

}

六、网易踩过的3个坑（干货！）

七、总结：你能从中学到什么？

• 不要迷信 qiankun，自己也能搞微前端（原理简单）


• 微前端不仅是技术，更是权限、部署、治理一整套体系


• 想要稳定运行，必须有主子应用契约 + 灰度发布 + 统一通信策略

尾声：

“你看到的稳定，其实是他们踩了无数坑后的优雅。”

引言

老张最近有一个重点项目在推进，他准备今天回家加班赶赶进度。

可到家之后，发现孩子发烧了，由于妻子出差，他赶紧放下手头的事情，抱起带孩子往医院跑。

堵车、吃饭、挂号、排队，一路折腾下来，已经九点了。

可就是这个点，儿科急诊仍是人山人海。孩子好奇的问东问西，手机里还不断跳出加急的消息，老张焦急的不断盘算着还有多久能排到他们。

马上到老张了，突然有一个人抱着孩子挤进了医生房间，老张愣了一下，火一下子就上来了，冲进屋子和对方吵了起来......

幸运的是孩子没什么事，可老张熬了一晚上啥也没干成。第二天上班状态不好，和业务方沟通时及其不耐烦。

下午收到了业务方的投诉，理由是态度消极。

老张一天什么也没干，却感觉自己马上就要崩溃了。

英雄就是这么被击垮的。据说是伏尔泰有句话说，“使人疲惫的不是远方的高山，而是你鞋里的一粒沙子”。

工作繁忙、孩子生病、业务方催促进度......都不是什么“重大事件”，可就是会压的你喘不过气来。

处理不好这些小麻烦，不但会影响你的情绪和工作表现，还有可能会影响我们的健康，最重要的是，如果被这些小事击垮了，我们哪还有心思去想什么大事呢？

我现在“大概”可以做到情绪稳定，我有四个自己在用的心法，分享给大家。

学会忽略

学会忽略，是我看到一句，据说是爱因斯坦说过的话：“弱者报复，强者原谅，智者忽略”。

就拿开车举例，我在路上发现过一个特别有意思的现象，如果开车的时候遇见插队，不同的司机有三种反应。

第一种人是对抗型，面对插队丝毫不让，眼看着两辆车的距离都塞不下一根手指头了，插队车决定放弃，他可能赢得了这场面子仗。

第二种人是原谅型，一开始会正常起步，但如果对方强行变道， 他会及时刹车，毕竟剐蹭了浪费时间浪费金钱。

第三种人是忽略型，他可能根本就没有在意这辆车在插队，他会直到前车完全进来，才会继续出发。他可能正沉浸在播客或者音乐里，神游在另一个维度。

你觉着哪种应对方式最好？

之前我是第二种人，并且还觉着第三种人是技术不佳，或者说是“好欺负”，直到最近我也有点了第三种人的样子。

有一次我在路上，听播客听的入迷，前方有个车有变道的意图。我也不着急，就让他变道进来了。

随后我才意识到，自己好像甚至都没有为这件事情，分散一点注意力。

那一刻我才明白，忽略，不是退让，也不用压抑情绪——

而是你根本没分配注意力分配给小事，负面情绪自然也就不会被激活。

忽略负面情绪非常有必要，有一项针对1300名男性做的研究，让他们对自己遇见类似于加塞这种小麻烦的反应打分，分数越高代表情绪反应越大。

结果发现，经常对小事有激烈反应的男性，他们的健康状况和死亡率，和面对那些重大人生压力的人一样。反应最激烈的那一组，在同样时间段内的死亡率，竟然是正常人的三倍。

我想起之前我奶奶家挂着一副《莫生气》的字画，里面有一句话：别人生气我不气，气出病来无人替。

看来对小事有激烈反应，真的会影响身心健康啊。我实践下来，忽略情绪有三个小技巧：

第一个是觉察情绪。当你发现自己心跳加快、紧握双拳，要注意情绪可能要来了。你需要深吸一口气，把注意力放到自己身上，让自己停下来，别被情绪牵着鼻子。

第二是控制自己的反应。‌维克多·弗兰克尔有一句话：“在面对外界刺激时，我们拥有选择如何回应的自由”。人真正能控制的只有自己的行动和态度，你控制不了堵车，但你能控制堵车的时候听一首钢琴曲。

第三是发现身边的美好，也就是感知生活中的“小确幸”。比如阳台上的花突然开了，孩子自己穿衣服了。有研究表明，对生活中积极细节的留意，能有效中和压力引发的负面情绪。

不恶意揣测

不过有些事情你很难忽略，比如公司考核政策调整，甚至说你持仓的股票大跌。

你感觉这个世界充满了恶意：公司打压你、社会在压榨你、资本在收割你。

可现实真的是这样吗？

帮助我解决心结的法则叫做「汉隆剃刀」。简单的说，它的意思就是「能解释为愚蠢的，就不要解释为恶意」。

这里说的愚蠢，代表各种无知的、偶然的、非故意的原因。这些情况发生的可能性远远大于恶意，汉隆剃刀大多数情况下反应了客观事实。  

比如你开车，前方突然有车插队，你怒不可遏，心想：你是不是觉着我好欺负？

但其实他根本不认识你，只不过恰巧他意识到前方需要拐弯了。

这个法则在理解社会、组织层面，特别有效。

比如你持有的一只股票突然暴跌，你会听到一些传闻：说这是“庄家”在故意控盘。

我之前特别相信这种阴谋论，觉着股价是被人为操控的。可真实情况是，大公司的股价是很难操控的，投入很多钱也不一定能成功，一旦失败就会受到很大损失。而且市场上每个股民的互动、追涨杀跌，也会给股价造成很大影响。

再比如一家公司突然开始了绩效改革，给研发人员制定了和销售额相关的KPI，而且目标不完成还会对薪资产生影响。

可研发的考核怎么可能和销售的KPI挂钩呢？你怀疑管理层在变相降薪。

可更大的可能性是：管理层也不知道如何满足老板制定的目标，只能先套个模版应付一下。

不是你被打压了，只是碰巧他们不专业，你以为它是在有意的做坏事，但更大的可能是它没能力做好事。

我们大脑为了认知方便，常常会把一家公司或者一个政府当成一个人，假设他有自由意志，是一个决策缜密、心怀不轨的敌人。但其实组织就是一部机器而已。

不是组织在有意针对你，这世界其实就是个草台班子。

超越身份思维

你有没有经历过这种场面，过年回家刚坐下，七大姑八大姨联合开麦：

“你看你三十多了还在北京漂着，准备啥时候结婚啊？你表哥孩子都上小学了。”

“北京租房多贵啊，在咱老家，这都够还房贷了，干嘛不考个公务员安稳点？”

你努力工作、认真生活，熬过了失业焦虑、加班压力，结果成了他们口中的“混日子”。

你不是气他们说了什么，而是他们压根不懂你，却笃定地定义你。

可他们的确不懂你，也不会真正的懂你。他们只不过是在维护自己的世界观而已。

学术界有一个流行的说法是，人们的行为和观点，是由身份认同决定的。你的长辈，可能在一个小城过了一辈子，有编制、有房子、生儿育女，就是他们眼里的体面生活。

你异地漂泊、私企行业、租房未婚，就是他们眼中的“不务正业”。

你不需要反驳，也不需要忍耐。而是你明白了，你不需要从所有人眼里获得认可，你可以看到不同身份的局限性。

超越身份思维，在养育孩子的过程中特别有用。

那天我带儿子去上烘焙课，糖刚撒进面粉中，他就开始一边揉一边往嘴里塞。

我试图制止，他越发固执，并且不耐烦的喊：“我要回家！我要回家！”

我有点崩溃，一边怕他吃坏肚子，一边气他为什么这么不听话。

但那一刻我突然意识到，他不是故意气我，他只不过多想吃几口糖而已。

我们常说父母要包容孩子，为此你需要先理解他们的行为。糖果能刺激大脑释放多巴胺，这是最本能的反应，而且他们理性大脑还没有开始发育，你不能要求一个孩子有“自控力”

我们总以“大人的身份”要求孩子守规矩，可孩子的很多行为，并不是“不听话”，而是“做不到”。

就像人类的大脑，在25岁才能完全发育完成。也就是说，一个孩子即使成年之后，也会做出一些你不理解的事情。一个人成长的过程中，本就充满了能力滞后，

你不理解他，就会对抗他。你理解了，才能包容他。

找到目标

有一天我正坐在电脑前，正为了文章选题抓耳挠腮。

我儿子“砰”地一下推开门，一屁股坐在我旁边，拿着小汽车喊：“爸爸！爸爸...”

以往工作时被打断，我会特别不耐烦。可那天，我关上电脑开始陪他玩，我发现自己变得很有耐心。

过了一会他自己去客厅玩了，我坐在电脑前，去想我为什么会有这种改变。

是我变得有耐心了？还是我终于佛系了？后来我想明白了——是自己的目标更明确了。

过去一被打断就恼火，其实都是因为自己都不知道要干什么。我只是模糊的觉得，自己得做点有意义的事情。

但现在写好每一篇文章就是我想做的事情，就算短暂的停下来，也没有任何影响。

心理学上有一个「自我决定理论」：真正让人持续投入的，从来不是外界的压力或奖励，而是自己选的方向。

比如说当你在街道上跑步，周围车水马龙、喧嚣嘈杂，可你根本就听不见。因为你眼中，只有即将抵达的下一个路口。目标感就像降噪耳机，能让你不被外界打扰。

但如果你没有目标呢？虽然一天什么都没干，却很容易因为工作上的催促，家人的一句话，就能让你心烦意乱。

你不是没有承受力，你可能只是没有方向而已。

尼采说：“一个人知道自己为什么而活，就可以忍受任何一种生活。”

现在看来这不是鸡汤，而是硬道理。

真正让你内心安定的，不是时间管理、情绪技巧，而是——你有没有在朝着自己认可的方向，慢慢靠近。

说在最后

最后分享一句据说是爱默生说的一段话来结尾吧。

当整个世界似乎都在暗中图谋，用琐事一次又一次侵扰你、纠缠你，当所有人都来敲你的门，并且说，“到我们这里来吧。”绝对不要动心，不要加入到他们的喧闹中。始终保有一颗自助自主的心，不受外界影响和左右，活在自己的意志里，才能够使心灵得到宁静，才会过上真正独立的生活。

以上就是我自己应对生活中一些“小麻烦”的个人心得，如果你也有面对“小麻烦”时处理情绪的技巧，欢迎在评论区分享～

这是东东拿铁的第84篇原创文章，欢迎关注。

前言

从我进入公司开始，我给自己立了一个三年成为中级前端工程师的目标，或者说flag吧，最近正好三年合同到期了，我开始思考过去的这三年我都做了什么，是否完成了flag，所以我在个人博客中增加了一个模块《项目需求》用于管理自己在生活、工作、学习过程中开发过的项目文档和思考，在整理的过程中才发现很多东西都忘记是怎么做的了，大概是只知道做，不知道为什么做吧，所以这里想写一篇文章记录下或者说获取一些建议吧。

很多人说博客和todo没啥用，开发完几乎都不会使用，我觉得看怎么用吧，我这里把项目和todo、技术文档、技术栈绑定了。编辑项目和可以和todo绑定，我觉得还挺好使，这样在整理技术文档、技术调研的时候也可以用

过去三年我都做了什么

2022年

基本情况

因为在学校的时候根本没想过这么早出社会，原本是打算走学术路线的，结果考研那年因为家里临时出了点状况，最后决定先工作再说。现在回头看也挺好的，早点接触社会，其实成长得更快。
在这一年我主要是疯狂补项目经验和疯狂加班，因为社会始终不同于学校，排期让人很头疼，在以往我缺失了很多的项目经验，导致对企业级项目几乎不通，导致我在做任何项目都比较挣扎，再加上进的是一个小厂，完全没有导师制，属于放养，并且大家都很忙，所以只能自己多花时间，并且当时我学的vue的技术栈，但是公司是react的，光是搞懂 React 那一套生态就花了不少时间。

项目经历

成长

2023年

基本情况

这个阶段已经开始逐步适应工作生活了，但是还是会畏惧需求，因为还有很多没接触过的东西，依然还是疯狂加班，不光是需求，还有自己学习一些东西，这时候我已经切换到了编辑器领域，其中涉及很多图形学知识，比如坐标转换、矩阵运算、渲染原理、渲染库的使用等等，因为公司里的人几乎不写文档，代码也是anyscript，并且这时候ai还没有，编辑器这个领域，网上几乎搜不到什么文档啥的，只能生啃代码和类型文件并尝试demo，这时候用的就是最笨却最有效的方法，做到哪就把哪个模块整理一篇文档记录下来，慢慢的也就掌握了项目的大部分逻辑和架构思路

项目经历

成长

2024年

基本情况

这时候已经对编辑器开发很熟练了，能够自己调研、处理一些模块，不会畏惧需求，拿到什么都能做也敢做，再加上ai的爆发，现在很轻松就能应付日常需求，还有一些时间开发自己的东西。这时候我几乎不用在追着别人问了，开始探究一些技术上的原理，看了react的源码，了解了react的运行原理，我最初看这个的驱动是因为我想看懂编辑器底层的数据结构和自定义渲染器的实现原理，因为是相通的。

项目经历

成长

2025年

基本情况

进入新团队后，开始参与 AI 方向的生成类产品开发。虽然整体技术难度相比之前的编辑器项目要低一些，但节奏非常快，很多需求都是边想边做，对响应能力和落地能力要求更高。项目整体强调快速迭代、快速验证，很多时候从 0 到上线都只有几天时间。

项目经历

成长

我自己写的项目

就这几个，其他的几乎都是一些不成型的demo，还有几乎都在写公司的项目

现在我是怎么想的

以后我想干啥

说实话，我现在还没完全想明白这个问题。过去几年我经历了从业务开发，到编辑器、到 AI 项目，接触了很多不同的方向，也成长了不少。但也正因为尝试了很多，现在反而更谨慎，不想轻易贴标签。

我想我还是会继续写代码，但不一定只写代码。我更在意的是：“我做的东西有没有价值？有没有可能改变点什么？”也许未来会往架构方向走，也许会继续在 AI 产品方向深入，也可能有一天突然转向一个完全不同的方向，比如做点属于自己的产品。

我目前能确定的就是三件事：

• 我希望能一直保持学习和探索的状态，不断拓宽认知边界；


• 我希望在一个让我有成长、有挑战感的环境里工作；


• 我希望做的事能让我感到值得，能有一点点“留下痕迹”的感觉。

剩下的，就边走边看吧，继续更新文章，但不会跟之前一样那么频繁，从中学到东西，并且能够帮助别人

老板： 咱们公司的设备开机，怎么显示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>