前言：这一年来我基本处于断更的状态，我知道在AI时代，编码的成本已经变得越来越低，技术分享的流量必然会下降。但这依然是一个艰难的过程，日常斥责自己没有成长，没有作品。

除了流量问题、巨量的工作，更多的原因是由于技术栈的变化。我开始使用Electron编写一个重要的AI产品，并且在 Flutter 与 Electron 之间来回拉扯......

背景

我们对 Flutter 技术的应用，不仅是在移动端APP，在我们的终端设备也用来做 OS 应用，跨Android、Windows、Linux系统。

在 Flutter 上，我们是有所沉淀的，但是当我们决定研发一款重要的PC应用时，依然产生了疑问：Flutter 这门技术，真的能满足我们在核心桌面应用的研发需求吗？

最终，基于官方能力、技术生态、roadmap等一系列原因，我们放弃在核心应用上使用 Flutter，转而代之选择了 Electron ！

这篇文章将从这几个月使用 Electron 的切实体验，从不同角度，对 Flutter 和 Electron 这两款支持跨端桌面应用开发技术，做一个详细的对比。

Flutter VS Electron

方案成熟度

毫无疑问，在方案成熟度上 Electron 是碾压 Flutter 的存在。

1. 多进程能力

• Flutter 目前还是单进程的能力，只能通过创建 isolate 来实现部分耗时任务，但是内存也是不共享的。


• Electron 集成了 Nodejs 服务，自带多进程的能力，且提供了完整的跨进程机制（IPC「Inter-Process Communication」）。

2. 多窗口支持

• Flutter 目前不支持多窗口。由于其是自绘引擎，本身还是依赖原生进程提供的桌面窗口，所以需要原生与 Flutter 引擎不断的进行沟通对接，才能很好的使用多窗口能力。
  
  目前官方只是提供了 demo 来验证多窗口的可行性，但截止发文还没有办法在公版试用。


• Electron 将 Chromium 的核心模块打包到发行包中，借助浏览器的能力，可以随意开辟新的窗口（如： BrowserWindow）

3. 开发语言

• Flutter 使用dart语言开发，采用声明式UI进行布局，插件管理使用官方的 pub 社区，学习和使用成本不算高。


• Electron 使用JavaScript/TypeScript + HTML/CSS 的前端技术栈进行开发，社区也完全跟前端一致，非常丰富但鱼龙混杂。

4. 原生能力的支持

• Flutter 本质是一个 UI 框架，原生能力需要通过编写插件去调用，或者通过 FFI 调用，成本是很高的，你很难找到一个懂多端原生技术的开发。


• Electron 有 node 环境，node.js 很多原生模块，可以直接调用到系统的能力，非常的高效。

开发体验和技术生态

1. 调试工具

• Flutter 的调试工具，主要是依赖 IDE 本身的断点调试能力，以及自研的Flutter Inspector、devTools。
  
  在UI定位、性能监控方面，基本可以满足。但由于是个 UI 框架，对于原生容器是无法进行调试的，这在混合开发过程中是个比较大的痛点。


• Electron 就是个浏览器，对于主进程和node子进程，有 Inspect 的机制； UI 层就更方便了，就是浏览器的调试器一模一样。生产环境下调试成本也低。

2. 打包编译

Flutter 是通过自绘引擎生成原生应用包，而 Electron 是将网页技术（HTML/CSS/JS）包裹在 Chromium 内核中。

底层技术架构的区别，直接决定了 Electron 的打包相对 Flutter 有些困难，且包体积很大。

3. 官方和社区的活跃性

• Flutter 官方在桌面端的推进很慢，很多基础能力都没有太多的推进。同时在 roadmap 中，重心都偏向移动端和 web 端。


• Electron 由于产品的体量和成熟度，稳定的在更新，每个版本都会带来一些新的特性。
  

4. 研发团队

可以看出，Flutter至少需要 1-2 名熟悉 Dart 的开发者，还需要有原生开发能力，技术门槛是比较高的；而 Electron 以前端开发者为主，熟悉 Node.js 即可完成所有开发，是可以快速上手的。

同时前端开发也比 Flutter 开发要更容易招聘。

结语

笔者本身是 Flutter 的忠实维护者，我认为 Flutter 的 Impeller 图形渲染引擎将不断完善，能在各个端达到更好的渲染速度和效果；同时 Flutter 目前的多窗口方案，让我们可以充分的相信可以多个窗口共用一份内存，而不需要通过进程间通信机制

但是，在 Flutter 暂未成熟的阶段，桌面核心产品还是用 Electron 进行开发会更加合适。我们 也期待未来 Electron 可以多集成WebAssembly来提升计算密集型任务的性能，减少 Chromium 内核的高内存占用。

前言：由于“无处安放”而引发的混乱

在 HTML5 普及之前，前端开发者为了在 DOM 元素上绑定一些数据（比如用户 ID、商品价格、状态码），可谓是八仙过海，各显神通：

直到 HTML5 引入了 data-*  自定义数据属性，这一切终于有了“官方标准”。

第一阶段：基础——它长什么样？

data-* 属性允许我们在标准 HTML 元素中存储额外的页面私有信息。

1. HTML 写法

语法非常简单：必须以 data- 开头，后面接上你自定义的名称。

codeHtml

<!-- ❌ 错误示范：不要大写，不要乱用特殊符号 -->

<div data-User-Id="1001"></div> 



<!-- ✅ 正确示范：全小写，连字符连接 -->

<div 

  id="user-card"

  data-id="1001" 

  data-user-name="juejin_expert" 

  data-value="99.9"

  data-is-vip="true"

>

  用户信息卡片

</div>

2. CSS 中的妙用

很多人以为 data-* 只是给 JS 用的，其实 CSS 也能完美利用它。

场景一：通过属性选择器控制样式

/* 当 data-is-vip 为 "true" 时，背景变金 */

div[data-is-vip="true"] {

  background: gold;

  border: 2px solid orange;

}

场景二：利用 attr() 显示数据

这是一个非常酷的技巧，可以用来做 Tooltip 或者计数器显示。

div::after {

  /* 直接把 data-value 的值显示在页面上 */

  content: "当前分值: " attr(data-value);

  font-size: 12px;

  color: #666;

}

第二阶段：进阶——JavaScript 如何读写？

这才是重头戏。在 JS 中操作 data-* 有两种方式：传统派 和 现代派。

1. 传统派：getAttribute / setAttribute

这是最稳妥的方法，兼容性最好（虽然现在也没人要兼容 IE6 了）。

const el = document.getElementById('user-card');



// 读取

const userId = el.getAttribute('data-id'); // "1001"



// 修改

el.setAttribute('data-value', '100');

特点：读出来永远是字符串。哪怕你存的是 100，取出来也是 "100"。

2. 现代派：dataset API (推荐 ✨)

HTML5 为每个元素提供了一个 dataset 对象（DOMStringMap），它将所有的 data-* 属性映射成了对象的属性。

这里有个大坑（或者说是规范），请务必注意：

HTML 中的 连字符命名 (kebab-case)  会自动转换为 JS 中的 小驼峰命名 (camelCase) 。

const el = document.getElementById('user-card');



// 1. 访问 data-id

console.log(el.dataset.id); // "1001"



// 2. 访问 data-user-name (注意变身了！)

console.log(el.dataset.userName); // "juejin_expert"

// ❌ el.dataset.user-name 是语法错误

// ❌ el.dataset['user-name'] 是 undefined



// 3. 修改数据

el.dataset.value = "200"; 

// HTML 会自动变成 data-value="200"



// 4. 删除数据

delete el.dataset.isVip;

// HTML 中的 data-is-vip 属性会被移除

💡 敲黑板：dataset 里的属性名不支持大写字母。如果你在 HTML 里写 data-MyValue="1", 浏览器会强制转为小写 data-myvalue，JS 里就得用 dataset.myvalue 访问。所以，HTML 里老老实实全小写吧。

第三阶段：深入——类型陷阱与性能权衡

1. 一切皆字符串

不管你赋给 dataset 什么类型的值，最终都会被转为字符串。

el.dataset.count = 100;        // HTML: data-count="100"

el.dataset.active = true;      // HTML: data-active="true"

el.dataset.config = {a: 1};    // HTML: data-config="[object Object]" -> 灾难！

避坑指南：

• 如果你要存数字，取出来时记得 Number(el.dataset.count)。


• 如果你要存布尔值，判断时不能简单用 if (el.dataset.active)，因为 "false" 字符串也是真值！要用 el.dataset.active === 'true'。


• 千万不要试图在 data-* 里存复杂的 JSON 对象。如果非要存，请使用 JSON.stringify()，但在 DOM 上挂载大量字符串数据会影响性能。

2. 性能考量

• 读写速度：dataset 的访问速度在现代浏览器中非常快，但在极高频操作下（比如每秒几千次），直接操作 JS 变量肯定比操作 DOM 快。


• 重排与重绘：修改 data-* 属性会触发 DOM 变更。如果你的 CSS 依赖属性选择器（如 div[data-status="active"]），修改属性可能会触发页面的重排（Reflow）或重绘（Repaint）。

第四阶段：实战——优雅的事件委托

data-value 最经典的用法之一就是在列表项的事件委托中。

需求：点击列表中的“删除”按钮，删除对应项。

<ul id="todo-list">

  <li>

    <span>学习 HTML5</span>

    <!-- 把 ID 藏在这里 -->

    <button class="btn-delete" data-id="101" data-action="delete">删除</button>

  </li>

  <li>

    <span>写掘金文章</span>

    <button class="btn-delete" data-id="102" data-action="delete">删除</button>

  </li>

</ul>

const list = document.getElementById('todo-list');



list.addEventListener('click', (e) => {

  // 利用 dataset 判断点击的是不是删除按钮

  const { action, id } = e.target.dataset;



  if (action === 'delete') {

    console.log(`准备删除 ID 为 ${id} 的条目`);

    // 这里发送请求或操作 DOM

    // deleteItem(id);

  }

});

