阅读视图

发现新文章,点击刷新页面。

pxcharts Ultra V2.3更新:多维表一键导出 PDF,渲染兼容性拉满!

最近粉丝咨询最多的问题莫过于 pxcharts 多维表是否能导出PDF的能力了。

图片

说实话,我回避了很久。浏览器打印引擎差异大,中文渲染、分页断行、复杂表格适配...每个都是坑。

直到上个月,一个做财务的朋友跟我吐槽:月底导报表,调格式调到凌晨2点。我决定,这功能必须上。

于是在1周的设计和研究下,终于实现了多维表导出PDF的功能。

演示如下:

图片

导出后的PDF文件预览效果:

图片

演示地址:pxcharts.com

开源版:github.com/MrXujiang/p…

接下来和大家分享一下详细的功能技术实现。

Pxcharts多维表导出PDF功能技术实现

支持将表格数据导出为 PDF 格式,便于用户打印、存档和分享,核心需求包括:

  • 保持表格结构和样式
  • 支持分页(避免行被截断)
  • 支持封面页(统计信息)
  • 状态标签着色
  • 横向/纵向布局可选

技术选型

为了实现这个方案,我们的核心依赖如下:

依赖 版本 用途
jspdf latest 生成 PDF 文件
html2canvas latest 将 HTML 渲染为 Canvas 图像

选型理由

为什么选择 html2canvas + jsPDF?原因如下:

  1. 纯前端实现无需后端服务,保护数据隐私
  2. 样式可控通过 CSS 精确控制 PDF 外观
  3. 兼容性好支持现代浏览器
  4. 生态成熟社区活跃,文档完善

为什么不直接用 jsPDF 的表格 API?

  • jsPDF 的 autoTable 插件对复杂样式支持有限
  • 自定义样式(状态标签着色、交替行背景)实现困难
  • html2canvas 可以复用现有的 HTML/CSS 样式

实现架构

整体流程我这里设计如下:

表格数据
    ↓
生成 HTML(按页)
    ↓
html2canvas 渲染为 Canvas
    ↓
Canvas 转 PNG 图像
    ↓
jsPDF 写入 PDF(每页一张图)
    ↓
下载 PDF 文件

分页策略

关键问题:如何避免表格行在分页时被截断?

我的解决方案:按行预分页

  1. 估算每行高度(约 36px)
  2. 计算每页可容纳行数:rowsPerPage = floor((pageHeight - headerHeight) / rowHeight)
  3. 按行数切分数据,每页独立渲染
  4. 每页都包含表头,方便阅读
const estimateRowHeight36// 每行大约 36px
const headerHeight60// 表头高度
const pageContentHeightPx = Math.round(contentHeight / scale)
const rowsPerPage = Math.floor((pageContentHeightPx - headerHeight) / estimateRowHeight)

// 分页
for (let i0; i < records.length; i += rowsPerPage) {
const pageRecords = records.slice(i, i + rowsPerPage)
  pages.push(renderDataPage(pageRecords, i))
}

核心代码解析

1. 动态导入(SSR 兼容):

const [{ default: jsPDF }, { default: html2canvas }] = awaitPromise.all([
import("jspdf"),
import("html2canvas"),
])

原因jspdf 和 html2canvas 依赖浏览器 API(如 documentwindow),在 Next.js SSR 阶段会报错。使用动态导入确保只在客户端执行。

2. 页面尺寸计算:

const pageDimensions = {
a4: { width: 595, height: 842 },  // pt 单位
a3: { width: 842, height: 1191 },
}

const pdfWidth = orientation === "landscape"
  ? pageDimensions[pageSize].height
  : pageDimensions[pageSize].width

注意:jsPDF 使用 pt(点)作为单位,1pt = 1/72 英寸。

3. HTML 生成

数据页结构这里我预设如下

<divstyle="width:1122px;padding:32px;box-sizing:border-box;background:#fff">
<tablestyle="width:100%;border-collapse:collapse">
<thead><!-- 表头 --></thead>
<tbody><!-- 数据行 --></tbody>
</table>
</div>

关键样式

  • width:1122px固定 canvas 宽度(A4 横向像素)
  • border-collapse:collapse合并表格边框
  • white-space:nowrap防止文本换行

4. Canvas 渲染

const canvasawaithtml2canvas(element, {
scale2,              // 2倍缩放,提高清晰度
useCORStrue,         // 允许跨域图片
allowTainttrue,      // 允许污染 canvas
backgroundColor"#ffffff",
loggingfalse,
})

参数说明

参数 说明
scale: 2 2倍分辨率,PDF 更清晰
useCORS 处理跨域图片(如附件预览图)
allowTaint 允许 canvas 被污染(某些图片需要)

5. PDF 写入

const imgData = canvas.toDataURL("image/png"1.0)
const imgWidth = contentWidth
const imgHeight = (canvas.height * imgWidth) / canvas.width

pdf.addImage(imgData, "PNG", margin, margin, imgWidth, imgHeight)

图像格式选择

  • PNG无损,清晰度高,适合文字
  • JPEG有损压缩,文件小,但不适合文字

样式处理技巧

状态标签着色这里我做了一层数据映射,方便精准还原样式:

constcolorMap: Record<stringstring> = {
"已完成""#dcfce7;color:#16a34a",
"进行中""#dbeafe;color:#2563eb",
"待开始""#fef3c7;color:#d97706",
"已停滞""#f3f4f6;color:#6b7280",
"重要紧急""#fee2e2;color:#dc2626",
}

交替行背景我采用的逻辑判断来动态渲染:

<tr style="background:${idx % 2 === 0 ? "#fff" : "#f8fafc"}">

如果文本出现截断换行,用canvas很难处理,这里我采用如下方案截断处理:

// 方案1:省略号截断(适合固定宽度列)
<span style="overflow:hidden;text-overflow:ellipsis;white-space:nowrap;max-width:160px">

// 方案2:完全显示(适合自动宽度列)
<spanstyle="white-space:nowrap">

当然还有很多细节的处理,这里就不一一介绍了。我们可以基于这个方案,继续扩展出如下场景:

  1. 水印支持添加企业 Logo 或水印
  2. 页码在页脚添加 "第 X 页 / 共 Y 页"
  3. 图表嵌入将图表大屏的图表嵌入 PDF
  4. 批量导出支持同时导出多个表格

今天就分享到这,后续我们还会持续迭代和更新,打造最强大的多维表格和文档协同系统。

演示地址:pxcharts.com

开源版:github.com/MrXujiang/p…

如何实现一个「万能」的通用打印组件?

在我们组开发的业务系统中,存在文书种类多、格式不一的场景,但又要求保持一致的打印体验,怎么办呢?难道每次加一种新文书就写一套打印逻辑?不存在的。用「配置 + 动态模板 + iframe 打印」的思路,可以搭出一套一个组件打天下的通用打印方案。


一、先想清楚:我们要解决什么问题?

  • 多种文书:不同业务对应不同的文书模板,字段、布局、样式都不一样。
  • 统一入口:希望小伙伴调用时只关心「打开打印、传文书类型和业务单号」,不用关心具体模板和接口。
  • 可编辑再打:部分文书需要在预览里编辑或填充后再打印,而不是纯静态展示。
  • 打印体验:要能控制打印样式(页眉页脚、分页、字体),并且不把整页 UI 一起打出去。

二、整体架构:三层拆解

可以把通用打印拆成三层,逻辑会非常清晰:

  1. 主组件:包含组件状态提示、调用 iframe 执行打印等功能;
  2. 配置层:文书类型与文书模版要一一对应;
  3. 模板层:每种文书一个 Vue 模板组件,负责展示、编辑字段,同时提供方法给壳层拿去保存/打印。

三、配置层:文书类型与模板的映射

用一份配置集中维护,后续扩展新文书主要就是:加一条配置 + 加一个模板组件。

export const DOC_TYPE = {
  FORM_A: 'FORM_A',  // 例如:某登记表
  FORM_B: 'FORM_B',  // 例如:某告知书
  // ...
};

export const documentTemplates = {
  [DOC_TYPE.FORM_A]: {
    title: '某登记表',
  },
  [DOC_TYPE.FORM_B]: {
    title: '某告知书',
  },
};

export function getTemplateConfig(docType) {
  const config = documentTemplates[docType];
  if (!config) {
    console.warn(`未找到文书类型 ${docType} 的模板配置`);
    return null;
  }
  return config;
}

主组件里使用 getTemplateConfig(docType) 拿配置,这样「加新文书」对主组件来说就是多一个配置键和对应的模板组件啦。


四、壳层:动态组件 + 打印流程

主组件只认「当前 docType 对应哪个模板组件」,用 component :is 动态渲染,这样无需在壳里写一长串 if/else 或 v-if。

4.1 模板区域与动态组件

<!-- 打印区域:唯一 id 便于后面克隆到 iframe -->
<div id="commonPrintArea" class="print-area">
  <component
    :is="templateComponent"
    ref="templateRef"
    :data="printData"
    :numb="numb"
    :template-config="templateConfig"
  />
</div>
computed: {
  templateComponent() {
    const componentMap = {
      FORM_A: 'FormATemplate',
      FORM_B: 'FormBTemplate',
      // 新文书:加一行即可
    };
    return componentMap[this.docType] || null;
  },
},

printData 由你在 init/loadCommonData 里请求接口或直接使用外部传入的数据;templateConfig 来自 getTemplateConfig(this.docType)

4.2 从模板组件拿数据:约定 getData()

打印或保存前,主组件需要拿到当前模板里用户可能改过的内容,所以约定:每个模板组件暴露 getData()方法,返回要落库/打印的纯数据。

// 主组件 methods
getTemplateData() {
  const templateComponent = this.$refs.templateRef;
  if (!templateComponent || typeof templateComponent.getData !== 'function') {
    return null;
  }
  return templateComponent.getData();
},

async handlePrint() {
  const templateData = this.getTemplateData();
  if (!templateData) return;

  const saved = await this.savePrintRecord(templateData);
  if (!saved) return;

  this.executePrint();
  this.$emit('print-success', { docType: this.docType, numb: this.numb, printData: templateData });
}

这样无论是「先保存再打」还是「仅打印」,数据源都统一来自模板的 getData()


五、模板层:可编辑字段与 getData()

模板里会有大量「看起来像下划线填空」的格子,既要可编辑又要打印时样式干净,我们的做法是,用一个可编辑字段的子组件包一层,再在模板里用 v-model 绑定 editableData对象,最后 getData() 直接返回这个对象。

5.1 可编辑字段的子组件(EditableField组件)

用 HTML5的contenteditable属性做内联编辑,通过 v-model和父组件同步;输入法期间用 compositionstart/end 防抖。

<template>
  <span
    ref="editableElement"
    :class="['editable-field', customClass]"
    :contenteditable="editable"
    :data-placeholder="placeholder"
    @blur="handleBlur"
    @input="handleInput"
    @compositionstart="isComposing = true"
    @compositionend="isComposing = false; handleInput($event)"
  />
</template>

<script>
export default {
  name: 'EditableField',
  props: ['value', 'editable', 'placeholder', 'customClass', 'maxlength'],
  data() {
    return { isComposing: false, innerValue: '' };
  },
  watch: {
    value: {
      immediate: true,
      handler(newVal) {
        if (!this.isComposing && newVal !== this.innerValue) {
          this.innerValue = newVal || '';
          if (this.$refs.editableElement) this.$refs.editableElement.innerText = this.innerValue;
        }
      },
    },
  },
  methods: {
    handleBlur(e) {
      const text = e.target.innerText.trim();
      this.innerValue = text;
      this.$emit('input', text);
    },
    handleInput(e) {
      if (this.isComposing) return;
      let text = e.target.innerText;
      if (this.maxlength && text.length > this.maxlength) {
        text = text.substring(0, this.maxlength);
        this.$refs.editableElement.innerText = text;
      }
      this.innerValue = text;
      this.$emit('input', text);
    },
  },
};
</script>

模板里用法示例:

<editable-field v-model="editableData.name" placeholder="请输入" custom-class="inline-underline-field" />

打印样式里对 .editable-field.inline-underline-field 等做「无边框、无背景、保下划线」的覆盖,即可做到「屏幕可编辑、纸上像填空」。


六、iframe 打印:只打「这一块」且样式可控

直接 window.print() 会连侧边栏、导航、按钮一起打。我们的做法是:把要打印的那块 DOM 克隆到隐藏的 iframe 里,在 iframe 里注入完整打印样式,再对 iframe 执行 print()

6.1 克隆 + 处理特殊节点(如复选框)

克隆时注意:像 Element UI 的 checkbox,在 iframe 里可能不会按「勾选状态」渲染,所以克隆后先把这类控件转成「勾选用 ☑ / 未勾选用 ☐」的纯文本,再塞进 iframe,这样打印出来稳定一致。

processCheckboxes(container) {
  container.querySelectorAll('.el-checkbox').forEach((el) => {
    const input = el.querySelector('input[type="checkbox"]');
    const isChecked = input && input.checked;
    const checkmark = document.createElement('span');
    checkmark.textContent = isChecked ? '☑' : '☐';
    // 若有 .el-checkbox__label,可把 label 文本和 checkmark 拼成新节点替换 el
    el.parentNode.replaceChild(checkmark, el);
  });
}

6.2 创建 iframe 并写入 HTML + 样式

executePrint() {
  const printArea = document.getElementById('commonPrintArea');
  if (!printArea) return;

  const cloned = printArea.cloneNode(true);
  this.processCheckboxes(cloned);

  const iframe = document.createElement('iframe');
  iframe.style.cssText = 'position:fixed;right:0;bottom:0;width:0;height:0;border:none';
  document.body.appendChild(iframe);

  const printStyles = this.getPrintStyles(); // 见下一小节

  const doc = iframe.contentWindow.document;
  doc.open();
  doc.write(`
    <!DOCTYPE html>
    <html>
      <head>
        <meta charset="UTF-8">
        <title>${this.templateConfig.title}</title>
        <style>
          * { margin: 0; padding: 0; box-sizing: border-box; }
          body { font-family: "Microsoft YaHei", Arial, sans-serif; line-height: 1.5; color: #000; background: #fff; }
          ${printStyles}
        </style>
      </head>
      <body>${cloned.innerHTML}</body>
    </html>
  `);
  doc.close();

  iframe.onload = () => {
    iframe.contentWindow.focus();
    setTimeout(() => {
      iframe.contentWindow.print();
      setTimeout(() => document.body.removeChild(iframe), 500);
    }, 100);
  };
}

这样只有 iframe 里的 body 被打印,且样式完全由你注入的 printStyles 控制。


七、打印样式:基础 + 按文书类型扩展

拆成「基础样式(所有文书共用)」和「按 docType 的扩展样式」,主组件里根据 docType 拼成最终样式字符串。

