前言：这一年来我基本处于断更的状态，我知道在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 年的开发趋势，将让我们有更多选择，让我们能够用最适合的工具解决问题，而不是纠结于某种工具是否“最好”。

引言

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篇文章了。

行动建议：

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

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

本文首发自个人博客

做前端项目的时候，经常听到"静态资源要放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;

}

读起来都费劲。

增加了前端同学的学习成本

开发是必须学习大量的tailwind的实用类，并且要花时间学习这些命名规则，例如：

• p-4 是 padding，m-4 是 margin。


• text-sm 是小字体，text-lg 是大字体。


• bg-blue-500 是背景色，text-blue-500 是文字颜色。

国内的项目大家都知道，不是在赶工期，就是在赶工期的路上，好多小伙伴开发的时候直接就上style了。

当然这样也有好处，能使用JIT模式，按需生成css，减少文件的大小。避免了以前项目中好多无用的css。

动态样式支持有限

有时候需要动态生成的类会导致错误，例如：

<div class="text-{{ color }}-500 bg-{{ bgColor }}-100">

  Content

</div>

如果color被复制为green，但是系统并没有定义 text-green-500 这个类。让项目变得难以调试和维护。

总结

Tailwind CSS 是一把双刃剑，它既能为开发带来极大的便利，也可能成为项目的“神坑”。作为开发者，我们需要根据项目需求，合理使用 Tailwind，并通过一些最佳实践规避它的弊端。希望这篇文章能帮助你在项目中更好地使用 Tailwind CSS，享受它带来的便利，同时避免踩坑！

如果你有更多关于 Tailwind CSS 的问题或经验分享，欢迎在评论区留言讨论！ 😊

如果你关注前端图标的发展，会发现一个现象：

过去前端图标主要有三种方案：

• PNG 小图（配合雪碧图）


• Iconfont


• SVG

到了今天，大部分中大型项目都把图标系统全面迁移到 SVG。

无论 React/Vue 项目、新框架（Next/Remix/Nuxt），还是大厂的设计规范（Ant Design、Material、Carbon），基本都默认 SVG。

为什么是 SVG 胜出？

为什么不是 Iconfont、不是独立 PNG、不是雪碧图？

答案不是一句“清晰不失真”这么简单。

下面从前端实际开发的角度，把 SVG 胜出的原因讲透。

一、SVG 为什么比位图（PNG/JPG）更强？

① 矢量图永不失真（核心优势）

PNG/JPG 是位图，只能按像素存图。

移动端倍率屏越来越高（2x、3x、4x……），一张 24px 的 PNG 在 iPhone 高分屏里可能看起来糊成一团。

SVG 是矢量图，数学计算绘制：

• 任意缩放不糊


• 任意清晰度场景都不怕


• 深色模式也不会变形

这点直接解决了前端图标领域长期存在的一个痛点：适配成本太高。

② 体积小、多级复用不浪费

同样一个图标：

• PNG 做 1x/2x/3x 需要三份资源


• SVG 只要一份

而且：

• SVG 本质是文本


• gzip 压缩非常有效

在 CDN 下，通常能压到个位数 KB，轻松复用。

③ 图标换色非常容易

PNG 改颜色很麻烦：

• 设计师改


• 重新导出


• 重新上传/构建

Iconfont 的颜色只能统一，只能覆盖轮廓颜色，多色很麻烦。

SVG 则非常灵活：

.icon {

  fill: currentColor;

}

可以跟随字体颜色变化，支持 hover、active、主题色。

深浅模式切换不需要任何额外资源。

④ 支持 CSS 动画、交互效果

SVG 不只是图标文件，它是 DOM，可以直接加动画：

• stroke 动画


• 路径绘制动画


• 颜色渐变


• hover 发光


• 多段路径动态控制

PNG 和 Iconfont 都做不到这种级别的交互。

很多现代 UI 的微动效（Loading、赞、收藏），都是基于 SVG 完成。

二、SVG 为什么比 iconfont 更强？

Iconfont 在 2015~2019 年非常火，但明显已经退潮了。

原因有以下几个：

① 字体图标本质是“字符”而不是图形

这带来大量问题：

● 不能多色

只能 monochrome，彩色图标很难实现。

● 渲染脆弱

在 Windows 某些字体渲染环境下会出现：

• 发虚


• 锯齿


• baseline 不一致

● 字符冲突

不同项目的字体图标可能互相覆盖。

相比之下，SVG 是独立图形文件，没有这些问题。

② iconfont 需要加载字体文件，失败会出现“乱码方块”

如果字体文件没加载成功，你会看到：

☐ ☐ ☐ ☐

这在弱网、支付类页面、海外环境都非常常见。

SVG 就没有这个风险。

③ iconfont 不利于按需加载