为什么这么做优雅？

你不需要给每个按钮都绑定事件，也不需要去分析 DOM 结构（比如 e.target.parentNode...）来找数据。数据就在元素身上，唾手可得。

总结与“禁忌”

HTML5 的 data-* 属性是连接 DOM 和数据的一座轻量级桥梁。

什么时候用？

• 当需要把少量数据绑定到特定 UI 元素上时。


• 当 CSS 需要根据数据状态改变样式时。


• 做事件委托需要传递参数时。

什么时候别用？（禁忌）

最后一句：

代码整洁之道，始于不再乱用 Class。下次再想存个 ID，记得想起那个以 data- 开头的帅气属性。

Happy Coding! 🚀

有时候我们发了新版，结果用户看到的还是老界面。
你：“我更新了啊！”
用户：“我这儿没变啊！”
然后你俩开始互相怀疑人生。
那咋办？总不能让用户都清缓存吧？
当然不能。
我们得让浏览器自己知道“该换新的了”。
核心思路就一条：让静态资源的文件名变一变。
浏览器靠文件名判断是不是同一个文件。
文件名变了，它就会重新下载。

方法1：加时间戳（简单粗暴）

以前：

<script src="/js/app.js"></script>

现在：

<script src="/js/app.js?v=20250901"></script>

或者用时间戳：

<script src="/js/app.js?t=1725153600"></script>

发版的时候，改一下v 或t的值，浏览器看到后发现文件名不一样，就会重新下载。

优点：简单，立马见效

缺点：每次发版都得手动改，容易忘记。

方法2：用构建工具加hash（推荐！）

这是现在最主流的做法。
你用Webpack、Vite、Rollup这些工具打包时，它会自动给文件名加一串hash：

<script src="/js/app.a1b2c3d.js"></script>

你代码一改，hash就变。

比如下次变成：

<script src="/js/app.e4f5g6h.js"></script>

浏览器看到后发现文件名不一样，会自动拉新文件。

使用时需要检查你的打包配置，确保输出文件带hash。

Vite配置（vite.config.js）：

export default defineConfig({

  build: {

    rollupOptions: {

      output: {

        entryFileNames: 'assets/[name].[hash].js',

        chunkFileNames: 'assets/[name].[hash].js',

        assetFileNames: 'assets/[name].[hash].[ext]'

      }

    }

  }

})

Vue CLI（vue.config.js）：

module.exports = {

  filenameHashing: true, // 默认就是 true，别关掉！

}

只要这个开着，JS/CSS 文件名就会变，浏览器就会更新。

优点：全自动，不用操心

优点：用户无感知，体验好

优点：还能利用缓存（没改的文件hash不变，继续用旧的）

来看看Vue的项目

只要你用的是Vue CLI、Vite或 Webpack打包，发版时默认就解决了缓存问题。
因为它们会自动给文件名加hash。
比如你打包后：

dist/

├── assets/app.8a2b1f3.js

├── assets/chunk-vendors.a1b2c3d.js

└── index.html

你改了代码，再打包，hash就变了：

assets/app.x9y8z7w.js  # 新文件

虽说是这样，但为啥还有人卡在旧版本？

文件名带hash，但index.html这个入口文件本身可能被缓存了！

流程：

• index.html里引用了app.8a2b1f3.js


• 用户第一次访问，加载了index.html和对应的JS


• 你发新版，index.html指向app.x9y8z7w.js


• 但用户浏览器缓存了旧的index.html，还在引用app.8a2b1f3.js


• 结果：页面还是旧的

这是入口文件缓存导致的发版无效。

解决方案

方法1：让index.html不被缓存

这是最简单有效的办法。
配置Nginx，让index.html不缓存：

location = /index.html {

    add_header Cache-Control "no-cache, no-store, must-revalidate";

    add_header Pragma "no-cache";

    add_header Expires "0";

}

这样每次用户访问，都会重新下载最新的 index.html，自然就拿到新的 JS 文件名。

注意：其他静态资源（js/css）可以长期缓存，只有 index.html 要禁缓存。

方法2：根据版本号来控制

每一次更新都新建一个文件夹

然后修改Nginx配置

location / {

	root /home/server/html/yudao-vue3/version_1_2_5;

	index index.html index.htm;

	try_files $uri $uri/ /index.html;

}

最后：
缓存这事看着小，真出问题能让我们忙半天。
提前设好机制，发版才能睡得香。
搞定！

我是大华，专注分享前后端开发的实战笔记。关注我，少走弯路，一起进步！

📌往期精彩

《Elasticsearch 太重？来看看这个轻量级的替代品 Manticore Search》

《只会写 Mapper 就敢说会 MyBatis？面试官：原理都没懂》

《别学23种了！Java项目中最常用的6个设计模式，附案例》

《写给小公司前端的 UI 规范：别让页面丑得自己都看不下去》

《Vue3+TS设计模式：5个真实场景让你代码更优雅》

大多数前端开发者在公司里，很少需要直接操心“部署”这件事——那通常是运维或 DevOps 的工作。

但一旦回到个人项目，情况就完全不一样了。写个小博客、搭个文档站，或者搞个 demo 想给朋友看，部署往往成了最大的拦路虎。

常见的选择无非是 Vercel、Netlify 或 GitHub Pages。它们表面上“一键部署”，但细节其实并不轻松：要注册平台账号、要配置域名，还得接受平台的各种限制。国内的一些云服务商（比如阿里云、腾讯云）管控更严格，操作门槛也更高。更让人担心的是，一旦平台宕机，或者因为地区网络问题导致访问不稳定，你的项目可能随时“消失”在用户面前。虽然这种情况不常见，但始终让人心里不踏实。

很多时候，我们只是想快速上线一个小页面，不想被部署流程拖累，有没有更好的方法？

一个更轻的办法

前段时间我发现了一个开源工具 PinMe，主打的就是“极简部署”。

它的使用体验非常直接：

• 不需要服务器


• 不用注册账号


• 在项目目录敲一条命令，就能把项目打包上传到 IPFS 网络


• 很快，你就能拿到一个可访问的地址

实际用起来的感受就是一个字：爽。

整个过程几乎没有繁琐配置，不需要绑定平台账号，也不用担心流量限制或收费。

这让很多场景变得顺手：

• 临时展示一个 demo，不必折腾服务器


• 写了个静态博客，不想搞 CI/CD 流程


• 做了个活动页或 landing page，随时上线就好

以前这些需求可能要纠结“用 GitHub Pages 还是 Vercel”，现在有了 PinMe，直接一键上链就行。

体验一把

接下来看看它在真实场景下的表现：部署流程有多简化？访问速度如何？和传统方案相比有没有优势？

测试项目

为了覆盖不同体量的场景，这次我选了俩类项目来测试：

• 小型项目：fuwari（开源的个人博客项目），打包体积约 4 MB。


• 中大型项目：Soybean Admin（开源的后台管理系统），打包体积约 15 MB。

部署项目

PinMe 提供了两种方式：命令行 和 可视化界面。

这两种方式我们都来试一下。

命令行部署

先全局安装：

npm install -g pinme

然后一条命令上传：

pinme upload <folder/file-path>

比如上传 Soybean Admin，文件大小 15MB：

输入命令之后，等着就可以了：

只用了两分钟，终端返回的 URL 就能直接访问项目的控制页面。还能绑定自己的域名：

点击网站链接就可以看到已经部署好的项目，访问速度还是挺快的：

同样地，上传个人博客也是一样的流程。

部署完成：

可视化部署

不习惯命令行？PinMe 也提供了网页上传，进度条实时显示：

部署完成后会自动进入管理页面：

经过测试，部署速度和命令行几乎一致。

其他功能

历时记录

部署过的网站都能在主页的 History 查看：

历史部署记录：

也可以用命令行：

pinme list

历史部署记录：

删除网站

如果不再需要某个项目，执行以下命令即可：

pinme rm

PinMe 背后的“硬核支撑”

如果只看表层，PinMe 就像一个极简的托管工具。但要理解它为什么能做到“不依赖平台”，还得看看它背后的底层逻辑。

PinMe 的底层依赖 IPFS，这是一个去中心化的分布式文件系统。

要理解它的意义，得先聊聊“去中心化”这个概念。

传统互联网是中心化的：你访问一个网站时，浏览器会通过 DNS 找到某台服务器，然后从这台服务器获取内容。这条链路依赖强烈，一旦 DNS 被劫持、服务器宕机、服务商下线，网站就无法访问。

去中心化的思路完全不同：

• 数据不是放在单一服务器，而是分布在全球节点中


• 访问不依赖“位置”，而是通过内容哈希来检索


• 只要有节点存储这份内容，就能访问到，不怕单点故障

这意味着：

• 更稳定：即使部分节点宕机，内容依然能从其他节点获取。


• 防篡改：文件哪怕改动一个字节，对应的 CID 也会完全不同，从机制上保障了前端资源的完整性和安全性。


• 更自由：不再受制于中心化平台，文件真正由用户自己掌控。

当然，IPFS 地址（哈希）太长，不适合直接记忆和分享。这时候就需要 ENS（Ethereum Name Service）。它和 DNS 类似，但记录存储在以太坊区块链上，不可能被篡改。比如你可以把 myblog.eth 指向某个 IPFS 哈希，别人只要输入 ENS 域名就能访问，不依赖传统 DNS，自然也不会被劫持。

换句话说：

ENS + IPFS = 内容去中心化 + 域名去中心化

前端个人项目瞬间就有了更高的自由度和安全性。

一点初步感受

PinMe 并不是要取代 Vercel 这类成熟平台，但它带来了一种新的选择：更简单、更自由、更去中心化。

如果你只是想快速上线一个小项目，或者对去中心化部署感兴趣，PinMe 值得一试。

• 官网：pinme.eth.limo/


• Github：github.com/glitternetw…

这是一个完全开源的项目，开发团队也会持续更新。如果你在测试过程中有想法或需求，不妨去 GitHub 提个 Issue —— 这不仅能帮助项目成长，也能让它更贴近前端开发的实际使用场景！