getPrintStyles() {
  const baseStyles = `
    @page { margin: 0; size: A4; }
    body { margin: 10mm 10mm 15mm 10mm; font-family: "仿宋", serif; }
    .form-table { width: 100%; border-collapse: collapse; border: 2px solid #000; }
    .form-table th, .form-table td { border: 1px solid #000; padding: 6px 8px; }
    .form-table tr { page-break-inside: avoid; }
    .editable-field { border: none !important; background: transparent !important; box-shadow: none !important; }
    .inline-underline-field { border-bottom: 1px solid #333 !important; min-height: 1.2em; }
  `;
  const docTypeStyles = this.getDocTypeSpecificStyles(); // 从 styleMap[docType] 取
  return `${baseStyles}\n${docTypeStyles}`;
}

新增文书时,如需单独调表格列宽、标题字号等,在 getDocTypeSpecificStyles() 的 styleMap 里加一条即可,主组件逻辑不用改。


结尾:按这套思路实现后,业务侧只需要「传 docType + 外部数据) + 监听事件」,就能接住多种文书、可编辑、可保存的通用打印能力啦;后续加新文书也不会再在主组件里堆逻辑,维护成本也会低很多。

别再无脑用 `JSON.parse()` 了!这个安全漏洞你可能每天都在触发

你以为只是解析个字符串?其实黑客已经在你服务器上跑脚本了!

在前端和 Node.js 开发中,JSON.parse() 几乎无处不在:

const data = JSON.parse(localStorage.getItem('user'));
const config = JSON.parse(req.body.payload);
const settings = JSON.parse(fs.readFileSync('config.json'));

简洁、直接、好用——但极其危险

如果你没有对输入做任何校验就调用 JSON.parse(),你正在为应用打开一扇“任意代码执行”的后门。

今天,我们就来揭开 JSON.parse() 背后的安全雷区,并告诉你如何用更安全、更现代的方式处理 JSON 数据。


危险场景一:原型污染(Prototype Pollution)

这是 JSON.parse() 最臭名昭著的安全漏洞之一。

虽然原生 JSON.parse() 本身不会执行代码,但它会忠实地还原对象结构——包括 __proto__constructor.prototype 这类特殊属性。

来看一个真实攻击载荷:

const userInput = '{"__proto__":{"isAdmin":true}}';
const obj = {};
JSON.parse(userInput, (key, value) => {
  obj[key] = value;
  return value;
});
console.log({}.isAdmin); // true!全局对象被污染!

如果这段代码出现在你的登录逻辑、权限校验或配置合并中,攻击者就能:

  • 绕过身份验证(isAdmin: true);
  • 注入恶意属性(如 exec: 'rm -rf /');
  • 篡改全局行为,导致服务崩溃或数据泄露。

尤其在使用 Lodash、merge、assign 等工具库时,风险更高!


危险场景二:拒绝服务(DoS)

恶意构造的 JSON 字符串可导致内存爆炸CPU 耗尽

// 深度嵌套攻击
const evil = '{"a":{"a":{"a":{"a":{"a":{"a": ... }}}}}}';

// 或超大数组
const evil2 = '[1,1,1,...,1]' // 1000 万个元素

调用 JSON.parse(evil) 可能:

  • 占用数 GB 内存;
  • 阻塞事件循环数秒;
  • 直接触发 OOM(Out of Memory)崩溃。

在 API 接口或 Webhook 处理中,这等于把“关机按钮”交给了攻击者。


正确姿势:安全解析 JSON 的三重防护

第一步:限制输入大小

在解析前先检查字符串长度:

function safeParse(str, maxSize = 1024 * 100) { // 100KB
  if (typeof str !== 'string' || str.length > maxSize) {
    throw new Error('Input too large');
  }
  return JSON.parse(str);
}

