普通视图
Veaury:让Vue和React组件在同一应用中共存的神器
【节点】[SampleGradient节点]原理解析与实际应用
Web文档的"Office时刻":jitword共建版1.0正式发布,让浏览器变成本地生产力
前端向架构突围系列 - 状态数据设计 [8 - 1]:从 MVC 到 Flux 再到 Atomic
React 的 ViewTransition 元素
JavaScript 框架展望 2026
10万数据点可视化:Echarts性能优化实战
最近在工作中遇到了一个颇具挑战的需求,需要在Web页面上通过Echarts图表渲染超过10万条点位数据。对于前端开发来说,大数据量的可视化渲染一直是个棘手的问题,尤其是当数据量达到10万级别时,不仅浏览器请求响应速度变慢,浏览器的渲染性能瓶颈会变得非常明显;因此,本文我们就看下如果在工作中遇到这种场景,应该如何处理。
首先介绍一下实际的场景,我们团队最近接到一个物联网设备数据分析需求:业务方需要查看特定设备一段时间范围内的运行状态趋势。这看起来似乎是个简单的折线图需求,但当我们深入了解数据规模时,发现了巨大的挑战。
首先是业务方要求不限制时间范围,例如可以跨数年的范围,从2021年到2025年;这对我们前后端来说,意味着查询和渲染数据量会非常庞大,因为设备采集一般都是按照固定的时间频率采集的;比如如果设备每隔15分钟就会采集发送一次数据,一天的数据量就是24小时 × (60分钟/15分钟) = 96个数据点/天,如果查询4年的数据就是4年* 365天* 96个数据点 = 14余万条数据。
业务人员给我们的需求很明确:"我们需要在这张图上看到四年的完整趋势,能够快速发现异常波动,并且可以随意缩放查看任意时间段的细节"。他们补充道:"之前试过按天聚合的数据,但那样会丢失很多重要信息。比如设备在某个具体时间点的瞬时异常,在日度数据中就看不出来了。"
我们最初的尝试非常直接,一次性加载所有的数据,然后通过Echarts渲染。
![]()
但是请求接口的时间就达到了14秒,数据响应时浏览器内存占用激增,非常容易崩溃卡死,完全没有用户体验可言。
数据分割:化整为零的策略
于是,根据业务需求,我们首先尝试数据分割,将数据按天维度进行分割,然后分别请求数据;下面是分割的核心函数:
import dayjs from "dayjs";
/**
* 按指定天数分割日期区间
* @param {string} startDate 开始日期
* @param {string} endDate 结束日期
* @param {number} num 分割天数
*/
function separateDate(startDate, endDate, num = 180) {
// 使用dayjs.js创建日期对象
const start = dayjs(startDate);
const end = dayjs(endDate);
// 验证日期有效性
if (!start.isValid() || !end.isValid()) {
throw new Error('无效的日期格式');
}
// 确保开始日期早于或等于结束日期
if (start.isAfter(end)) {
throw new Error('开始日期不能晚于结束日期');
}
// 计算总天数
const totalDays = end.diff(start, 'days');
// 如果总天数小于等于最大分割天数,直接返回一个区间
if (totalDays <= num) {
return [
{
segmentStartDate: start.format('YYYY-MM-DD'),
segmentEndDate: end.format('YYYY-MM-DD'),
segmentStartDay: 0,
segmentEndDay: totalDays,
},
];
}
}
在处理时,我们会先校验参数格式并计算总天数,若总天数未超过最大分割天数,则将直接返回该日期区间,不再进行分割处理。
function separateDate(startDate, endDate, num = 180) {
// 省略其他代码...
// 计算需要分割的区间数量
const numIntervals = Math.ceil(totalDays / num);
const result = [];
for (let i = 0; i < numIntervals; i++) {
// 计算当前区间的开始日期
const iStart = start.clone().add(i * num, 'days');
// 计算当前区间的结束日期(最后一个区间使用实际结束日期)
const iEnd = i === numIntervals - 1 ? end : start.clone().add((i + 1) * num - 1, 'days');
// 确保结束日期不超过实际结束日期
const actualEnd = iEnd.isAfter(end) ? end : iEnd;
// 计算相对于开始日期的天数
const segmentStartDay = iStart.diff(start, 'days');
const segmentEndDay = actualEnd.diff(start, 'days');
result.push({
segmentStartDate: iStart.format('YYYY-MM-DD'),
segmentEndDate: actualEnd.format('YYYY-MM-DD'),
segmentStartDay,
segmentEndDay,
});
}
return result;
}
然后通过Math.ceil将数字向上舍入到最接近的整数,得到numIntervals,也就是我们区间的数量。此外在separateDate返回的数据每个分片中,包含了segmentStartDay和segmentEndDay,对应了时间区间的开始和结束的天数,方便后续的数据合并处理。
这里separateDate函数是我们整个优化方案的核心基础,它将长时间跨度的数据请求分解为多个可管理的子请求;startDate和endDate接收日历📅组件传入的用户选择的开始和结束日期;num参数默认设置为180天,这个值基于我们后端响应效率和速度的最优分段时长,如果单个时间跨度太长,则达不到分段的效果,而如果太短,则分段数量过多,请求次数太频繁。
正是基于separateDate函数分割出的这些独立、合规的日期区间,我们后续的所有优化操作才得以展开;接下来,每一个子区间的数据会进行独立的处理和加载,从而将原本庞大而笨重的单次请求,转化为一次次高效、可管理的并行任务流。
WebWorker:开辟“第二战线”
在上一节,我们实现了数据的分割,成功将14万+的数据请求分解为多个小请求;但是即使数据分片了,每一分片数据量仍然可能很大(最多180天×96个点/天=17280个点);如果直接在主线程中处理这些数据,仍然会导致UI卡顿。这时候,Web Worker就派上用场了。
Web Worker是HTML5提供的API,允许在浏览器后台运行JavaScript脚本,与主线程并行执行。这意味着我们可以在Worker线程中执行繁重的数据处理任务,而不会阻塞用户界面;如果说主线程是“前台服务员”,既要响应客人(用户)的点击,又要去后厨炒菜(计算),那么Web Worker就是雇来的“专职后厨”;它有以下几个特点:
- 独立线程:运行在独立的线程中,与主线程并行
- 无DOM访问权限:不能直接操作DOM或访问window对象
- 通过消息通信:与主线程通过postMessage和onmessage通信
- 生命周期独立:关闭标签页或Worker脚本执行完毕才会终止
![]()
首先,我们需要创建一个专门处理数据的Worker文件data-processor.worker.js:
self.onmessage = function (e) {
var list = e.data.data;
const listHandled = list.value.map((el) => {
// 对数据进行一系列耗时计算
});
self.postMessage({
list: listHandled,
});
};
这里我们定义了一个专用Worker线程,负责执行所有阻塞型的计算任务,负责对数据进行一些耗时的处理,例如原始数据清洗、复杂指标计算等等,并返回处理后的数据;主线程则专注于UI交互与流畅渲染,仅在需要时(分割数据返回)向Worker派发任务并异步接收其返回的、可直接用于图表(如ECharts)的轻量化结果。
async function loadEchartData(rangeItem) {
const { segmentStartDate, segmentEndDate } = rangeItem;
const res = await fetchListData({
startDate: segmentStartDate,
endDate: segmentEndDate,
});
if (res && res.data) {
const { list } = res.data;
const worker = new Worker("/data-processor.worker.js");
worker.postMessage({
data: list,
});
worker.onmessage = function (e) {
const { list } = e.data;
renderChart(list);
};
}
}
我们将前面分割好的数据区间,分发为并发的数据请求进行加载。待数据返回后,主线程会实例化一个Worker线程,并通过postMessage函数,将原始数据调度至Worker进行后续处理。
这里还涉及一个数据返回后拼接的问题,我们在循环调用loadEchartData请求数据时,由于是异步返回,分片数据返回的时候,数据会乱序返回,因此不能直接通过数组的push来添加数据。
我们在全局定义x轴和y轴两个数组,在页面初始化的时候,根据业务需求,提前预估计算出数组的长度,并使用默认数据进行填充:
const _xList: string[] = []
const _yList: number[] = []
for (let i = 0; i < diffDay; i++) {
const nowDate = dayjs(startDate.value).add(i, 'days');
for (let j = 0; j < 96; j++) {
_xList.push(
nowDate.add(i * 15, 'minutes')
.format('YYYY-MM-DD HH:mm')
)
_yList.push(0)
}
}
当响应数据返回后,我们只需要将数据添加到对应的位置即可:
async function loadEchartData(rangeItem) {
const { segmentStartDay } = rangeItem;
if (res && res.data) {
const { list } = res.data;
const startIndex = segmentStartDay * 96;
// 在对应索引处添加数据
_yList.splice(startIndex, list.length, ...list);
}
}
Echarts渲染优化:让大数据飞起来
至此,我们已经通过分割、处理与加载的优化,为海量数据的渲染搭建了一条高效的前置管线。。然而,当数据最终抵达浏览器并准备在ECharts中绘制时,性能的“最终挑战”才真正开始。如何让ECharts“消化”这数万个数据点并保持流畅交互?本节将深入ECharts的渲染层,拆解那些让图表“飞起来”的关键优化策略。
在大数据量的前提下,我们首先需要确保,echarts的渲染器是canvas而不是SVG,因为SVG图像在处理复杂图形时可能会导致性能问题,因此确保你的图表使用canvas进行渲染:
// renderer不是svg
echarts.init(domElement, null, { renderer: 'canvas' });
降采样策略
什么是数据采样?数据采样是ECharts中处理大数据量的优化技术,当图表需要展示的数据点过多时(通常超过几千个点),浏览器渲染性能会显著下降。采样算法可以在保持图表大致趋势不变的前提下,减少实际渲染的数据点数。
例如,通过对一万个原始数据点进行分层抽样,我们将渲染节点的数量直接从10,000个缩减至1,000个。这一优化直接带来了渲染性能的激增,帧率得到显著提升。Echarts提供了多种数据采样算法,包括如下:
- sum:取过滤点的和
- average:取过滤点的平均值
- min: 取过滤点的最小值
- max: 取过滤点最大的值
- minmax:取过滤点绝对值的最大极值 (从 v5.5.0 开始支持)
- lttb:采用
Largest-Triangle-Three-Bucket算法,可以最大程度保证采样后线条的趋势,形状和极值。
使用时,通过配置series的sampling属性,指定数据采样算法:
{
series: [
{
type: "bar",
sampling: "lttb",
data: yourData,
},
];
}
我们对柱状图进行lttb算法采样后,效果如下,我们能够明显看到柱子的密度有些稀疏:
![]()
需要注意的是,数据经过采样后,数据点会减少,采样会丢失细节,因此不适合需要精确值的场景;同时由于数据点的减少,一些图表的交互功能,如tooltip,也会受到影响。
针对折线图,我们也应用了lttb算法进行下采样。从如下效果图中可以观察到,算法在大幅减少数据点的同时,仍保持了原始曲线的核心趋势与形状,整体还原效果非常好。其主要误差出现在变化剧烈的边界区域或极值点附近,导致局部拟合不够平滑。
相较之下,在之前柱状图的测试中,lttb算法因会改变离散柱的分布位置而导致信息失真,因此它更适用于折线图这类强连续性的序列数据可视化。
![]()
lttb算法原理
鉴于LTTB算法在降采样中表现出的出色效果,我们有必要深入探究其核心实现原理。作为ECharts等主流可视化库采用的关键算法,其核心步骤是将数据点分组为多个连续的“桶”,并在每个桶内仅筛选一个最具代表性的点。那么,这个代表点是如何被选定的?要回答这个问题,关键在于理解其“最大三角形面积”的筛选准则。
数据点分布:
▲
│
│ 桶A 桶B 桶C
│ ┌──────┐ ┌──────┐ ┌──────┐
│ │ │ │ │ │ │
│ │ • │ │ • │ │ • │
│ │ • │ │ • │ │ • │
│ │ • • │ │• • │ │ • • │
│ •│ • • │ •│• • │ •│• • │
│ • •│• •│ • •│• •│• • │• •│
│ • • │ •│• • │ •│• • │ •│
│ • • │ │• • │ │• • │ │
└──────────┴──────┴────┴──────┴────┴──────┴──▶
0 10 20 30 40 50 60
frameSize = 10个点/桶
我们第一个桶A的点选择初始位置的点,当我们开始选取下一个桶B时点时,再下一个桶C的点,我们暂定为这个桶的平均值;这样,我们前后桶的点都确定了,让我们回到桶B点的选择上来;这个时候,我们遍历桶B的所有点,计算ABC三个桶的点形成三角形的面积,并选择面积最大的点作为这个桶的点。
为什么面积大的点就能代表这个桶呢?我们想像一下,如果B点靠近了AC连线上,那么B点几乎就没有提供了新的信息了。
A─────B─────C
面积 ≈ 0(三点几乎共线)
但是如果B点远离AC连线,那么B点就提供了新的信息,那么B点就可以代表这个桶的点。
B
/ \
/ \
/ \
A C
面积很大,B点代表了重要特征
当我们已知二维平面上上三个点的坐标,利用初中的知识就能推导三角形的面积为:
三角形面积 = 0.5 × |AB × AC| = 0.5 × |(x2-x1)(y3-y1) - (x3-x1)(y2-y1)|
下面是一个简单的推导过程:
![]()
我们访问Echarts仓库中查看源码,发现lttb算法代码在src/data/DataStore.ts的lttbDownSample函数中实现;有了上面理论的支撑,我们下面就来好好的拆解拆解这个函数:
/**
* Large data down sampling using largest-triangle-three-buckets
* @param {string} valueDimension
* @param {number} targetCount
*/
lttbDownSample(
valueDimension: DimensionIndex,
rate: number
){
// 总数据点数,如 10000
const len = this.count();
// 每个桶的大小,如rate = 0.1,则frameSize = 10
const frameSize = Math.floor(1 / rate);
}
首先上面的代码中,我们首先获取数据点的总数,并计算每个桶的大小;这里传入的valueDimension代表值的维度,如果直接传入数据列表,会导致内存占用过高,因此这里的做法是传入数据维度,通过维度来获取数据,从而提高性能。
for (let i = 1; i < len - 1; i += frameSize) {
// 下一个桶的边界
const nextFrameStart = Math.min(i + frameSize, len - 1);
const nextFrameEnd = Math.min(i + frameSize * 2, len);
// 计算下一个桶的平均点
const avgX = (nextFrameEnd + nextFrameStart) / 2; // X坐标平均值
let avgY = 0; // Y坐标平均值
}
然后我们开始遍历数据点,我们发现i是从1开始的,因为我们默认第一个点就是第一个桶的选择点;接着,在当前桶遍历下,我们先要计算出下一个桶C的平均点(avgX, avgY)。
for (let i = 1; i < len - 1; i += frameSize) {
// 省略上面代码
for (let idx = nextFrameStart; idx < nextFrameEnd; idx++) {
// 获取下一个桶上面每一个点的值
const y = dimStore[rawIndex] as number;
avgY += y as number;
}
avgY /= (nextFrameEnd - nextFrameStart);
}
然后,我们开始遍历下一个C桶中的每一个数据点,并计算出下一个桶的平均值。
let maxArea;
for (let i = 1; i < len - 1; i += frameSize) {
// 当前桶的起始索引
const frameStart = i;
// 当前桶的结束索引
const frameEnd = Math.min(i + frameSize, len);
// 上一个点的X坐标
const pointAX = i - 1;
// 上一个点的Y值
const pointAY = dimStore[currentRawIndex] as number;
// 当前桶最大的面积
maxArea = -1;
}
紧接着,我们为当前桶B点的遍历准备一下数据,frameStart和frameEnd是当前桶B的边界,pointAX和pointAY是上一个桶A的坐标。
我们发现这里的pointAX取得是上一个桶最后一个点的坐标i - 1,而不是每次都将上一个桶的选择点存起来使用,这其实是Echarts为了性能优化,牺牲了一点精度,减少变量跟踪。
// 循环遍历每个桶
for (let i = 1; i < len - 1; i += frameSize) {
// 省略上面代码
// 循环遍历桶B中的数据点
for (let idx = frameStart; idx < frameEnd; idx++) {
// 当前点的X坐标
const rawIndex = this.getRawIndex(idx);
// 当前点的Y坐标
const y = dimStore[rawIndex] as number;
// 计算三角形的面积
area = Math.abs((pointAX - avgX) * (y - pointAY)
- (pointAX - idx) * (avgY - pointAY)
);
if (area > maxArea) {
maxArea = area;
nextRawIndex = rawIndex;
}
}
newIndices[sampledIndex++] = nextRawIndex;
}
最后这个代码是整个算法的核心代码,也是最精妙的地方;基于之前桶的循环,我们在当前桶内,遍历桶中每个数据点,rawIndex和y表示当前点的坐标;而这里的area就是我们上面介绍的三角形的计算公式,经过之前对于桶A、桶B、桶C的点准备,相信这里的area计算相信大家都能够理解了;最后如果area超出了记录的最大面积maxArea,则将当前点加入到新的采样数据中进行数据留存。
纸上得来终觉浅,算法的精妙,非得亲手试一下不可。为此,笔者写了一个简单的页面来演示LTTB算法的实际效果,默认设置采样率rate为0.1,同时对折线图数据进行采样对比,就能看到和原始数据之间的细微差异:
![]()
dataZoom分块渲染
在处理海量数据时,启用dataZoom组件是实现性能跃升的核心策略之一。它将渲染模式从一次性承载全量数据,转变为动态的窗口化渲染。初始化时仅加载视口范围内的数据,随着用户滚动或缩放再动态加载其他部分。这种方式将渲染压力分散到多次轻量级操作中,从根本上避免了单次渲染卡顿,大幅提升了交互响应速度。
const option = {
dataZoom: [
{
type: "inside",
start: 0,
end: 20
},
{
type: "slider",
start: 0,
end: 20,
},
],
series:[
//...
]
};
然而,这里存在一个状态冲突问题,每次从接口获取新数据并重渲染图表时,dataZoom都会被强制重置到初始的[0, 20]区间。如果用户在之前已经通过拖拽缩放浏览了其他数据区域,这个行为就会破坏其探索状态,导致用户体验割裂。
第一种常规的解决方案是,我们在核心的图表渲染函数renderChart中引入一个守卫参数isInitial。只有当 isInitial 为 true(例如初次渲染时),才设置dataZoom的区间。在常规的数据更新渲染中,则保留用户当前交互状态,仅刷新数据而不触动缩放组件。
另一种解决方案是,在setOption时,使用replaceMerge参数,告诉ECharts只替换指定的组件,其他组件(如 dataZoom)保持不变:
echartsInst.setOption({
dataZoom: [
{
type: "inside",
start: 0,
end: 20
},
{
type: "slider",
start: 0,
end: 20,
},
],
series:[
//...
]
}, {
notMerge: false,
replaceMerge: ["xAxis", "series"],
})
这样即使多次setOption也不会重置dataZoom的区间。
大数据模式与渐进式渲染
经常查看Echarts官方文档的小伙伴,相信都看到过large和progressive等属性,但是什么情况下需要用到large和progressive呢?相信很多小伙伴都一头雾水,这一节,我们就来好好说道说道。
large属性是ECharts为海量数据渲染设计的专用性能优化开关,通常指数据量在数万到数百万级别; 当你的数据量预计达到此规模时,开启此选项将直接调用底层优化算法,从而获得显著的渲染性能提升,下面我们通过表格实际感受一下10w+级的实测对比数据:
| 指标 | 未开启 large | 开启 large |
|---|---|---|
| FPS | 3-10 | 51-60 |
| MS(渲染一帧所需的毫秒数) | 179-246 | 17-28 |
| 内存占用(MB) | 277-305 | 53-59 |
| 交互响应 | 卡顿明显 | 基本流畅 |
largeThreshold是与large属性配合使用的阈值参数,它定义了启用大规模优化模式的数据量下限。当且仅当数据项数超过此阈值时,优化绘制逻辑才会生效;反之,系统将使用标准渲染流程,避免不必要的开销;大多数情况下无需手动调整。
setOption({
series: [
{
type: "bar",
data,
large: true,
largeThreshold: 1000,
},
],
});
需要注意的是,不是每种类型的图表都支持large和largeThreshold属性的,目前仅有bar和scatter图表支持。
需要指出的是,在large模式下,Echarts出于性能优化的考虑,无法为单个数据点设置独立样式,所有数据点将共享同一套样式配置;比如下面代码中,我们为最后一个数据项单独设置的itemStyle就不会生效:
setOption({
series: [
{
type: "bar",
data: [
10,
20,
30,
// 这个不会生效
{ value: 40, itemStyle: { color: 'red' } }
],
large: true,
largeThreshold: 1000,
itemStyle: {
// 所有柱子都是这个颜色
color: '#fff'
}
},
],
});
progressive属性本质是开启“分片渲染”模式,用以解决超大规模图形元素(数千至千万级)造成的浏览器瞬时阻塞风险。启用后,ECharts会将庞大的数据集自动分割为多个小块(chunk),在多个动画帧中依次渲染,从而将一次性的沉重负载分散为平缓的增量任务。我们在散点图上实测此功能,可以清晰地观察到数万个数据点如同雨点般在画布上逐渐浮现:
const data: Array<[number, number]> = [];
for (let i = 0; i < 10000; i++) {
data.push([
Math.random() * 1000,
Math.random() * 1000
]);
}
setOption({
series: [
{
type: "scatter",
data,
progressive: 100,
progressiveThreshold: 3000,
progressiveChunkMode: 'mod'
},
],
});
![]()
progressive属性控制渐进式渲染的 “粒度”,其值为每一帧渲染的图形数量,默认值为400,设为0,则相当于关闭此功能;而progressiveThreshold属性则设定了启用此功能的 “门槛”。仅当图形总数超过此阈值时,progressive的配置才会生效,开始分帧渲染。
开启large默认会开启progressive渐进渲染。
总结
到这里,我的Echarts性能优化三部曲总算告一段落了;当看到业务方在流畅渲染着四年设备数据的图表前露出满意笑容时,我就知道,这次优化的努力没有白费。
我们首先构建了数据分割机制。当用户选择跨年度的查询范围时,系统不再傻乎乎地一次性请求所有数据,而是像一位细心的图书管理员,将厚厚的历史档案按时间章节分册取出。这个简单的策略,将原本长达14秒的接口响应时间分解为多个毫秒级的快速请求,从根本上避免了浏览器的内存过载和界面冻结。
接着我们引入了Web Worker并行计算。这相当于给数据处理流程雇佣了一位专属的后台助理。所有耗时的数据清洗、格式转换和指标计算都被转移到独立线程中执行,主线程得以保持轻盈,继续流畅地响应用户的每一次点击和滑动。这种前后台分工协作的模式,让数据处理从“阻塞性任务”变成了“后台服务”。
最后,我们在Echarts渲染层施展了一系列组合优化。通过LTTB采样算法,我们在保留数据趋势灵魂的同时,巧妙地减少了渲染负担;借助dataZoom的视口动态加载,我们实现了“所见即所得”的按需渲染;而启用large和progressive模式,则是给图表引擎装上了涡轮增压,让万级数据点的绘制也能达到60帧的流畅体验。
现在回顾这段旅程,让我深刻认识到数据可视化的本质——它不仅仅是数据的图形化呈现,更是信息与洞察的艺术表达。好了,我的优化之旅暂告一段落,但技术的探索永无止境。那么,你的项目中是否也藏着需要被驯服的“数据巨兽”呢?带上这份实战心得,开始你的优化之旅吧!
二、Prettier 配置文件指南
浏览器的垃圾回收机制是什么
从零开始基于Three.js设计3D地图控件系统:小白也能看懂
【性能优化】响应式图片
引言
在现代 Web 开发中,图片往往占据了页面总资源的 50% 以上。在移动设备和高分辨率屏幕普及的今天,如何让用户以最小的带宽成本获得最优的视觉体验,是性能优化中的关键课题。响应式图片正是解决这一问题的核心技术方案。
手段(从手段上通过格式优化与按需加载选图)
- 格式优化:优先使用现代高效格式(AVIF、WebP),不支持则降级到传统格式(JPG、PNG)
- 按需加载:根据图片显示尺寸(槽位分段适配)/视口宽度(视口分段适配)、设备像素比(DPR)选择最合适的图片资源
作用(从作用上减少带宽浪费、提升加载速度)
- 减少带宽浪费:避免在小屏设备上加载过大的图片,避免在低 DPR 设备上加载高清图片
- 提升加载速度:更小的图片体积意味着更快的首屏渲染和更流畅的用户体验
一、槽位适配(Slot-based Adaptation)
定义:以分段适配的方式,预先提供多档尺寸、多档 DPR 的候选图片,根据图片在页面中的实际显示宽度、**设备像素比(DPR)**选择最合适的一档资源。
技术实现:通过 HTML 的 <picture> + srcset + sizes 属性实现。
核心特性:
-
srcset定义了多个候选图片地址及宽度描述符(如image-400w.jpg 400w) -
sizes由多组「媒体条件 + 源尺寸值」组成,描述在不同视口下的槽位宽度(如(max-width: 600px) 100vw, 50vw) - 浏览器根据 媒体条件 与 源尺寸值 得出槽位宽度,再结合 设备像素比(DPR) 与 宽度描述符 选择最合适的图片
示例代码:
① 槽位分段 + 多格式(完整用法):
<picture>
<source
type="image/avif"
srcset="/images/hero-400w.avif 400w, /images/hero-800w.avif 800w, /images/hero-1200w.avif 1200w"
sizes="(max-width: 600px) 100vw, 50vw"
/>
<source
type="image/webp"
srcset="/images/hero-400w.webp 400w, /images/hero-800w.webp 800w, /images/hero-1200w.webp 1200w"
sizes="(max-width: 600px) 100vw, 50vw"
/>
<img
src="/images/hero-400w.jpg"
srcset="/images/hero-400w.jpg 400w, /images/hero-800w.jpg 800w, /images/hero-1200w.jpg 1200w"
sizes="(max-width: 600px) 100vw, 50vw"
alt="Hero Image"
/>
</picture>
② DPR + 格式适配(srcset 用 x 描述符,picture 做格式切换):
<picture>
<source type="image/avif" srcset="/images/hero.avif 1x, /images/hero@2x.avif 2x" />
<source type="image/webp" srcset="/images/hero.webp 1x, /images/hero@2x.webp 2x" />
<img
src="/images/hero.jpg"
srcset="/images/hero.jpg 1x, /images/hero@2x.jpg 2x"
alt="Hero Image"
/>
</picture>
二、视口适配(Viewport-based Adaptation)
定义:以分段适配的方式,结合格式选择(AVIF/WebP)、媒体查询(视口宽度、设备像素比 DPR)为每一档指定图片,浏览器根据当前视口、DPR 及格式支持情况匹配到对应的一档并加载该资源。
技术实现:
-
视口 × DPR 分段:通过 CSS 媒体查询
@media实现 -
格式选择(AVIF/WebP 等):依赖 JS 检测——在应用启动时探测浏览器支持情况,给
<html>添加.avif、.webp等 class,再由 CSS 选择器覆盖对应格式的背景图。CSS 的@supports对图片格式不可靠,故采用 JS + class 方案
示例代码(视口 × DPR 分段 + 格式覆盖):
① 格式检测并往 document 加 class(仅示例 AVIF):
// 用 1x1 AVIF data URI 探测,支持则在根节点加 .avif
const avifDataUri = 'data:image/avif;base64,AAAAIGZ0eXBhdmlm...'
const img = new Image()
img.onload = () => { if (img.width > 0) document.documentElement.classList.add('avif') }
img.onerror = () => {}
img.src = avifDataUri
② 视口 × DPR 分段 + 用 .avif 覆盖格式:
.hero {
// 降级格式(JPG):视口 × DPR
@media (width >= 0) {
@media (resolution >= 1dppx) {
background-image: url('/images/hero-400w.jpg');
}
}
@media (width >= 768px) {
@media (resolution >= 2dppx) {
background-image: url('/images/hero-800w@2x.jpg');
}
}
.avif & {
@media (width >= 0) {
@media (resolution >= 1dppx) {
background-image: url('/images/hero-400w.avif');
}
}
@media (width >= 768px) {
@media (resolution >= 2dppx) {
background-image: url('/images/hero-800w@2x.avif');
}
}
}
}
三、槽位适配与视口适配的对比
3.1 槽位适配更细腻精确
槽位适配在媒体查询的基础上,还依据图片在页面中的实际显示宽度选图,形成“二维精准匹配”。例如:视口 1920px 时,若图片只占 50vw(960px),通过 sizes="50vw" 浏览器会选约 1000w 的图,而视口适配只能按 1920px 选图,容易造成浪费。在复杂布局(多栏、网格等)中,这种差异更明显。
3.2 适用场景不同
槽位适配适用于页面中某些槽位的显示尺寸会随视口变化而变化的场景(如多栏、网格、响应式布局中宽度不固定的图片区域)。通过 sizes 声明各视口下的槽位宽度,浏览器按实际显示宽度选图,避免大视口下小槽位仍加载大图。
视口适配则适合整体随视口缩放的场景(如全屏头图、整页背景),只按视口宽度与 DPR 分段选图,不关心图片在页面中的实际占位大小。该方案在 H5 / 小程序 等移动端页面中应用广泛。
3.3 背景图
槽位适配依赖 HTML 的 sizes 来声明“图片在不同视口下的实际宽度”。CSS 的 background-image 没有等价语法,无法描述“背景在容器中的显示宽度”,只能通过媒体查询获知视口宽度与 DPR。因此背景图无法做槽位式选图,只能采用视口分段适配。
Vue 组件 API 覆盖率工具
前言
在组件开发中,我们经常面临一个问题:组件测试是否真正覆盖了组件的所有 API,传统的代码覆盖率工具只能告诉我们代码行数的覆盖情况,却无法准确反映组件的 Props、Events、Slots 和 Exposed Methods 是否被充分测试。
传统代码覆盖率的局限性
传统的代码覆盖率工具(如 Istanbul、nyc 等)虽然能够统计代码行的执行情况,但在组件测试场景下存在明显的不足。它们无法检查出以下这些问题:
- 无法追踪对象的某个 key 是否被使用:这是根本性的限制。传统工具只能知道某行代码被执行了,但无法精确追踪对象的哪些属性被访问。例如,组件的 props 对象被传递了,但不知道具体哪些 prop 键被使用
- 无法 测试 是否遗漏了 Slots 的 TS 类型定义:组件有测试 slots 的功能,但没有声明 slots 的类型
- 无法找出是否存在冗余的 Props:定义了某些 props,但未被实际使用
-
无法检查 Props 的所有枚举值是否都 测试 过:例如
type: 'primary' | 'ghost' | 'dashed'这种联合类型,可能只测试了'primary',而遗漏了其他变体 -
无法检查 Props 的所有类型是否都 测试 过:例如
value可能接受Boolean | String | Number | Array,但测试中只传了字符串
这些问题在组件库开发中尤为突出。一个看似 90% 代码覆盖率的组件,实际上可能有大量未经测试的 API 边界情况。传统覆盖率工具基于代码执行行数统计,而组件 API 测试需要的是基于类型系统和对象属性的精确追踪。
实践中的困境
在早期做公司内部组件库的时候,我们也开启过一轮对组件 API 覆盖率的人工检查。然而,由于组件 API 过多,检查过程极其困难,最终总会有许多漏写的单元测试。人工核对的方式不仅效率低下,而且容易遗漏,标准也难以统一。
为了解决这个问题,我在半年前用 AI 开发了 vc-api-coverage,一个专门为 Vue 3 TSX 组件设计的 API 覆盖率分析工具。本文将深入剖析这个工具的技术实现原理,分享如何利用 TypeScript 类型系统和 AST 分析来实现精准的 API 覆盖率检测。
![]()
核心设计思路
这个工具的核心理念是:通过静态分析组件定义和 测试 代码,建立组件 API 与测试用例之间的映射关系。
设计理念
在大学学过的一门项目管理课程中,讲到了"设备点检",这是一种预防性设备维护管理制度。通过定期、定点、定标、定人、定法的方式对设备进行检查,以确保设备正常运行。
这个覆盖率工具的设计思路与"设备点检"有异曲同工之妙,主要对定标、定法、定期这3个环节进行了强化:
- 定标:将原本模糊、可完成可不完成的测试标准,变成一个明确、量化、强制的标准(如:100% API 覆盖率)。
- 定法:将对api覆盖率的手动检查,变成程序自动化的检查。
- 定期:将原本一次性的检查,变成CI流水线的周期检查。
通过工具化的方式,我们把主观的人工检查转变为客观的自动化检测,把模糊的质量要求转变为精确的量化指标。
整体架构
整体架构分为三个核心模块:
- ComponentAnalyzer:分析组件定义,提取所有可用的 API
- UnitTestAnalyzer:分析测试代码,识别哪些 API 被测试覆盖
- Reporter:生成可视化的覆盖率报告(CLI、HTML、JSON)
![]()
技术选型
在开始介绍具体实现之前,先分享一下技术选型过程中的弯路和思考。
早期方案
最初设计这个覆盖率工具时,我的想法是通过 AST(抽象语法树)去分析组件代码,直接提取出 Props、Slots 和 Exposed Methods。这个方案看起来很直接,但在实践中遇到了巨大的挑战:
Vue 组件的写法复杂多变,静态分析难以覆盖所有场景:
-
多种 API 风格:组件既可以用 Composition API 的
setup写法,也可以用 Options API 写法 -
运行时配置:组件可能配置了
mixins、extends等,这些内容需要递归分析多个文件 -
动态计算的 Props:有些组件的 props 需要运行时才能确定,例如使用
lodash.pick从另一个对象选取部分 props:
import { pick } from 'lodash';
const baseProps = { a: String, b: Number, c: Boolean };
const componentProps = pick(baseProps, ['a', 'b']); // 静态分析无法得知结果
4. 类型信息丢失:纯 AST 分析只能看到代码结构,很难准确推断出 union 类型、可选属性等类型信息
经过几次尝试,发现要覆盖所有 Vue 组件的写法,需要实现一个接近完整的 Vue 编译器,这显然不现实。
最终方案
后来换了一个思路:既然 Vue 3 组件本身就有完整的类型定义,为什么不直接利用 TypeScript 的类型系统呢?
这个方案的优势非常明显:
- 统一的接口:无论组件怎么写(setup、options、mixins),最终都会生成统一的组件类型,TypeScript 编译器已经帮我们处理好了所有复杂情况
- 完整的类型信息:可以直接获取 union 类型、可选属性、泛型参数等完整的类型信息
-
简单快捷:通过
InstanceType<typeof Component>['$props']就能获取所有 props,无需关心组件内部实现 - 零维护成本:随着 Vue 版本升级,只要类型定义更新了,工具就能自动适配
这就是为什么最终选择了"类型系统 + AST"的混合方案:
- 用类型系统提取 Props、Events、Slots(简单可靠)
- 用 AST 提取单元测试代码(类型系统无法覆盖的场景)
技术选型的启示:不要试图重新实现已有的轮子。TypeScript 编译器已经解决了类型推断的复杂问题,我们应该站在巨人的肩膀上。
技术实现详解
组件 API 提取
组件的 Props、Events 和 Slots 信息隐藏在 Vue 组件的类型定义中,见TS Playground示例。我们利用 ts-morph 库来访问 TypeScript 的类型系统:
1. Props/Events 提取
// src/analyzer/ComponentAnalyzer.ts:30
analyzePropsAndEmits(instanceType: Type, exportedExpression: Expression) {
// 通过 $props 属性获取组件的所有 props
const dollarPropsSymbol = instanceType.getProperty('$props');
if (!dollarPropsSymbol) returnconst dollarPropsType = dollarPropsSymbol.getTypeAtLocation(exportedExpression);
dollarPropsType.getProperties().forEach(propSymbol => {
const propName = propSymbol.getName();
// 过滤内部属性
if (!internalProps.includes(propName)) {
this.props.add(propName);
}
});
}
核心原理:Vue 3 组件通过 InstanceType<typeof Component>['$props'] 暴露了所有 props 的类型信息。我们直接访问这个类型,遍历其所有属性,就能获得完整的 props 列表。
2. Slots 提取
// src/analyzer/ComponentAnalyzer.ts:157
analyzeSlots(instanceType: Type, exportedExpression: Expression) {
const dollarPropsSymbol = instanceType.getProperty('$slots');
if (!dollarPropsSymbol) returnconst dollarPropsType = dollarPropsSymbol.getTypeAtLocation(exportedExpression);
dollarPropsType.getProperties().forEach(propSymbol => {
const propName = propSymbol.getName();
this.slots.add(propName);
});
}
核心原理:与 props 类似,通过 $slots 属性获取所有插槽的类型定义。
3. Exposed Methods 提取
Exposed methods无法从 TypeScript 类型系统中获取,我们采用了 AST 代码分析的方法:
// src/analyzer/ComponentAnalyzer.ts:176
analyzeExposeContextCalls() {
// 方法1: 检测 expose({ ... }) 调用
const matches = this.code.match(/expose(\s*{([^}]+)}\s*)/g);
if (matches && matches.length > 0) {
for (const match of matches) {
const propsStr = match.replace(/expose(\s*{/, '').replace(/}\s*)/, '');
const propMatches = propsStr.match(/(\w+),?/g);
if (propMatches) {
for (const prop of propMatches) {
const cleanProp = prop.replace(/,/g, '').trim();
if (cleanProp) {
this.exposes.add(cleanProp);
}
}
}
}
}
}
// src/analyzer/ComponentAnalyzer.ts:202
analyzeExposeArrayOption(exportedExpression: Expression) {
// 方法2: 检测 defineComponent({ expose: ['method1', 'method2'] })
const componentOptions = this.getComponentOptions(exportedExpression);
if (!componentOptions) return;
const exposeArray = this.getExposeArrayFromOptions(componentOptions);
if (!exposeArray) return;
const exposeItems = exposeArray.getElements();
for (const item of exposeItems) {
const itemName = this.getItemName(item);
if (itemName) {
this.exposes.add(itemName);
}
}
}
核心原理:
- 通过正则表达式匹配
expose({ ... })调用 - 通过 AST 分析
defineComponent的expose选项 - 支持多种写法:字符串字面量、标识符、枚举值等
测试覆盖分析
测试代码有多种写法,我们需要支持各种常见的测试模式。
模式 1:传统 mount 方法
// 测试代码
mount(Button, {
props: { variant: 'primary', disabled: true },
slots: { default: 'Click me' }
});
// src/analyzer/UnitTestAnalyzer.ts:186
processMountComponent(componentArgNode: Node, optionsNode?: ObjectLiteralExpression) {
if (!optionsNode) returnconst componentName = componentArgNode.getText();
const componentFile = this.resolveComponentPath(componentArgNode as Identifier);
if (!this.result[componentFile]) {
this.result[componentFile] = {};
}
// 提取 props、emits、slots
this.extractProps(optionsNode, this.result[componentFile]);
this.extractEmits(optionsNode, this.result[componentFile]);
this.extractSlots(optionsNode, this.result[componentFile]);
}
模式 2:JSX 写法
// 测试代码
render(<Button variant="primary" disabled onClick={handler}>
Click me
</Button>);
// src/analyzer/UnitTestAnalyzer.ts:678
private analyzeJSXElements(callExpression: CallExpression) {
const jsxElements = this.findJsxInCallExpression(callExpression);
for (const jsxElement of jsxElements) {
const openingElement = Node.isJsxElement(jsxElement)
? jsxElement.getOpeningElement()
: jsxElement;
const tagName = openingElement.getTagNameNode().getText();
const filePath = this.resolveComponentPath(openingElement.getTagNameNode());
// 提取 JSX 属性作为 props
this.extractJSXAttrs(openingElement, this.result[filePath]);
// 提取 JSX 子元素作为 slots
if (Node.isJsxElement(jsxElement)) {
this.extractJSXSlots(jsxElement, this.result[filePath]);
}
}
}
模式 3:Template 字符串
// 测试代码
mount({
template: '<Button variant="primary" @click="handler">Click me</Button>',
components: { Button }
});
// src/analyzer/UnitTestAnalyzer.ts:269
private extractPropsFromTemplate(template: string, componentTagName: string, componentTestUnit: TestUnit) {
// 使用正则表达式解析模板中的属性
const tagRegex = new RegExp(`<${componentTagName}(\s+[^>]*?)?>`, 'ig');
let match;
const propsFound: string[] = [];
while ((match = tagRegex.exec(template)) !== null) {
const attrsString = match[1];
if (!attrsString) continue;
// 解析属性名
const attrRegex = /([@:a-zA-Z0-9_-]+)(?:=(?:"[^"]*"|'[^']*'|[^\s>]*))?/g;
let attrMatch;
while ((attrMatch = attrRegex.exec(attrsString)) !== null) {
let propName = attrMatch[1];
// 处理 v-bind:, :, v-model: 等前缀
if (propName.startsWith(':')) {
propName = propName.substring(1);
} else if (propName.startsWith('v-bind:')) {
propName = propName.substring(7);
}
propsFound.push(propName);
}
}
componentTestUnit.props = [...new Set([...(componentTestUnit.props || []), ...propsFound])];
}
Exposed Methods 检测
对于暴露的方法,我们采用了一个简单但有效的策略:方法名匹配。
// src/analyzer/UnitTestAnalyzer.ts:1381
private analyzeExposedMethods(testCall: CallExpression) {
const calledMethods = new Set<string>();
// 查找所有属性访问表达式 (xxx.methodName)
const propertyAccesses = testCall.getDescendantsOfKind(SyntaxKind.PropertyAccessExpression);
for (const access of propertyAccesses) {
const methodName = access.getName();
// 检查是否为暴露的方法
if (this.isExposedMethod(methodName)) {
calledMethods.add(methodName);
}
}
// 将这些方法添加到组件的覆盖记录中
for (const componentFile in this.result) {
if (!this.result[componentFile].exposes) {
this.result[componentFile].exposes = [];
}
for (const method of calledMethods) {
if (!this.result[componentFile].exposes.includes(method)) {
this.result[componentFile].exposes.push(method);
}
}
}
}
核心原理:扫描测试代码中的所有属性访问表达式(如 wrapper.vm.focus()),提取方法名,然后过滤掉 Vue 内置方法和测试工具方法。
Strict Mode
在严格模式下,我们不仅检测 prop 是否被测试,还会检测每个 union 类型的变体是否都被测试。
// src/analyzer/ComponentAnalyzer.ts:42
if (this.strictMode) {
const propType = propSymbol.getTypeAtLocation(exportedExpression);
const nonNullableType = propType.getNonNullableType();
const variants = this.extractVariantsFromType(nonNullableType);
if (variants.length > 0) {
this.propsWithVariants.push({
name: propName,
variants
});
}
}
Union 类型展开
// src/analyzer/ComponentAnalyzer.ts:62
private extractVariantsFromType(type: Type): PropVariant[] {
const variants: PropVariant[] = [];
if (type.isUnion()) {
const unionTypes = type.getUnionTypes();
for (const unionType of unionTypes) {
// 跳过 undefined 和 null
if (unionType.isUndefined() || unionType.isNull()) {
continue;
}
const variant = this.getVariantFromType(unionType);
if (variant) {
// 跳过 false(boolean 类型只展开 true)
if (!(variant.type === 'literal' && variant.value === false)) {
variants.push(variant);
}
}
}
}
return variants;
}
核心原理:
- 检测 prop 类型是否为 union 类型
- 遍历所有 union 成员,提取字面量值
- Boolean 类型只展开
true(因为false通常是默认值) - 过滤掉
undefined和null
测试值提取
在测试代码中,我们需要提取实际传递的值:
// src/analyzer/UnitTestAnalyzer.ts:942
private extractPropValue(attr: Node): PropValue | null {
if (!Node.isJsxAttribute(attr)) return null;
const propName = attr.getNameNode().getText();
const initializer = attr.getInitializer();
if (!initializer) {
// 布尔属性 <Button disabled />
return { propName, value: true, type: 'literal' };
}
// 字符串字面量
if (Node.isStringLiteral(initializer)) {
return { propName, value: initializer.getLiteralValue(), type: 'literal' };
}
// JSX 表达式
if (Node.isJsxExpression(initializer)) {
const expression = initializer.getExpression();
if (!expression) return null;
// 数字、布尔等字面量
if (Node.isNumericLiteral(expression)) {
return { propName, value: Number(expression.getLiteralValue()), type: 'literal' };
}
// 处理变量:通过类型推断获取实际值
const exprType = expression.getType();
if (exprType.isLiteral()) {
const literalValue = exprType.getLiteralValue();
if (literalValue !== undefined) {
return { propName, value: literalValue, type: 'literal' };
}
}
}
return null;
}
核心原理:
- 直接提取字面量值
- 对于变量和表达式,利用 TypeScript 的类型推断获取值
- 支持 ref 值追踪、循环变量展开等复杂场景
组件路径解析
为了准确关联测试代码和组件定义,我们需要解析 import 语句,找到组件的真实路径:
// src/analyzer/UnitTestAnalyzer.ts:89
private resolveComponentPath(identifier: Identifier, importSymbol?: Symbol) {
try {
let originalSymbol: Symbol | undefined = importSymbol;
if (identifier) {
const typeChecker = this.project.getTypeChecker();
originalSymbol = typeChecker.getSymbolAtLocation(identifier);
}
if (!originalSymbol) return null;
// 解析别名
while (originalSymbol?.getAliasedSymbol()) {
originalSymbol = originalSymbol.getAliasedSymbol();
}
if (!originalSymbol) return null;
const declarations = originalSymbol.getDeclarations();
const declarationNode = declarations[0];
if (!declarationNode) return null;
const declarationSourceFile = declarationNode.getSourceFile();
const originalPath = declarationSourceFile.getFilePath();
if (!isComponentFile(originalPath)) {
// 继续解析转发导出
return this.resolveTsPath(declarationNode);
}
return originalPath;
} catch (error) {
return null;
}
}
核心原理:
-
从 identifier 获取 symbol
-
递归解析 alias symbol(处理
export { Button as Btn }等情况) -
获取原始声明文件路径
-
处理中间层的转发导出
实际应用场景
1. CI/CD 集成
通过 onFinished 回调强制 100% 覆盖:
export default defineConfig({
test: {
reporters: [['vc-api-coverage', {
onFinished: (data) => {
for (const item of data) {
if (item.total > item.covered) {
throw new Error(`${item.name} API Coverage is not 100%`)
}
}
}
}]]
}
})
2. 组件库开发
对于组件库,确保每个组件的所有 API 都有测试覆盖:
reporters: [['vc-api-coverage', {
include: ['**/src/components/**/*.{tsx,vue}'],
format: ['cli', 'html'],
openBrowser: true
}]]
3. 严格模式下的全面测试
对关键组件使用严格模式,确保每个 prop 变体都被测试:
reporters: [['vc-api-coverage', {
include: ['**/src/components/Button/**/*.tsx'],
strict: true // 开启严格模式
}]]
总结
vc-api-coverage 通过巧妙地结合 TypeScript 类型系统和 AST 分析,实现了对 Vue 组件 API 覆盖率的精准检测。核心技术点包括:
-
类型系统利用:通过
$props、$slots等类型属性提取组件 API - 多模式识别:支持 JSX、模板字符串、mount 对象等多种测试写法
- 严格模式:细粒度追踪 union 类型的每个变体
- 路径解析:递归追踪 import/export,准确关联测试和组件
这个工具不仅提升了组件测试的质量,还为团队提供了可量化的测试指标,让"测试覆盖率"这个概念更加贴近前端组件开发的实际需求。
后记
在目前 AI 辅助开发、Markdown 文档泛滥的场景下,其实开发一个强约束的工具也是一个不错的方向。相比于只能提供建议的文档和规范,带有强制检查能力的工具能够真正保证代码质量的底线。就像这个 API 覆盖率工具,它不是告诉你“应该写测试”,而是确保“必须写哪些测试”。
最后,感谢 Cursor 和 Claude Code 帮我完成了这个覆盖率工具和这篇分享文档。在 AI 辅助开发的时代,借助这些强大的工具,我们能够快速将想法转化为可用的产品。当然 AI 也不是万能,在某些场景下 AI i写的单测并没有实际测试到组件的功能,所以 AI 写的单测还是要让 AI 去review的。
参考资源
v-bind 你用对了吗?
先极简总结(2 句话记死,终身受用)
-
绑 1 个属性:用缩写
:属性名="值"(原生标签 / Vue 组件通用,日常 90% 用这个); -
绑 N 个属性:用
v-bind="属性对象"(无冒号、无属性名,属性越多越简洁,封装组件 / 配置驱动场景必用)。
核心前提先讲透(一句话干货)
-
v-bind是 Vue 用来给HTML 标签 / Vue 组件绑定动态属性值的指令,只有 2 种核心用法,本质都是「动态传值」,区别仅在于绑 1 个属性还是绑多个属性
-
单个属性绑定:
v-bind:属性名="值"→ 缩写:属性名="值"(日常 90% 高频用); -
批量属性绑定:直接
v-bind="属性对象"(无属性名、无冒号,把多个属性打包成对象一次性绑定);
关键:批量绑定的属性对象,键 = HTML 标签 / Vue 组件的属性名,值 = 要绑定的动态数据,Vue 会自动解析成「键 = 值」的单个属性,一一绑定到标签上。
例子 :原生img图片标签(最易理解的通用场景)
img标签的src(图片地址)、alt(占位文字)、width(宽度)是所有人都认识的原生属性,用它举例最直观,重点看单个绑定和批量绑定的等价关系。
步骤 :先定义 Vue 里的动态数据(脚本部分,通用)
<script setup>
// Vue3基础响应式数据,不用纠结ref,知道是动态值就行
import { ref } from 'vue'
// 图片地址
const imgUrl = ref('https://picsum.photos/200/200')
// 图片占位文字
const imgText = ref('风景图')
// 图片宽度
const imgW = ref(200)
</script>
用法 1:单个属性绑定(缩写:,逐个绑)
最常用的写法,给img逐个绑定动态属性,每个属性都用:缩写,模板清晰:
<template>
<!-- 核心:每个原生属性前加:,绑定对应的动态值 -->
<img :src="imgUrl" :alt="imgText" :width="imgW" />
</template>
等价于完整v-bind写法(繁琐,几乎没人用):
<script setup>
import { ref, reactive } from 'vue'
// 1. 先定义零散动态值
const imgUrl = ref('https://picsum.photos/200/200')
const imgText = ref('风景图')
const imgW = ref(200)
// 2. 打包成「属性对象」:键=img原生属性名,值=动态值
const imgProps = reactive({ src: imgUrl, alt: imgText, width: imgW })
</script>
<template>
<!-- 核心:无属性名、无冒号,v-bind直接绑属性对象 -->
<img v-bind="imgProps" />
</template>
用法 2:批量属性绑定(v-bind="对象",打包绑)
把img需要的所有动态属性打包成一个对象,用v-bind直接绑定这个对象,Vue 会自动解析:
<script setup>
import { ref, reactive } from 'vue'
// 1. 先定义零散动态值
const imgUrl = ref('https://picsum.photos/200/200')
const imgText = ref('风景图')
const imgW = ref(200)
// 2. 打包成「属性对象」:键=img原生属性名,值=动态值
const imgProps = reactive({ src: imgUrl, alt: imgText, width: imgW })
</script>
<template>
<!-- 核心:无属性名、无冒号,v-bind直接绑属性对象 -->
<img v-bind="imgProps" />
</template>
完全等价于单个绑定的写法,Vue 会自动把imgProps里的src/alt/width逐个绑定到img标签上,效果一模一样。
单个和批量这两种用法是 Vue 最基础、最高频的语法,不用记复杂概念,只要知道「单个用:,多个用 v-bind = 对象」,就能搞定所有动态属性绑定场景。
Guigu 甑选平台第一篇:项目初始化与配置
第一章:项目创建 - 使用Create Vue的理由和步骤
步骤1:使用官方脚手架创建项目
使用npm create vue@latest是因为这是Vue团队官方维护的脚手架工具,能够确保项目结构与最新Vue特性完全兼容。它集成了Vue社区的最佳实践和推荐配置,减少了手动配置可能出现的错误。交互式命令行让开发者能够按需选择功能模块。
bash
复制下载
# 执行创建命令
npm create vue@latest
# 交互式配置
√ Project name: ... guigu-zhenxuan-platform
√ Add TypeScript? ... Yes # 选择TypeScript是为了提供类型安全,减少运行时错误
√ Add JSX Support? ... No # 不使用JSX是因为Vue推荐使用模板语法,保持项目语法一致性
√ Add Vue Router for Single Page Application development? ... Yes # 添加Vue Router是因为SPA应用必须的路由管理
√ Add Pinia for state management? ... Yes # 选择Pinia是因为它是Vue官方推荐的状态管理库
√ Add Vitest for Unit Testing? ... No # 不先添加单元测试是为了先搭建项目基础架构,测试可以后期添加
√ Add an End-to-End Testing Solution? ... No # 不添加E2E测试是因为初期项目重点在功能开发
√ Add ESLint for code quality? ... Yes # 添加ESLint是为了统一代码风格,提高代码质量
√ Add Prettier for code formatting? ... Yes # 添加Prettier是为了自动格式化代码,避免团队成员间的格式争议
# 进入项目并安装基础依赖
cd guigu-zhenxuan-platform
npm install
初始化后的项目结构说明:
text
复制下载
guigu-zhenxuan-platform/
├── src/
│ ├── components/ # components目录用于存放可复用的UI组件
│ ├── views/ # views目录用于存放页面级组件,这是Vue Router的惯例命名
│ ├── router/ # router目录用于集中管理路由配置
│ ├── stores/ # stores目录用于存放Pinia状态管理文件
│ └── main.ts # main.ts是Vue应用的入口文件
├── public/ # public目录用于存放不需要构建处理的静态资源
├── .eslintrc.cjs # ESLint配置文件,使用.cjs扩展名是因为需要CommonJS格式
├── .prettierrc # Prettier代码格式化配置文件
├── index.html # HTML入口文件,浏览器通过这个文件加载应用
├── package.json # 项目配置文件,管理依赖和脚本
├── tsconfig.json # TypeScript编译配置文件
└── vite.config.ts # Vite构建工具配置文件
第二章:修改Package.json - 详细配置解析
步骤1:更新scripts配置
scripts配置决定了项目的开发工作流,合理的配置能提高开发效率。
打开package.json,修改scripts部分:
json
复制下载
"scripts": {
"dev": "vite --open",
// 配置vite --open是为了启动开发服务器后自动打开浏览器,提升开发体验
"build": "run-p type-check "build-only {@}" --",
// 这样配置build命令是为了并行执行类型检查和构建过程,提高构建速度
"preview": "vite preview",
// preview命令用于预览生产环境构建结果,验证构建效果是否符合预期
"build-only": "vite build",
// 单独的build-only命令用于纯构建操作,方便在组合命令中调用
"type-check": "vue-tsc --build",
// 使用vue-tsc是因为它专门针对Vue单文件组件进行TypeScript类型检查
"lint": "run-s lint:*",
// 使用run-s是为了顺序执行所有lint相关任务,确保代码检查的完整性
"lint:oxlint": "oxlint . --fix",
// 配置oxlint是因为它相比ESLint有更好的性能表现,检查速度更快
"lint:eslint": "eslint . --fix --cache",
// 保留ESLint是因为它有成熟的生态系统和丰富的插件支持
"format": "prettier --write --experimental-cli src/",
// 使用--experimental-cli参数是为了启用Prettier新版本的命令行特性
"preinstall": "node ./scripts/preinstall.js"
// preinstall脚本用于在安装依赖前检查开发环境是否符合要求
}
步骤2:添加生产依赖
生产依赖是项目运行时必须的包,每个依赖都有特定的业务用途。
执行以下安装命令:
bash
复制下载
# 安装Element Plus UI组件库
npm install element-plus
# 安装Element Plus是因为它提供了丰富的企业级UI组件,能显著加快开发速度
# 安装Element Plus图标库
npm install @element-plus/icons-vue
# 安装图标库是为了提供丰富的图标资源,提升用户界面视觉效果
# 安装Axios HTTP客户端
npm install axios
# 安装Axios是因为它是一个功能强大的HTTP客户端,支持请求拦截、响应拦截等高级特性
# 安装Mock.js数据模拟库
npm install mockjs
# 安装Mock.js是为了在开发阶段模拟后端API数据,实现前后端并行开发
package.json中的dependencies部分配置如下:
json
复制下载
"dependencies": {
"@element-plus/icons-vue": "^2.3.2", // Element Plus图标组件
"axios": "^1.13.4", // HTTP请求库,用于API调用
"element-plus": "^2.13.1", // UI组件库,提供基础界面组件
"mockjs": "^1.1.0", // 模拟数据生成器
"pinia": "^2.1.7", // 状态管理库,已由create-vue安装
"vue": "^3.4.21", // Vue核心框架,已由create-vue安装
"vue-router": "^4.3.0" // 路由管理库,已由create-vue安装
}
步骤3:添加开发依赖
开发依赖只在开发阶段使用,用于提升开发体验和保证代码质量。
执行以下安装命令:
bash
复制下载
# 安装TypeScript相关配置
npm install --save-dev @tsconfig/node24
# 安装@tsconfig/node24是为了使用Node.js 24的TypeScript配置预设
npm install --save-dev @vue/tsconfig
# 安装@vue/tsconfig是为了使用Vue官方推荐的TypeScript配置预设
npm install --save-dev @types/node
# 安装@types/node是为了获取Node.js API的类型定义
# 安装Vite插件
npm install --save-dev vite-plugin-mock
# 安装vite-plugin-mock是为了将Mock数据集成到Vite开发服务器中
npm install --save-dev vite-plugin-svg-icons
# 安装vite-plugin-svg-icons是为了优化SVG图标的使用体验
npm install --save-dev vite-plugin-vue-devtools
# 安装vite-plugin-vue-devtools是为了增强Vue开发工具的功能
# 安装代码质量工具
npm install --save-dev eslint-config-prettier
# 安装eslint-config-prettier是为了集成Prettier和ESLint,避免规则冲突
npm install --save-dev eslint-plugin-oxlint
# 安装eslint-plugin-oxlint是为了在ESLint中使用oxlint规则
npm install --save-dev oxlint
# 安装oxlint是因为它提供了比ESLint更快的JavaScript代码检查
# 安装工具库
npm install --save-dev npm-run-all2
# 安装npm-run-all2是为了并行或顺序运行多个npm脚本
npm install --save-dev jiti
# 安装jiti是为了提供TypeScript文件的即时编译能力
完整的devDependencies配置如下:
json
复制下载
"devDependencies": {
"@tsconfig/node24": "^24.0.4", // Node.js 24的TypeScript配置预设
"@types/node": "^20.12.7", // Node.js API类型定义
"@vitejs/plugin-vue": "^5.0.4", // Vite的Vue单文件组件插件
"@vue/eslint-config-typescript": "^13.0.0", // Vue项目的TypeScript ESLint配置
"@vue/tsconfig": "^0.5.0", // Vue项目的TypeScript配置
"eslint": "^9.0.0", // JavaScript代码检查工具
"eslint-config-prettier": "^9.1.0", // 关闭与Prettier冲突的ESLint规则
"eslint-plugin-oxlint": "~1.42.0", // oxlint的ESLint插件
"eslint-plugin-vue": "^9.23.0", // Vue.js的ESLint插件
"jiti": "^1.21.0", // TypeScript即时编译工具
"npm-run-all2": "^8.0.4", // 并行运行npm脚本的工具
"oxlint": "~1.42.0", // 高性能JavaScript linter
"prettier": "3.2.5", // 代码格式化工具
"typescript": "~5.3.3", // TypeScript编译器
"vite": "^5.2.0", // 前端构建工具
"vite-plugin-mock": "^3.0.2", // Vite的Mock数据插件
"vite-plugin-svg-icons": "^2.0.1", // Vite的SVG图标插件
"vite-plugin-vue-devtools": "^7.3.0", // Vite的Vue开发工具插件
"vue-tsc": "^1.8.27" // Vue单文件组件的TypeScript检查器
}
步骤4:配置引擎要求和Prettier
在package.json末尾添加以下配置:
json
复制下载
"engines": {
"node": "^20.19.0 || >=22.12.0"
},
// 配置engines是为了明确项目所需的Node.js版本范围,确保开发环境一致性
"prettier": {
"ignorePath": ".prettierignore"
}
// 配置prettier是为了指定忽略文件配置,避免对特定文件进行格式化
第三章:创建环境检查脚本
步骤1:创建预安装脚本
预安装脚本在npm install之前执行,用于检查开发环境是否符合要求。
bash
复制下载
# 创建scripts目录
mkdir scripts
# 创建preinstall.js文件
touch scripts/preinstall.js
编辑scripts/preinstall.js文件:
javascript
复制下载
// 检查Node.js版本是否符合项目要求
const currentNodeVersion = process.versions.node;
const semver = currentNodeVersion.split('.');
const major = parseInt(semver[0], 10);
// 项目要求Node.js 20.19.0或更高版本
if (major < 20) {
console.error(
'你正在使用 Node.js ' +
currentNodeVersion +
'。\n' +
'本项目需要 Node.js 20.19.0 或更高版本。\n' +
'请升级你的 Node.js 版本。'
);
process.exit(1); // 退出进程,阻止继续安装
}
console.log('✅ Node.js 版本检查通过');
// 版本检查通过后,npm install会继续执行
这个脚本的作用:确保所有开发者在一致的Node.js环境下工作,避免因版本差异导致的兼容性问题。
第四章:配置HTML入口文件
步骤1:修改index.html
index.html是Web应用的入口文件,浏览器通过加载这个文件启动整个应用。
编辑index.html文件:
html
复制下载运行
<!DOCTYPE html>
<html lang="zh-CN">
<!-- 指定中文语言是为了更好的无障碍支持和SEO优化 -->
<head>
<meta charset="UTF-8">
<!-- 设置UTF-8编码是为了支持中文等多语言字符 -->
<link rel="icon" href="/favicon.ico">
<!-- 设置网站图标,提升品牌识别度 -->
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<!-- 配置viewport是为了实现响应式设计,适配移动设备 -->
<title>硅谷甑选平台</title>
<!-- 设置页面标题,显示在浏览器标签页上 -->
</head>
<body>
<div id="app"></div>
<!-- Vue应用挂载点,所有Vue组件将在这个div内渲染 -->
<script type="module" src="/src/main.ts"></script>
<!-- 使用type="module"启用ES模块支持,加载应用入口文件 -->
</body>
</html>
第五章:配置TypeScript和Vite
步骤1:修改tsconfig.json
TypeScript配置文件决定了TypeScript编译器如何工作。
打开tsconfig.json,确保配置正确:
json
复制下载
{
"extends": "@vue/tsconfig/tsconfig.dom.json",
// 继承Vue官方的TypeScript配置,减少手动配置工作量
"compilerOptions": {
"target": "ES2020",
// 设置编译目标为ES2020,使用较新的JavaScript特性
"useDefineForClassFields": true,
// 使用ES2022的类字段定义方式
"module": "ESNext",
// 使用ES模块系统,支持tree-shaking
"lib": ["ES2020", "DOM", "DOM.Iterable"],
// 包含的库文件,提供类型提示
"skipLibCheck": true,
// 跳过库文件的类型检查,加快编译速度
"moduleResolution": "bundler",
// 使用bundler的模块解析策略,与Vite保持一致
"allowImportingTsExtensions": true,
// 允许导入TypeScript扩展名的文件
"resolveJsonModule": true,
// 允许导入JSON文件作为模块
"isolatedModules": true,
// 确保每个文件都能单独编译
"noEmit": true,
// 不输出编译文件,由Vite处理构建
"jsx": "preserve",
// 保留JSX语法,由其他工具处理
"strict": true,
// 启用所有严格类型检查
"noUnusedLocals": true,
// 检查未使用的局部变量
"noUnusedParameters": true,
// 检查未使用的函数参数
"noFallthroughCasesInSwitch": true,
// 检查switch语句的fallthrough情况
"baseUrl": ".",
// 设置基础路径为当前目录
"paths": {
"@/*": ["./src/*"]
}
// 配置路径别名,@表示src目录,简化导入路径
},
"include": ["src/**/*.ts", "src/**/*.tsx", "src/**/*.vue"],
// 包含需要编译的文件类型
"references": [
{
"path": "./tsconfig.node.json"
}
// 引用Node环境的TypeScript配置
]
}
步骤2:修改tsconfig.node.json
这个文件用于配置Node.js环境的TypeScript编译。
json
复制下载
{
"extends": "@tsconfig/node24/tsconfig.json",
// 继承Node.js 24的TypeScript配置预设
"include": [
"vite.config.ts",
"scripts/**/*",
"mock/**/*"
],
// 包含Node环境下的TypeScript文件
"compilerOptions": {
"composite": true,
// 启用复合编译,支持项目引用
"noEmit": true,
// 不输出编译文件
"tsBuildInfoFile": "./node_modules/.tmp/tsconfig.node.tsbuildinfo"
// TypeScript构建信息文件位置
}
}
步骤3:配置Vite构建工具
Vite配置文件决定了项目的构建行为和开发服务器配置。
打开vite.config.ts,修改为:
typescript
复制下载
import { fileURLToPath, URL } from 'node:url'
// 导入URL处理工具,用于处理文件路径
import { defineConfig } from 'vite'
// 导入Vite配置函数
import vue from '@vitejs/plugin-vue'
// 导入Vite的Vue插件,用于处理.vue文件
import { viteMockServe } from 'vite-plugin-mock'
// 导入Mock插件,用于开发阶段的数据模拟
import { createSvgIconsPlugin } from 'vite-plugin-svg-icons'
// 导入SVG图标插件,优化图标使用
import VueDevTools from 'vite-plugin-vue-devtools'
// 导入Vue开发工具插件,增强调试能力
import path from 'path'
// 导入路径处理工具
export default defineConfig(({ command }) => ({
// 根据命令模式(serve/build)返回不同配置
plugins: [
vue(),
// Vue单文件组件插件,必须放在第一个
viteMockServe({
mockPath: 'mock',
// Mock数据文件存放目录
enable: command === 'serve',
// 只在开发服务器启用Mock
}),
createSvgIconsPlugin({
iconDirs: [path.resolve(process.cwd(), 'src/assets/icons')],
// SVG图标文件目录
symbolId: 'icon-[dir]-[name]',
// 图标ID生成规则
}),
VueDevTools(),
// Vue开发工具插件
],
resolve: {
alias: {
'@': fileURLToPath(new URL('./src', import.meta.url))
// 配置路径别名,@指向src目录
}
},
server: {
port: 3000,
// 开发服务器端口号
open: true,
// 启动后自动打开浏览器
proxy: {
'/api': {
target: 'http://localhost:8080',
// 代理目标地址
changeOrigin: true,
// 修改请求头中的Origin字段
rewrite: (path) => path.replace(/^/api/, '')
// 重写请求路径,移除/api前缀
}
}
}
}))
第六章:配置代码质量和样式
步骤1:创建样式重置文件
样式重置文件用于统一不同浏览器的默认样式,提供一致的基准样式。
bash
复制下载
# 创建styles目录
mkdir src/styles
# 创建reset.css文件
touch src/styles/reset.css
编辑src/styles/reset.css文件:
css
复制下载
/* 重置所有元素的默认边距和内边距 */
* {
margin: 0;
padding: 0;
box-sizing: border-box;
/* 使用border-box盒模型,更符合开发直觉 */
}
/* 设置根元素和body的高度 */
html, body {
height: 100%;
/* 确保页面能占满整个视口高度 */
font-family: -apple-system, BlinkMacSystemFont, 'Segoe UI', Roboto, 'Helvetica Neue', Arial, sans-serif;
/* 设置字体栈,优先使用系统字体 */
}
/* 设置Vue应用容器的样式 */
#app {
height: 100%;
/* 应用容器占满整个父元素高度 */
}
步骤2:修改ESLint配置
ESLint配置文件定义了代码检查规则,确保代码质量一致性。
打开.eslintrc.cjs,修改为:
javascript
复制下载
/* eslint-env node */
// 声明当前文件运行在Node.js环境中
require('@rushstack/eslint-patch/modern-module-resolution')
// 使用ESLint补丁,解决模块解析问题
module.exports = {
root: true,
// 指定为根配置文件,ESLint不会向上查找其他配置
extends: [
'plugin:vue/vue3-essential',
// Vue 3基础规则集
'eslint:recommended',
// ESLint推荐规则
'@vue/eslint-config-typescript',
// Vue的TypeScript配置
'@vue/eslint-config-prettier/skip-formatting'
// 跳过Prettier的格式化规则
],
parserOptions: {
ecmaVersion: 'latest'
// 使用最新的ECMAScript版本
},
rules: {
'vue/multi-word-component-names': 'off'
// 关闭Vue组件必须多单词命名的规则
// 因为有些基础组件如Login、Home使用单单词更合适
}
}
步骤3:创建.prettierignore文件
Prettier忽略文件指定了哪些文件不需要进行代码格式化。
bash
复制下载
# 创建Prettier忽略文件
touch .prettierignore
编辑.prettierignore文件:
plaintext
复制下载
node_modules
# 忽略node_modules目录,因为这是第三方依赖
dist
# 忽略构建输出目录
*.min.js
# 忽略压缩的JavaScript文件
*.min.css
# 忽略压缩的CSS文件
第七章:配置项目核心文件
步骤1:修改main.ts文件
main.ts是Vue应用的入口文件,负责初始化Vue应用并注册各种插件。
打开src/main.ts,修改为:
typescript
复制下载
import { createApp } from 'vue'
// 导入Vue的createApp函数,用于创建Vue应用实例
import './styles/reset.css'
// 导入重置样式,确保样式一致性
import App from './App.vue'
// 导入根组件
import router from './router'
// 导入路由配置
import { createPinia } from 'pinia'
// 导入Pinia的createPinia函数,用于创建状态存储
// 导入Element Plus
import ElementPlus from 'element-plus'
import 'element-plus/dist/index.css'
// 导入Element Plus及其样式
import * as ElementPlusIconsVue from '@element-plus/icons-vue'
// 导入Element Plus的所有图标组件
// 创建Vue应用实例
const app = createApp(App)
// 创建Pinia状态存储实例
const pinia = createPinia()
// 注册Element Plus插件
app.use(ElementPlus)
// 注册路由
app.use(router)
// 注册Pinia状态管理
app.use(pinia)
// 注册所有Element Plus图标组件
for (const [key, component] of Object.entries(ElementPlusIconsVue)) {
app.component(key, component)
// 将每个图标注册为全局组件
}
// 将Vue应用挂载到HTML中的#app元素
app.mount('#app')
步骤2:修改App.vue文件
App.vue是应用的根组件,所有其他组件都在这个组件内渲染。
打开src/App.vue,修改为:
vue
复制下载
<script setup lang="ts">
// 使用<script setup>语法糖,简化组合式API的使用
// lang="ts"指定使用TypeScript
import { RouterView } from 'vue-router'
// 导入RouterView组件,用于渲染当前路由对应的组件
</script>
<template>
<!-- 路由视图容器,根据当前路由显示不同的页面 -->
<RouterView />
</template>
<style scoped>
/* scoped样式,只作用于当前组件 */
/* 可以在这里添加全局的样式规则 */
</style>
步骤3:配置路由
路由配置文件定义了应用的路由结构和页面导航逻辑。
打开src/router/index.ts,确保基本配置:
typescript
复制下载
import { createRouter, createWebHistory } from 'vue-router'
// 导入Vue Router的创建函数
// createWebHistory使用HTML5 History API,URL更美观
import type { RouteRecordRaw } from 'vue-router'
// 导入路由记录类型定义
// 定义路由数组,每个路由对应一个页面
const routes: Array<RouteRecordRaw> = [
{
path: '/',
// 根路径
redirect: '/login'
// 重定向到登录页面,作为默认首页
},
{
path: '/login',
// 登录页面路径
name: 'Login',
// 路由名称,用于编程式导航
component: () => import('@/views/LoginView.vue')
// 使用动态导入实现路由懒加载,提高首屏加载速度
}
// 可以在这里添加更多路由配置
]
// 创建路由实例
const router = createRouter({
history: createWebHistory(import.meta.env.BASE_URL),
// 使用history模式,需要服务器配置支持
// import.meta.env.BASE_URL获取基础URL
routes
// 传入路由配置
})
// 导出路由实例,供main.ts使用
export default router
步骤4:配置Pinia Store
Pinia配置文件定义了应用的状态管理结构。
打开src/stores/index.ts,修改为:
typescript
复制下载
import { createPinia } from 'pinia'
// 导入createPinia函数,用于创建Pinia实例
// 创建Pinia实例
const pinia = createPinia()
// 导出Pinia实例,供main.ts使用
export default pinia
// 在这里可以导出具体的store模块
// 例如:export { useUserStore } from './user'
// 这样可以集中管理所有store的导出
第八章:创建Mock数据
步骤1:创建Mock目录和文件
Mock数据用于在开发阶段模拟后端API响应,实现前后端并行开发。
bash
复制下载
# 创建mock目录
mkdir mock
# 创建user mock文件
touch mock/user.ts
步骤2:配置Mock数据
编辑mock/user.ts文件:
typescript
复制下载
/*
* @Description: Stay hungry,Stay foolish
* @Author: Huccct
* @Date: 2024-03-21
*/
// 模拟用户列表数据
const userList = [
{
id: 1,
username: 'admin',
password: '123456',
name: '超级管理员',
phone: '13800138000',
roleName: '超级管理员',
createTime: '2024-03-21',
updateTime: '2024-03-21',
status: 1,
},
{
id: 2,
username: 'test',
password: '123456',
name: '测试用户',
phone: '13800138001',
roleName: '普通管理员',
createTime: '2024-03-21',
updateTime: '2024-03-21',
status: 1,
},
]
export default [
// 用户登录接口
{
url: '/api/user/login',
method: 'post',
response: ({ body }) => {
const { username, password } = body
const checkUser = userList.find(
(item) => item.username === username && item.password === password,
)
if (!checkUser) {
return { code: 201, data: { message: '账号或者密码不正确' } }
}
return { code: 200, data: {token:'Admin Token' }}
},
},
// 获取用户信息
{
url: '/api/user/info',
method: 'get',
response: (request) => {
const token = request.headers.token
if (token === 'Admin Token') {
return {
code: 200,
data: {
name: 'admin',
avatar:
'https://wpimg.wallstcn.com/f778738c-e4f8-4870-b634-56703b4acafe.gif',
roles: ['admin'],
buttons: ['cuser.detail'],
routes: [
'home',
'Acl',
'User',
'Role',
'Permission',
'Product',
'Trademark',
'Attr',
'Spu',
'Sku',
],
},
message: '获取用户信息成功',
}
}
return {
code: 201,
data: null,
message: '获取用户信息失败',
}
},
},
// 获取用户列表
{
url: '/api/acl/user/:page/:limit',
method: 'get',
response: ({ query }) => {
const { username } = query
let filteredList = userList
if (username) {
filteredList = userList.filter((user) =>
user.username.includes(username),
)
}
return {
code: 200,
data: {
records: filteredList,
total: filteredList.length,
},
}
},
},
// 添加/更新用户
{
url: '/api/acl/user/save',
method: 'post',
response: ({ body }) => {
const newUser = {
...body,
id: userList.length + 1,
createTime: new Date().toISOString().split('T')[0],
updateTime: new Date().toISOString().split('T')[0],
status: 1,
}
userList.push(newUser)
return { code: 200, data: null, message: '添加成功' }
},
},
{
url: '/api/acl/user/update',
method: 'put',
response: ({ body }) => {
const index = userList.findIndex((item) => item.id === body.id)
if (index !== -1) {
userList[index] = {
...userList[index],
...body,
updateTime: new Date().toISOString().split('T')[0],
}
}
return { code: 200, data: null, message: '更新成功' }
},
},
// 删除用户
{
url: '/api/acl/user/remove/:id',
method: 'delete',
response: (request) => {
const id = request.query.id
if (!id) {
return { code: 201, data: null, message: '参数错误' }
}
const index = userList.findIndex((item) => item.id === Number(id))
if (index !== -1) {
userList.splice(index, 1)
return { code: 200, data: null, message: '删除成功' }
}
return { code: 201, data: null, message: '用户不存在' }
},
},
// 批量删除用户
{
url: '/api/acl/user/batchRemove',
method: 'delete',
response: ({ body }) => {
const { idList } = body
idList.forEach((id) => {
const index = userList.findIndex((item) => item.id === id)
if (index !== -1) {
userList.splice(index, 1)
}
})
return { code: 200, data: null, message: '批量删除成功' }
},
},
// 获取用户角色
{
url: '/api/acl/user/toAssign/:userId',
method: 'get',
response: () => {
return {
code: 200,
data: {
assignRoles: [
{
id: 1,
roleName: '超级管理员',
createTime: '2024-03-21',
updateTime: '2024-03-21',
},
],
allRolesList: [
{
id: 1,
roleName: '超级管理员',
createTime: '2024-03-21',
updateTime: '2024-03-21',
},
{
id: 2,
roleName: '普通管理员',
createTime: '2024-03-21',
updateTime: '2024-03-21',
},
],
},
}
},
},
// 分配用户角色
{
url: '/api/acl/user/doAssignRole',
method: 'post',
response: () => {
return { code: 200, data: null, message: '分配角色成功' }
},
},
// 用户登出接口
{
url: '/api/user/logout',
method: 'post',
response: () => {
return { code: 200, data: null, message: '退出成功' }
},
},
]
第九章:总结
至此,你已经完成了Guigu致选平台项目的初始化配置。通过这个一步一步的教程,你应该能够:
- ✅ 使用create-vue脚手架创建项目
- ✅ 按照项目文档配置所有依赖
- ✅ 设置TypeScript和Vite配置
- ✅ 配置Element Plus和图标
- ✅ 设置Mock数据服务
- ✅ 创建基础的项目结构
- ✅ 启动并验证项目运行
从递归爆炸到闭包优化:彻底搞懂斐波那契数列的性能演进
在前端算法面试中,斐波那契数列(Fibonacci Sequence)不仅仅是一道考察递归逻辑的数学题,更是一块考察候选人对时间复杂度、记忆化(Memoization)以及JavaScript 闭包机制理解深度的试金石。
本文将基于一段代码的三个演进版本,带你深入理解如何将一个
O(2n) ->2的n次方
的“灾难级”代码优化为
O(n)
的生产级代码。
一、 数学定义与暴力递归的陷阱
斐波那契数列的定义非常简洁:从 0 和 1 开始,后续每一项都等于前两项之和。
即:
f(n)=f(n−1)+f(n−2)f(n)=f(n−1)+f(n−2)
。
将这个公式直接翻译成代码,就是我们最常见的递归写法:
JavaScript
// 版本 1:暴力递归
function fib(n) {
// 退出条件
if(n <= 1){
return n;
}
// 递归公式
return fib(n-1) + fib(n-2);
}
为什么这种写法在面试中只能得 50 分?
虽然代码逻辑正确,但它存在严重的性能问题。当你执行 fib(10) 时,计算很快;但一旦尝试 fib(50),浏览器可能会直接卡死。
原因是大量的重复计算。
为了计算 fib(5),程序需要计算 fib(4) 和 fib(3)。
而在计算 fib(4) 时,又需要计算 fib(3) 和 fib(2)。
注意到了吗?fib(3) 被重复计算了多次。随着 n 的增加,这种重复计算呈指数级爆炸,时间复杂度为
O(2n) ->2的n次方
。
二、 核心优化思想:用空间换时间
既然瓶颈在于“重复计算”,解决思路就是:凡是算过的,都记下来。下次再遇到相同的参数,直接读取结果,不再重新递归。这就是“记忆化(Memoization)”。
优化第一步:引入全局缓存
我们可以引入一个对象作为缓存容器(HashMap):
JavaScript
// 版本 2:外部缓存
const cache = {}; // 用空间换时间
function fib(n) {
// 1. 先查缓存
if(n in cache){
return cache[n];
}
// 2. 边界条件
if(n <= 1){
cache[n] = n;
return n;
}
// 3. 计算并写入缓存
const result = fib(n-1) + fib(n-2);
cache[n] = result;
return result;
}
通过引入 cache,每个数字只会被计算一次。时间复杂度从指数级
O(2n) ->2的n次方
降维到了线性
O(n)
。这是一个巨大的性能飞跃。
![]()
三、 进阶实现:闭包与 IIFE 的完美结合
版本 2 虽然解决了性能问题,但在工程上有一个致命缺陷:cache 变量定义在函数外部,是一个全局变量(或模块级变量)。这意味着任何外部代码都可以修改它,导致程序不安全,且污染了作用域。
在 JavaScript 中,完美的解决方案是结合 IIFE(立即执行函数表达式) 和 闭包(Closure) 。
JavaScript
// 版本 3:闭包封装
const fib = (function() {
// 闭包内的私有变量,外部无法访问
const cache = {};
// 返回实际执行的函数
return function(n) {
if(n in cache){
return cache[n];
}
if(n <= 1){
cache[n] = n;
return n;
}
// 注意:这里的 fib 指向的是外部接收 IIFE 返回值的那个变量
cache[n] = fib(n-1) + fib(n-2);
return cache[n];
}
})()
代码解析
- IIFE (function(){...})() :函数定义后立即执行,创建了一个独立的作用域。
- 闭包:IIFE 返回的内部函数引用了外层作用域的 cache 变量。即便 IIFE 执行完毕,cache 依然驻留在内存中,不会被销毁,也不会被外部访问。
- 数据持久化:当你多次调用 fib(10)、fib(20) 时,它们共享同一个 cache,计算过的结果可以跨函数调用被复用。
这种写法不仅实现了性能优化,还体现了优秀的代码封装思想,是面试中的高分回答。
![]()
四、 面试总结
当面试官让你手写斐波那契数列时,建议按照以下逻辑展开:
-
先写基本解法:快速写出递归版本,并主动指出其
O(2n) ->2的n次方的复杂度问题和爆栈风险。
-
提出优化方案:阐述“用空间换时间”的记忆化思想。
-
展示语言特性:使用 IIFE + 闭包 的方式实现记忆化函数。这能展示你对 JavaScript 作用域链和闭包机制的深刻理解。
-
扩展思维:如果面试官进一步追问,可以提到通用记忆化函数(Memoize Helper)的编写,或者提到使用迭代(循环)方式来进一步避免递归深度的限制。
掌握这段代码的演进过程,不仅是为了解决一道算法题,更是为了掌握 JavaScript 函数式编程中“状态保持”的核心模式。
每日一题-转换数组🟢
给你一个整数数组 nums,它表示一个循环数组。请你遵循以下规则创建一个大小 相同 的新数组 result :
i(其中 0 <= i < nums.length),独立执行以下操作:
- 如果
nums[i] > 0:从下标i开始,向 右 移动nums[i]步,在循环数组中落脚的下标对应的值赋给result[i]。 - 如果
nums[i] < 0:从下标i开始,向 左 移动abs(nums[i])步,在循环数组中落脚的下标对应的值赋给result[i]。 - 如果
nums[i] == 0:将nums[i]的值赋给result[i]。
返回新数组 result。
注意:由于 nums 是循环数组,向右移动超过最后一个元素时将回到开头,向左移动超过第一个元素时将回到末尾。
示例 1:
输入: nums = [3,-2,1,1]
输出: [1,1,1,3]
解释:
- 对于
nums[0]等于 3,向右移动 3 步到nums[3],因此result[0]为 1。 - 对于
nums[1]等于 -2,向左移动 2 步到nums[3],因此result[1]为 1。 - 对于
nums[2]等于 1,向右移动 1 步到nums[3],因此result[2]为 1。 - 对于
nums[3]等于 1,向右移动 1 步到nums[0],因此result[3]为 3。
示例 2:
输入: nums = [-1,4,-1]
输出: [-1,-1,4]
解释:
- 对于
nums[0]等于 -1,向左移动 1 步到nums[2],因此result[0]为 -1。 - 对于
nums[1]等于 4,向右移动 4 步到nums[2],因此result[1]为 -1。 - 对于
nums[2]等于 -1,向左移动 1 步到nums[1],因此result[2]为 4。
提示:
1 <= nums.length <= 100-100 <= nums[i] <= 100
3379. 转换数组
解法
思路和算法
根据题意模拟,计算结果数组 $\textit{result}$ 即可。
用 $n$ 表示数组 $\textit{nums}$ 的长度。对于 $0 \le i < n$ 的每个下标 $i$,计算 $\textit{result}[i]$ 的方法如下。
-
当 $\textit{nums}[i] > 0$ 时,$\textit{result}[i]$ 的值等于数组 $\textit{nums}$ 的下标 $i$ 向右移动 $\textit{nums}[i]$ 的下标处的值,即数组 $\textit{nums}[i]$ 的下标 $i + \textit{nums}[i]$ 对应的范围 $[0, n - 1]$ 中的下标。
-
当 $\textit{nums}[i] < 0$ 时,$\textit{result}[i]$ 的值等于数组 $\textit{nums}$ 的下标 $i$ 向左移动 $-\textit{nums}[i]$ 的下标处的值,即数组 $\textit{nums}[i]$ 的下标 $i + \textit{nums}[i]$ 对应的范围 $[0, n - 1]$ 中的下标。
-
当 $\textit{nums}[i] = 0$ 时,$\textit{result}[i]$ 的值等于数组 $\textit{nums}$ 的下标 $i$ 处的值。
上述情况可以统一表示成数组 $\textit{nums}[i]$ 的下标 $i + \textit{nums}[i]$ 对应的范围 $[0, n - 1]$ 中的下标。对于 $0 \le i < n$ 的每个下标 $i$,计算 $\textit{result}[i]$ 时为了确保得到范围 $[0, n - 1]$ 中的下标,应计算 $\textit{index} = ((i + \textit{nums}[i]) \bmod n + n) \bmod n$,则 $\textit{result}[i] = \textit{nums}[\textit{index}]$。
计算数组 $\textit{result}$ 中的所有元素之后,即可得到结果数组。
代码
###Java
class Solution {
public int[] constructTransformedArray(int[] nums) {
int n = nums.length;
int[] result = new int[n];
for (int i = 0; i < n; i++) {
int index = ((i + nums[i]) % n + n) % n;
result[i] = nums[index];
}
return result;
}
}
###C#
public class Solution {
public int[] ConstructTransformedArray(int[] nums) {
int n = nums.Length;
int[] result = new int[n];
for (int i = 0; i < n; i++) {
int index = ((i + nums[i]) % n + n) % n;
result[i] = nums[index];
}
return result;
}
}
###C++
class Solution {
public:
vector<int> constructTransformedArray(vector<int>& nums) {
int n = nums.size();
vector<int> result(n);
for (int i = 0; i < n; i++) {
int index = ((i + nums[i]) % n + n) % n;
result[i] = nums[index];
}
return result;
}
};
###Python
class Solution:
def constructTransformedArray(self, nums: List[int]) -> List[int]:
n = len(nums)
return [nums[(i + nums[i]) % n] for i in range(n)]
###C
int* constructTransformedArray(int* nums, int numsSize, int* returnSize) {
int* result = (int*) malloc(sizeof(int) * numsSize);
for (int i = 0; i < numsSize; i++) {
int index = ((i + nums[i]) % numsSize + numsSize) % numsSize;
result[i] = nums[index];
}
*returnSize = numsSize;
return result;
}
###Go
func constructTransformedArray(nums []int) []int {
n := len(nums)
result := make([]int, n)
for i := 0; i < n; i++ {
index := ((i + nums[i]) % n + n) % n
result[i] = nums[index]
}
return result
}
###JavaScript
var constructTransformedArray = function(nums) {
let n = nums.length;
let result = new Array(n);
for (let i = 0; i < n; i++) {
let index = ((i + nums[i]) % n + n) % n;
result[i] = nums[index];
}
return result;
};
###TypeScript
function constructTransformedArray(nums: number[]): number[] {
let n = nums.length;
let result = new Array(n);
for (let i = 0; i < n; i++) {
let index = ((i + nums[i]) % n + n) % n;
result[i] = nums[index];
}
return result;
};
复杂度分析
-
时间复杂度:$O(n)$,其中 $n$ 是数组 $\textit{nums}$ 的长度。结果数组的每个元素的计算时间都是 $O(1)$。
-
空间复杂度:$O(1)$。注意返回值不计入空间复杂度。
模拟
解法:模拟
按题意模拟即可。复杂度 $\mathcal{O}(n)$。
参考代码(c++)
###cpp
class Solution {
public:
vector<int> constructTransformedArray(vector<int>& nums) {
int n = nums.size();
vector<int> ans;
for (int i = 0; i < n; i++) {
int j = (i + nums[i] % n + n) % n;
ans.push_back(nums[j]);
}
return ans;
}
};