最近在使用 NestJs 和 NextJs 在做一个协同文档 DocFlow，如果感兴趣，欢迎 star，有任何疑问，欢迎加我微信进行咨询 yunmz777

老实说，我对 Tailwind CSS 的看法有些复杂。它像是一个总是表现完美的朋友，让我觉得自己有些不够好。
我一直是纯 CSS 的拥护者，直到最近，我才意识到，Tailwind 也有其独特的优点。
然而，虽然我不喜欢 Tailwind 的一些方面，但它无疑为开发带来了更多的选择，让我反思自己做决定的方式。

问题

大家争论的，不是 "哪个更好"，而是“哪个让你觉得更少痛苦”。
对我来说，Tailwind 有时带来的是压力。比如：

<button

  class="bg-blue-500 hover:bg-blue-700 text-white font-bold py-2 px-4 rounded-lg shadow-md hover:shadow-lg transition duration-300 ease-in-out transform hover:-translate-y-1"

>

  Click me

</button>

它让我想：“这已经不再是简单的 HTML，而是样式类的拼凑。”
而纯 CSS 则让我感到平静、整洁：

.button {

  background-color: #3b82f6;

  color: white;

  font-weight: bold;

  padding: 0.5rem 1rem;

  border-radius: 0.5rem;

  box-shadow: 0 4px 6px rgba(0, 0, 0, 0.1);

  transition: all 0.3s ease-in-out;

}

.button:hover {

  background-color: #2563eb;

  box-shadow: 0 10px 15px rgba(0, 0, 0, 0.1);

  transform: translateY(-4px);

}

纯 CSS 让我觉得自己在“写代码”，而不是“编排类名”。

背景说明

为什么要写这篇文章呢？因为到了 2026 年，CSS 和 Tailwind 的争论已经不再那么重要。

• Tailwind 发布了  v4，速度和性能都大大提升。


• 纯 CSS 也在复兴，容器查询（container queries）、CSS 嵌套（nesting）和 Cascade Layers 这些新特性令人振奋。


• 还有像 Panda CSS、UnoCSS 等新兴工具在不断尝试解决同样的问题。
  这让选择变得更加复杂，也让开发变得更加“累”。

Tailwind 的优缺点

优点：

缺点：

纯 CSS 的优缺点

优点：

缺点：

到 2026 年，你该用哪个？

Tailwind 适合：

• 使用 React、Vue 或 Svelte 等组件化框架的开发者


• 需要快速开发并保证一致性的团队


• 不介意添加构建步骤并依赖工具链的人

纯 CSS 适合：

• 小型项目或静态页面


• 喜欢简洁代码、分离 HTML 和 CSS 的开发者


• 想要完全掌控样式并避免复杂构建步骤的人

两者结合：

• 你可以在简单的页面中使用纯 CSS，在复杂的项目中使用 Tailwind 或两者结合，以此来平衡灵活性与效率。

真正值得关注的 2026 年趋势

• 容器查询：响应式设计不再依赖视口尺寸，而是根据容器的尺寸进行调整。


• CSS 嵌套原生支持：你可以直接在 CSS 中使用嵌套，避免了依赖预处理器。


• Cascade Layers：这让你能更好地管理 CSS 优先级，避免使用 !important 来解决冲突。


• View Transitions API：它让页面过渡更平滑，无需依赖 JavaScript。

这些新特性将极大改善我们的开发体验，无论是使用纯 CSS 还是借助 Tailwind。

结尾

不管是 Tailwind 还是纯 CSS，都有它们的优缺点。关键是要根据项目需求和个人偏好做出选择。
至于我：我喜欢纯 CSS，因为它更干净，HTML 更直观。但是如果项目需求更适合 Tailwind，那我也会使用它。
2026 年的开发趋势，将让我们有更多选择，让我们能够用最适合的工具解决问题，而不是纠结于某种工具是否“最好”。

辛苦写了3天的代码，突然一下，全部消失了

我说我每次都git add .了，但是他就是消失了

你会相信我吗

这次真的跳进黄河都洗不清，六月都要飞雪了

一个安静的夜晚，主包正在和往常一样敲着代码，最后一个优化完成以后执行了git add .

看着长长的暂存区，主包想是时候git commit -m了

变故就发生在一瞬间，commit校验返回失败，伴随着电脑的终端闪烁了一下，主包的 所 有 改 动都消失了，文件内容停留在上次的提交...

老板，你相信我吗？我真的干活了

不过幸好，我的Gemini在我的指导下一步一步帮我把3天的劳动成果还原了，下面记录一下整个事件过程

首先。我已经执行了 git add .，这意味着 Git 已经将这些文件的内容以「blob 对象」的形式保存到本地 .git/objects 目录中，这些数据就不会凭空消失。

解决步骤

第一步：不要乱动

立即停止在仓库中执行任何覆写的操作！避免覆盖磁盘上的 blob 对象

• ❌ 不要执行 git reset --hard/git clean -fd/git gc/git prune；


• ❌ 不要往仓库目录写入新文件

第二步：检查 Git 状态

git status查看当前暂存区的状态，如果暂存区有文件的话可以通过get checkout -- .进行恢复，可是我没有了，我的暂存区和我的脑袋一样空空

第三步：拉取悬空文件

如果 git status 显示「Working Tree Clean」，且 git checkout -- . 没效果，说明暂存区被清空，但 Git 仍保存了 git add 时的 blob 对象
需通过 git fsck --lost-fond 找回

该指令会扫描 .git/objects/ 目录，找出所有没有被任何分支/标签引用的对象，列出 悬空的 commits、blobs、trees（优先找最新的commit）

第四步：验证每个commit

执行 git show --stat <commit ID> 可以验证该悬空 commit 内容

• 如果「提交信息 / 时间 / 作者」匹配你刚才中断的 commit → 这就是包含你所有改动的快照；


• 如果显示 initial commit 或旧提交信息 → 这是历史悬空 commit，换列表里下一个时间最新的 commit ID 重试。

• 这里会列出该 commit 中所有改动的文件路径 + 行数变化 → 如果能看到你丢失的文件（如 src/App.js），说明找对了；


• 如果显示 0 files changed → 这个 commit 是空的，换其他 commit ID 重试。

第五步：恢复提交

方式 1：仅恢复文件到工作区（推荐，不修改 HEAD）

git checkout commitId -- .

方式 2：#### 直接将 HEAD 指向该 commit（完成提交）

    git reset --hard commitId // 等同于完成当时的 commit 操作

到这里基本就已经恢复了，可以check一下更改的文件，如果不全可以继续执行checkout进行恢复，如果已经完成了就尽快commit以防发生别的变故啦～

最后，还是简单讲解一下为什么优先恢复悬空commit，commit、tree、Blob的区别

核心结论先摆清楚

一、逐个拆解：悬空 blob/commit/tree 到底是什么？

Git 仓库的所有内容（文件、目录、提交记录）最终都会被存储为「对象」，存放在 .git/objects 目录下；「悬空」意味着这些对象没有被任何分支 / 标签 / HEAD 引用（比如 commit 中断、reset 后、删除分支等），但只要没执行 git gc（垃圾回收），就不会消失。

1. 悬空 Blob（数据对象）—— 「只存内容，不管路径」

• 本质：Git 中最小的存储单元，仅保存「单个文件的原始内容」，不包含文件名、路径、修改时间等信息；


• 举例：你修改了 src/App.js 并执行 git add .，Git 会把 App.js 的内容打包成一个 blob 对象（比如你看到的 ec0529e46516594593b1befb48740956c8758884），存到 .git/objects 里；


• 悬空原因：执行 git add 后生成了 blob，但 commit 中断 / 执行 git reset 清空暂存区，导致这个 blob 没有被 tree/commit 引用；


• 恢复特点：能拿到文件内容，但不知道原文件路径（比如你只知道 blob 是一段 JS 代码，却不知道它原本是 src/App.js 还是 src/Page.js）。

2. 悬空 Tree（树对象）—— 「只存目录结构，不存内容」

• 本质：描述「目录层级 + 文件映射关系」，相当于「文件路径 ↔ blob ID」的对照表，也能包含子 tree（对应子目录）；


• 举例：一个 tree 对象可能记录：
  
  

  src/ (子tree) → tree ID: bb0065eb...
  
  package.json → blob ID: e90a82fe...
  
  src/App.js → blob ID: ec0529e4...
  
  

  
  


• 悬空原因：Tree 是 commit 的「子对象」，如果 commit 变成悬空（比如 reset 后），对应的 tree 也会悬空；


• 恢复特点：仅能看到「哪些 blob 对应哪些路径」，但本身不存储文件内容，需结合 blob 才能恢复完整文件。

3. 悬空 Commit（提交对象）—— 「完整的提交快照」

• 本质：Git 中最高级的对象，是「一次提交的完整记录」，包含：
  
  
  
  
  • 指向一个 root tree（根目录的 tree 对象）→ 能拿到整个项目的目录结构 + 所有 blob；
  
  
  • 作者、提交时间、提交信息；
  
  
  • 父 commit ID（如果是后续提交）；
  
  
  
  


• 举例：你执行 git commit -m "修改App.js" 时，Git 会生成一个 commit 对象，关联 root tree（包含所有文件路径 + blob），记录你的操作信息；


• 悬空原因：commit 执行中断、git reset --hard 后原 HEAD 指向的 commit 无引用、删除分支后分支上的 commit 无引用；


• 恢复特点：✅ 最优选择！通过一个 commit 对象，能一键恢复「该提交时刻的所有文件（路径 + 内容）」，不用手动匹配 blob 和路径。

二、为什么你该优先恢复「悬空 Commit」？

你之前执行了 git add . + 尝试 git commit，大概率 Git 已经生成了 commit 对象（只是没被 HEAD 引用，变成悬空）—— 恢复 commit 有 2 个核心优势：

三、实操场景：不同悬空对象该怎么用？

场景 1：有可用的悬空 Commit（优先选）