第二步:禁用危险键(如 __proto__

使用 reviver 函数过滤敏感属性:

function secureJSONParse(str) {
  return JSON.parse(str, (key, value) => {
    if (key === '__proto__' || key === 'constructor') {
      throw new Error('Disallowed key in JSON');
    }
    return value;
  });
}

第三步(推荐):用 Zod / Joi 做运行时校验

这才是现代 JS 工程的最佳实践!

import { z } from 'zod';

const UserSchema = z.object({
  id: z.number(),
  name: z.string(),
  email: z.string().email(),
  isAdmin: z.boolean().optional(),
});

function parseUser(jsonStr: string) {
  const raw = secureJSONParse(jsonStr);
  return UserSchema.parse(raw); // 自动校验 + 类型推导
}

优势:

  • 类型安全(配合 TypeScript 完美);
  • 自动过滤多余字段
  • 明确拒绝非法结构
  • 防止原型污染、字段注入等攻击

特别提醒:Node.js 中的额外风险

在服务端,如果你从以下来源解析 JSON,风险更高:

  • HTTP 请求体(req.body
  • 文件读取(用户上传的 JSON 配置)
  • Redis / 数据库存储的序列化数据
  • 第三方 Webhook 回调

务必在解析前做来源校验 + 结构校验 + 大小限制三重保险!


结语

JSON.parse() 不是“坏 API”,但它是一把没有保险的枪
在现代 Web 开发中,信任任何用户输入 = 自毁程序

下次当你写下 JSON.parse(someString) 时,请自问:

“我确定这个字符串来自可信源吗?它的结构真的安全吗?”

如果答案不确定,请立即切换到 Zod / Joi + 安全解析函数 的组合。

转发给那个还在裸用 JSON.parse() 的队友吧!


各位互联网搭子,要是这篇文章成功引起了你的注意,别犹豫,关注、点赞、评论、分享走一波,让我们把这份默契延续下去,一起在知识的海洋里乘风破浪!

别再让 `console.log` 上线了!它正在悄悄拖垮你的生产系统

你以为只是“打个日志”?其实它在泄露数据、吃光内存、暴露源码!

在开发过程中,console.log() 是我们最亲密的伙伴:

function calculatePrice(items) {
  console.log('items:', items); // 调试用
  return items.reduce((sum, item) => sum + item.price, 0);
}

方便、直观、零成本——但一旦这段代码被部署到生产环境,隐患就开始蔓延

今天我们就来揭开 console.log 在生产环境中的三大“罪状”,并告诉你如何彻底杜绝它。


危害一:敏感信息泄露

这是最致命的问题。

你在本地调试时可能这样写:

console.log('User login:', { email, password });
console.log('DB connection string:', process.env.DB_URL);
console.log('Admin token:', req.headers.authorization);

如果这些日志随代码上线:

  • 用户密码、API 密钥、数据库地址 会直接打印到服务器控制台;
  • 如果你用了 PM2、Docker、K8s 或云平台(如阿里云、AWS),这些日志会被自动采集到日志系统;
  • 任何有日志权限的运维、实习生、外包人员都能看到!
  • 更糟的是,如果日志被错误地公开(比如 GitHub 泄露、ELK 未设权限),黑客将直接拿到“系统钥匙”。

真实案例:2023 年某电商因 console.log 泄露支付密钥,导致数万元盗刷。


危害二:性能损耗与内存泄漏

别小看一个 console.log,它在高并发下是“隐形杀手”。

1. 同步 I/O 阻塞

Node.js 中的 console.log 默认是同步写入 stdout 的(尤其在非 TTY 环境,如 Docker 容器)。
这意味着:每打一行日志,事件循环都会被短暂阻塞。

在 QPS 1000+ 的接口中,频繁 console.log 可能导致:

  • 响应延迟增加 10%~30%;
  • CPU 使用率异常飙升;
  • 请求排队甚至超时。

2. 大对象序列化开销

console.log('Full user object:', hugeUserData); // 包含头像 Buffer、历史订单等

console.log 会调用 .toString() 或内部序列化逻辑,若对象巨大(如图片 Buffer、长数组),会:

  • 消耗大量 CPU;
  • 生成超长字符串,占用堆内存;
  • 触发频繁 GC,甚至 OOM 崩溃。

危害三:暴露源码结构与业务逻辑

生产环境的日志往往会被集中管理(如 Sentry、Datadog、阿里云 SLS)。
如果你不小心把函数名、变量名、内部路径打出来:

console.log('Calling internal service: /v1/billing/calculate-discount');
console.log('Error in function: validatePromoCodeV2');

攻击者就能:

  • 推测你的 API 设计;
  • 发现未公开的内部接口;
  • 结合其他漏洞发起精准攻击(如 IDOR、越权)。

这等于主动给黑客画地图


正确姿势:用专业日志系统替代 console.log

第一步:开发阶段就禁用生产级日志输出

使用环境判断(但不推荐仅靠这个!):

if (process.env.NODE_ENV !== 'production') {
  console.log('Debug info:', data);
}

问题:容易遗漏,且无法防止“忘记删除”的日志。


第二步(强烈推荐):引入专业日志库

使用 WinstonBunyanPino 等结构化日志工具:

import winston from 'winston';

const logger = winston.createLogger({
  level: process.env.NODE_ENV === 'production' ? 'info' : 'debug',
  transports: [
    new winston.transports.Console(),
    // 生产环境可加文件、Sentry、阿里云 SLS 等
  ],
});

// 安全地记录
logger.debug('User data', { userId: user.id }); // 不会打印完整对象
logger.error('Payment failed', { orderId, reason });

优势:

  • 支持日志级别(debug/info/warn/error);
  • 自动过滤敏感字段(可通过 format 实现);
  • 异步/高性能输出;
  • 与监控系统无缝集成。

第三步:构建时自动清除 console.log

在打包阶段用工具彻底移除:

Webpack:

// webpack.config.js
optimization: {
  minimizer: [
    new TerserPlugin({
      terserOptions: {
        compress: {
          drop_console: true, // 删除所有 console.*
        },
      },
    }),
  ],
}

Vite / Rollup:

使用插件如 rollup-plugin-stripvite-plugin-remove-console

ESLint(预防):

配置规则禁止提交 console

{
  "rules": {
    "no-console": "warn"
  }
}

配合 Git Hooks(如 husky + lint-staged),提交前自动检查。


终极建议:建立“日志规范”

  • 绝不在生产代码中使用 console.log
  • 所有日志必须通过统一 logger 实例输出
  • 敏感字段(密码、token、身份证)必须脱敏
  • 日志内容需经过安全审计

结语

console.log 是开发的好帮手,但它是生产环境的毒药
一次疏忽,可能导致数据泄露、服务崩溃、甚至法律风险。

记住:

真正的专业,不是能写出功能,而是能守住底线。

从今天起,让 console.log 止步于你的本地开发机。


各位互联网搭子,要是这篇文章成功引起了你的注意,别犹豫,关注、点赞、评论、分享走一波,让我们把这份默契延续下去,一起在知识的海洋里乘风破浪!

我的新同事是个AI:支持skill后,它用TinyVue搭项目还挺溜!

本文由体验技术团队Kagol原创。

一个月前,有用户建议 TinyVue 出几个 Skills,方便 AI 编程。

1.png

必须安排上!

目前 TinyVue 组件库和 TinyRobot AI 对话组件均已支持 Agent Skills,你可以在支持 Skills 的 IDE(比如 VSCode、Cursor、Trae 等) 上配置和使用。

1 演示视频

先看下使用效果(以 Trae 为例)。

TinyVue Skills:让 AI 使用 TinyVue 组件生成前端页面:www.bilibili.com/video/BV1d6…

以 Trae 为例,给大家介绍如何安装和配置 TinyVue Skills。

2 安装 TinyVue Skills

在命令行终端中执行以下命令:

npx skills add opentiny/agent-skills -g --skill tiny-vue-skill --agent trae

2.png

安装方式选择 Symlink (Recommended)

安装成功!

3.png

查看 Skills 是否安装成功:

npx skills list -g

4.png

3 开启 TinyVue Skills

打开 Trae 的设置页面,在左侧的【规则和技能】菜单中找到【技能】,开启【tiny-vue-skill】这个技能即可。

5.png

4 在 AI 对话框中使用 TinyVue Skills

在 Trae 中打开 AI 侧栏,输入以下内容:

使用TinyVue组件创建一个登录组件,并集成到App.vue中

AI 会去调用 tiny-vue-skill 技能,根据其中的 SKILL.md 中的描述,去查看对应的组件 API/Demo 文档,然后使用适当的 TinyVue 组件搭建你需要的页面。

这样比 AI 去海量互联网信息中寻找 TinyVue 的用法要准确得多,而且消耗更少的 Token,也不容易产生幻觉。

6.png

如果你正在使用 TinyVue 组件库,强烈推荐你配置上 tiny-vue-skill,让 AI 辅助编码,效率更高!

如果你用的是 VSCode Copilot、Cursor 等其他 IDE也没关系,安装 TinyVue Skills 遵循类似的步骤,只需要把命令中的 --agent 修改成对应的 IDE 即可,以下是对应表格。

比如在 Cursor 中安装 tiny-vue-skill:

npx skills add opentiny/agent-skills -g --skill tiny-vue-skill --agent cursor
Agent --agent 项目内路径 全局路径
Amp amp .agents/skills/ ~/.config/agents/skills/
Antigravity antigravity .agent/skills/ ~/.gemini/antigravity/skills/
Claude Code claude-code .claude/skills/ ~/.claude/skills/
Clawdbot clawdbot skills/ ~/.clawdbot/skills/
Codex codex .codex/skills/ ~/.codex/skills/
Cursor cursor .cursor/skills/ ~/.cursor/skills/
Droid droid .factory/skills/ ~/.factory/skills/
Gemini CLI gemini-cli .gemini/skills/ ~/.gemini/skills/
GitHub Copilot github-copilot .github/skills/ ~/.copilot/skills/
Goose goose .goose/skills/ ~/.config/goose/skills/
Kilo Code kilo .kilocode/skills/ ~/.kilocode/skills/
Kiro CLI kiro-cli .kiro/skills/ ~/.kiro/skills/
OpenCode opencode .opencode/skills/ ~/.config/opencode/skills/
Roo Code roo .roo/skills/ ~/.roo/skills/
Trae trae .trae/skills/ ~/.trae/skills/
Windsurf windsurf .windsurf/skills/ ~/.codeium/windsurf/skills/

关于OpenTiny

欢迎加入 OpenTiny 开源社区。添加微信小助手:opentiny-official 一起参与交流前端技术~
OpenTiny 官网:opentiny.design
OpenTiny 代码仓库:github.com/opentiny
TinyVue skill源码:github.com/opentiny/ag… (欢迎 Star ⭐)

欢迎进入代码仓库 Star🌟TinyVue、TinyEngine、TinyPro、TinyNG、TinyCLI、TinyEditor 如果你也想要共建,可以进入代码仓库,找到 good first issue标签,一起参与开源贡献~

从入门到精通:Vue3 ref vs reactive 最佳实践与底层原理

在 Vue 3 中,ref 和 reactive 是 Composition API 提供的两个核心响应式 API,用于创建响应式状态。它们都基于 JavaScript 的 Proxy(reactive)和 getter/setter(ref 的内部机制)来实现响应式追踪,但在使用场景和行为上有一些关键区别。


1. ref

用途

  • 用于定义基本数据类型(如 stringnumberboolean)的响应式数据。
  • 也可以用于定义对象或数组,此时内部会自动调用 reactive
  • 在模板中使用时,无需 .value,Vue 会自动解包。
  • 在 JavaScript 中访问或修改时,必须通过 .value

示例

import { ref } from 'vue'

const count = ref(0)
console.log(count.value) // 0

count.value++
<template>
  <p>{{ count }}</p> <!-- 自动解包,无需 .value -->
  <button @click="count++">增加</button>
</template>

特点

  • 适用于任何类型。
  • 对于对象/数组,ref 内部会调用 reactive
  • 可以通过 ref() 创建对对象的响应式引用,保留其引用身份(identity)。

2. reactive

用途

  • 专门用于定义对象或数组类型的响应式数据。
  • 不能用于基本数据类型(如 numberstring)。
  • 返回的是一个代理对象(Proxy),直接操作其属性即可,不需要 .value

示例

import { reactive } from 'vue'

const state = reactive({
  count: 0,
  user: { name: 'Alice' }
})

state.count++
state.user.name = 'Bob'
<template>
  <p>{{ state.count }}</p>
  <p>{{ state.user.name }}</p>
</template>

特点

  • 只能用于对象/数组。

  • 返回的是原始对象的代理,无法替换整个对象(否则失去响应性)。

    // ❌ 错误做法:直接赋值新对象会丢失响应性
    state = { count: 1 } 
    
    // ✅ 正确做法:修改属性
    state.count = 1
    

对比总结

特性 ref reactive
支持类型 任意类型(基本类型 + 对象/数组) 仅对象或数组
访问方式(JS 中) 需 .value 直接访问属性
模板中使用 自动解包,无需 .value 直接访问
替换整个对象 可以(重新赋值 .value 不可以(会丢失响应性)
内部实现 基本类型用 getter/setter;对象用 reactive 基于 Proxy
适用场景 简单值、需要替换整个对象的情况 复杂对象状态管理

最佳实践建议

  • 优先使用 ref:尤其在 TypeScript 项目中,ref 的类型推断更直观,且统一使用 .value 有助于代码一致性。
  • 当你有一个复杂的对象状态,并且不需要替换整个对象时,可以使用 reactive
  • 避免混用导致困惑。例如,不要在一个 reactive 对象中嵌套 ref 除非必要(虽然 Vue 会自动解包,但可能影响可读性)。

补充:toRefs 和 toRef

当你从 reactive 对象中解构属性时,会丢失响应性。此时可使用 toRefs 或 toRef

import { reactive, toRefs } from 'vue'

const state = reactive({ count: 0 })
const { count } = toRefs(state) // count 是一个 ref

count.value++ // 仍然响应式

大屏天气展示太普通?视觉升级!用 Canvas 做动态天气遮罩,雷阵雨效果直接封神

之前做天气那个模块的时候,突发奇想想做一个大屏实时展示天气状况的蒙版。# Vue实现大屏获取当前所处城市及当地天气(纯免费)

需求

现在大屏上展示天气一般都是在左上/右上做天气的图标/纯文字的展示,虽然看起来非常直观,但是对于大屏这种需要炫酷效果的产品显得不合适。

目前市面上对于天气这一块也并不是非常重视,我接触的大屏项目/产品对这部分基本都没啥要求。

但是能够展示天气效果对于大屏本身有相当不错的加成效果。

屏幕录制 2026-03-05 102909.gif

所以我开发了这个大屏天气展示蒙版组件,能够根据当前天气状况以蒙版的形式展示出来,目前支持多种天气的展示效果。

方案

视频方案

一开始考虑的是纯视频解决方案,首先说这个方案非常的简单,将视频以背景图的形式放在蒙版上,通过 pointer-events: none; 鼠标穿透就能算是完成了。

但是实际操作过程中发现问题比较多,首先是透明背景需要特定格式的视频才能够支持。

必须使用支持 Alpha 通道(透明通道)的视频格式‌。

常见支持透明背景的格式包括:

  • ‌WebM(VP8 或 VP9 编码 + Alpha 通道)‌:Chrome、Firefox 和 WebView2 等 Chromium 内核环境支持良好 。
  • ‌MOV(Apple ProRes 4444 编码)‌:支持 Alpha 通道,但主要在 macOS 和专业软件(如 Final Cut Pro、After Effects)中使用 ‌。
  • ‌MP4(H.265/HEVC 编码)‌:部分平台(如 WebView2)支持含 Alpha 通道的 H.265 视频。

但是我在网上并没有找到相应格式的视频,自己录也弄得不好,所以放弃了。

另外以视频作为背景图在弱网环境下比较难加载,毕竟视频一般都要超过5M以上了。

但是如果有相应的视频,效果做出来绝对是最顶尖的。

GIF动图方案

和视频方案基本一致,唯一的区别是使用 GIF 动图作为背景图使用,效果也非常好。

问题点在于需要UI做一系列的动图效果,GIF 动图在加载上速度也不算太快,毕竟比较好的动图也不会太小。

还有一个问题在于如果屏幕大小发生变化,或者不是标准屏,可能存在图片拉伸/裁切等问题。

如果有UI协助,采用这个方案也非常不错。

Canvas渲染

采用 Canvas 渲染的方案实现这个是我最后的选择,原因有三:

  • Canvas性能开销不算太大,对低端设备相对比较友好
  • Canvas不依赖静态资源,弱网环境下不影响加载效果
  • Canvas能够根据屏幕大小达到自适应效果,避免特殊屏幕尺寸显示异常

采用 Canvas 粒子效果和渐变效果模拟阳光和雨滴、雪花等等状态,实现天气状态。

代码

初始化遮罩层

目前使用的是 Vue3 框架,因为是遮罩层所以采用 pointer-events: none; 鼠标穿透,避免影响大屏正常的操作。

<template>
    <canvas
        ref="weatherCanvas"
        class="weather-mask"
        :style="{ opacity: maskOpacity }"
    ></canvas>
</template>

<style scoped>
.weather-mask {
    position: absolute;
    top: 0;
    left: 0;
    width: 100%;
    height: 100%;
    pointer-events: none; /* 鼠标事件穿透 */
    z-index: 10; /* 确保在内容上方,可根据项目调整 */
}
</style>

这里需要注意,初始化画布的时候要记得设置一下width、height,让画布充满整个屏幕。

晴天效果

晴天效果采用光照渐变效果,在 Canvas 中绘制了一个从左上角到右下角线性渐变的效果,来模拟阳光照射的感觉。

同时增加部分光斑效果,模仿阳光投射在玻璃上的感觉。

// 创建从左上角到右下角的线性渐变(模拟阳光照射)
lightGradient = ctx.createLinearGradient(0, 0, canvas.width, canvas.height);

// 绘制光斑效果
ctx.beginPath();
ctx.arc(x, y, radius, 0, Math.PI * 2);
ctx.fillStyle = `rgba(255, 255, 200, ${Math.random() * 0.1 + 0.05})`;
ctx.fill();

雨天效果

雨天采用粒子效果,实现细长的雨丝效果,这里没有做明显的区分,对于小雨、中雨、大雨。

其实想要区分也很简单,只要控制粒子的数量和速度即可。

ctx.beginPath();
ctx.moveTo(particle.x, particle.y);
ctx.lineTo(particle.x, particle.y + particle.height);
ctx.strokeStyle = particle.color.replace('OPACITY', particle.opacity);
ctx.lineWidth = particle.width;
ctx.stroke();

这里我进行了简单的封装,因为雨天、雪天、雾天等等大部分都用到了粒子效果,所以针对粒子的绘制部分进行了封装。

因为下雨是一个连续的绘制过程,所以动画部分做了简单的循环。

const animate = () => {
    updateParticles(props.weatherType);
    animationId = requestAnimationFrame(animate);
};

下雪效果

下雪本质上和下雨区别不大,唯一的区别是粒子的状态、运动速度和运动方向。

这里没有采用雪花造型的粒子,确实做出来了,但是效果并不好,不如这种圆形的效果看起来好一些。

雪花的绘制和雨滴的绘制区别在于,雨滴的宽度是1,而雪花的大小是一定范围内随机的。

ctx.beginPath();
ctx.arc(particle.x, particle.y, particle.radius, 0, Math.PI * 2);
ctx.fillStyle = particle.color.replace('OPACITY', particle.opacity);
ctx.fill();

雷阵雨效果

雷阵雨效果是这里面个人觉得做的最好的一个,通过对下雨效果增加随机雷电闪烁屏幕的效果,达到雷阵雨天气的遮罩。

下雨仍然是复用的。

// 绘制主闪电路径
ctx.globalCompositeOperation = 'lighter';
ctx.strokeStyle = `rgba(255, 255, 255, ${thunderAlpha})`;
ctx.lineWidth = Math.random() * 8 + 4;
ctx.lineCap = 'round';
ctx.beginPath();
ctx.moveTo(startX, startY);

// 绘制闪电分支
ctx.lineWidth = Math.random() * 4 + 1;
ctx.beginPath();
ctx.moveTo(branch.startX, branch.startY);
let bx = branch.startX;
let by = branch.startY;
const dx = Math.random() * 30 - 15;
const dy = Math.random() * 20 + 5;
ctx.lineTo(bx + dx, by + dy);
bx += dx;
by += dy;
ctx.stroke();

// 闪烁效果
ctx.fillStyle = `rgba(255, 255, 255, ${thunderAlpha * 0.1})`;

总结

这个遮罩我做了好几天,Canvas部分我也不是特别的熟悉,所以很多地方仍然有非常大的优化空间,有感兴趣的朋友可以移步下面的文章获取源代码。

# 动态天气实时渲染动态生成组件,附源代码及详细注释

至于为啥收费,我也是想尝试一下代码还能不能搞到钱,毕竟现在的软件行业白嫖是大家的常态。

如果您能支持1元钱那我不胜感激,如果确实认为不值,自己能够写出更好的,那我也祝福。

一共做个几个效果:晴、雨、雪、雾、雷阵雨、多云、沙尘、阴天。有兴趣的朋友可以运行起来自行查看一下。

文本字符数统计 在线工具核心JS实现

这篇只讲功能层 JavaScript。这个工具的实现方式很直接:用户输入文本后,触发统一统计函数,一次计算出全部指标,再把结果绑定到界面。

在线工具网址:see-tool.com/text-charac…
工具截图:
工具截图.png

1. 核心状态

先定义输入文本、统计结果、字符频率三个响应式状态:

import { ref } from 'vue'

const inputText = ref('')

const stats = ref({
  lines: 0,
  chars: 0,
  chinese: 0,
  english: 0,
  words: 0,
  numbers: 0,
  symbols: 0,
  displayLength: 0,
  fileSize: 0,
  charsNoSpace: 0,
  sentences: 0,
  paragraphs: 0,
  avgWordLen: '0',
  readTime: 0
})

const charFrequency = ref([])

2. 统一统计入口函数

输入框 @input 直接调用 updateStatistics,所有统计都在这个函数里完成:

const updateStatistics = () => {
  if (!process.client) return

  const text = inputText.value

  // 行数
  const lines = text ? text.split('\n') : []
  stats.value.lines = lines.length

  // 总字符数
  stats.value.chars = text.length

  // 中文字符数
  const chineseChars = text.match(/[\u4e00-\u9fff]/g) || []
  stats.value.chinese = chineseChars.length

  // 英文字符数
  const englishChars = text.match(/[a-zA-Z]/g) || []
  stats.value.english = englishChars.length

  // 单词数
  const words = text.trim() ? text.trim().split(/\s+/).filter(w => w.length > 0) : []
  stats.value.words = words.length

  // 符号数(排除字母、数字、下划线、空白、中日韩统一表意文字)
  const symbols = text.match(/[^\w\s\u4e00-\u9fff]/g) || []
  stats.value.symbols = symbols.length

  // 数字数
  const numbers = text.match(/[0-9]/g) || []
  stats.value.numbers = numbers.length

  // 显示长度:中文记 2,其它记 1
  let displayLength = 0
  for (const char of text) {
    if (/[\u4e00-\u9fff]/.test(char)) {
      displayLength += 2
    } else {
      displayLength += 1
    }
  }
  stats.value.displayLength = displayLength

  // UTF-8 字节大小
  stats.value.fileSize = new Blob([text]).size

  // 去空白字符数
  stats.value.charsNoSpace = text.replace(/\s/g, '').length

  // 句子数
  const sentences = text.split(/[.!?。!?]+/).filter(s => s.trim().length > 0)
  stats.value.sentences = sentences.length

  // 段落数(空行分隔)
  const paragraphs = text.split(/\n\s*\n/).filter(p => p.trim().length > 0)
  stats.value.paragraphs = paragraphs.length

  // 平均词长
  const avgWordLen = words.length > 0
    ? (words.reduce((sum, w) => sum + w.length, 0) / words.length).toFixed(1)
    : '0'
  stats.value.avgWordLen = avgWordLen

  // 阅读时长(200词/分钟)
  const readTime = Math.ceil(words.length / 200)
  stats.value.readTime = readTime

  updateCharFrequency(text)
}

这段代码把基础统计和派生统计放在同一流程,输入变化时只跑一次主函数,逻辑清晰。

3. 字符频率分析

字符频率的做法是遍历全文,过滤空白,统一小写,最后排序截断:

const updateCharFrequency = (text) => {
  if (!text.trim()) {
    charFrequency.value = []
    return
  }

  const freq = {}
  for (const char of text) {
    if (/\S/.test(char)) {
      const lower = char.toLowerCase()
      freq[lower] = (freq[lower] || 0) + 1
    }
  }

  const sorted = Object.entries(freq)
    .sort((a, b) => b[1] - a[1])
    .slice(0, 20)
    .map(([char, count]) => ({ char, count }))

  charFrequency.value = sorted
}

这里 Aa 会被合并统计,更符合实际阅读习惯。

4. 复制统计结果

复制逻辑分两层:优先使用 Clipboard API,不可用时自动降级:

const formatNumber = (num) => num.toLocaleString()

const copyStats = async (t, MessagePlugin) => {
  if (!process.client) return

  const statsText = [
    t('textCharacterCount.statsResult'),
    '==================',
    `${t('textCharacterCount.lines')}: ${formatNumber(stats.value.lines)}`,
    `${t('textCharacterCount.chars')}: ${formatNumber(stats.value.chars)}`,
    `${t('textCharacterCount.chinese')}: ${formatNumber(stats.value.chinese)}`,
    `${t('textCharacterCount.english')}: ${formatNumber(stats.value.english)}`,
    `${t('textCharacterCount.words')}: ${formatNumber(stats.value.words)}`,
    `${t('textCharacterCount.numbers')}: ${formatNumber(stats.value.numbers)}`,
    `${t('textCharacterCount.symbols')}: ${formatNumber(stats.value.symbols)}`,
    `${t('textCharacterCount.displayLength')}: ${formatNumber(stats.value.displayLength)} (${t('textCharacterCount.displayLengthHint')})`,
    `${t('textCharacterCount.fileSize')}: ${formatNumber(stats.value.fileSize)} ${t('textCharacterCount.bytes')}`,
    `${t('textCharacterCount.charsNoSpace')}: ${formatNumber(stats.value.charsNoSpace)}`,
    `${t('textCharacterCount.sentences')}: ${formatNumber(stats.value.sentences)}`,
    `${t('textCharacterCount.paragraphs')}: ${formatNumber(stats.value.paragraphs)}`,
    `${t('textCharacterCount.avgWordLen')}: ${stats.value.avgWordLen}`,
    `${t('textCharacterCount.readTime')}: ${stats.value.readTime} ${t('textCharacterCount.minutes')}`
  ].join('\n')

  try {
    await navigator.clipboard.writeText(statsText)
    MessagePlugin.success(t('textCharacterCount.messages.copySuccess'))
  } catch {
    const textarea = document.createElement('textarea')
    textarea.value = statsText
    textarea.style.position = 'fixed'
    textarea.style.opacity = '0'
    document.body.appendChild(textarea)
    textarea.select()

    try {
      document.execCommand('copy')
      MessagePlugin.success(t('textCharacterCount.messages.copySuccess'))
    } catch {
      MessagePlugin.error(t('textCharacterCount.messages.copyFailed'))
    }

    document.body.removeChild(textarea)
  }
}

5. 示例文本与清空

两个动作都很轻:改值 + 重新统计。

const loadSample = (t, MessagePlugin) => {
  const sampleText = `Hello World! 这是一个文本统计分析的示例。

这个工具可以统计文本中的字符数、单词数、行数、句子数和段落数。
同时还能分析字符频率,帮助您了解文本的构成特点。`

  inputText.value = sampleText
  updateStatistics()
  MessagePlugin.success(t('textCharacterCount.messages.sampleLoaded'))
}

const clearText = (t, MessagePlugin) => {
  inputText.value = ''
  updateStatistics()
  MessagePlugin.info(t('textCharacterCount.messages.textCleared'))
}

6. 触发方式

输入区直接绑定:

<textarea v-model="inputText" @input="updateStatistics"></textarea>

这种绑定方式保证了“输入即统计”,不需要额外点击计算按钮。

《vue 2 升级vue3 父组件 子组件 传值: value 和 v-model

🧩 v-model 与 value 的关系

当你在一个原生 <input> 上使用 v-model 时,Vue 会将其展开为以下代码:

html

预览

1<!-- 你写的代码 -->
2<input v-model="message">
3
4<!-- Vue 展开后的代码 -->
5<input :value="message" @input="message = $event.target.value">

可以看到,v-model 自动利用了 value 属性来展示数据,并监听 input 事件来更新数据。

🆚 Vue 2 与 Vue 3 的核心区别

1. 响应式原理的变革 (根本原因)

这是导致所有行为差异的根源。

  • Vue 2: 使用 Object.defineProperty。它只能劫持对象的已有属性,无法检测到对象属性的动态添加或删除5。
  • Vue 3: 使用 Proxy。它代理整个对象,可以检测到对象属性的任意变化(增、删、改)25。

2. 组件上 v-model 的默认行为

这是你在开发中感受最明显的区别,尤其是在封装自定义组件时。

表格

特性 Vue 2 Vue 3
默认 Prop value modelValue
默认事件 input update:modelValue
多 Model 支持 不支持,需使用 .sync 修饰符 原生支持多个 v-model

代码对比:

  • Vue 2 中的组件使用

    html

    预览

    1<!-- 父组件 -->
    2<MyComponent v-model="title" />
    3
    4<!-- MyComponent 内部 -->
    5<template>
    6  <!-- 接收 value,触发 input -->
    7  <input :value="value" @input="$emit('input', $event.target.value)" />
    8</template>
    9<script>
    10export default {
    11  props: ['value'] // 默认接收 value
    12}
    13</script>
    
  • Vue 3 中的组件使用

    html

    预览

    1<!-- 父组件 -->
    2<MyComponent v-model="title" />
    3
    4<!-- MyComponent 内部 -->
    5<template>
    6  <!-- 接收 modelValue,触发 update:modelValue -->
    7  <input :value="modelValue" @input="$emit('update:modelValue', $event.target.value)" />
    8</template>
    9<script setup>
    10defineProps(['modelValue']) // 默认接收 modelValue
    11</script>
    

3. v-model 修饰符与多绑定

Vue 3 的 v-model 变得更加强大和灵活。

  • 多个 v-model:Vue 3 允许你在同一个组件上绑定多个 v-model,通过参数名区分14。

    html

    预览

    1<!-- Vue 3 语法 -->
    2<UserEditor 
    3  v-model:name="userName" 
    4  v-model:age="userAge"
    5/>
    

    这在 Vue 2 中是无法直接实现的,通常需要配合 .sync 修饰符来模拟。

  • 自定义修饰符:Vue 3 支持更灵活的修饰符扩展2。

4. 在原生元素上的表现

对于原生的 <input><textarea><select> 等元素,v-model 的用法在 Vue 2 和 Vue 3 中基本一致,都用于简化双向绑定的代码。主要区别体现在自定义组件的封装上。


💡 总结与迁移建议

  1. 核心变化:Vue 3 将组件 v-model 的默认 prop 从 value 改为了 modelValue,事件从 input 改为了 update:modelValue
  2. 迁移注意:当你将 Vue 2 项目升级到 Vue 3 时,所有自定义表单组件如果依赖默认的 v-model 行为,都需要将 props 中的 value 改为 modelValue,并将 $emit('input') 改为 $emit('update:modelValue')1。
  3. 兼容写法:如果你在 Vue 3 中需要兼容旧的组件库(如 Ant Design Vue),它们可能仍然使用 value prop,这时你需要显式地使用 v-model:value 来绑定,而不是简写的 v-model3。

Cursor配置MasterGo MCP:一键读取设计稿生成高还原度前端代码

通过在 Cursor 的 MCP 设置中添加命令 npx -y @mastergo/magic-mcp --token=YOUR_TOKEN,即可让 AI 直接读取 MasterGo 设计稿数据并自动生成高还原度的前端代码。

前言:告别像素级手磨代码

在传统的前端开发流程中,"从设计到代码"往往是最耗时的环节。开发者需要反复在设计工具和编辑器之间切换,手动测量间距、提取颜色值、计算布局比例。即便如此,最终的样式还原度也难以保证。随着 Cursor 引入了 MCP(Model Context Protocol)协议,MasterGo 官方推出的 Magic MCP 服务彻底打破了这一壁垒。它允许 Cursor AI 直接访问设计稿的底层 DSL 数据,这意味着 AI 不再是"看图说话",而是直接读取精确的设计规范,实现 99% 以上的样式还原。

第一步:获取 MasterGo 访问令牌 (Token)

要让 Cursor 有权限读取你的 MasterGo 文件,首先需要生成一个个人访问令牌。请登录 MasterGo 官网,点击右上角头像进入"个人设置",随后在"设置"菜单中找到"安全设置"选项。在这里你可以看到"生成令牌"的按钮,点击并为该令牌命名(如 Cursor-Integration)。系统会生成一段长字符串,请务必立即复制并妥善保存,因为出于安全考虑,该令牌在关闭窗口后将无法再次查看。 MasterGo MCP - MasterGo 帮助中心

第二步:环境准备与 Node.js 检查

MasterGo MCP 服务是基于 Node.js 运行的,因此在配置之前,请确保你的电脑已安装 Node.js 环境。你可以打开终端(Terminal 或 CMD),输入 node -v 来验证。如果显示版本号(建议 v18 及以上),则说明环境已就绪。如果尚未安装,请前往 Node.js 官网下载长期支持版(LTS)。此外,确保你的 Cursor 版本是最新的,以获得对 MCP 协议的最佳支持。 MasterGo MCP - MasterGo 帮助中心

第三步:在 Cursor 中激活 MasterGo MCP

Cursor 提供了两种配置 MCP Server 的方式,你可以根据自己的习惯选择:

方式一:通过 UI 界面配置(推荐新手)

打开 Cursor 的设置面板(快捷键 Ctrl + Shift + J 或点击右上角齿轮图标),导航至 Features 选项卡下的 MCP 栏目。点击 + Add New MCP Server 按钮,在弹出的窗口中填入以下信息:

  • Name: 建议填写 MasterGo
  • Type: 选择 command
  • Command: 输入 npx -y @mastergo/magic-mcp --token=你的Token(请将"你的Token"替换为第一步中获取的字符串)。

对于 Windows 用户,如果遇到执行权限问题,建议将 Command 栏的内容修改为 cmd /c npx -y @mastergo/magic-mcp --token=你的Token。点击保存后,如果看到绿色的连接状态,说明配置成功。

方式二:通过 mcp.json 配置文件(推荐进阶用户)

如果你更喜欢直接编辑配置文件,或者需要在多个项目中复用相同的 MCP 配置,可以手动创建或修改 mcp.json 文件。该文件通常位于以下位置之一:

  • 项目级别:.cursor/mcp.json(仅当前项目生效)
  • 全局级别:~/.cursor/mcp.json(所有项目生效)

将以下内容粘贴到配置文件中,并将 YOUR_TOKEN 替换为你实际获取的 Token:

{
  "mcpServers": {
    "mastergo-magic-mcp": {
      "command": "npx",
      "args": [
        "-y",
        "@mastergo/magic-mcp",
        "--token=YOUR_TOKEN",
        "--url=https://mastergo.com"
      ],
      "env": {
        "NPM_CONFIG_REGISTRY": "https://registry.npmjs.org/"
      }
    }
  }
}

这里的 env 字段配置了 npm 镜像源,可以有效避免国内网络环境下可能出现的包下载超时问题。保存文件后,重启 Cursor 使配置生效。 mastergo-design/mastergo-magic-mcp

第四步:实战演练——从设计稿到 React/Vue 组件

配置完成后,你就可以在 Cursor Chat 中通过链接直接### **通过在 Cursor 的 MCP 设置中添加命令 npx -y @mastergo/magic-mcp --token=YOUR_TOKEN,即可让 AI 直接读取 MasterGo 设计稿数据并自动生调用设计数据了。在 MasterGo 设计稿中,选中你想要生成的图层或容器,右键选择"复制链接"。回到 Cursor 的对话框,输入类似这样的指令:"参考这个设计稿链接 https://mastergo.com/file/xxxx?layer=yyyy,帮我用 React 和 Tailwind CSS 写一个响应式的商品卡片组件"。

此时,Cursor 会通过 MCP 插件调用 MasterGo 的 API,解析该图层的宽度、高度、圆角、阴影、字体样式以及 Flex 布局信息。它生成的代码将不再是模糊的猜测,而是带有精确像素值和 CSS 变量的高质量组件代码。

进阶技巧与常见问题排查

为了获得更佳的体验,你可以尝试一些高级配置。例如,在配置命令中添加 --cleanLayers=true 参数,可以自动过滤掉设计稿中冗余的编组层,让生成的代码结构更加扁平化。如果遇到连接超时,可以检查是否设置了网络代理,或者尝试在 env 中配置其他 npm 镜像源(如 https://registry.npmmirror.com)。

如果 Cursor 提示找不到工具,请检查 MCP 设置中的状态是否为 Active。有时重启 Cursor 能够解决大部分配置不生效的问题。此外,请确保你提供的 MasterGo 链接包含具体的 layer 参数,否则 AI 可能无法准确定位到具体的设计元素。 mastergo-design/mastergo-magic-mcp

希望这份指南能帮你成功开启 AI 驱动的设计开发新流。祝你的编码过程如丝般顺滑。

如何设计一个真正可扩展的表单生成器?

🧩 如何设计一个真正可扩展的表单生成器?

🧠 你写过多少次 CRUD 表单?登录表单、搜索表单、配置表单、后台管理表单……
有没有想过:为什么不抽象成一套“表单引擎”?

封装一个可以扩展的表单生成器,尤其是对一些中后台系统、低代码平台、企业级项目,会非常有价值。


🚀 一、从“写表单”到“设计表单系统”

我们先看一个普通的表单:

<el-form :model="form">
  <el-form-item label="用户名">
    <el-input v-model="form.username" />
  </el-form-item>

  <el-form-item label="年龄">
    <el-input-number v-model="form.age" />
  </el-form-item>
</el-form>

问题在哪?

  • ❌ 每个页面都写一遍
  • ❌ 字段变化要改代码
  • ❌ 无法动态生成
  • ❌ 后端配置驱动做不了

这时候我们会思考一个问题:

能不能用 JSON 描述表单?


📦 二、Schema 驱动:表单的核心抽象

理想状态是这样:

const schema = [
  {
    type: 'input',
    label: '用户名',
    field: 'username',
    props: {
      placeholder: '请输入用户名'
    }
  },
  {
    type: 'number',
    label: '年龄',
    field: 'age',
  }
]

然后我们写一个 <SchemaForm />

<SchemaForm :schema="schema" v-model="formData" />

这就是:

Schema Driven UI(配置驱动 UI)


🧠 三、设计表单生成器的核心架构

一个成熟的表单生成系统,至少包含 5 个层次:

Schema 配置层
      ↓
字段解析层
      ↓
组件映射层
      ↓
状态管理层
      ↓
渲染引擎层

我们逐层拆解。


🧩 四、组件映射系统设计(核心关键)

最重要的一步:

type → 组件映射

const componentMap = {
  input: ElInput,
  number: ElInputNumber,
  select: ElSelect,
}

渲染逻辑:

const Component = componentMap[item.type]

return h(Component, {
  ...item.props,
  modelValue: formData[item.field],
  'onUpdate:modelValue': (val) => {
    formData[item.field] = val
  }
})

这样我们就实现了:

  • ✅ 动态组件渲染
  • ✅ 双向绑定
  • ✅ 可扩展组件类型

🧱 五、真正高级的地方:扩展能力设计

一个“玩具级”表单生成器和一个“工程级”的区别在于:

可扩展能力

必须支持:

1️⃣ 动态显隐

{
  type: 'input',
  field: 'company',
  visible: (form) => form.role === 'admin'
}

解析时:

if (typeof item.visible === 'function') {
  return item.visible(formData)
}

2️⃣ 联动机制

{
  type: 'select',
  field: 'province',
  onChange: (val, form) => {
    form.city = ''
  }
}

3️⃣ 异步字段(远程选项)

{
  type: 'select',
  field: 'user',
  asyncOptions: () => fetchUserList()
}

4️⃣ 插槽扩展

<SchemaForm>
  <template #customField="{ field }">
    <MyCustomComponent />
  </template>
</SchemaForm>

🧠 六、状态管理怎么设计才优雅?

很多人会这样写:

const formData = reactive({})

但在复杂场景中:

  • 校验
  • dirty 状态
  • touched 状态
  • 提交状态
  • 异步 loading

你需要抽象出一个 FormStore

class FormStore {
  values = reactive({})
  errors = reactive({})
  touched = reactive({})

  setFieldValue(field, value) {
    this.values[field] = value
  }

  validate() {}
}

⚙️ 七、企业级表单生成器的高级能力

真正成熟的系统会支持:

能力 说明
嵌套表单 object / array 结构
动态增删字段 表单列表
表单分组 step 表单
表单布局系统 grid / col 配置
表单 JSON 导出 支持保存配置
拖拽编辑器 低代码场景
远程 schema 后端下发表单配置

🔥 八、进阶认知:为什么很多大厂都在做 Schema Form?

原因很简单:

  • 后端驱动 UI
  • 多系统复用
  • 业务快速迭代
  • 统一规范
  • 降低重复开发成本

Ant Design Pro、阿里飞冰、字节内部平台,核心都在做这件事。


🧠 九、总结:表单生成器的本质是什么?

不是为了“少写代码”。

而是:

把 UI 抽象成数据
把行为抽象成规则
把渲染抽象成引擎

别再用 scoped 了!Vue 项目中真正安全的 CSS 封装方案,第 3 种连尤雨溪都在用

上周,设计师跑来问我:“为什么这个按钮在 A 页面是蓝色,在 B 页面变成紫色了?”

我一查代码,发现两个组件都写了:

.btn {
  background: blue;
}

<style scoped> 根本没生效——因为某个第三方 UI 库用了 :global(.btn),污染了全局。

那一刻我悟了:scoped 不是银弹,它只是“看起来安全”。

今天,我就带你盘点 Vue 项目中 4 种真正可靠的 CSS 封装方案,从“能用”到“企业级”,尤其第 3 种,连 Vue 官方文档和 Vite 团队都在悄悄推广。


先看一张对比表(建议收藏)

方案 隔离性 可维护性 支持动态主题 学习成本
<style scoped> ⚠️ 中(会被 :global 破坏) 低(命名仍可能冲突) ❌ 难
CSS Modules ✅ 强 ⚠️ 需额外处理
CSS-in-JS(如 Vanilla Extract) ✅✅ 极强 ✅ 原生支持 中高
CSS 变量 + 作用域类名(推荐!) ✅ 强 ✅✅ 极高 ✅✅ 天然支持

核心原则:隔离靠机制,不是靠“看起来不一样”


方案 1:<style scoped> —— 谨慎使用!

Vue 的 scoped 通过给元素加 data-v-xxxx 属性实现样式隔离:

<template>
  <button class="btn">Click</button>
</template>

<style scoped>
.btn { color: red; } /* 编译后 → .btn[data-v-f3f3eg9] */
</style>

致命缺陷

  • 无法防止 全局样式污染(比如 reset.css 或 UI 库)
  • 深度选择器>>>:deep())容易误伤其他组件
  • 动态插入的 HTML(如富文本)无法应用 scoped 样式

适用场景:内部工具、小型页面、快速原型

不要用在:对外组件库、多团队协作项目、需要主题切换的系统


方案 2:CSS Modules —— 经典但略重

启用后,每个 class 会被哈希化:

// Button.module.css
.primary { background: blue; }

// Button.vue
import styles from './Button.module.css';
// styles.primary → "Button_primary__aB3cD"
<template>
  <button :class="styles.primary">OK</button>
</template>

优点:

  • 100% 隔离,不怕任何全局污染
  • 支持组合(composes

缺点:

  • 模板里写 :class="styles.xxx" 略啰嗦
  • 不支持原生 CSS 嵌套(除非配合 PostCSS)
  • 动态主题需配合 JS 重新生成

在 Vite 中开启:

// vite.config.ts
export default defineConfig({
  css: { modules: { localsConvention: 'camelCase' } }
})

方案 3:CSS 变量 + 作用域类名(尤雨溪团队推荐!)

这是 Vue 官方新文档Vite 插件生态 中越来越主流的做法。

核心思想:用 CSS 变量定义设计 token,用唯一类名包裹组件

<template>
  <div class="my-button--root">
    <button class="my-button--inner">Submit</button>
  </div>
</template>

<style>
.my-button--root {
  /* 定义局部变量 */
  --btn-bg: var(--theme-primary, #3b82f6);
  --btn-color: white;
}

.my-button--inner {
  background: var(--btn-bg);
  color: var(--btn-color);
  border: none;
  padding: 8px 16px;
  border-radius: 4px;
}
</style>

神奇在哪?

  1. 天然支持主题切换
/* 全局定义亮色主题 */
:root {
  --theme-primary: #3b82f6;
}
/* 暗色主题 */
.dark {
  --theme-primary: #60a5fa;
}

只需切换 <html class="dark">,所有组件自动适配!

  1. 无构建时哈希,调试友好
  2. 类名前缀化(如 my-button--)避免冲突,比随机 hash 更语义化

这正是 ShadCN VueRadix Vue 等现代组件库的做法。


方案 4:零运行时 CSS-in-JS(Vanilla Extract)

如果你追求极致工程化,试试 编译时 CSS-in-JS

// Button.css.ts
import { style } from '@vanilla-extract/css';

export const root = style({
  vars: {
    '--btn-bg': '#3b82f6'
  }
});

export const inner = style({
  background: 'var(--btn-bg)',
  color: 'white',
  borderRadius: 4,
  selectors: {
    '&:hover': { opacity: 0.9 }
  }
});
<script setup lang="ts">
import * as styles from './Button.css';
</script>

<template>
  <div :class="styles.root">
    <button :class="styles.inner">OK</button>
  </div>
</template>

优势:

  • 100% 类型安全(TS 直接提示拼写错误)
  • 零运行时(编译成静态 CSS 文件)
  • 自动作用域(生成哈希类名)
  • 支持主题变量、条件样式

配合 Vite 插件 @vanilla-extract/vite-plugin 即可使用。


实战建议:怎么选?

项目类型 推荐方案
内部后台系统 CSS 变量 + 作用域类名(方案 3)
对外组件库 CSS 变量 + 作用域类名 or Vanilla Extract
快速原型 scoped(但警惕全局污染)
超大型应用(含多主题/国际化) Vanilla Extract(方案 4)

永远不要:

  • 在 scoped 中大量使用 :deep()
  • 把业务样式写进全局 app.css
  • 用 BEM 命名试图“人工隔离”(治标不治本)

各位互联网搭子,要是这篇文章成功引起了你的注意,别犹豫,关注、点赞、评论、分享走一波,让我们把这份默契延续下去,一起在知识的海洋里乘风破浪!

Pinia状态管理原理:从响应式核心到源码实现

在前面的文章中,我们学习了 Vue Router 与响应式系统的集成。今天,我们将探索 Pinia,这是 Vue 官方推荐的状态管理库。Pinia 充分利用 Vue3 的响应式系统,提供了简单、类型安全的状态管理方案。理解它的实现原理,将帮助我们更好地组织应用状态,写出更可维护的代码。

前言:状态管理的演进

随着应用规模增长,组件间共享状态变得越来越复杂: 组件通信复杂性 在 Vue2 开发中,使用 Vuex 状态管理来解决组件共享状态问题;而 Vue3 则采用了 Pinia 的方式,为什么会有这层变化呢?

传统 Vuex 的问题

  • 繁琐的 mutations:必须通过 mutations 修改状态
  • 类型支持差:TypeScript 体验不佳
  • 模块化复杂:namespaced 概念增加心智负担
  • 体积较大:包含大量模板代码

Pinia的优势:

  • 直接修改状态:无需 mutations
  • 完美的类型推导:原生 TypeScript 支持
  • 扁平化结构:没有嵌套模块
  • 轻量高效:核心逻辑精简

Pinia 的设计理念与架构

Pinia 的本质

Pinia 本质上是一个 基于 Vue 3 响应式系统 + effectScope 的全局可控副作用容器 。它的核心目标是以最简洁的方式管理全局状态,同时保持类型安全和开发体验。

整体架构分层

Pinia 的源码架构可以清晰地分为三层: Pinia三层架构 这种分层设计使得 Pinia 既保持了上层 API 的简洁性,又能够充分利用 Vue 3 底层响应式系统的能力。

Pinia 如何利用 Vue 3 响应式系统

响应式核心:reactive 与 ref

Pinia 的状态管理完全建立在 Vue 3 的响应式 API 之上。当我们在 Pinia 中定义状态时,实际上是在创建 Vue 的响应式对象 :

// Pinia 内部的核心实现
import { reactive, ref } from 'vue'

// 选项式 Store 的 state 会被转换为 reactive
const state = reactive({
  count: 0,
  user: null
})

// 组合式 Store 直接使用 ref/reactive
const count = ref(0)
const user = ref(null)

Pinia 并不会重新发明一套响应式系统,而是直接复用 Vue 的响应式能力,这意味着:

  • 状态变化自动触发视图更新:当 state 变化时,所有依赖它的组件会自动重新渲染
  • 依赖自动收集:getters 中访问 state 时,Vue 会自动收集依赖关系

effectScope:全局副作用管理

Pinia 的一个重要创新是使用 Vue 3 的 effectScope API 来管理所有 store 的副作用 :

// createPinia 源码简化
export function createPinia() {
  // 创建全局 effectScope
  const scope = effectScope(true)
  
  // 全局 state 容器
  const state = scope.run(() => ref({}))!

  const pinia = markRaw({
    _e: scope,        // 全局 scope
    _s: new Map(),    // store 注册表
    state,            // 全局 state
    install(app) {
      app.provide(piniaSymbol, pinia)
    }
  })

  return pinia
}

这种设计有以下优势:

  • 统一管理:所有 storecomputedwatcheffect 都挂载在全局 scope
  • 一键清理:调用 pinia._e.stop() 即可销毁所有 store 的副作用
  • 每个 store 独立 scope:每个 store 还有自己的 scope,支持独立销毁(store.$dispose()

Store 的创建与类型推导

defineStore 的核心逻辑

defineStore 是用户定义 store 的入口,它返回一个 useStore 函数 :

// defineStore 源码简化
export function defineStore(id, setupOrOptions) {
  return function useStore() {
    // 获取当前活跃的 pinia 实例
    const pinia = getActivePinia()
    
    // 单例模式:同一 id 的 store 只创建一次
    if (!pinia._s.has(id)) {
      createStore(id, setupOrOptions, pinia)
    }
    
    return pinia._s.get(id)
  }
}

两种 Store 定义方式的实现

Pinia 支持两种定义 store 的方式:选项式 Store组合式 Store,它们的底层实现略有不同 :

选项式 Store(Options Store)

// 用户定义
export const useCounterStore = defineStore('counter', {
  state: () => ({ count: 0, name: 'Pinia' }),
  getters: {
    doubleCount: (state) => state.count * 2
  },
  actions: {
    increment() {
      this.count++
    }
  }
})

// 内部处理逻辑
function createOptionsStore(id, options, pinia) {
  const { state, getters, actions } = options
  
  // 1. 初始化 state
  pinia.state.value[id] = state ? state() : {}
  
  // 2. 创建 store 实例
  const store = reactive({})
  
  // 3. 将 state 转换为 refs 挂载到 store
  for (const key in pinia.state.value[id]) {
    store[key] = toRef(pinia.state.value[id], key)
  }
  
  // 4. 处理 getters -> 转换为 computed
  for (const key in getters) {
    store[key] = computed(() => {
      setActivePinia(pinia)
      return getters[key].call(store, store)
    })
  }
  
  // 5. 处理 actions -> 绑定 this
  for (const key in actions) {
    store[key] = wrapAction(key, actions[key])
  }
  
  return store
}

组合式 Store(Setup Store)

// 用户定义
export const useCounterStore = defineStore('counter', () => {
  const count = ref(0)
  const name = ref('Pinia')
  
  const doubleCount = computed(() => count.value * 2)
  
  function increment() {
    count.value++
  }
  
  return { count, name, doubleCount, increment }
})

// 内部处理逻辑
function createSetupStore(id, setup, pinia) {
  const scope = effectScope()
  
  // 运行 setup 函数,创建响应式状态
  const setupResult = scope.run(() => setup())
  
  // 创建 store 实例(reactive 包裹整个 store)
  const store = reactive({})
  
  // 将 setup 返回的属性挂载到 store
  for (const key in setupResult) {
    const prop = setupResult[key]
    store[key] = prop
  }
  
  pinia._s.set(id, store)
  return store
}

类型推导的实现

Pinia 的类型推导之所以强大,是因为它充分利用了 TypeScript 的 类型推断条件类型

// 简化的类型定义
export function defineStore<Id, S, G, A>(
  id: Id,
  options: Omit<DefineStoreOptions<Id, S, G, A>, 'id'>
): StoreDefinition<Id, S, G, A>

// 使用时的类型推导
const store = useCounterStore()
// TypeScript 自动推导出:
// store.count: number
// store.doubleCount: number
// store.increment: () => void

Actions 的实现原理

Action 的本质

Pinia 中的 actions 就是普通的函数,但它们的 this 被自动绑定到了 store 实例上 :

// 源码中的 action 包装
function wrapAction(name, action) {
  return function(this: any) {
    // 绑定 this 为当前 store
    return action.apply(this, arguments)
  }
}

同步与异步 Action

Piniaactions 天然支持同步和异步操作,无需任何特殊处理 :

export const useUserStore = defineStore('user', {
  state: () => ({
    user: null,
    loading: false
  }),
  
  actions: {
    // 同步 action
    setUser(user) {
      this.user = user
    },
    
    // 异步 action
    async fetchUser(id) {
      this.loading = true
      try {
        const response = await fetch(`/api/users/${id}`)
        this.user = await response.json()
      } finally {
        this.loading = false
      }
    }
  }
})

Actions 的订阅机制

Pinia 提供了 $onAction 方法来订阅 actions 的执行 :

// 源码简化
store.$onAction(({ name, store, args, after, onError }) => {
  console.log(`Action ${name} 开始执行`)
  
  after((result) => {
    console.log(`Action ${name} 执行完成`, result)
  })
  
  onError((error) => {
    console.error(`Action ${name} 执行失败`, error)
  })
})

Getters 的实现原理

Getter 的本质是 computed

Piniagetters 底层就是 Vue 的 computed 属性:

// 源码中的 getter 处理
for (const key in getters) {
  store[key] = computed(() => {
    // 确保当前 pinia 实例活跃
    setActivePinia(pinia)
    // 调用 getter 函数,绑定 this 为 store
    return getters[key].call(store, store)
  })
}

这意味着 getters 具备 computed 的所有特性:

  • 缓存性:只有依赖变化时才重新计算
  • 懒计算:只有在被访问时才执行
  • 响应式依赖收集:自动追踪依赖的 state

Getter 的互相调用

getters 之间可以相互调用,就像计算属性可以组合一样 :

getters: {
  doubleCount: (state) => state.count * 2,
  
  // 通过 this 访问其他 getter
  quadrupleCount(): number {
    return this.doubleCount * 2
  }
}

Pinia vs Vuex:核心差异对比

设计理念对比

维度 Pinia Vuex
API 设计 简洁直观,无 mutations 严格区分 state/getters/mutations/actions
TypeScript 支持 原生支持 需要手动声明类型,支持有限
模块化 store 自然拆分 单一 store + 模块嵌套
响应式系统 直接使用 reactive/computed 内部实现响应式
代码体积 轻量(约1KB) 相对较大

核心差异详解

Mutations 的废除

Pinia 最大的改变是移除了 mutations。在 Vuex 中,修改状态必须通过 mutations(同步)和 actions(异步): Vuex 方式:

mutations: {
  add(state) {
    state.count++
  }
},
actions: {
  increment({ commit }) {
    commit('add')
  }
}

而在 Pinia 中,actions 可以直接修改状态:

actions: {
  increment() {
    this.count++  // 直接修改
  }
}

模块化设计

  • Vuex:单一 store,通过 modules 拆分,需要处理命名空间
  • Pinia:每个 store 独立,按需引入,天然支持代码分割

TypeScript 支持

Pinia 在设计之初就充分考虑 TypeScript,几乎所有 API 都支持类型推导。

源码简析:Pinia 的核心逻辑

createPinia:全局容器创建

// 源码简化自 pinia/src/createPinia.ts
export function createPinia() {
  const scope = effectScope(true)
  
  // 全局状态容器
  const state = scope.run(() => ref({}))
  
  const pinia = markRaw({
    // 唯一标识
    __pinia: true,
    
    // 全局 effectScope
    _e: scope,
    
    // store 注册表
    _s: new Map(),
    
    // 全局状态
    state,
    
    // 插件数组
    _p: [],
    
    // Vue 插件安装方法
    install(app) {
      // 设置为当前活跃 pinia
      setActivePinia(pinia)
      
      // 通过 provide 注入
      app.provide(piniaSymbol, pinia)
      
      // 挂载 $pinia 到全局属性
      app.config.globalProperties.$pinia = pinia
      
      // 使用效果域来管理响应式
      pinia._e.run(() => {
        app.runWithContext(() => {
          // 初始化
        })
      })
    }
  })
  
  return pinia
}

响应式 store 的创建过程

// 源码简化自 pinia/src/store.ts
function createStore(id, options, pinia) {
  // 创建 store 的作用域
  const scope = effectScope()
  
  // 创建 store 实例(整个 store 是 reactive 的)
  const store = reactive({})
  
  // 初始化 state
  pinia.state.value[id] = options.state ? options.state() : {}
  
  // 将 state 转换为 ref 并挂载
  for (const key in pinia.state.value[id]) {
    store[key] = toRef(pinia.state.value[id], key)
  }
  
  // 处理 getters(转换为 computed)
  if (options.getters) {
    for (const key in options.getters) {
      store[key] = computed(() => {
        setActivePinia(pinia)
        return options.getters[key].call(store, store)
      })
    }
  }
  
  // 处理 actions(绑定 this)
  if (options.actions) {
    for (const key in options.actions) {
      store[key] = function(...args) {
        return options.actions[key].apply(store, args)
      }
    }
  }
  
  // 缓存 store 实例
  pinia._s.set(id, store)
  
  return store
}

storeToRefs 的实现原理

为什么直接从 store 解构会失去响应式?因为 store 本身是一个 reactive 对象,解构会得到原始值 。storeToRefs 的源码揭示了解决方案:

// 源码简化自 pinia/src/storeToRefs.ts 
export function storeToRefs(store) {
  // 将 store 转换为原始对象,避免重复代理
  store = toRaw(store)
  
  const refs = {}
  
  for (const key in store) {
    const value = store[key]
    
    // 只转换响应式数据(state 和 getters)
    if (isRef(value) || isReactive(value)) {
      // 使用 toRef 保持响应式连接
      refs[key] = toRef(store, key)
    }
  }
  
  return refs
}

这个实现的核心在于:

  • toRaw(store):脱掉 storeProxy 外壳,获取原始对象
  • 只转换响应式数据:过滤掉 actions 等非响应式属性
  • toRef 包装:创建 ref 引用,保持与原始数据的响应式连接

结语

Pinia 的成功告诉我们,优秀的状态管理库不一定要复杂,而是要在保持简洁的同时,充分利用框架底层的能力。理解 Pinia 的响应式原理,不仅有助于我们更好地使用它,也为我们在实际项目中设计和封装自己的组合式函数提供了思路和借鉴。

对于文章中错误的地方或有任何疑问,欢迎在评论区留言讨论!

前端组件化样式隔离实战:React CSS Modules、styled-components 与 Vue scoped 对比

前端组件化样式隔离实战:React CSS Modules、styled-components 与 Vue scoped 对比

引言:当组件遇见 CSS

在现代前端开发中,组件化已成为构建用户界面的主流方式。我们将页面拆分为独立、可复用的组件,每个组件管理自己的 HTML、CSS 和 JavaScript。然而,CSS 的设计初衷是全局作用域的 —— 样式一旦定义,就会影响整个页面,这给组件化带来了严峻挑战。

试想一个多人协作的项目:A 同学写了一个按钮组件,类名为 .button;B 同学也写了一个按钮组件,同样用了 .button。当两个组件同时出现在页面上时,后加载的样式会覆盖前者,造成意料之外的 UI 错乱。如何让组件的样式“与世隔绝”,既不影响他人,也不被他人影响?本文将深入探讨 React 和 Vue 生态中三种主流的样式隔离方案:CSS Modulesstyled-componentsVue scoped。我们将通过实际代码,由浅入深地理解它们的原理与用法。

1. CSS 的“先天不足”与组件化的冲突

在传统网页开发中,我们通常这样写 CSS:

/* global.css */
.button {
  background-color: blue;
  color: white;
}

这个 .button 样式会作用于页面上所有带有 class="button" 的元素,无论它身处哪个组件。这种全局性在小型项目中或许无伤大雅,但在组件化架构下却成了灾难。

假设我们有 Button.jsxAnotherButton.jsx 两个组件,分别引入了各自的 CSS 文件:

/* Button.css */
.button { background: blue; }

/* AnotherButton.css */
.button { background: red; }
效果图

image.png

最终页面上两个按钮都会是红色,因为后引入的 AnotherButton.css 覆盖了前者的规则。这就是样式冲突的典型场景。

为了解决这一问题,社区发展出了多种作用域隔离方案,核心思想都是将样式“限定”在组件内部。下面我们分别看看 React 和 Vue 是如何做到的。

2. React 中的 CSS Modules

2.1 什么是 CSS Modules?

CSS Modules 是一种将 CSS 文件编译为局部作用域的技术。它并不是官方的 CSS 规范,而是通过构建工具(如 webpack)在编译时给类名自动添加唯一的哈希字符串,从而实现样式隔离。在 React 项目中,使用 Create React App 或 Vite 脚手架时,开箱即支持 CSS Modules。

2.2 基本用法

我们约定 CSS 文件命名为 *.module.css。在组件中像导入一个对象一样导入样式文件,然后通过对象的属性引用类名。

Button.module.css

.button {
  background-color: blue;
  color: white;
  padding: 10px 20px;
}

.txt {
  color: red;
  background-color: orange;
  font-size: 30px;
}

Button.jsx

import styles from './Button.module.css';
console.log(styles); // 输出:{ button: "Button_button__1a2b3c", txt: "Button_txt__4d5e6f" }

export default function Button() {
  return (
    <>
      <h1 className={styles.txt}>你好,世界!!!</h1>
      <button className={styles.button}>My Button</button>
    </>
  );
}
效果图

image.png

在浏览器中,最终渲染的 HTML 类似:

<h1 class="Button_txt__4d5e6f">你好,世界!!!</h1>
<button class="Button_button__1a2b3c">My Button</button>
打开控制台我们点击元素开可以看到每个元素都有唯一的id

image.png

可以看到,原始的类名 .button.txt 被转换成了带有组件名和哈希的唯一类名,从而避免了全局污染。

2.3 多人协作的保障

再来看另一个组件 AnotherButton,它也定义了同名的 .button 样式:

anotherButton.module.css

.button {
  background-color: red;
  color: black;
  padding: 10px 20px;
}

AnotherButton.jsx

import styles from './anotherButton.module.css';

export default function AnotherButton() {
  return <button className={styles.button}>My Another Button</button>;
}

两个组件的样式互不干扰,因为编译后的类名分别是 AnotherButton_button__xxxButton_button__xxx。这正是 CSS Modules 的魅力所在——让开发者无需担心类名冲突,专注于组件本身的样式。

2.4 原理浅析

CSS Modules 的原理并不复杂:在构建阶段,webpack 的 css-loader 会解析 *.module.css 文件,将每个类名映射为一个唯一的标识符(通常是 [文件名]_[类名]__[hash]),同时生成一个映射对象(即 styles)。在 JavaScript 中,我们通过这个映射对象来引用最终的类名,而 CSS 文件中的原始类名则被替换为哈希后的类名。这样,CSS 和 JS 就通过同一份映射关系保证了样式的私有性。

3. React 中的 styled-components

如果说 CSS Modules 是在编译时通过修改类名来实现隔离,那么 styled-components 则代表了另一种思潮:CSS-in-JS,即在 JavaScript 中编写 CSS,并利用 JavaScript 的作用域来实现样式隔离。

3.1 什么是 styled-components?

styled-components 是一个流行的 React 库,它允许你使用 ES6 的模板字符串定义样式组件,这些样式组件会自动生成一个唯一的类名,并将样式注入到 <head> 中。

3.2 基本用法

首先安装 styled-components:

npm install styled-components

然后在组件中创建样式化组件:

import styled from 'styled-components';

// 定义一个带样式的 button 组件
const Button = styled.button`
  background-color: ${props => props.primary ? 'blue' : 'white'};
  color: ${props => props.primary ? 'white' : 'blue'};
  border: 1px solid blue;
  padding: 8px 16px;
  border-radius: 4px;
`;

function App() {
  return (
    <>
      <Button>默认按钮</Button>
      <Button primary>主要按钮</Button>
    </>
  );
}
效果图

image.png 渲染后的 HTML 如下(每个人的截图中的真实类名可能不同):

<button class="sc-axZvf jflFSQ">默认按钮</button>
<button class="sc-axZvf efDizw">主要按钮</button>
打开控制台点开控制台元素,我们同样可以看到每个元素都有唯一id

image.png 这里的 sc-axZvf 是组件标识前缀,同一组件生成的实例共享这个前缀,而 jflFSQ 和 efDizw 则是具体的样式类名,分别对应不同的样式规则(例如一个是默认样式,一个是 primary 样式)。所有样式都被动态地生成为 <style> 标签插入页面头部。

3.3 动态样式与 props

styled-components 的一大优势是支持基于 props 的动态样式。如上例所示,通过 props.primary 可以轻松改变背景色和文字颜色。这比传统 CSS 需要额外维护多个类名要直观得多。

3.4 原理浅析

styled-components 在运行时(runtime)工作:当组件渲染时,它会解析模板字符串中的样式规则,根据 props 计算出最终的 CSS 文本,然后生成一个唯一的类名(如 jflFSQ),并将 CSS 规则以 <style> 标签的形式插入到文档头部。值得注意的是,同一组件(如 Button)的所有实例会共享一个组件级标识(sc-axZvf),而具体样式类名则每个实例或每个变体可能不同。由于每个组件实例都可能生成不同的类名,样式天然是隔离的。同时,它还能自动处理浏览器前缀、关键帧动画等,为开发者提供了良好的体验。

4. Vue 中的 scoped 样式

Vue 作为另一大前端框架,其单文件组件(SFC)提供了内置的样式隔离方案——scoped 属性。

4.1 什么是 scoped?

在 Vue 的单文件组件中,可以在 <style> 标签上添加 scoped 属性,指示该样式只作用于当前组件。它的实现方式是为组件模板中的元素添加唯一的自定义属性(如 data-v-xxxxx),然后通过属性选择器来限制样式的生效范围。每个组件会生成一个唯一的哈希 ID,该组件内的所有元素都会被打上这个 ID 作为属性。

4.2 基本用法

App.vue

<script setup>
import HelloWorld from './components/HelloWorld.vue'
</script>

<template>
  <div>
    <h1 class="txt">Hello world in App</h1>
    <h2 class="txt2">一点点</h2>
    <HelloWorld />
  </div>
</template>

<style scoped>
.txt {
  color: red;
}
.txt2 {
  color: green;
}
</style>

HelloWorld.vue

<template>
  <div>
    <h1 class="txt">你好,世界!!!</h1>
    <h2 class="txt2">一点点</h2>
  </div>
</template>

<style scoped>
.txt {
  color: blue;
}
.txt2 {
  color: orange;
}
</style>
效果图

image.png

4.3 渲染结果与原理

编译后,Vue 会为每个组件生成一个唯一的哈希 ID。假设 App 组件的 ID 为 data-v-7a7a37b1,HelloWorld 组件的 ID 为 data-v-e17ea971。最终渲染的 HTML 结构如下(来自实际截图):

html

<div data-v-7a7a37b1>
  <h1 data-v-7a7a37b1 class="txt">Hello world in App</h1>
  <h2 data-v-7a7a37b1 class="txt2">一点点</h2>
</div>

<div data-v-e17ea971 data-v-7a7a37b1>
  <h1 data-v-e17ea971 class="txt">你好,世界!!!</h1>
  <h2 data-v-e17ea971 class="txt2">一点点</h2>
</div>

仔细观察可以发现:

  • App 组件内的所有元素(包括根 div)都带有自己的 ID data-v-7a7a37b1
  • HelloWorld 组件内的所有元素(包括其根 div)都带有自己的 ID data-v-e17ea971特别地,HelloWorld 的根元素上还额外附加了父组件 App 的 ID data-v-7a7a37b1。这是 Vue 故意设计的,目的是让父组件的样式可以通过属性选择器(如 .txt[data-v-7a7a37b1])作用于子组件的根元素,从而实现父组件对子组件根节点的样式控制(如果父组件样式选择器匹配的话)。

对应的 CSS 会被编译为:

css

.txt[data-v-7a7a37b1] { color: red; }
.txt2[data-v-7a7a37b1] { color: green; }
.txt[data-v-e17ea971] { color: blue; }
.txt2[data-v-e17ea971] { color: orange; }

由于属性选择器的存在,每个组件的样式只作用于带有对应属性的元素,实现了完美的样式隔离。同时,子组件根元素拥有双重属性,使得父组件的样式能够有选择地影响子组件的最外层,保持了样式的可控性。

打开控制台元素,我们就可以看到

image.png

4.4 与 CSS Modules 的对比

Vue 的 scoped 与 React 的 CSS Modules 思路相似,都是通过给选择器附加唯一标识来实现作用域。区别在于:

  • CSS Modules 修改了类名本身,而 Vue 保留了原始类名,额外添加了属性选择器。
  • Vue 的 scoped 无需导入对象,直接在模板中使用原始类名,可读性更好。
  • CSS Modules 需要显式引用 styles 对象,略显繁琐,但胜在灵活(比如可以组合多个类名)。

4.5 原理浅析

Vue 在编译单文件组件时,会为每个组件生成一个唯一的哈希 ID。然后:

  1. 将模板中的所有元素加上该 ID 作为属性(根元素额外加上父组件的 ID,如果存在父组件)。
  2. 将 <style scoped> 中的每条 CSS 规则都加上对应的属性选择器。
  3. 最终生成带作用域的 CSS。

整个过程在构建阶段完成,没有运行时开销,性能极佳。

5. 对比与总结

方案 框架 实现原理 优点 缺点
CSS Modules React / Vue 编译时修改类名,生成哈希映射 静态样式,简单可靠;可与预处理器结合 类名需要引用,模板稍显啰嗦
styled-components React 运行时生成唯一类名,注入 <style> 动态样式能力强;完全组件化;支持 props 运行时开销;包体积较大;调试稍难
Vue scoped Vue 编译时添加唯一属性,属性选择器限制 语法简洁;无运行时开销;保留原始类名 仅适用于 Vue;深度选择器需特殊处理

如何选择?

  • 如果你的项目是 React,且偏好“传统”的 CSS 写法,CSS Modules 是最佳选择,它简单、高效,与设计工具(如 Figma)配合良好。
  • 如果你追求极致的动态样式和组件封装,或者希望将样式也作为组件逻辑的一部分,styled-components 能带来流畅的开发体验。
  • 对于 Vue 项目,scoped 是官方推荐的内置方案,开箱即用,足够满足绝大多数场景。

当然,这些方案并非互斥。在大型项目中,你可能会组合使用它们:用 CSS Modules 处理全局样式库,用 styled-components 处理高频复用的动态组件。重要的是理解每种方案的原理,以便在合适的场景做出正确的选择。

结语

从 CSS 的全局困境到组件样式的精细隔离,前端社区给出了多种优雅的解决方案。无论是 React 的 CSS Modules 和 styled-components,还是 Vue 的 scoped,它们都体现了“关注点分离”到“组件内聚”的思想演进。希望本文能帮助你更好地掌握这些工具,在项目中写出健壮、可维护的样式代码。如果你有更多关于样式隔离的思考或实践,欢迎在评论区交流讨论!

Vue3 嵌套路由 KeepAlive:动态缓存与反向配置方案

在电商系统中,用户的操作路径往往是这样的:

进入商品列表页 → 进行筛选、排序、分页 → 点击进入商品详情页 → 查看后返回列表页。

这时,用户通常有一个非常明确的预期:

  • 筛选条件还在
  • 分页状态保持
  • 滚动位置不丢失

但同时,我们也会遇到另一种场景:

  • 从首页、搜索页或其他模块进入商品列表页时
  • 希望列表页是“全新状态”
  • 需要重新请求数据

也就是说:

同一个页面,在不同来源路径下,对“是否缓存”的期望是不同的。

在 Vue 项目开发中,KeepAlive 是提升用户体验的重要工具。但在复杂的嵌套路由场景(例如:Layout → SubLayout → Page)下,我们常常会遇到两个典型痛点:

1️⃣ 缓存失效

明明在路由里配置了 keepAlive: true
但页面返回时依然重新挂载,onMounted 再次触发,状态丢失。

2️⃣ 控制逻辑越来越混乱

当我们尝试实现:

  • 从 A 页面跳到 B 页面时缓存
  • 从 C 页面跳到 B 页面时不缓存

路由守卫里开始出现大量 if-else 判断,
逻辑逐渐变得难以维护,甚至演变成“屎山”。

如何实现:

  • 精准控制缓存来源
  • 支持嵌套路由结构
  • 避免父级 Layout 被误销毁
  • 同时保持代码清晰、可维护

本文将分享一种“反向配置”的缓存设计方案,并深入解析嵌套路由场景下的一个核心原则:

父随子存。

通过这套设计,我们可以在复杂电商场景中,实现精细化、可控且可扩展的页面缓存策略。

一、核心痛点:为什么嵌套路由下的缓存容易失效?

在 Vue 中,KeepAlive 的本质其实是“链路存活”。

换句话说,只要组件所在的这条渲染链路还存在,它的缓存才能继续保留。一旦链路中某一层被销毁,缓存就会随之消失。

假设我们的路由结构是这样的:

  • 一级容器:WebsiteLayout(顶层布局)
  • 二级容器:UserLayout(用户中心布局)
  • 三级页面:UserProfile、UserFavorites 等子页面
WebsiteLayout
  └── UserLayout
        └── UserProfile / UserFavorites

这里有一个很多人忽略的“真相”:

如果父容器(例如 UserLayout)被销毁,那么它内部缓存的所有子页面,也会被瞬间“物理清空”。

即使你在 UserProfile 上配置了keepAlive: true, 只要 UserLayout 这一层被重新挂载, 内部所有缓存都会失效,onMounted 会再次触发。

这就是嵌套路由场景下缓存“看起来配置了却没生效”的根本原因。

很多开发者只给子页面设置缓存,却忽略了一个关键原则:

子页面想存活,父容器必须先存活。

这也是后文要讲的核心设计理念——“父随子存”原则。

二、 解决方案:反向配置 + 递归缓存

1. 路由配置:由“去向页”决定“来源页”

我们不再在每个页面写复杂的判断,而是在详情页声明:“从我这里回退时,请保持谁的缓存”

// router/index.ts
export const routes = [
  {
    path: '/user',
    name: 'User',
    component: () => import('@/layouts/UserLayout.vue'),
    meta: { keepAlive: true }, // 父容器必须支持缓存
    children: [
      {
        path: 'favorites',
        name: 'UserFavorites',
        component: () => import('@/views/user/Favorites.vue'),
        meta: { keepAlive: true }
      }
    ]
  },
  {
    path: '/product/:id',
    name: 'Product',
    component: () => import('@/views/product/index.vue'),
    meta: { 
      // 反向配置:从这里回退时,保护以下页面的缓存
      keepAliveSources: ['UserFavorites', 'Home'] 
    }
  }
];

2. 全局守卫:实现“父随子存”

这是整套方案的灵魂。我们需要在路由守卫中做两件事:

  1. 补全链路:进入子页面时,强制将其所有父 Layout 加入缓存名单。
  2. 精准清理:非合法来源进入时,即时销毁旧缓存。
export const cacheStack = ref<string[]>([]);

router.beforeEach(async (to, from, next) => {
    const fromName = from.name as string;
    const keepAliveSources = to.meta.keepAliveSources as string[] || [];

    // 1️⃣ 核心:补全父路由缓存名单
    // 遍历 to.matched,确保当前路由的所有父 Layout 都在缓存数组中
    to.matched.forEach((record) => {
      if (record.meta.keepAlive && record.name) {
        const name = record.name as string;
        if (!cacheStack.value.includes(name)) {
          cacheStack.value.push(name);
        }
      }
    });

    // 2️⃣ 处理来源页逻辑
    if (from.meta.keepAlive && fromName) {
      // 如果来源页本身声明了需要缓存,保留它
      if (!cacheStack.value.includes(fromName)) cacheStack.value.push(fromName);
    } else if (keepAliveSources.includes(fromName)) {
      // 如果去向页声明了它是合法的回退来源,保留它
      if (!cacheStack.value.includes(fromName)) cacheStack.value.push(fromName);
    } else if (fromName) {
      // 3️⃣ 清理:如果不是合法来源,从名单中移除,触发组件销毁
      const index = cacheStack.value.indexOf(fromName);
      if (index > -1) cacheStack.value.splice(index, 1);
    }

    next();
});

3. 布局组件:视图层的配合

在所有包含 router-viewLayout 组件中,必须使用 include 绑定这个全局名单。

  1. WebsiteLayout.vue
// WebsiteLayout.vue
<template>
    <router-view v-slot="{ Component, route }">
      <keep-alive :include="cacheStackList">
        <component 
          :is="Component" 
          :key="route.fullPath" 
        />
      </keep-alive>
    </router-view>
</template>

<script lang="ts" setup name="WebsiteLayout">
  import { defineComponent, computed } from 'vue';
  import { cacheStack } from '/@/router/guard/index';

  const cacheStackList = computed(() => {
    return cacheStack.value
  })
</script>
  1. UserLayout.vue
// UserLayout.vue
<template>
  <div class="flex flex-col">
    <div class="flex gap-6 py-4">
      <!-- 左侧菜单 -->
      <aside class="w-96 shrink-0">
        <UserMenu />
      </aside>

      <!-- 右侧内容 -->
      <main class="flex-1">
        <router-view v-slot="{ Component, route }">
          <keep-alive :include="cacheStackList">
            <component 
              :is="Component" 
              :key="route.fullPath" 
            />
          </keep-alive>
        </router-view>
      </main>
    </div>
  </div>
</template>
<script setup lang="ts" name="User">
import UserMenu from './userMenu/index.vue'
import { cacheStack } from '/@/router/guard/index';
import { computed } from 'vue';
const cacheStackList = computed(() => {
  return cacheStack.value
})
</script>

三、 方案优势

  1. 物理隔离确保生效:通过 to.matched 递归确保父容器存活,彻底解决了嵌套路由“名单对了但不缓存”的问题。

  2. 配置解耦:新加一个详情页时,只需在详情页 meta 里增加一行回退目标,无需改动任何业务组件。

  3. 内存友好:不满足回退条件时,缓存会被立即 splice 清理,避免内存堆积。

defineModel 是进步还是边界陷阱?双数据源组件的选择逻辑

defineModel 是 Vue 3.4 引入的语法糖。

它看起来只是让 v-model 更优雅:

const visible = defineModel<boolean>('visible')

但它背后做的事情,远不止简单的语法糖,甚至改变了组件的状态哲学

传统 v-model 的“单一数据源”假设

在大部分 v-model 语义里,存在一个隐含规则:

只传 prop,不监听 update 事件 = 组件不可更新。

比如对弹窗组件,如果父组件只传递了 visibleprop

<MyDialog :visible="visible" />

我们会认为 MyDialog 的显示和隐藏完全由父组件控制

父组件的 visible 变量是控制 MyDialog 显示/隐藏的唯一数据源

这是一种非常清晰的“受控组件”边界

defineModel 在子组件中引入的本地数据源

但是如果 MyDialog.vuevisibledefineModel 实现时,情况会有些不一样:

<script setup>
  const visible = defineModel('visible')
</script>

<template>
  <div>
    <div>MyDialog 内的 visible:{{ visible }}</div>
    <button @click="visible = !visible">MyDialog 内切换 visible</button>
  </div>
</template>

如果父组件中还是

<MyDialog :visible="visible" />

请问子组件按钮点击时,visible 会变化吗?

答案是:会变化

switch.gif

代码链接

defineModel 做了什么?

直接看 playground 生成的代码:

image.png

defineModel 除了生成对应的 propsemits,还通过 useModel 产生了 MyDialog 内的 visible 变量。

而在 useModel 里,会使用 customRef 创建一个本地变量。

在这个本地变量的设值逻辑里,是这样的(简化):

if (
  !(
    rawProps &&
    // check if parent has passed v-model
    (name in rawProps ||
      camelizedName in rawProps ||
      hyphenatedName in rawProps) &&
    (`onUpdate:${name}` in rawProps ||
      `onUpdate:${camelizedName}` in rawProps ||
      `onUpdate:${hyphenatedName}` in rawProps)
  )
) {
  // no v-model, local update
  localValue = value
  trigger()
}

:visible="visible"@update:visible="..." 任意一个不存在,就会更新本地数据。

翻译一下:

只有父组件同时提供 “prop + @update”,子组件才会始终使用父组件的值

否则 —— 子组件会使用本地变量的数据

useModel 的动态数据源

这意味着:

父组件传入的数据,并不一定是最终数据源。

真正的数据源变成:

  • 有监听 → 父组件
  • 无监听 → 子组件本地

这是一种动态切换的数据源模型。

这是不是问题?

从功能角度看,它很强大。

优点

  • 支持“受控 / 非受控”自动切换
  • 多 model 场景写法更优雅

对于“有内部状态”的组件,非常舒服。比如手风琴组件,使用方不需要提供变量保存手风琴的开关状态。

但对于大部分输入组件,它带来了新的权衡。

模糊了边界

传统设计下:

只传 prop = 组件不可修改

现在:

只传 prop ≠ 不可修改

如果你想让组件真正受控,你必须写:

<MyDialog
  :visible="visible"
  @update:visible="() => {}"
/>

用一个空监听器,强制关闭本地数据源。

这就产生了一个认知断层:

  • 使用者需要知道组件内部是否用了 defineModel
  • 否则无法判断它是否会维护本地状态

组件的状态模型,不再从接口上显式表达。

语义变化

<MyDialog :visible="visible" />

由原本的只读受控语义,隐式拓展出了类似 init-visible 的初始值赋值语义。

而是受控,还是初始值赋值,取决于内部是否使用了 defineModel

总结与想法

defineModel 带来的不只是语法糖。还把

数据源从“静态归属”变成了“动态判断”。

它让 Vue 组件具备了“双数据源能力”。需要清醒认知它的能力边界。

defineModel 并没有让 v-model 更简单,反而让组件的状态模型更复杂。

两个想法:

  • 对于普通的输入组件,尽量避免使用 defineModel,保持单一数据源
  • 在状态不一致的问题排查上,需要考虑缺少监听器引发的问题

要闹哪样?又出现了一款新的格式化插件,尤雨溪力荐,速度提升了惊人的45倍!

前两天刚刚讨论完Vize(参考这篇文章: # 前端圈子又出新东西了,大幅提升解析速度。尤雨溪推荐,但我不太推荐),这两天发现前端又出现新工具了,而且是尤大力荐的,我得到这个消息还算是比较晚的了。

其实这款插件早已官宣,最最关键的一点是,它的速度比咱们常用的Prettier快了整整45倍。

今天咱们简单看一下这款插件 —— oxfmt

image.png

背景

其实前端最近几年一直在致力于底层的革新,原因也非常简单,Js在系统中的运行效率和编解码速度远逊于Rust这样的语言。

所以Vite中的 Rollup 变成了 Rolldownesbuild 变成了 Oxc

大家可能不太清楚 Oxc 是啥,咱们简单过一下。

image.png

OxcVoidZero 团队(Vite 核心团队,尤雨溪的公司)用 Rust 开发的 JS/TS 全链路工具链。

简单说就是以后前端的底层部分全都用 Rust 写了,补齐了 Oxc 以后,Rust在前端领域实现了全替换。

带来的好处不言而喻,首先是速度。

作为编译型语言,Rust 的执行效率接近 C/C++,相比传统前端工具的 JS/Go 实现构建 / 转译速度提升 数倍到数十倍。

并且内存占用降低 50%+,大型项目不会出现 JS 工具的内存溢出 / 卡顿问题,真正意义上实现了闪电般的加载速度

其次做为底层语言,Rust 的所有权、借用检查机制从语法层面杜绝空指针、内存泄漏等常见问题,前端工具的崩溃率、异常率大幅降低,尤其适合大型工程化场景。

最关键的一点,Rust 编译出的二进制文件无需依赖 Node.js 运行时,在 Windows/macOS/Linux 上的执行逻辑、性能表现高度一致。

解决了 JS 工具在不同系统下的兼容性问题,完美解决了跨平台一致性的问题。

Oxfmt

理解了Oxc就能简单说说 Oxfmt 了,Oxfmt 是 Oxc 生态中的代码格式化工具,也是目前已经基本上完成的 Rust 替换 Prettier 的例子。

image.png

Oxfmt Beta 几个关键词过一下:

  • 100% Prettier 兼容,无缝迁移
  • 支持 --migrate-prettier
  • 支持更丰富的文件格式
  • Import 自动排序
  • package.json 自动排序
  • Node.js API
  • IDE 完美支持

因为本身 Oxfmt 就可以看作是 Prettier 的Rust版本,所以团队在开发的时候也选择了对 Prettier API的完全兼容,所以开发者一般是没啥感知的。

你能够感受到的也就是快!

尝鲜

安装 Oxfmt

pnpm add -D oxfmt

这里需要给 oxfmt 配置一下脚本,找到 package.json

{
  "scripts": {
    "fmt": "oxfmt",
    "fmt:check": "oxfmt --check"
  }
}

现在已经可以用了。

# 格式化文件
pnpm run fmt

# 检查格式,但不修改文件
pnpm run fmt:check

以上是比较粗浅的应用,真正想要实现项目内详细可用还需要创建一下配置文件,oxfmt 默认使用 .oxfmtrc.json 作为配置文件。

# 初始化配置文件
oxfmt --init

# 从Prettier迁移
oxfmt --migrate prettier

# 全量格式化
npx oxfmt . --write

工程化应用

日常项目开发过程中主要是保存、提交的时候自动格式化,这个场景应用的比较多。

oxfmt 在 vscode 中可以通过 Oxfmt 官方扩展实现保存格式化。

首先安装 Oxfmt 官方插件,搜索 Oxc 即可。

image.png

.vscode/settings.json 中添加以下配置:

{
    "editor.formatOnSave": true,
    "[vue]": {
        "editor.defaultFormatter": "oxc.oxfmt"
    },
    "[javascript]": {
        "editor.defaultFormatter": "oxc.oxfmt"
    },
    "[typescript]": {
        "editor.defaultFormatter": "oxc.oxfmt"
    }
}

之前用 Prettier 的同学记得关掉,避免冲突。

提交格式化可以通过 pre-commit 钩子实现:

pnpm install -D husky lint-staged
npx husky install
# 添加 pre-commit 钩子
npx husky add .husky/pre-commit "npx lint-staged"

同时在 package.json 中增加相应配置:

{
    "lint-staged": {
        "*.{js,ts,vue,json,css,scss,md}": [
        "oxfmt --write"
        ]
    }
}

总结

我个人比较建议大家从现在开始就把 Prettier 替换为 Oxfmt,原因主要有三:

  • Rust实现前端底层已成为大趋势,未来一定是这套工程大一统。
  • 速度更快,内存用的更少,Vite团队开发。
  • 确实好用,接近无感的存在。

React Context 详解:从入门到性能优化

React Context 详解:从入门到性能优化

本文适合熟悉 Vue 但刚开始学习 React 的开发者,通过 Vue 的 provide/inject 对比来理解 React Context。

一、什么是 Context?

在组件开发中,我们经常遇到这样的场景:某个数据需要在多层嵌套的组件间共享。如果一层层通过 props 传递,代码会变得非常冗长且难以维护,这就是所谓的 "prop drilling" 问题。

React 的 Context 和 Vue 的 provide/inject 都是为了解决这个问题而设计的 —— 它们允许数据跨层级传递,跳过中间组件。

二、React Context 基础用法

核心三步

  1. 创建 Context —— 创建一个数据共享的"通道"
  2. 提供数据 —— 父组件通过 Provider 提供数据
  3. 消费数据 —— 子组件通过 useContext 获取数据

完整示例

// ========== 1. 创建 Context ==========
// context.tsx
import { createContext, useContext } from 'react'

// 定义数据类型
type MyContextValue = {
  name: string
  age: number
}

// 创建 Context(可设置默认值)
const MyContext = createContext<MyContextValue>({ name: '', age: 0 })

// 导出一个 hook 方便使用
const useMyContext = () => useContext(MyContext)

export { MyContext, useMyContext }
// ========== 2. 父组件提供数据 ==========
// parent.tsx
import { MyContext } from './context'
import Child from './child'

const Parent = () => {
  const data = { name: '张三', age: 18 }

  return (
    <MyContext.Provider value={data}>
      <Child />
    </MyContext.Provider>
  )
}
// ========== 3. 子组件消费数据 ==========
// child.tsx
import { useMyContext } from './context'

const Child = () => {
  const { name, age } = useMyContext()
  
  return <div>{name} - {age}岁</div>
}

三、对比 Vue 的 provide/inject

如果你熟悉 Vue,这个概念其实非常相似:

步骤 React Vue
创建 createContext() 无需显式创建
提供 <Context.Provider value={}> provide(key, value)
消费 useContext(Context) inject(key)

Vue 等价写法

<!-- 父组件 -->
<script setup>
import { provide } from 'vue'
import Child from './child.vue'

const data = { name: '张三', age: 18 }
provide('myContext', data)
</script>

<template>
  <Child />
</template>
<!-- 子组件 -->
<script setup>
import { inject } from 'vue'

const { name, age } = inject('myContext')
</script>

<template>
  <div>{{ name }} - {{ age }}岁</div>
</template>

可以看到,两者的设计思想是一致的,只是语法不同:

  • React 使用 JSX 的组件包裹方式 <Context.Provider>
  • Vue 使用 Composition API 的函数调用方式

四、原生 Context 的性能问题

原生 React Context 存在一个性能陷阱:

只要 Context value 中的任何一个字段变化,所有消费这个 Context 的组件都会重新渲染,即使它们只用到了没变的字段。

// 原生 React Context 的问题
const MyContext = createContext({ name: '张三', age: 18, city: '北京' })

// 这个组件只用 name,但 age 或 city 变化时也会重新渲染!
const Child = () => {
  const { name } = useContext(MyContext)
  return <div>{name}</div>
}

当 Context 中有几十个字段时(这在大型应用中很常见),这个问题会严重影响性能。

五、use-context-selector:性能优化方案

为了解决这个问题,社区提供了 use-context-selector 库。它支持选择器模式,让组件只订阅自己关心的字段。

安装

npm install use-context-selector

使用方式

// 从 use-context-selector 导入,而不是 react
import { createContext, useContext } from 'use-context-selector'

const MyContext = createContext({ name: '张三', age: 18, city: '北京' })

// 使用选择器,只订阅 name
const Child = () => {
  const name = useContext(MyContext, v => v.name)  // age 或 city 变化不会触发重渲染
  return <div>{name}</div>
}

核心区别

特性 React 原生 use-context-selector
导入来源 'react' 'use-context-selector'
更新粒度 整个 Context 变化就重渲染 可以用选择器精确订阅某个字段
性能 大型 Context 可能性能差 优化了选择器模式,避免不必要的重渲染
使用方式 useContext(ctx) useContext(ctx, selector?)

六、实际案例分析

以 Dify 项目中的 ChatWithHistoryContext 为例:

// context.tsx
import { createContext, useContext } from 'use-context-selector'

export type ChatWithHistoryContextValue = {
  appMeta?: AppMeta | null
  appData?: AppData | null
  appParams?: ChatConfig
  currentConversationId: string
  conversationList: AppConversationData['data']
  handleNewConversation: () => void
  handleChangeConversation: (conversationId: string) => void
  // ... 还有 20+ 个字段
}

export const ChatWithHistoryContext = createContext<ChatWithHistoryContextValue>({
  currentConversationId: '',
  // ... 默认值
})

export const useChatWithHistoryContext = () => useContext(ChatWithHistoryContext)
// parent.tsx - 提供数据
const ChatWithHistoryWrap = () => {
  const contextValue = useChatWithHistory()  // 获取所有数据

  return (
    <ChatWithHistoryContext.Provider value={contextValue}>
      <ChatWithHistory />
    </ChatWithHistoryContext.Provider>
  )
}
// child.tsx - 消费数据
const ChatWithHistory = () => {
  const { 
    appData, 
    conversationList, 
    handleChangeConversation 
  } = useChatWithHistoryContext()
  
  // 使用数据...
}

这个 Context 有 30+ 个字段,如果使用原生 Context,任何一个字段变化都会导致所有子组件重渲染。使用 use-context-selector 后,框架内部做了优化,避免了不必要的渲染。

七、数据流图解

┌─────────────────────────────────────────────────┐
│  ChatWithHistoryWrap (父组件)                    │
│                                                 │
│  通过 useChatWithHistory() 获取所有数据          │
│  { appData, appParams, conversationList, ... }  │
└─────────────────────────────────────────────────┘
                        │
                        ▼
┌─────────────────────────────────────────────────┐
│  ChatWithHistoryContext.Provider                │
│  value={{ appData, appParams, ... }}            │  ← 数据注入到 Context
└─────────────────────────────────────────────────┘
                        │
                        ▼
┌─────────────────────────────────────────────────┐
│  ChatWithHistory (子组件)                        │
│                                                 │
│  useChatWithHistoryContext() 获取数据           │
└─────────────────────────────────────────────────┘
                        │
          ┌─────────────┼─────────────┐
          ▼             ▼             ▼
     ┌─────────┐  ┌─────────┐  ┌─────────┐
     │ Sidebar │  │ Header  │  │ ChatWrap│
     └─────────┘  └─────────┘  └─────────┘
          │             │             │
          └─────────────┴─────────────┘
                        │
              孙组件同样可以通过
           useChatWithHistoryContext() 获取数据

八、最佳实践

  1. 小型项目:使用原生 React Context 即可,简单直接
  2. 大型项目:当 Context 字段较多(10+)时,考虑使用 use-context-selector
  3. 拆分 Context:如果可能,将不相关的数据拆分到不同的 Context 中
  4. 命名规范:导出一个自定义 hook(如 useMyContext),统一消费方式

九、总结

场景 推荐方案
简单数据共享 React 原生 Context
大型 Context,字段多 use-context-selector
Vue 背景开发者 理解为 provide/inject 的 React 版本

Context 本质上就是 跨层级传递数据 的工具,理解了这一点,无论是 React 还是 Vue,核心概念都是相通的。

别再乱用 ref 和 reactive 了!Vue 3 响应式最佳实践,90% 的人都踩过坑

上周 Code Review,我看到同事写了这样一段代码:

const state = reactive({
  user: null,
  loading: false,
  error: '',
  list: []
});

// 后面又单独定义
const currentPage = ref(1);
const pageSize = ref(10);

乍看没问题,但一运行**——页面卡顿、watch 失效、调试器里数据对不上……**

问题出在哪?
不是逻辑错,而是响应式对象的“组合方式”错了

今天,我就用3 条黄金法则 + 2 个实战模板,帮你彻底搞懂 Vue 3 响应式怎么写才高效、安全、可维护。

法则 1:简单值用 ref,复杂对象用 reactive —— 但别混用!

很多教程说:“primitive 用 ref,object 用 reactive”,这没错,但忽略了“解构陷阱”。

错误示范:

const { user, loading } = reactive({ user: null, loading: false });
// 解构后失去响应性!

正确做法:

// 方案 A:全部用 ref(推荐新手)
const user = ref(null);
const loading = ref(false);

// 方案 B:用 toRefs 保持响应性
const state = reactive({ user: null, loading: false });
const { user, loading } = toRefs(state); // ✅ 响应式保留

经验公式:

  • 如果你要频繁解构 or 传递单个属性 → 优先用 ref
  • 如果是完整状态模块(如表单、列表配置)→ 用 reactive + toRefs

法则 2:别把 ref 套进 reactive,除非你真的需要

见过这种写法吗?

const state = reactive({
  count: ref(0), // ❌ 不要!
  name: 'Vue'
});

这会导致:

  • 访问时必须写 state.count.value(破坏一致性)
  • 模板中虽然自动 unwrap,但逻辑层混乱
  • 容易引发“value 嵌套地狱”

正确做法:统一层级

// 要么全 ref
const count = ref(0);
const name = ref('Vue');

// 要么全 reactive(count 直接是 number)
const state = reactive({
  count: 0,
  name: 'Vue'
});

小技巧:在 setup() 返回时,用 ...toRefs(state) 一键暴露所有属性。

法则 3:大型组件,用“状态模块化”代替巨型 reactive

当组件状态超过 5 个字段,别堆在一个 reactive 里!

反面教材:

const state = reactive({
  // 用户信息
  userId, userName, userAvatar,
  // 分页
  page, size, total,
  // 搜索条件
  keyword, status, dateRange,
  // UI 状态
  showDrawer, loading, errorMsg...
});

推荐拆分:

// 按功能拆成多个小状态块
const userState = reactive({ id: '', name: '', avatar: '' });
const pagination = reactive({ page: 1, size: 10, total: 0 });
const uiState = reactive({ loading: false, drawerVisible: false });

// 或封装成 composable
const { userState } = useUserStore();
const { pagination, fetchList } = usePagination();

这样不仅逻辑清晰,还天然支持 逻辑复用(比如分页逻辑抽成 usePagination)。

实战模板:两种主流写法对比

模板 A:全 ref 风格(适合中小型组件)

export default {
  setup() {
    const loading = ref(false);
    const list = ref([]);
    const keyword = ref('');

    const search = async () => {
      loading.value = true;
      list.value = await api.search(keyword.value);
      loading.value = false;
    };

    return { loading, list, keyword, search };
  }
}

优点:直观、无解构风险、TS 类型推导友好
注意:返回时别漏写 .value

模板 B:reactive + toRefs(适合状态密集型组件)

export default {
  setup() {
    const state = reactive({
      loading: false,
      list: [] as Item[],
      keyword: ''
    });

    const search = async () => {
      state.loading = true;
      state.list = await api.search(state.keyword);
      state.loading = false;
    };

    return { ...toRefs(state), search };
  }
}

优点:状态聚合、减少变量声明、模板中直接用 list
注意:内部操作用 state.xxx,别解构!

高阶建议:结合 更清爽

如果你用 Vue 3.3+,直接上 :

import { ref } from 'vue'

const loading = ref(false)
const list = ref([])
const keyword = ref('')

const search = async () => {
  loading.value = true
  list.value = await api.search(keyword.value)
  loading.value = false
}

没有 return,没有 setup(),变量自动暴露——这才是 Vue 3 的终极舒适区。

最后说两句

Vue 3 的响应式系统很强大,但自由也意味着责任。
用对了,代码清爽如诗;用错了,bug 隐蔽如鬼。

记住三句话:

  1. 简单用 ref,复杂用 reactive
  2. 别混用,别嵌套,别解构裸对象
  3. 大组件,拆状态,抽 composable

各位互联网搭子,要是这篇文章成功引起了你的注意,别犹豫,关注、点赞、评论、分享走一波,让我们把这份默契延续下去,一起在知识的海洋里乘风破浪!

❌