# 1. 找时间最新的悬空 commit

git fsck --lost-found | grep 'dangling commit' | awk '{print $3}' | while read c; do

  echo "$c | $(git log -1 --format='%ai' $c)"

done | sort -k2 -r



# 2. 验证该 commit 包含你的文件

git show --stat <最新的commit ID>



# 3. 一键恢复所有文件到工作区

git checkout <commit ID> -- .

场景 2：只有悬空 Blob/Tree（无可用 Commit）

# 1. 先通过 tree 找「blob ID ↔ 文件路径」的映射

git ls-tree -r <tree ID>  # 列出该 tree 下的所有文件路径+blob ID



# 2. 按路径恢复 blob 内容

git cat-file -p <blob ID> > <原文件路径>  # 比如 git cat-file -p ec0529e4 > src/App.js

场景 3：只有悬空 Blob（无 Tree/Commit）

只能批量导出 blob，通过内容匹配原文件：

mkdir -p recover

for blob in $(git fsck --lost-found | grep 'dangling blob' | awk '{print $3}'); do

  git cat-file -p $blob > recover/$blob

  # 自动补文件后缀（如 .js/.json）

  file_type=$(file -b --mime-type recover/$blob | awk -F '/' '{print $2}')

  [ "$file_type" != "octet-stream" ] && mv recover/$blob recover/$blob.$file_type

done

四、关键提醒：避免悬空对象被清理

Git 的 git gc（垃圾回收）默认会清理「超过 14 天的悬空对象」，所以恢复前务必：

总结来说：优先找悬空 Commit（一键恢复）→ 其次用 Tree 匹配 Blob 路径 → 最后批量导出 Blob 手动匹配，这是最高效的恢复路径

引言

2025年了，想搭个博客，在Hugo、Hexo、Astro之间纠结了一周，还是不知道选哪个？

我完全理解这种感受。去年我也在这几个博客框架之间来回折腾,看了无数对比文章，最后发现大部分都是2022-2023年的过时内容。性能数据变了、框架更新了、生态也不一样了。每次看完一篇文章就更纠结，到底该听谁的？

更让人崩溃的是，深夜折腾博客配置，第二天还要上班。花了三个月研究框架，结果一篇文章都没写出来。这种感觉，相信你也经历过。

这篇文章基于2024-2025年最新数据，用真实的构建时间测试、实际的使用体验，帮你在5分钟内做出最适合的选择。不是告诉你"哪个最好"，而是"哪个最适合你"。

我会用9大框架的最新性能对比、3分钟决策矩阵，帮你避免90%新手会踩的坑。说实话，早点看到这篇文章，我能省好几周时间。

为什么2025年还在聊博客框架？

静态博客真的还有必要吗？

老实讲，我一开始也觉得搭博客是个过时的想法。但用了一年多，真香。

静态博客和WordPress这类动态博客的本质区别，就是"提前做好"和"现场制作"的区别。静态网站生成器（SSG）会在你写完文章后，就把所有页面生成好，像做批量打印一样。访客来了直接看成品，速度飞快。WordPress这类动态博客呢，每次有人访问就现场从数据库拉数据、拼装页面，就像现场手工做菜。

为什么静态博客成为主流趋势？

说白了就是：快、便宜、不用操心服务器。

WordPress需要租服务器，一个月怎么也得几十块钱起步。静态博客呢？GitHub Pages、Vercel、Cloudflare Pages全都免费托管。我现在博客一年花费0元，连域名都是之前买的。

性能上更没得比。静态页面的Lighthouse评分能轻松拿到95+，WordPress想到90分都费劲。用户打开页面，一眨眼就加载完了，这种体验真的会让人爱上写博客。

那什么时候该选动态博客？

也不是说静态博客就天下无敌。如果你要做复杂的功能，比如：

• 多人协作发布（需要后台管理）


• 电商集成（要处理支付、订单）


• 复杂的用户系统（评论、权限管理）

这些场景，WordPress或者Ghost确实更合适。但老实说，大部分个人博客和技术博客，真用不到这些。

一句话总结：个人博客、技术文档、作品展示，选静态博客框架准没错。需要复杂功能、多人协作，才考虑动态博客。

性能对决 - 谁是速度之王？

性能这块，说实话是我最关心的。刚开始用Gatsby的时候，每次改一点内容，重新构建等十几分钟，真的想砸电脑。

构建速度：差距大到惊人

先说结论：Hugo是速度之王，没有之一。

看看这组2024年的实测数据：

| 框架 | 构建10000页用时 | 平均每页速度 |

|------|----------------|-------------|

| Hugo | 2.95秒 | <1ms |

| Hexo | 45秒（1000页） | ~45ms |

| Jekyll | 187.15秒 | ~18ms |

| Gatsby | 30分钟+ | ~180ms |

第一次看到Hugo的构建速度，真的惊到我了。10000篇文章，不到3秒！这意味着啥？你改个标题、修个错别字，按个保存，页面刷新，博客就更新完了。这种即时反馈，爽到飞起。

Hexo呢，中型博客（100-1000文章）表现也挺不错。我之前300篇文章的博客，15秒就构建完成，完全够用。

Gatsby...嗯，别提了。我用它做过一个项目，200多篇文章，每次构建5分钟起步。后来文章多了，直接放弃了。

页面加载速度：Astro异军突起

2024年Astro成了最大黑马。根据HTTP Archive的数据：

• Astro：中位传输大小889KB（最轻）


• Hugo：1,174KB（平衡不错）


• Next.js：1,659KB（功能多，体积大）

Astro的"零JavaScript默认"策略真的厉害。页面只加载必要的JS，不像其他框架，把整个React/Vue库都塞给用户。结果就是，页面打开速度飞快，用户体验特别好。

实际项目表现：别只看数字

老实讲，如果你博客不到100篇文章，选啥框架都差不多。几秒和十几秒的区别，你感受不出来。

但如果你计划长期写作，文章会越来越多，提前选个性能好的框架，能省很多麻烦。我见过太多人，开始用了Gatsby，写到500篇文章，构建慢到受不了，迁移框架，那个痛苦...

推荐组合：

• 小型博客（<100文章）：随便选，都够用


• 中型博客（100-1000文章）：Hugo、Hexo、Astro


• 大型站点（1000+文章）：闭眼选Hugo

开发体验 - 哪个最好用？

性能再好，用起来糟心，也是白搭。

学习曲线：新手别踩坑

说实话，Hugo的Go模板语法，我当初学了好久才上手。那些{{ range }}、{{ with }}的语法，刚开始真的看懵了。虽然性能无敌，但新手上来就选Hugo，可能会被劝退。

新手友好度排名：

我的建议：如果你和我一样是Node.js开发者，Hexo真的是顺手。装个npm包，改改配置，半小时搞定。前端技术栈是React？那Astro或Next.js更合适。别纠结了，新手就选Hexo，错不了。

配置和自定制：平衡艺术

Hexo和Jekyll的配置简单直接，一个YAML文件搞定。但也有缺点：想做复杂定制，就得深入源码改，不太灵活。

Gatsby的灵活性确实强，GraphQL数据层可以接各种数据源。但坦白说，个人博客真用不到那么复杂的功能。就像买了辆跑车在市区开，性能过剩了。

Astro走了个中间路线，既灵活又不复杂。支持多框架（React、Vue、Svelte随便混），但配置没那么吓人。这种平衡感，我挺喜欢的。

开发工具和调试

现代框架在开发体验上真的吊打老框架。

Vite驱动的Astro和VuePress，热重载快到飞起。改个内容，不到1秒页面就更新了。Webpack那套老架构，等待时间能让人发呆。

Hugo虽然是传统框架，但速度快，改完刷新也很即时。这点体验还不错。

生态系统 - 主题与插件谁更丰富？

框架再好，没主题也白搭。谁想从零开始写CSS啊。

主题生态：Hexo中文世界称王

Hexo真的是中文博客的天选之子。200+中文主题，风格各异，总有一款适合你。我用的那个主题，中文文档详细到连怎么改字体颜色都写得清清楚楚。

Hugo主题虽然有300+，但质量参差不齐。有些特别精美，有些就是demo级别。很多主题文档是英文的，踩坑全靠自己摸索。

Jekyll作为老牌框架，主题数量最多，但很多都是好几年前的设计风格了，看着有点过时。

Gatsby和Astro的主题，走的是现代化路线，设计感很强。如果你追求视觉效果，这两个不错。

插件和扩展能力

Jekyll的插件生态最庞大，毕竟历史最久。想要啥功能，基本都能找到插件。

Gatsby依托npm生态，插件也超级丰富。但很多插件其实是为商业项目设计的，个人博客可能用不上。

Hexo插件生态在Node.js圈很成熟，常用的评论、搜索、SEO优化，都有现成插件。我装了七八个插件，没遇到过兼容问题。

社区活跃度：看数据说话

2024-2025年的数据挺有意思：

• Astro：增长最快，npm下载量2024年9月达到300万。Netlify调查显示，它是2024年开发者关注度最高的框架。


• Hugo：GitHub星标6万+，稳定增长，老牌强者。


• Hexo：中文社区最活跃，知乎、掘金、CSDN到处都是教程。

说实话，社区活跃度对新手很重要。遇到问题，能搜到中文解决方案，省太多时间了。

部署与SEO - 上线才是王道

博客搭好了，不上线有啥用？

部署平台：全都免费真香

现在部署静态博客，真的太简单了。

GitHub Pages：Jekyll原生支持，push代码就自动部署。其他框架需要配个GitHub Actions，也就多写几行配置，5分钟搞定。

Vercel/Netlify：这俩是我最推荐的。拖个仓库进去，自动识别框架，自动构建部署。都有免费额度，个人博客完全够用。我现在用的Vercel，一年没花过一分钱。

Cloudflare Pages：性能特别好，CDN全球分布。免费额度也很大，速度比GitHub Pages快不少。

老实讲，2025年部署静态博客，已经没有技术门槛了。真的，比你想象的简单。

SEO：静态博客天生优势

所有静态博客框架，SEO都友好。为啥？生成的都是纯HTML，搜索引擎最爱这个。

区别在于细节：

• Hugo和Jekyll：成熟稳定，sitemap、RSS自动生成，SEO基础功能齐全。


• Astro和Next.js：在现代SEO实践上更领先，支持更细致的元数据管理，结构化数据也更方便。


• Hexo：通过插件实现SEO功能，也挺完善，中文SEO教程多。

说白了，只要你写好内容、优化好关键词、页面结构合理，用哪个框架SEO都不会差。别太纠结这个。

长期维护成本：别选冷门框架

这个坑我踩过。之前用过一个小众框架，开始挺好，半年后发现作者不更新了。后来依赖库升级，博客直接跑不起来，迁移框架花了整整一周。

低维护框架：Hugo、Jekyll。成熟稳定，基本不会出幺蛾子。我Hugo博客跑了一年多，一次问题都没遇到。

需要关注更新：Gatsby、Next.js。依赖多，更新频繁，偶尔会遇到breaking changes。如果你不想经常折腾，慎选。

平衡选手：Astro、Hexo。更新有节制，兼容性做得不错。

决策框架 - 如何选择最适合你的？

好了，前面说了这么多数据和对比，到底该怎么选？

3分钟快速决策矩阵

别想太多，回答三个问题：

问题1：你的技术栈是什么？

• 熟悉Node.js → Hexo（新手）/ Astro（追求现代化）


• React开发者 → Gatsby（重型）/ Astro（轻量）/ Next.js（全栈）


• Vue开发者 → VuePress（博客+文档）/ Gridsome


• 技术栈不限 → Hugo（性能第一）/ Jekyll（求稳）

如果你和我一样是Node.js开发者，Hexo真的顺手。装个npm包，改改配置，半小时搞定。

问题2：你的项目规模是多大？

• <100文章 → 随便选，性能差异你感受不出来


• 100-1000文章 → Hugo（快）/ Hexo（够用）/ Astro（现代）


• 1000+文章或大型文档站 → Hugo（一骑绝尘，没得比）

我现在500多篇文章，用的Hexo，45秒构建完成，完全够用。如果文章继续增长到1000+，可能会换Hugo。

问题3：你的经验水平如何？

• 新手 → Hexo（中文资源多）/ Jekyll（文档友好）


• 前端开发者 → Astro（现代化体验）/ VuePress（Vue技术栈）


• 性能极客 → Hugo（速度无敌，值得学Go模板）


• 求稳用户 → Jekyll（GitHub原生支持，最省心）

典型场景具体推荐

个人技术博客：

• 中文用户：Hexo（生态强，主题多）


• 国际化：Hugo（性能好，英文资源丰富）


• 追求现代化：Astro（体验好，性能也不错）

技术文档站点：

• Docusaurus（Facebook出品，专为文档设计）


• VuePress（Vue生态，中文支持好）

大型内容站点：

• Hugo（1000+页面，只有它能扛住）

现代化项目网站：

• Astro（灵活性+性能的最佳平衡）


• Next.js（需要动态功能时选它）

我的真实建议

说实话，别再纠结了。我见过太多人花三个月研究框架，一篇文章没写。框架真的只是工具，内容才是核心。

选择建议：

• 90%的人：选Hexo或Hugo，够用了


• 前端开发者：Astro值得尝试，体验很现代


• 新手怕选错：Hexo，中文教程多到看不完，遇到问题都能搜到答案


• 性能焦虑症患者：闭眼选Hugo，速度真的无敌

记住：框架可以迁移（内容都是Markdown，搬家成本不高），但荒废的时间回不来。先选一个动起来，边用边优化，这才是正道。

避坑指南与最佳实践

最后说说那些大坑，我替你踩过了。

5个常见错误

错误1：过度追求完美框架，迟迟不开始

这个坑我踩得最深。当年对比了两个月框架，看了几十篇文章，结果还是不确定。后来一个前辈跟我说："先选一个动起来，框架不满意可以换，但浪费的时间回不来。"

说白了，内容才是博客的核心，框架只是工具。没有完美的框架，只有最适合当下的选择。

错误2：只看主题外观，忽略框架本质

看到某个Hugo主题特别炫酷，就选了Hugo。结果发现Go模板语法学不会，自定义主题难如登天。最后用了半年，还是换回Hexo。

主题可以定制、可以换，但框架的性能、生态、维护性，这些本质特性才是长期影响你的因素。

错误3：新手直接上Gatsby/Next.js被劝退

我一朋友，刚学前端，听说Gatsby牛逼，直接上手。结果GraphQL不会、React不熟、配置看不懂，折腾两周直接放弃了。

老实说，Gatsby和Next.js真的不适合新手。它们是给有经验的开发者准备的工具。新手想快速上线博客，Hexo或Jekyll才是正确选择。

错误4：忽略长期维护成本

选了个冷门框架，一开始挺好，半年后作者不更新了。依赖库升级，博客跑不起来。迁移框架，痛苦得要死。

看框架选择的三个指标：

• GitHub更新频率（至少每月有commit）


• 社区规模（遇到问题能找到人问）


• 中文资源（新手必看，能省80%时间）

错误5：花80%时间折腾框架，20%写内容

我见过太多人，陷入"完美主义陷阱"。CSS改来改去、插件装了卸卸了装，就是不写文章。

记住80/20法则：80%精力写内容，20%折腾框架。够用就好，别追求极致完美。

框架迁移建议

万一真选错了，想换框架怎么办？

其实没那么可怕。所有静态博客框架，内容都是Markdown，迁移成本不高。我从Hexo迁移到Hugo，内容迁移只花了1小时。主要是配置和主题要重新搞，但也就半天时间。

迁移原则：

• 先有后优：快速上线 > 完美配置


• 内容优先：写够50篇文章再考虑迁移，不然没必要


• 不影响SEO：做好301重定向，URL结构尽量保持一致

2025年趋势展望

根据2024-2025的数据和社区动向，我预测：

• Astro会继续增长：岛屿架构是未来趋势，零JavaScript默认太香了


• Hugo保持性能王者地位：大型站点没得选


• Hexo中文生态持续稳定：中文博客的首选不会变


• 传统框架逐步被取代：Jekyll虽然稳定，但新项目会越来越少

但说实话，趋势只是参考。选框架还是要看自己的需求和技术栈。

结论

回到最开始的问题：2025年博客框架该怎么选？

一句话总结：

• 新手首选：Hexo（中文资源丰富，主题多，上手快）


• 前端开发者：Astro（性能+灵活性的最佳平衡，现代化体验）


• 性能极客：Hugo（速度无敌，适合大型站点）


• 文档站点：Docusaurus/VuePress（专为文档设计）


• 求稳：Jekyll（GitHub原生支持，最省心）

但老实讲，选择框架只需要5分钟，写好内容需要一辈子。

别再纠结了。选一个顺手的，开始行动吧。写第一篇文章，比研究框架重要一百倍。

我当初纠结了两个月，现在回头看，那段时间完全是浪费。早点开始写，现在可能已经有200篇文章了。

行动建议：

记住：框架不重要，内容才重要。够用就好，专注写作。

评论区说说你的选择和理由？我很好奇大家最后都选了什么。如果有问题，我会尽量回复的。

本文首发自个人博客

在经济下行的大背景下，越来越多的中小型企业开始放弃“前后端分离”的人员配置，开始采用“全栈式开发”的模式来进行研发费用的节省。

这方法真那么好吗？

作为一名从“全栈开发”自我阉割成“前端开发”的逆行研发，我有很多话想说。

先从一个活生生的真实案例开始吧。

我认识一个非常优秀的全栈开发，因为名字最后一个字是阳，所以被大家称为“阳神”。

1. “阳神”的“神狗二相性”

阳神当然是牛逼的。

他不仅精通后端开发，更是对前端了解的非常深。这样来说吧:

当他作为后端开发时，他可以是那群后端同事里库表设计最清晰，代码最规范，效率最高的后端。

当他作为前端开发时，他除了比几位高级别前端稍逊一点外，效率和UI还原性都非常高，还会主动封装组件减少耦合。

但是非常奇怪的事情总是会发生，因为一旦阳神不是全职的“后端”或者“前端”时，一旦让他同时操刀“后端+前端”开发任务，作为一名“全栈”来进行业务推进时，他的表现会让人感到惊讶：

他会写出设计糟糕，不规范，职责混乱的代码。

这个现象我把他戏称为“阳神”的“神狗二相性”，作为单一职责时他是“阳神”，同时兼任多职时，他就有非常大的可能降格为“阳狗”。

为什么呢？这是阳神主观上让自己写更糟糕的代码吗？

不是的兄弟，不是的。

这是系统性的崩塌，几乎不以人的意志为转移。换我去也是一样，换你去也是一样。

2. 分工粗化必然导致技术细节的差异

从前，在软件开发的古老行会里，一个学徒需要花很多年才能出师，专门做一把椅子，或者专门雕一朵花。现在，你被要求从伐木到抛光，从结构力学到表面美学，全部一手包办。

生产力在发展，对人的技能要求也在发展。

因此“分工细化”成为了工业革命之后完全不可逆的趋势。

在 IT 产业上也是如此。

“软件开发”经过多年被细化出了前端开发、后端开发、客户端开发、大数据开发 等等多种不同的细分职业。

但是现在有人想通过 粗化 职业分功来达到 “提效” 的目的，在我眼中这就是和客观规律对着干。

人的精力是守恒的。当你需要同时关心useEffect的依赖数组会不会导致无限渲染，和kubectl的配置能不能正确拉起Pod时，你的注意力就被稀释了。你不再有那种“针对一个领域，往深里钻，钻到冒油”的奢侈。

当你脑袋里冒出了一个关于前端工程化优化的问题时，身为全栈的你会本能地冒出另一个念头：

在整个全栈体系内，前端工程化优化是多么边角料且无关痛痒的问题啊，我去深入研究和解决它的性价比实在太低了，算了不想了。

如此一来，无论是后端的性能问题还是前端的性能问题都会变得无关紧要。

结果是，只有业务问题是全栈开发要关心的问题。

2. “岗位对立”与“自我妥协”

在日常开发中，前端开发和后端开发之间互相吐槽争论是再正常不过的话题，而且争论的核心非常简单易懂：

前端：这事儿不能在后端做吗？

后端：这事儿前端不能做吗？

可以的，兄弟，最后你会发现都是可以的，代码里大部分的事情无论是在浏览器端完成还是在服务器里完成都是可行的。

但是，总有一个“哪方更适合做”吧？

• 一个大屏页面的几万几十万条的数据统计，是应该后端做还是前端做？


• 业务数据到Echarts展示数据的格式转换应该后端做还是前端做？


• 用户数据权限的过滤应该后端做还是前端做？


• 一个列表到底要做真分页还是假分页？


• 列表已经返回了全量实体信息，为什么还要再增加一个详情接口？

这都是日常开发时前端和后端都会去争论思考的问题，身处不同的职位，就会引入不同的立场和思考。

• 前端需要去思考页面刷新后状态的留存，js单线程下大量数据处理的卡顿，页面dom树爆表的困境。


• 后端也需要思考并发下服务器资源和内存的分配，可能的死锁问题，以及用户的无状态token如何处理等。

前后端的“争吵”和观点输出是不可避免的。

真理总是越辩越清晰的，后续讨论出的结果多半是最有利于当前现状的。

但如果“前后端”都是同一个人呢？

全栈模式，完美地消灭了这种“有益的摩擦”。当你自己和自己联调时，你不会给自己提挑战灵魂的问题。你不会问：“这个API设计是否RESTful？”因为你赶时间。你也不会纠结：“这个组件的可访问性够好吗？”因为你还得去部署服务器。

这两种思想在你的大脑里打架，最终往往不是最优解胜出，而是最省事的那个方案活了下来。

于是，你的代码里充满了“差不多就行”的妥协。这种妥协，一两个无所谓，当成百上千个“差不多”堆积起来时，质量的基础就酥了。

内部摩擦的消失，使得代码在诞生之初就缺少了一道质量校验的工序。它顺滑地流向生产环境，然后，在某个深夜，轰然引爆。

3. 工程的“不可能三角”

软件开发领域有一个著名的“不可能三角”：

快、好、省，你只能选两样。

全栈模式，在管理者眼中，完美地实现了“省”（一个人干两个人的活）和“快”（省去沟通成本）。那么，被牺牲掉的是谁？

雪崩时，没有一片雪花是无辜的。但更重要的是，当结构性雪崩发生时，问责任何一片雪花，都意义不大。

至于“快、好、省”这三兄弟怎么选？

那主要看老板的认知和他的钱包了。

做前端项目的时候，经常听到"静态资源要放CDN"这种说法：

• CDN到底是什么，为什么能加速？


• 用户访问CDN的时候发生了什么？


• 前端项目怎么配置CDN？

先说结论

CDN（Content Delivery Network）的核心原理：把内容缓存到离用户最近的服务器上。

没有CDN时，北京用户访问美国服务器，数据要跨越太平洋。有了CDN，数据从北京的CDN节点返回，快得多。

flowchart LR

    subgraph 没有CDN

        U1[北京用户] -->|跨越太平洋| S1[美国服务器]

    end



    subgraph 有CDN

        U2[北京用户] -->|就近访问| C2[北京CDN节点]

        C2 -.->|首次回源| S2[美国服务器]

    end

CDN的工作流程

当用户访问一个CDN加速的资源时，会经过这几步：

1. DNS解析

用户访问 cdn.example.com，DNS会返回离用户最近的CDN节点IP。

# 在北京查询

$ dig cdn.example.com

;; ANSWER SECTION:

cdn.example.com.    60    IN    A    101.37.27.xxx  # 北京节点



# 在上海查询

$ dig cdn.example.com

;; ANSWER SECTION:

cdn.example.com.    60    IN    A    47.100.99.xxx  # 上海节点

同一个域名，不同地区解析出不同IP，这就是CDN的智能调度。

2. 缓存判断

请求到达CDN节点后，节点检查本地是否有缓存：

• 缓存命中：直接返回，速度最快


• 缓存未命中：向源服务器获取，然后缓存起来

flowchart TD

    A[用户请求] --> B[CDN边缘节点]

    B --> C{本地有缓存?}

    C -->|有| D[直接返回]

    C -->|没有| E[回源获取]

    E --> F[源服务器]

    F --> G[返回内容]

    G --> H[缓存到边缘节点]

    H --> D



    classDef hit fill:#d4edda,stroke:#28a745,color:#155724

    classDef miss fill:#fff3cd,stroke:#ffc107,color:#856404

    class D hit

    class E,F,G,H miss

3. 缓存策略

CDN根据HTTP头决定怎么缓存：

# 典型的静态资源响应头

Cache-Control: public, max-age=31536000

ETag: "abc123"

Last-Modified: Wed, 21 Oct 2024 07:28:00 GMT

• max-age=31536000：缓存1年


• public：允许CDN缓存


• ETag：文件指纹，用于验证缓存是否过期

为什么CDN能加速

1. 物理距离更近

光在光纤中的传播速度约为 20 万公里/秒。北京到美国往返 2 万公里，光传输就要 100ms。

CDN把内容放到离用户近的地方，这个延迟几乎可以忽略。

2. 分散服务器压力

没有CDN，所有请求都打到源服务器。有了CDN，只有第一次请求（缓存未命中）才需要回源。

假设一张图片被访问 100 万次：

• 没有CDN：源服务器处理 100 万次请求


• 有CDN：源服务器只处理几十次（各节点首次回源）

3. 边缘节点优化

CDN服务商的边缘节点通常有这些优化：

• 自动压缩：Gzip/Brotli压缩


• 协议优化：HTTP/2、HTTP/3


• 连接复用：Keep-Alive连接池


• 智能路由：选择最优网络路径

前端项目配置CDN

1. 构建配置

以Vite为例，配置静态资源的CDN地址：

// vite.config.js

export default defineConfig({

  base: process.env.NODE_ENV === 'production'

    ? 'https://cdn.example.com/'

    : '/',

  build: {

    rollupOptions: {

      output: {

        // 文件名带hash，便于长期缓存

        entryFileNames: 'js/[name].[hash].js',

        chunkFileNames: 'js/[name].[hash].js',

        assetFileNames: 'assets/[name].[hash].[ext]'

      }

    }

  }

})

Webpack配置类似：

// webpack.config.js

module.exports = {

  output: {

    publicPath: process.env.NODE_ENV === 'production'

      ? 'https://cdn.example.com/'

      : '/',

    filename: 'js/[name].[contenthash].js',

  }

}

2. 上传到CDN

构建完成后，把dist目录的文件上传到CDN。大多数CDN服务商都提供CLI工具或API：

# 阿里云OSS + CDN

aliyun oss cp -r ./dist oss://your-bucket/



# AWS S3 + CloudFront

aws s3 sync ./dist s3://your-bucket/



# 七牛云

qshell qupload2 --src-dir=./dist --bucket=your-bucket

3. 缓存策略配置

关键是区分两类文件：

带hash的静态资源（JS、CSS、图片）：长期缓存

location ~* \.(js|css|png|jpg|jpeg|gif|ico|svg|woff2?)$ {

    expires 1y;

    add_header Cache-Control "public, immutable";

}

HTML文件：不缓存或短期缓存

location ~* \.html$ {

    expires 0;

    add_header Cache-Control "no-cache, must-revalidate";

}

为什么这样设计？因为HTML是入口文件，它引用的JS/CSS带有hash。更新代码时：

4. DNS配置

把CDN域名配置成CNAME指向CDN服务商：

# 阿里云CDN

cdn.example.com.    IN    CNAME    cdn.example.com.w.kunlunsl.com.



# Cloudflare

cdn.example.com.    IN    CNAME    example.com.cdn.cloudflare.net.

常见问题

跨域问题

CDN域名和主域名不同，字体文件、AJAX请求可能遇到跨域。

解决方案是在CDN配置CORS头：

# CDN服务器配置

add_header Access-Control-Allow-Origin "https://example.com";

add_header Access-Control-Allow-Methods "GET, HEAD, OPTIONS";

或者在源服务器的响应里加上CORS头，CDN会透传。

缓存更新问题

发布新版本后，用户还是看到旧内容？

方案一：文件名带hash（推荐）

前面已经提到，文件名带hash，新版本就是新文件，不存在缓存问题。

方案二：主动刷新缓存

// 调用CDN服务商的刷新API

await cdnClient.refreshObjectCaches({

  ObjectPath: 'https://cdn.example.com/app.js\nhttps://cdn.example.com/app.css',

  ObjectType: 'File'

});

方案三：URL加版本号

<script src="https://cdn.example.com/app.js?v=1.2.3"></script>

不太推荐，因为有些CDN会忽略查询参数。

HTTPS证书

CDN域名也需要HTTPS证书。大多数CDN服务商提供免费证书或支持上传自有证书。

配置方式：

# 用certbot申请泛域名证书

certbot certonly --manual --preferred-challenges dns \

  -d "*.example.com" -d "example.com"

回源优化

如果源服务器压力大，可以启用"回源加速"或"中间源"：

用户 → 边缘节点 → 中间源 → 源服务器

中间源作为二级缓存，减少对源服务器的请求。多数CDN服务商默认开启这个功能。

CDN选型

个人项目推荐Cloudflare，免费套餐够用，全球节点覆盖好。

企业项目根据用户分布选择。面向国内用户，阿里云/腾讯云更合适；面向全球用户，Cloudflare或CloudFront。

验证CDN效果

浏览器开发者工具

打开Network面板，关注这几个指标：

• TTFB（Time To First Byte）：首字节时间，越小越好


• 响应头中的缓存信息：X-Cache: HIT 表示命中CDN缓存

命令行测试

# 查看响应头

curl -I https://cdn.example.com/app.js



# 输出示例

HTTP/2 200

cache-control: public, max-age=31536000

x-cache: HIT from CN-Beijing

在线工具

• Pingdom - 全球多点测速


• GTmetrix - 性能分析


• WebPageTest - 详细的加载瀑布图

小结

CDN加速的核心原理：

前端配置CDN的关键：

如果你觉得这篇文章有帮助，欢迎关注我的 GitHub，下面是我的一些开源项目：

Claude Code Skills（按需加载，意图自动识别，不浪费 token，介绍文章）：

• code-review-skill - 代码审查技能，覆盖 React 19、Vue 3、TypeScript、Rust 等约 9000 行规则（详细介绍）


• 5-whys-skill - 5 Whys 根因分析，说"找根因"自动激活


• first-principles-skill - 第一性原理思考，适合架构设计和技术选型

全栈项目（适合学习现代技术栈）：

• prompt-vault - Prompt 管理器，用的都是最新的技术栈，适合用来学习了解最新的前端全栈开发范式：Next.js 15 + React 19 + tRPC 11 + Supabase 全栈示例，clone 下来配个免费 Supabase 就能跑


• chat_edit - 双模式 AI 应用（聊天+富文本编辑），Vue 3.5 + TypeScript + Vite 5 + Quill 2.0 + IndexedDB

😱 我发现了一个「零依赖」的数据可视化宝藏！

Hey，前端小伙伴们！今天必须给你们安利一个「让数据说话」的神器——Heat.js！这可不是一个普通的JavaScript库，而是一个能让你的数据「热」起来的魔法工具！

想象一下，当你有一堆枯燥的日期数据，想要以直观、炫酷的方式展示出来时，Heat.js就像一个魔法师，「唰」的一下就能把它们变成色彩斑斓的热图、清晰明了的图表，甚至还有详细的统计分析！

🤩 这个库到底有什么「超能力」？

1. 「零依赖」轻量级选手，绝不拖你后腿 🦵

在这个「依赖地狱」的时代，Heat.js简直就是一股清流！它零依赖，体积小得惊人，加载速度快得飞起！再也不用担心引入一个库就拖慢整个页面加载速度了～

2. 「四种视图」任你选，总有一款适合你 🔄

Heat.js提供了四种不同的视图模式：

• Map视图：就像GitHub贡献图一样炫酷，用颜色深浅展示日期活跃度


• Chart视图：把数据变成专业的图表，让趋势一目了然


• Days视图：专注于展示每一天的详细数据


• Statistics视图：直接给你算出各种统计数据，懒人福音！

想换个姿势看数据？只需轻轻一点，瞬间切换～

3. 「51种语言」支持，真正的「世界公民」🌍

担心你的国际用户看不懂？不存在的！Heat.js支持51种语言，从中文、英文到阿拉伯语、冰岛语，应有尽有！你的应用可以轻松走向全球，再也不用为语言本地化发愁了～

4. 「数据导入导出」无所不能，数据来去自由 📤📥

想导出数据做进一步分析？没问题！Heat.js支持导出为CSV、JSON、XML、TXT、HTML、MD和TSV等多种格式，任你选择！

想导入已有数据快速生成热图？同样简单！支持从JSON、TXT、CSV和TSV导入，甚至还支持拖拽上传，简直不要太方便！

5. 「12种主题」随意切换，颜值与实用并存 💅

担心热图不好看？Heat.js提供了12种精心设计的主题，包括暗黑模式和明亮模式，让你的数据可视化既专业又美观！无论你的网站是什么风格，都能找到匹配的主题～

💡 这个神奇的库可以用来做什么？

1. 「活动追踪」，让你的用户活跃起来 📊

想展示用户的登录活跃度？想用热图展示文章的发布频率？Heat.js帮你轻松实现！就像GitHub的贡献图一样，让你的用户看到自己的「努力成果」，成就感满满！

2. 「数据分析」，让你的决策更明智 🧠

通过Heat.js的Statistics视图，你可以快速获取数据的各种统计信息，比如最活跃的月份、平均活动频率等。这些数据可以帮助你做出更明智的产品决策，优化用户体验！

3. 「趋势展示」，让你的报告更有说服力 📈

想在报告中展示某个指标的变化趋势？Heat.js的Chart视图可以将枯燥的数据变成直观的图表，让你的报告更有说服力，老板看了都说好！

🛠️ 如何用最简单的方式用上这个神器？

第一步：「把宝贝抱回家」📦

npm install jheat.js

或者直接使用CDN：

<link rel="stylesheet" href="https://cdn.jsdelivr.net/gh/williamtroup/Heat.js@4.5.1/dist/heat.js.min.css">

<script src="https://cdn.jsdelivr.net/gh/williamtroup/Heat.js@4.5.1/dist/heat.min.js"></script>

第二步：「给它找个家」🏠

<div id="heat-map" data-heat-js="{ 'views': { 'map': { 'showDayNames': true } } }">

  <!-- 这里将显示你的热图 -->

</div>

第三步：「喂它数据」🍽️

// 添加日期数据

let newDateObject = new Date();

$heat.addDate("heat-map", newDateObject, "Trend Type 1", true);



// 移除日期数据（如果需要）

// $heat.removeDate("heat-map", newDateObject, "Trend Type 1", true);

三步搞定！就是这么简单！

🎯 为什么Heat.js值得你拥有？

1. 「简单易用」，小白也能轻松上手 👶

Heat.js的API设计非常友好，文档也很详细，即使是JavaScript初学者也能快速上手。几个简单的步骤，就能实现专业级的数据可视化效果！

2. 「高度定制」，满足你的各种需求 ⚙️

无论是颜色、样式，还是功能配置，Heat.js都提供了丰富的选项。你可以根据自己的需求，定制出独一无二的数据可视化效果！

3. 「响应式设计」，在任何设备上都完美展示 📱💻

Heat.js完全支持响应式设计，无论是在手机、平板还是电脑上，都能完美展示。你的数据可视化效果将在任何设备上都一样出色！

4. 「TypeScript支持」，框架党福利 🎉

如果你使用React、Angular等现代前端框架，Heat.js的TypeScript支持会让你用得更爽！类型定义清晰，代码提示完善，开发体验一流！

🚀 最后想说的话...

在这个「数据为王」的时代，如何让数据更直观、更有说服力，是每个开发者都需要面对的挑战。而Heat.js，就是帮助你征服这个挑战的绝佳工具！

它轻量级、零依赖、功能强大、易于使用，无论是个人项目还是企业应用，都能轻松胜任。最重要的是，它让数据可视化不再是一件复杂的事情，而是一种乐趣！

所以，还等什么呢？赶紧去GitHub上给Heat.js点个Star⭐，然后在你的项目中用起来吧！相信我，它一定会给你带来惊喜！

✨ 祝大家的数据可视化之路一帆风顺，让我们一起用Heat.js让数据「热」起来！✨

这也许就是AI无法代替人的原因，只需一行代码就可以实现纯前端 html 转矢量 pdf 的功能

// 引入 dompdf.js库

import dompdf from "dompdf.js";



dompdf(document.querySelector("#capture")).then(function (blob) {

  //文件操作

});

实现效果（复杂表格）

1. 在线体验

dompdfjs.lisky.com.cn

2. Git 仓库地址 (欢迎 Star⭐⭐⭐)

github.com/lmn1919/dom…

3. 生成 PDF

在前端生态里，把网页内容生成 PDF 一直是一个常见但不简单的需求。从报表导出、小票生成、合同下载到打印排版，很多项目或多或少都会遇到。市面上常见的方案大致有以下几类：

• 服务端渲染 PDF（后端库如 wkhtmltopdf、PrinceXML 等）


• 客户端将 HTML 渲染为图片（如 html2canvas + jsPDF）然后再封装为 PDF


• 前端调用相关 pdf 生成库来生成 PDF（如 pdfmake，jspdf，pdfkit）

但是这些方案都有各自的局限性，

• 比如服务端渲染 PDF 对服务器资源要求高，需要后端参与。


• html2canvas + jsPDF 需要将 html 内容渲染为图片，再将图片封装为 PDF，速度会比较慢，而且生成体积会比较大，内容会模糊，限制于 canvas 生成高度，不能生成超过 canvas 高度的内容。


• 而前端调用相关 pdf 生成库来生成 PDF 则需要对相关库有一定的了解，api 比较复杂，学习使用成本很高。

使用 jspdf 生成如图简单的 pdf

就需要如此复杂的代码，如果要生成复杂的 pdf, 比如包含表格、图片、图表等内容，那使用成本就更高了。

function generateChinesePDF() {

  // Check if jsPDF is loaded

  if (typeof window.jspdf === "undefined") {

    alert("jsPDF library has not finished loading, please try again later");

    return;

  }



  const { jsPDF } = window.jspdf;

  const doc = new jsPDF();



  // Note: Default jsPDF does not support Chinese, this is just a demo

  // In real projects you need to add Chinese font support



  doc.setFontSize(16);

  doc.text("Chinese Text Support Demo", 20, 30);



  doc.setFontSize(12);

  doc.text("Note: Default jsPDF does not support Chinese characters.", 20, 50);

  doc.text("You need to add Chinese font support for proper display.", 20, 70);



  // Draw some graphics for demonstration

  doc.setFillColor(255, 182, 193);

  doc.rect(20, 90, 60, 30, "F");

  doc.setTextColor(0, 0, 0);

  doc.text("Pink Rectangle", 25, 108);



  doc.setFillColor(173, 216, 230);

  doc.rect(100, 90, 60, 30, "F");

  doc.text("Light Blue Rectangle", 105, 108);



  doc.save("chinese-example.pdf");

}

但是现在，有了 dompdf.js，你只需要一行代码，就可以完成比这个复杂 10 倍的 PDF 生成任务，html页面所见即所得，可以将复杂的css样式转化成pdf

dompdf(document.querySelector("#capture")).then(function (blob) {

  //文件操作

});

而且，dompdf.js 生成的 PDF 是矢量的，非图片式的，高清晰度的，文字可以选中、复制、搜索等操作（在支持的 PDF 阅读器环境下），区别于客户端将 HTML 渲染为图片（如 html2canvas + jsPDF）然后再封装为 PDF。

具体可以去体验 立即体验 https://dompdfjs.lisky.com.cn

4. dompdf.js 是如何实现的？

其实 dompdf.js 也是基于 html2canvas+jspdf 实现的，但是为什么 dompdf.js 生成的 pdf 文件可以二次编辑，更清晰，体积小呢？

不同于普通的 html2canvas + jsPDF 方案，将 dom 内容生成为图片，再将图片内容用 jspdf 绘制到 pdf 上，这就导致了生成的 pdf 文件体积大，无法编辑，放大后会模糊。

html2canvas 原理简介

1. DOM 树遍历
html2canvas 从指定的 DOM 节点开始，递归遍历所有子节点，构建一个描述页面结构的内部渲染队列。

2. 样式计算
对每个节点调用 window.getComputedStyle() 获取最终的 CSS 属性值。这一步至关重要，因为它包含了所有 CSS 规则（内联、内部、外部样式表）层叠计算后的最终结果。

3. 渲染模型构建
将每个 DOM 节点和其计算样式封装成渲染对象，包含绘制所需的完整信息：位置（top, left）、尺寸（width, height）、背景、边框、文本内容、字体属性、层级关系（z-index）等。

4. Canvas 上下文创建
在内存中创建 canvas 元素，获取其 2D 渲染上下文（CanvasRenderingContext2D）。

5. 浏览器绘制模拟
按照 DOM 的堆叠顺序和布局规则，遍历渲染队列，将每个元素绘制到 Canvas 上。这个过程实质上是将 CSS 属性"翻译"成对应的绘制 API 调用：

核心创新：API 替换，底层是封装了 jsPDF 的 API
dompdf.js 的关键突破在于改造了 html2canvas 的 canvas-renderer.ts 文件，将原本输出到 Canvas 的绘制 API 替换为 jsPDF 的 API 调用。这样就实现了从 DOM 直接到 PDF 的转换，生成真正可编辑、可搜索的 PDF 文件，而不是传统的图片格式。

目前实现的功能

1. 文字绘制 （颜色，大小）
2. 图片绘制 （支持 jpeg, png 等格式）
3. 背景，背景颜色 （支持合并单元格）
4. 边框，复杂表格绘制 （支持合并单元格）
5. canvas （支持多种图表类型）
6. svg （支持 svg 元素绘制）
7. 阴影渲染 （使用 foreignObjectRendering，支持边框阴影渲染）
8. 渐变渲染 （使用 foreignObjectRendering，支持背景渐变渲染）

7.使用

安装

        npm install dompdf.js --save

CDN 引入

<script src="https://cdn.jsdelivr.net/npm/dompdf.js@latest/dist/dompdf.js"></script>

基础用法

import dompdf from "dompdf.js";

dompdf(document.querySelector("#capture"), {

  useCORS: true, //是否允许跨域

})

  .then(function (blob) {

    const url = URL.createObjectURL(blob);

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

    a.href = url;

    a.download = "example.pdf";

    document.body.appendChild(a);

    a.click();

  })

  .catch(function (err) {

    console.log(err, "err");

  });

写在最后

dompdf.js 让前端 PDF 生成变得前所未有的简单：无需后端、无需繁琐配置、一行代码即可输出矢量、可检索、可复制的专业文档。无论是简历、报告还是发票，它都能轻松胜任。 欢迎在你的项目中使用它 。

如果它帮到了你，欢迎去 github.com/lmn1919/dom… 点个 Star，提优化，共建项目。

在日常业务开发里，DOM 截图 几乎是刚需场景。

无论是生成分享卡片、导出报表，还是保存一段精美排版内容，前端同学都绕不开它。

但问题来了——市面上的截图工具，比如 html2canvas，虽然用得多，却有一个致命缺陷：慢！
普通截图动辄 1 秒以上，大一点的 DOM，甚至能直接卡到怀疑人生，用户体验一言难尽。

大家好，我是芝士，欢迎点此扫码加我微信 Hunyi32 交流，最近创建了一个低代码/前端工程化交流群，欢迎加我微信 Hunyi32 进群一起交流学习，也可关注我的公众号[ 前端界 ] 持续更新优质技术文章

最近发现一个保存速度惊艳到我的库snapDOM 。

这货在性能上的表现，完全可以用“碾压”来形容：

• 👉 相比 html2canvas，快 32 ~ 133 倍


• 👉 相比 modern-screenshot，也快 2 ~ 93 倍

以下是官方基本测试数据：

📊 数据来源：snapDOM 官方 benchmark（基于 headless Chromium 实测）。

⚡ 为什么它这么快？

二者的实现原理不同

html2canvas 的实现方式

• 原理：
  通过遍历 DOM，把每个节点的样式（宽高、字体、背景、阴影、图片等）计算出来，然后在 <canvas> 上用 Canvas API 重绘一遍。


• 特点：
  
  
  
  
  • 需要完整计算 CSS 样式 → 排版 → 绘制。
  
  
  • 复杂 DOM 时计算量极大，比如渐变、阴影、字体渲染都会消耗 CPU。
  
  
  • 整个过程基本是 模拟浏览器的渲染引擎，属于“重造轮子”。
  
  
  
  

所以一旦 DOM 大、样式复杂，html2canvas 很容易出现 1s+ 延迟甚至卡死。

snapDOM 的实现方式

原理：利用浏览器 原生渲染能力，而不是自己模拟。

snapDOM 的 captureDOM 并不是自己用 Canvas API 去一笔一笔绘制 DOM（像 html2canvas 那样），而是：

所以核心就是：
👉 利用浏览器自己的渲染引擎（SVG foreignObject）来排版和绘制，而不是 JS 重造渲染过程。

如何使用 snapDOM

snapDOM 上手非常简单， 学习成本比较低。

1. 安装

通过npm 安装：

npm install @zumer/snapdom

或者直接用 CDN 引入：

<script src="https://cdn.jsdelivr.net/npm/@zumer/snapdom/dist/snapdom.min.js"></script>

2. 基础用法

只需要一行代码，就能把 DOM 节点“变”成图片：

// 选择你要截图的 DOM 元素

const target = document.querySelector('.card');



// 导出为 PNG 图片

const image = await snapdom.toPng(target);



// 直接添加到页面

document.body.appendChild(image);

3. 更多导出方式

除了 PNG，snapDOM 还支持多种输出格式：

// 导出为 JPEG

const jpeg = await snapdom.toJpeg(target);



// 导出为 SVG

const svg = await snapdom.toSvg(target);



// 直接保存为文件

await snapdom.download(target, { format: 'png', filename: 'screenshot.png' });

4. 导出一个这样的海报图

开发中生成海报并保存到， 是非常常见的需求，以前使用html2canvas，也要写不少代码， 还要处理图片失真等问题， 使用snapDOM，真的一行代码能搞定。

 <div ref="posterRef" class="poster">

   ....

</div>



<script setup lang="ts">

  const downloadPoster = async () => {

    if (!posterRef.value) {

        alert("海报元素未找到");

        return;

    }



    try {

        // snapdom 是 UMD 格式，通过全局 window.snapdom 访问

        const snap = (window as any).snapdom;

        if (!snap) {

            alert("snapdom 库未加载，请刷新页面重试");

            return;

        }

        await snap.download(posterRef.value, {

            format: "png",

            filename: `tech-poster-${Date.now()}`

        });





    } catch (error) {

        console.error("海报生成失败:", error);

        alert("海报生成失败，请重试");

    }

};

</script>

相比传统方案需要大量配置和兼容性处理，snapDOM 真正做到了 一行代码，极速生成。无论是分享卡片、营销海报还是报表导出，都能轻松搞定。

await snap.download(posterRef.value, {

    format: "png",

    filename: `tech-poster-${Date.now()}`

});

大家好，我是芝士，欢迎点此扫码加我微信 Hunyi32 交流，最近创建了一个低代码/前端工程化交流群，欢迎加我微信 Hunyi32 进群一起交流学习，也可关注我的公众号[ 前端界 ] 持续更新优质技术文章

总结

在前端开发里，DOM 截图是一个常见但“让人头疼”的需求。

• html2canvas 代表的传统方案，虽然功能强大，但性能和体验常常拖后腿；


• 而 snapDOM 借助浏览器原生渲染能力，让截图变得又快又稳。

一句话：
👉 如果你还在为截图慢、卡顿、模糊烦恼，不妨试试 snapDOM —— 可能会刷新你对前端截图的认知。 🚀

作为一个老前端人比大家虚长几岁，前端技术的飞速发展，从早期的 jQuery 到现代的 React、Vue，再到 CSS 框架的演变。最近几年，Tailwind CSS 成为了前端圈的热门话题，很多人称它为“神器”，但也有不少人认为它是“神坑”。今天，我就从实际项目经验出发，吐槽一下 Tailwind CSS 的弊端。

HTML 代码臃肿，可读性差

例如：

<div class="p-4 bg-white rounded-lg shadow-md text-gray-800 hover:bg-gray-100">

  Content

</div>

以至于前端同学前来吐槽，这和写style有个毛线区别。
虽然tailwind提供了@apply方法，将常用的实用类代码提取到css中，来减少html的代码量

.btn {

  @apply p-4 bg-blue-500 text-white rounded-lg hover:bg-blue-600;

}

可以一个大型项目样式复杂，常常看到这样的场景：

.btn1 {

  @apply p-4 bg-blue-500 text-white rounded-lg hover:bg-blue-600;

}

.btn2 {

  @apply p-6 bg-blue-500 text-blue rounded-lg hover:bg-blue-600;

}

.btn3 {

  @apply p-8 bg-blue-500 text-red rounded-lg hover:bg-blue-600;

}

.btn4 {

  @apply p-10 bg-blue-500 rounded-lg hover:bg-green-600;

}