Vue3 防重复点击指令 - clickOnce

一、问题背景

在实际的 Web 应用开发中，我们经常会遇到以下问题：

这些问题在以下场景中尤为常见：

• 表单提交（注册、登录、创建订单等）


• 数据保存操作


• 文件上传


• 支付操作


• API 调用

二、解决方案

clickOnce 指令通过以下机制解决上述问题：

1. 节流机制

使用 @vueuse/core 的 useThrottleFn，在 1.5 秒内只允许执行一次点击操作。

2. 按钮禁用

点击后立即禁用按钮，防止用户再次点击。

3. 视觉反馈

自动添加 Element Plus 的 Loading 图标，让用户明确知道操作正在进行中。

4. 智能恢复

• 如果绑定的函数返回 Promise（异步操作），则在 Promise 完成后自动恢复按钮状态


• 如果是同步操作，则立即恢复

三、核心特性

✅ 自动防重复点击：1.5秒节流时间

✅ 自动 Loading 状态：无需手动管理 loading 变量

✅ 支持异步操作：自动检测 Promise 并在完成后恢复

✅ 优雅的清理机制：组件卸载时自动清理事件监听

✅ 类型安全：完整的 TypeScript 支持

四、技术实现

关键技术点

工作流程

用户点击按钮

    ↓

节流检查（1.5秒内只执行一次）

    ↓

禁用按钮 + 添加 Loading 图标

    ↓

执行绑定的函数

    ↓

检测返回值是否为 Promise

    ↓

Promise 完成后（或同步函数执行完）

    ↓

移除 Loading + 恢复按钮状态

五、使用方法

1. 注册指令

// main.ts

import clickOnce from '@/directives/clickOnce'



app.directive('click-once', clickOnce)

2. 在组件中使用

<template>

  <!-- 异步操作示例 -->

  <el-button 

    type="primary" 

    v-click-once="handleSubmit">

    提交表单

  </el-button>



  <!-- 带参数的异步操作 -->

  <el-button 

    type="success" 

    v-click-once="() => handleSave(formData)">

    保存数据

  </el-button>

</template>



<script setup lang="ts">

const handleSubmit = async () => {

  // 模拟 API 调用

  await api.submitForm(formData)

  ElMessage.success('提交成功')

}



const handleSave = async (data: any) => {

  await api.saveData(data)

  ElMessage.success('保存成功')

}

</script>

六、优势对比

传统方式

<template>

  <el-button 

    type="primary" 

    :loading="loading"

    :disabled="loading"

    @click="handleSubmit">

    提交

  </el-button>

</template>



<script setup lang="ts">

const loading = ref(false)



const handleSubmit = async () => {

  if (loading.value) return

  

  loading.value = true

  try {

    await api.submit()

  } finally {

    loading.value = false

  }

}

</script>

问题：

• 需要手动管理 loading 状态


• 每个按钮都要写重复代码


• 容易遗漏 finally 清理逻辑

使用 clickOnce 指令

<template>

  <el-button 

    type="primary" 

    v-click-once="handleSubmit">

    提交

  </el-button>

</template>



<script setup lang="ts">

const handleSubmit = async () => {

  await api.submit()

}

</script>

优势：

• 代码简洁，无需管理状态


• 自动处理 loading 和禁用


• 统一的用户体验

七、注意事项

八、适用场景

✅ 适合使用：

• 表单提交按钮


• 数据保存按钮


• 文件上传按钮


• API 调用按钮


• 支付确认按钮

❌ 不适合使用：

• 普通导航按钮


• 切换/开关按钮


• 需要快速连续点击的场景（如计数器）

九、指令源码

import type { Directive } from 'vue'

import { createVNode, render } from 'vue'

import { useThrottleFn } from '@vueuse/core'

import { Loading } from '@element-plus/icons-vue'



const THROTTLE_TIME = 1500



const clickOnce: Directive<HTMLButtonElement, () => Promise<unknown> | void> = {

  mounted(el, binding) {

    const handleClick = useThrottleFn(

      () => {

        // 如果元素已禁用，直接返回（双重保险）

        if (el.disabled) return



        // 禁用按钮

        el.disabled = true

        // 添加 loading 状态

        el.classList.add('is-loading')



        // 创建 loading 图标容器

        const loadingIconContainer = document.createElement('i')

        loadingIconContainer.className = 'el-icon is-loading'



        // 使用 Vue 的 createVNode 和 render 来渲染 Loading 组件

        const vnode = createVNode(Loading)

        render(vnode, loadingIconContainer)



        // 将 loading 图标插入到按钮开头

        el.insertBefore(loadingIconContainer, el.firstChild)



        // 将 loading 图标存储到元素上，以便后续移除

        ;(el as any)._loadingIcon = loadingIconContainer

        ;(el as any)._loadingVNode = vnode



        // 执行绑定的函数（应返回 Promise 或普通函数）

        const result = binding.value?.()



        const removeLoading = () => {

          el.disabled = false

          // 移除 loading 状态

          el.classList.remove('is-loading')

          const icon = (el as any)._loadingIcon

          if (icon && icon.parentNode === el) {

            // 卸载 Vue 组件

            render(null, icon)

            el.removeChild(icon)

            delete (el as any)._loadingIcon

            delete (el as any)._loadingVNode

          }

        }



        // 如果返回的是 Promise，则在完成时恢复；否则立即恢复

        if (result instanceof Promise) {

          result.finally(removeLoading)

        } else {

          // 非异步操作，立即恢复（或根据需求决定是否恢复）

          // 通常建议只用于异步操作，所以这里也可以不处理，或给出警告

          removeLoading()

        }

      },

      THROTTLE_TIME,

    )



    // 将 throttled 函数存储到元素上，以便在 unmount 时移除

    ;(el as any)._throttledClick = handleClick

    el.addEventListener('click', handleClick)

  },



  beforeUnmount(el) {

    const handleClick = (el as any)._throttledClick

    if (handleClick) {

      el.removeEventListener('click', handleClick)

      // 取消可能还在等待的 throttle

      handleClick.cancel?.()

      delete (el as any)._throttledClick

    }

  },

}



export default clickOnce

十、总结

clickOnce 指令通过封装防重复点击逻辑，提供了一个开箱即用的解决方案，让开发者可以专注于业务逻辑，而不用担心重复点击的问题。它结合了节流、状态管理和视觉反馈，为用户提供了更好的交互体验。

目前Chrome浏览器依然没有放开12px的限制，但Chrome仍然是使用人数最多的浏览器。

在笔者开发某个项目时突发奇想：如果实际需要11px的字体大小怎么办？这在Chrome中是实现不了的。关于字体，一开始想到的就是rem等非px单位。但是rem只是为了响应式适配，并不能突破这一限制。

em、rem等单位只是为了不同分辨率下展示效果提出的换算单位，常见的库px2rem也只是利用了js将px转为rem。包括微信小程序提出的rpx单位也是一样！

这条路走不通，就只剩下一个方法：改变视觉大小而非实际大小。

理论基础

css中有一个属性：transform: scale();

• 值的绝对值>1，就是放大，比如2，就是放大2倍


• 值的绝对值 0<值<1，就是缩小，比如0.5，就是原来的0.5倍；


• 值的正负，负值表示图形翻转。

默认情况下，scale(x, y)：以x/y轴进行缩放；如果y没有值，默认y==x；
也可以分开写：scaleX() scaleY() scaleZ()，分开写的时候，可以对Z轴进行缩放

第二种写法：transform: scale3d(x, y, z)该写法是上面的方法的复合写法，结果和上面的一样。

但使用这个属性要注意一点：scale 缩放的时候是以“缩放元素所在空间的中心点”为基准的。
所以如果用在改变元素视觉大小的场景下，一般还需要利用另一个元素来“恢复位置”：

transform-origin: top left;

语法上说，transform-origin 拥有三个属性值：

transform-origin: x-axis y-axis z-axis;

默认为：

transform-origin:50% 50% 0;

属性值可以是百分比、em、px等具体的值，也可以是top、right、bottom、left和center这样的关键词。作用就是更改一个元素变形的原点。

实际应用

<div class="mmcce__info-r">

  <!-- 一些html结构 -->

  <div v-show="xxx" class="mmcce-valid-mj-period" :class="{'mmcce-mh': showStr}">

    <div class="mmcce-valid-period-child">xxx</div><!-- 父级结构，点击显示下面内容 -->

    <div class="mmcce-valid-pro" ref="mmcceW">

      <!-- 下面内容在后面有讲解 -->

      <div class="mmcce-text" 

        v-for="(item, index) in couponInfo.thresholdStr" 

        :key="index" 

        :index="index"

        :style="{height: mTextH[index] + 'px'}"

      >{{item}}</div>

    </div>

  </div>

</div>

.mmcce-valid-mj-period {

  max-height: 15px;

  transition: all .2s ease;



  &.mmcce-mh {

    max-height: 200px;

  }



  .mmcce-valid-pro {

    display: flex;

    flex-direction: column;

    padding-bottom: 12px;



    .mmcce-text {

      width: 200%; // !

      font-size: 22px;

      height: 15px;

      line-height: 30px;

      color: #737373;

      letter-spacing: 0;

      transform       : scale(.5);

      transform-origin: top left;

    }

  }

}



.mmcce-valid-period-child {

  position: relative;

  width      : 200%;

  white-space: nowrap;

  font-size  : 22px;

  color      : #979797;

  line-height: 30px;



  transform       : scale(.5);

  transform-origin: top left;



  //xxx

}

可以明确说明的是，这样的 hack 需要明确规定缩放元素的height值 ！！！

上面代码中为什么.mmcce-valid-mj-period类中要用max-height ？为什么对展开元素中的文字类.mmcce-text中使用height？
我将类.mmcce-text中的height去掉后，看下效果：

（使用min-height是一样的效果）

OK，可以看到，占高没有按我们想的“被缩放”。影响到了下面的元素位置。

本质上是“视觉大小改变了但实际(占位)大小无变化”。
这时候，宽高实际也被缩放了的。这一点通过代码中width:200%也可以看出来。或者你设置了overflow:hidden;也可以有相应的效果！

这一点需要注意，一般来说，给被缩放元素显式设置一个大于等于其font-size的height值即可。

缩放带来的其它问题

可能在很多人使用的场景中是不会考虑到这个问题的：被缩放元素限制高度以后如果元素换行那么会出现文字重叠的现象。

为此，我采用了在mounted生命周期中获取父元素宽度，然后动态计算是否需要换行以及换行的行数，最后用动态style重新渲染每一条数据的height值。
这里有三点需要注意：

关于第三点，还涉及到加载顺序的问题。比如刚进入页面时要展示弹窗，弹窗是一个组件。那你在index.vue中是获取不到这个组件的。但是你可以将比如header也拆分出来，然后在header组件的mounted中去调用弹窗组件暴露出的方法。

mounted(){

  let thresholdStr = this.info.dropDownTextList;

  let minW = false;

  if(this.$el.querySelector('.mmcce-valid-pro').clientWidth < 140) { // 以iPhone5位准，再小于其中元素宽度的的机型就要做特殊处理了

    minW = true

  }

  let mmcw = this.$el.querySelector('.mmcce-valid-pro').getBoundingClientRect().width;



  let mmch = [];



  for(let i=0;i<thresholdStr.length;i++) {

    // 11是指缩放后文字的font-size值，这是一种取巧的方式

    if(11*(thresholdStr[i].length) > mmcw) {

      if(minW) {

        mmch[i] = Math.floor((11*thresholdStr[i].length) / mmcw) * 15;

      }else {

        mmch[i] = Math.floor((11*(thresholdStr[i].length) + 40) / mmcw) * 15;

      }

    }else {

      mmch[i] = 15;

    }

  }



  this.mTextH = mmch;

},

笔者前段时间弄了一个微信公众号：前端Code新谈。里面暂时有webrtc、前端面试和用户体验系列文章，最近暂时搁置了webrtc，新开了一个系列“three.js”，欢迎关注！希望能够帮到大家，也希望能互相交流！一起学习共同进步

在数据可视化和大屏开发中，"适配"永远是绕不开的话题。不同分辨率下如何保持元素比例、位置精准，往往让开发者头疼不已。
autofit.js 作为老牌适配工具，早已在许多项目中证明了价值；而新晋的 vfit 则专为 Vue 3 量身打造。今天我们就来深入对比这两款工具，看看谁更适合你的场景。

一、核心定位：通用方案 vs Vue 专属

首先得明确两者的定位差异：

• autofit.js：无框架依赖的通用缩放工具，通过计算容器与设计稿的比例，对整个页面进行缩放处理，核心逻辑是 transform: scale(ratio) 的全局应用。


• vfit.js：专为 Vue 3 设计的轻量方案，不仅提供全局缩放，更通过组件化思想解决精细定位问题，是"缩放+定位"的一体化方案。

二、核心能力对比

1. 缩放逻辑：全局统一 vs 灵活可控

autofit.js 的缩放逻辑相对直接：

• 计算容器宽高与设计稿的比例（取宽/高比例的最小值或按配置选择）


• 对目标容器应用整体缩放，实现"一缩全缩"

vfit.js 则提供了更灵活的缩放策略：

// vfit 初始化配置

createFitScale({

  target: '#app',        // 监听缩放的容器

  designHeight: 1080,    // 设计稿高度

  designWidth: 1920,     // 设计稿宽度

  scaleMode: 'auto'      // 缩放模式：auto/height/width

})

•  auto 模式会自动对比容器宽高比与设计稿比例，智能选择按宽或按高缩放


• 支持在组件内通过 useFitScale() 获取当前缩放值，实现局部自定义缩放

2. 定位能力：粗犷适配 vs 精细控制

这是两者最核心的差异。

autofit.js 由于是全局缩放，元素定位依赖原始 CSS 布局，在复杂场景下容易出现：

• 固定像素定位的元素在缩放后偏离预期位置


• 相对定位元素在不同分辨率下比例失调

vfit.js 则通过 FitContainer 组件解决了这个痛点，支持两种定位单位：

<!-- 百分比定位：位置不受缩放影响，适合居中场景 -->

<FitContainer :top="50" :left="50" unit="%">

  <div class="card" style="transform: translate(-50%, -50%)">居中内容</div>

</FitContainer>



<!-- 像素定位：位置随缩放自动计算，适合固定布局 -->

<FitContainer :top="90" :left="90" unit="px">

  <div class="box">固定位置元素</div>

</FitContainer>

•  unit="%"：位置基于容器百分比，适合居中、靠边等相对位置


•  unit="px"：位置会自动乘以当前缩放值，保证设计稿像素与实际显示一致

更贴心的是，vfit.js 还支持通过 right/bottom 定位，并自动处理不同原点的缩放计算（比如右上角、右下角）。

3. 框架融合：独立工具 vs Vue 生态

autofit.js 作为独立库，需要手动在 Vue 项目中处理初始化时机（通常在 onMounted 中），且无法直接与 Vue 的响应式系统结合。

vfit.js 则完全融入 Vue 3 生态：

• 通过 app.use() 安装，自动处理初始化时机


• 缩放值通过 Ref 实现响应式，组件内可实时获取


• FitContainer 组件支持 props 动态更新，适配动态布局场景

三、适用场景分析

四、迁移成本与上手难度

• autofit.js：API 简单，几行代码即可初始化，学习成本低，适合快速接入简单场景。


• vfit.js：需要理解组件化定位思想，初期有一定学习成本，但对于复杂场景，后期维护成本更低。

如果你从 autofit.js 迁移到 vfit.js，只需：

总结：没有最好，只有最合适

autofit.js 胜在通用性和简单直接，适合非 Vue 项目或简单的全局缩放场景；而 vfit.js 则在 Vue 3 生态中展现了更强的针对性，通过组件化和精细定位，解决了复杂大屏的适配痛点。

如果你是 Vue 开发者，且正在为元素定位偏移烦恼，不妨试试 vfit——它可能正是你寻找的"Vue 大屏适配最优解"。

官网地址：web-vfit.netlify.app，可以直接在线体验效果～

github：github.com/v-plugin/vf…

😅 又是熟悉的对话

产品："小王，这个表格用户体验不好啊，用户要滚动到底部才能看到横向滚动条，能不能把滚动条固定在页面底部？"

我："emmm... 这个... 技术上可以实现，但是..."

产品："那就这么定了！明天上线！"

我："😭"

相信很多前端同学都遇到过类似的场景。面对超宽的 el-table，用户确实需要先滚动到表格底部才能进行左右滚动，体验确实不够友好。

💡干！

于是一个通用的水平滚动条组件 vue-horizontal-scrollbar 诞生了！

🌟 快速体验

想看看实际效果？访问 在线演示

🚀 最终的解决方案

<template>

    <el-table style="width: 100%">

    </el-table>

  

    <HorizontalScrollbar

      :target-selector="getSelector('.el-table__body-wrapper .el-scrollbar .el-scrollbar__wrap')"

      :content-selector="getSelector('.el-table__body-wrapper .el-scrollbar .el-scrollbar__view')"

    />

</template>



<script setup>

import { ref } from 'vue'

import { VueHorizontalScrollbar } from 'vue-horizontal-scrollbar'

import "vue-horizontal-scrollbar/dist/style.css"



function getSelector(selector: string) {

  const elements = document.querySelectorAll<HTMLElement>(selector) // 兼容展开行

  if (elements.length) {

    return elements[elements.length - 1] 

  }

  else {

    console.warn(`Selector "${selector}" did not match any elements.`)

    return null

  }

}

// 💡 tips: 如果是有侧边菜单的管理系统需要动态修改vue-horizontal-scrollbar-container的left

</script>

✨ 这样做的好处

🎯 用户体验升级

• 滚动条始终可见，无需滚动页面


• 位置固定，操作便捷


• 支持键盘和鼠标滚轮操作

🛠️ 开发体验友好

• 一行代码解决问题


• 不破坏原有组件结构


• 支持任意 DOM 元素

🎨 高度可定制

<template>

  <div>

    <!-- Your scrollable content -->

    <div id="scroll-container" style="overflow-x: auto; width: 100%;">

      <div id="scroll-content" style="width: 2000px; height: 200px;">

        <!-- Wide content here -->

        <p>This content is wider than the container...</p>

      </div>

    </div>

    

    <!-- Horizontal Scrollbar -->

    <VueHorizontalScrollbar

      target-selector="#scroll-container"

      content-selector="#scroll-content"

      :auto-show="true"

      @scroll="onScroll"

    />

  </div>

</template>



<script setup>

import { VueHorizontalScrollbar } from 'vue-horizontal-scrollbar'

import "vue-horizontal-scrollbar/dist/style.css"

function onScroll(info) {

  console.log('Scroll info:', info)

  // { scrollLeft: 100, maxScroll: 1000, scrollPercent: 10 }

}

</script>

✨ Features

• 🎯 Vue 3 & TypeScript - Full TypeScript support with Vue 3 Composition API


• 🎨 Customizable - Flexible styling and configuration options


• ♿ Accessible - ARIA labels and keyboard navigation support


• 📱 Touch Friendly - Mobile-friendly touch gestures


• 🚀 Performance - Optimized with throttling and efficient updates


• 🎪 Flexible - Works with any scrollable content


• 🎛️ Event Rich - Comprehensive event system for interactions


• 📦 Lightweight - Minimal dependencies

📖 API Reference

Props

🎪 更多有趣的玩法

除了解决表格滚动问题，这个组件还能用在：

• 商品展示：电商网站的商品横向滚动


• 图片画廊：摄影作品展示


• 时间轴：项目进度展示


• 标签导航：当标签太多时的横向滚动

📦 立即使用

bash

npm install vue-horizontal-scrollbar

🎉 结语

从此以后，再也不怕产品提这种"奇葩"需求了！

产品："这个滚动条能不能再加个渐变效果？"

我："没问题！改个 CSS 就行！"

产品："能不能支持触摸滑动？"

我："早就支持了！"

项目地址：GitHub

NPM 包：vue-horizontal-scrollbar

如果这个组件帮到了你，记得给项目点个 ⭐ 哦！让我们一起让前端开发变得更轻松！🎉

最近接到一个安卓App的活儿，虽然功能上不算复杂，但因为原本没怎么做过安卓端，所以也是"摸着石头过河"。简单写一下踩过的坑和淌的水吧~

uni-app实现离线地图主要用 leafletjs 实现，但是因为在安卓端运行，存在渲染问题，所以还要用上 renderjs。

实现方案一：web-view

因为uni-app引入第三方可以采用传统的 NPM 安装的方式，也可以采用引入打包完的js文件的方式。

这里采用 leafletjs 打包完的文件，将 leafletjs 放入 static 文件夹内。

在网上下载了公开的瓦片地图图片，以 {z}/{x}/{y} 的目录结构放入 tiles 文件夹中，将 tiles 放入 static 文件夹内。

在static文件夹下新建一个 offline-map.html 文件

<!DOCTYPE html>

<html>

	<head>

		<meta charset="utf-8" />

		<meta name="viewport" content="width=device-width, initial-scale=1.0">

		<title>离线地图</title>

		<link rel="stylesheet" href="./leaflet/leaflet.css" />

		<style>

			html,

			body {

				margin: 0;

				padding: 0;

			}



			#map {

				height: 100vh;

				width: 100vw;

				margin: 0;

				padding: 0;

			}

		</style>

	</head>

	<body>

		<div id="map"></div>

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

		<script>

			const baseUrl = './tiles/{z}/{x}/{y}.jpg';

			const map = L.map('map').setView([23.56, 113.23], 15);



			L.tileLayer(baseUrl, {

				minZoom: 15,

				maxZoom: 18,

				tms: true,

				attribution: 'Offline Tiles',

				errorTileUrl: ''

			}).addTo(map);

		</script>

	</body>

</html>

找到 pages/index/index.vue 文件，采用 web-view 引用的方式引入上述 html 文件。

// pages/index/index.vue

<template>

	<view class="content">

		<web-view src="/static/offline-map.html"></web-view>

	</view>

</template>



<style>

	.content {

		width: 100%;

		height: 100%;

		display: flex;

		flex-direction: column;

		align-items: center;

		justify-content: center;

	}

</style>

实现方案二：renderjs

仍然将 leafletjs 和 瓦片图片文件夹tiles 放入 static 文件夹中。

// pages/index/index.vue

<view class="content">

    <view id="map" class="map-container"></view>

</view>



<script module="leaflet" lang="renderjs">

    import '@/static/leaflet/leaflet.css';

	import * as L from "@/static/leaflet/leaflet.js";



    export default {

		mounted() {

			this.initMap();

		},

		methods: {

			initMap() {

				const baseUrl = 'static/tiles/{z}/{x}/{y}.jpg'

				map = L.map('map').setView([23.56, 113.23], 15);



				L.tileLayer(baseUrl, {

					minZoom: 15,

					maxZoom: 18,

					tms: true,

					attribution: 'Offline Tiles',

					errorTileUrl: ''

				}).addTo(map);

			},

        }

    }

</script>

这里需要注意的是一定要在 renderjs 中实现上述代码，如果在常规 script 中实现，在 H5端 没有任何问题，但是运行到真机上会白屏。（这个问题我反复试了好几次都不行，结果还是上传到 Trae 上解决了这个问题）。

导致这种情况的原因是在常规 sctipt 中的代码，在真机上是运行在 逻辑层 的代码，无法干扰到 视图层 的结构，这一点和Web是不同的。

而 renderjs 是运行在 视图层 的js，具备操作 DOM 的能力。

其次是引用 static 文件的路径，import static 中的文件可以使用 @/static 的方式，但是在代码中引用 static 文件需要采用 static/ 的形式。

总结

最后我做完以后让 Trae 给了一下评价，Trae 表示不建议采用这种方式实现离线地图，首先瓦片地图文件一般非常大，我用的仅仅是其中的一小部分，也超过了 60MB，打包出来的 App 包太大了。

其次无论是 web-view 还是 renderjs 本质上是一样的。在app-vue环境下，视图层由webview渲染，而renderjs就是运行在视图层的。

所以无论是渲染效率还是开发上基本没差。

从前端到爆点！抖音级 H5 如何炼成？

在万物互联的时代，H5 页面已成为产品推广的利器。当产品经理丢给你一个“像抖音一样流畅的 H5”任务时，是挑战还是机遇？别慌，今天就带你走进抖音 H5 的前端魔法世界。

一、先看清本质：抖音 H5 为何丝滑？

抖音 H5 之所以让人欲罢不能，核心在于两点：极低的卡顿率和极致的交互反馈。前者靠性能优化，后者靠精心设计的交互逻辑。比如，你刷视频时的流畅下拉、点赞时的爱心飞舞，背后都藏着前端开发的“小心机”。

二、性能优化：让页面飞起来

（一）懒加载与预加载协同作战

懒加载是 H5 性能优化的经典招式，只在用户即将看到某个元素时才加载它。但光靠懒加载还不够，聪明的抖音 H5 还会预加载下一个可能进入视野的元素。以下是一个基于 IntersectionObserver 的懒加载示例：

document.addEventListener('DOMContentLoaded', () => {

  const lazyImages = [].slice.call(document.querySelectorAll('img.lazy'));

  if ('IntersectionObserver' in window) {

    let lazyImageObserver = new IntersectionObserver((entries) => {

      entries.forEach((entry) => {

        if (entry.isIntersecting) {

          let lazyImage = entry.target;

          lazyImage.src = lazyImage.dataset.src;

          lazyImageObserver.unobserve(lazyImage);

        }

      });

    });

 lazy   Images.forEach((lazyImage) => {

      lazyImageObserver.observe(lazyImage);

    });

  }

});

（二）图片压缩技术大显神威

图片是 H5 的“体重”大户。抖音 H5 常用 WebP 格式，它在保证画质的同时，能将图片体积压缩到 JPEG 的一半。你可以用以下代码轻松实现图片格式转换：

function compressImage(inputImage, quality) {

  return new Promise((resolve) => {

    const canvas = document.createElement('canvas');

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

    canvas.width = inputImage.naturalWidth;

    canvas.height = inputImage.naturalHeight;

    ctx.drawImage(inputImage, 0, 0, canvas.width, canvas.height);

    const compressedImage = new Image();

    compressedImage.src = canvas.toDataURL('image/webp', quality);

    compressedImage.onload = () => {

      resolve(compressedImage);

    };

  });

}

三、交互设计：让用户欲罢不能

（一）微动画营造沉浸感

在点赞、评论等关键操作上，抖音 H5 会加入精巧的微动画。比如点赞时的爱心从手指位置飞出，这其实是一个 CSS 动画加 JavaScript 事件监听的组合拳。以下是一个简易版的点赞动画代码：

@keyframes flyHeart {

  0% {

    transform: scale(0) translateY(0);

    opacity: 0;

  }

  50% {

    transform: scale(1.5) translateY(-10px);

    opacity: 1;

  }

  100% {

    transform: scale(1) translateY(-20px);

    opacity: 0;

  }

}

.heart {

  position: fixed;

  width: 30px;

  height: 30px;

  background-image: url('../assets/heart.png');

  background-size: contain;

  background-repeat: no-repeat;

  animation: flyHeart 1s ease-out;

}

document.querySelector('.like-btn').addEventListener('click', function(e) {

  const heart = document.createElement('div');

  heart.className = 'heart';

  heart.style.left = e.clientX + 'px';

  heart.style.top = e.clientY + 'px';

  document.body.appendChild(heart);

  setTimeout(() => {

    heart.remove();

  }, 1000);

});

（二）触摸事件优化

在移动设备上，触摸事件的响应速度直接影响用户体验。抖音 H5 通过精准控制触摸事件的捕获和冒泡阶段，减少了延迟。以下是一个优化触摸事件的示例：

const touchStartHandler = (e) => {

  e.preventDefault(); // 防止页面滚动干扰

  // 处理触摸开始逻辑

};



const touchMoveHandler = (e) => {

  // 处理触摸移动逻辑

};



const touchEndHandler = (e) => {

  // 处理触摸结束逻辑

};



const element = document.querySelector('.scrollable-container');

element.addEventListener('touchstart', touchStartHandler, { passive: false });

element.addEventListener('touchmove', touchMoveHandler, { passive: false });

element.addEventListener('touchend', touchEndHandler);

四、音频处理：让声音为 H5 增色

抖音 H5 的音频体验也很讲究。它会根据用户的操作实时调整音量，甚至在不同视频切换时平滑过渡音频。以下是一个简单的声音控制示例：

const audioContext = new (window.AudioContext || window.webkitAudioContext)();

const audioElement = document.querySelector('audio');

const audioSource = audioContext.createMediaElementSource(audioElement);

const gainNode = audioContext.createGain();

audioSource.connect(gainNode);

gainNode.connect(audioContext.destination);



// 调节音量

function setVolume(level) {

  gainNode.gain.value = level;

}



// 音频淡入效果

function fadeInAudio() {

  gainNode.gain.setValueAtTime(0, audioContext.currentTime);

  gainNode.gain.linearRampToValueAtTime(1, audioContext.currentTime + 1);

}



// 音频淡出效果

function fadeOutAudio() {

  gainNode.gain.linearRampToValueAtTime(0, audioContext.currentTime + 1);

}

五、跨浏览器兼容：让 H5 无处不在

抖音 H5 能在各种浏览器上保持一致的体验，这离不开前端开发者的兼容性优化。常用的手段包括使用 Autoprefixer 自动生成浏览器前缀、为老浏览器提供 Polyfill 等。以下是一个为 CSS 动画添加前缀的示例：

const autoprefixer = require('autoprefixer');

const postcss = require('postcss');



const css = '.example { animation: slidein 2s; } @keyframes slidein { from { transform: translateX(0); } to { transform: translateX(100px); } }';



postcss([autoprefixer]).process(css).then(result => {

  console.log(result.css);

  /*

   输出：

   .example {

     animation: slidein 2s;

   }

   @keyframes slidein {

     from {

       -webkit-transform: translateX(0);

              transform: translateX(0);

     }

     to {

       -webkit-transform: translateX(100px);

              transform: translateX(100px);

     }

   }

  */

});

打造一个像抖音一样的流畅 H5，需要前端开发者在性能优化、交互设计、音频处理和跨浏览器兼容等方面全方位发力。希望这些技术点能为你的 H5 开发之旅提供助力，让你的产品在激烈的市场竞争中脱颖而出！

背景

在做项目时，总会遇到UI给出渐变色的卡片或者按钮，但在做高亮的时候，由于没有过渡，显得尤为生硬。

过去的解决方案

在过去，我们如果要实现渐变色的过渡，通常会使用如下几种方法：

但这几种方式都有各自的局限性：

@property新规则

@property规则可以定义一个自定义属性，并且可以指定该属性的语法、是否继承、初始值等。

@property --color {

  syntax: '<color>';

  inherits: false;

  initial-value: #000000;

}

我们只需要把这个自定义属性--color应用到linear-gradient中，在特定的时候改变它的值，非常轻松就可以实现渐变色的过渡了。

我们再看看@property规则中这些属性的含义。

Syntax语法描述符

Syntax用于描述自定义属性的数据类型，必填项，常见值包括：

• <number> 数字（如0，1，2.5）


• <percentage> 百分比（如0%，50%，100%）


• <length> 长度单位（如px，em，rem）


• <color> 颜色值


• <angle> 角度值（如deg，rad）


• <time> 时间值（如s，ms）


• <image> 图片


• <*> 任意类型

Inherits继承描述符

Inherits用于描述自定义属性是否从父元素继承值，必填项：

• true 从父元素继承值


• false 不继承，每个元素独立

Initial-value初始值描述符

Initial-value用于描述自定义属性的初始值，在Syntax为通用时为可选。

兼容性

@property目前仍是实验性规则，但主流浏览器较新版本都已支持。

总结与展望

@property规则的出现，标志着CSS在动态样式控制方面迈出了重要一步。它不仅解决了渐变色过渡的技术难题，更为未来的CSS动画和交互设计开辟了新的可能性。
随着浏览器支持的不断完善，我们可以期待：

• 更丰富的动画效果


• 更简洁的代码实现


• 更好的性能表现

Hi，我是石小石~

静态属性获取的缺陷

前段时间在做项目国际化时，遇到一个比较隐蔽的问题：

我们在定义枚举常量时，直接调用了 i18n 的翻译方法：

export const OverdueStatus: any = {

  ABOUT_TO_OVERDUE: {

    value: 'ABOUT_TO_OVERDUE',

    name: i18n.global.t('common.about_to_overdue'),

    color: '#ad0000',

    bgColor: '#ffe1e1'

  },

}

结果发现翻译始终不生效。排查后才发现原因很简单 —— OverdueStatus 对象的初始化早于 i18n 实例的生成，因此取到的翻译结果是空的。

虽然最后我通过封装自定义 Vue 插件的方式彻底解决了问题，但排查过程中其实还有一个可选思路。

当时我想到的最直接办法是：让 name 在被访问时再去执行 i18n.global.t，而不是在对象定义时就执行。比如把 OverdueStatus 定义为函数：

export const OverdueStatus = () => ({

  ABOUT_TO_OVERDUE: {

    value: 'ABOUT_TO_OVERDUE',

    name: i18n.global.t('common.about_to_overdue'),

    color: '#ad0000',

    bgColor: '#ffe1e1'

  },

})

这样在调用时：

OverdueStatus().ABOUT_TO_OVERDUE.name

就能确保翻译逻辑在 i18n 实例创建完成之后再执行，从而避免初始化顺序的问题。不过，这种方式也有明显的缺点：所有类似的枚举都要改成函数，调用时也得多加一层执行，整体代码会变得不够简洁。

如何优雅地实现“动态获取属性”？

上面提到的“把枚举改成函数返回”虽然能解决问题，但在实际业务中显得有些笨拙。有没有更优雅的方式，让属性本身就支持 动态计算 呢？

其实，JavaScript 本身就为我们提供了解决方案 —— getter。

举个例子，我们可以把枚举对象改写成这样：

export const OverdueStatus: any = {

  ABOUT_TO_OVERDUE: {

    value: 'ABOUT_TO_OVERDUE',

    get name() {

      return i18n.global.t('common.about_to_overdue')

    },

    color: '#ad0000',

    bgColor: '#ffe1e1'

  },

}

这样一来，在访问 name 属性时，才会真正执行 i18n.global.t，确保翻译逻辑在 i18n 实例创建完成后才生效，完美解决问题。

访问器属性的原理

在 JavaScript 规范里，get 定义的属性叫 访问器属性，区别于普通的 数据属性 (Data Property) 。简单来说getter 其实就是对象属性的一种特殊定义方式。

当我们写：

const obj = {

  get foo() {

    return "bar"

  }

}

等价于用 Object.defineProperty：

const obj = {}

Object.defineProperty(obj, "foo", {

  get: function() {

    return "bar"

  }

})

所以访问 obj.foo 时，其实是触发了这个 get 函数，而不是读取一个固定的值。

类比Vue的computed

在 Vue 里，我们经常写 computed 计算属性，其实就是 getter 的思想。

import { computed, ref } from "vue"



const firstName = ref("Tom")

const lastName = ref("Hanks")



const fullName = computed(() => `${firstName.value} ${lastName.value}`)

computed 内部其实就是包装了一个 getter 函数。

注意点

• getter 不能跟属性值同时存在：

const obj = {

  get name() { return "石小石" },

  name: "石小石Orz" //  会报错

}

• getter 是只读的，如果你想支持赋值，需要配合 setter：

const obj = {

  _age: 18,

  get age() { return this._age },

  set age(val) { this._age = val }

}



obj.age = 20

console.log(obj.age) // 20

其他实用场景

延迟计算

有些值计算比较复杂，但只有在真正使用时才去算，可以提升性能

const user = {

  firstName: "石",

  lastName: "小石",

  get fullName() {

    // 类比一个计算，实现开发中，一个很复杂的计算才使用此方法

    console.log("计算了一次 fullName")

    return `${this.firstName} ${this.lastName}`

  }

}



console.log(user.fullName) // "石小石"

这种写法让 API 看起来更自然，不需要调用函数 user.getFullName()，而是 user.fullName。

数据封装与保护

有些属性可能并不是一个固定字段，而是基于内部状态计算出来的：

const cart = {

  items: [100, 200, 300],

  get total() {

    return this.items.reduce((sum, price) => sum + price, 0)

  }

}



console.log(cart.total) // 600

这样 cart.total 永远是最新的，不用担心手动维护，你也不用写一个函数专门去更新这个值。

前言

“分库分表这种架构模式会逐步的被淘汰！” 不知道在哪儿看到的观点

如果我们现在在搭建新的业务架构，如果说你们未来的业务数据量会达到千万 或者上亿的级别 还在一股脑的使用分库分表的架构，那么你们的技术负责人真的就应该提前退休了🙈

如果对未来的业务非常有信心，单表的数据量能达到千万上亿的级别，请使用NewSQL 数据库，那么NewSQL 这么牛，分布库分表还有意义吗？

今天虽然写的是一篇博客，但是更多的是抱着和大家讨论的心态来的，所以大家目前有深度参与分库分表，或者NewSQL 的都可以在评论区讨论！

什么是NewSQL

NewSQL 是21世纪10年代初出现的一个术语，用来描述一类新型的关系型数据库管理系统（RDBMS）。它们的共同目标是：在保持传统关系型数据库（如Oracle、MySQL）的ACID事务和SQL模型优势的同时，获得与NoSQL系统类似的、弹性的水平扩展能力

NewSQL 的核心理念就是 将“分库分表”的复杂性从应用层下沉到数据库内核层，对上层应用呈现为一个单一的数据库入口，解决现在 分库分表的问题；

分库分表的问题

分库分表之后，会带来非常多的问题；比如需要跨库联查、跨库更新数据如何保证事务一致性等问题，下面就来详细看看分库分表都有那些问题

选择TiDB还是采用mysql 分库分表的设计

数据量非常大，需要满足OLTP (Online Transactional Processing)、OLAP (Online Analytical Processing)、HTAP 且预算充足（分布式数据库的成本也是非常高的这一点非常的重要），并且是新业务新架构落地 优先推荐使用TiDB。
当然实际上选择肯定是需要多方面考虑的，大家有什么观点都可以在评论区讨论。

可以看看一个资深开发，深度参与TiDB项目，他对TiDB的一些看法：

1 什么是TiDB？

TiDB是PingCAP公司研发的开源分布式关系型数据库，采用存储计算分离架构，支持混合事务分析处理（HTAP） 。它与MySQL 5.7协议兼容，并支持MySQL生态，这意味着使用MySQL的应用程序可以几乎无需修改代码就能迁移到TiDB。

🚀目标是为用户提供一站式 OLTP (Online Transactional Processing)、OLAP (Online Analytical Processing)、HTAP 解决方案。TiDB 适合高可用、强一致要求较高、数据规模较大等各种应用场景。

官方文档：docs.pingcap.com/zh/tidb/dev…

TiDB五大核心特性

TiDB之所以在分布式数据库领域脱颖而出，得益于其五大核心特性：

• 一键水平扩容或缩容：得益于存储计算分离的架构设计，可按需对计算、存储分别进行在线扩容或缩容，整个过程对应用透明。


• 金融级高可用：数据采用多副本存储，通过Multi-Raft协议同步事务日志，只有多数派写入成功事务才能提交，确保数据强一致性。


• 实时HTAP：提供行存储引擎TiKV和列存储引擎TiFlash，两者之间的数据保持强一致，解决了HTAP资源隔离问题。


• 云原生分布式数据库：通过TiDB Operator可在公有云、私有云、混合云中实现部署工具化、自动化。


• 兼容MySQL 5.7协议和生态：从MySQL迁移到TiDB无需或只需少量代码修改，极大降低了迁移成本。

2 TiDB与MySQL的核心差异

虽然TiDB兼容MySQL协议，但它们在架构设计和适用场景上存在根本差异。以下是它们的详细对比：

2.1 架构差异

表1：TiDB与MySQL架构对比

2.2 性能表现对比

性能方面，TiDB与MySQL各有优势，主要取决于数据量和查询类型：

• 小数据量简单查询：在数据量百万级以下的情况下，MySQL的写入性能和点查点写通常优于TiDB。因为TiDB的分布式架构在少量数据时无法充分发挥优势，却要承担分布式事务的开销。


• 大数据量复杂查询：当数据量达到千万级以上，TiDB的性能优势开始显现。一张千万级别表关联查询，MySQL可能需要20秒，而TiDB+TiKV只需约5.57秒，使用TiFlash甚至可缩短到0.5秒。


• 高并发场景：MySQL性能随着并发增加会达到瓶颈然后下降，而TiDB性能基本随并发增加呈线性提升，节点资源不足时还可通过动态扩容提升性能。

2.3 扩展性与高可用对比

MySQL的主要扩展方式是一主多从架构，主节点无法横向扩展（除非接受分库分表），从节点扩容需要应用支持读写分离。而TiDB的存储和计算节点都可以独立扩容，支持最大512节点，集群容量可达PB级别。

高可用方面，MySQL使用增强半同步和MGR方案，但复制效率较低，主节点故障会影响业务处理[]。TiDB则通过Raft协议将数据打散分布，单机故障对集群影响小，能保证RTO（恢复时间目标）不超过30秒且RPO（恢复点目标）为0，真正实现金融级高可用。

2.4 SQL功能及兼容性

虽然TiDB高度兼容MySQL 5.7协议和生态，但仍有一些重要差异需要注意：

不支持的功能包括：

• 存储过程与函数


• 触发器


• 事件


• 自定义函数


• 全文索引（计划中）


• 空间类型函数和索引

有差异的功能包括：

• 自增ID的行为（TiDB推荐使用AUTO_RANDOM避免热点问题）


• 查询计划的解释结果


• 在线DDL能力（TiDB更强，不锁表支持DML并行操作）

3 如何选择：TiDB还是MySQL？

选择数据库时，应基于实际业务需求和技术要求做出决策。以下是具体的选型建议：

3.1 选择TiDB的场景

TiDB在以下场景中表现卓越：

3.2 选择MySQL的场景

MySQL在以下情况下仍是更合适的选择：

3.3 决策参考框架

为了更直观地帮助决策，可以参考以下决策表：

4 迁移注意事项

如果决定从MySQL迁移到TiDB，需要注意以下关键点：

5 总结

TiDB和MySQL是适用于不同场景的数据库解决方案，没有绝对的优劣之分。MySQL是优秀的单机数据库，适用于数据量小、架构简单的场景；数据量大了之后需要做分库分表。而TiDB作为分布式数据库，专注于解决大数据量、高并发、高可用性需求下的数据库瓶颈问题，但是成本也是非常的高

本人没有使用过NewSQL ，还望各位大佬批评指正

众所周知，新生代的ui框架(如：kotlin，swift，flutter，鸿蒙）都已经抛弃了XML这类的结构化数据标记语言改为使用声明式UI

只有web端还没有支持此类ui语法，此次我开发的ovsjs为前端也带来了此类声明式UI语法的支持，语法如下

项目地址

github.com/alamhubb/ov…

语法插件地址：

marketplace.visualstudio.com/items?itemN…

新语法如下：

我认为更强的地方是我的新设计除了为前端带来了声明式UI，还支持了 #{ } 不渲染代码块的设计，支持在 声明式UI中编写代码，这样UI和逻辑之间的距离更近，维护更方便，抽象组件也更容易

对比kotlin，swift，flutter，鸿蒙语法如下：

kotlin的语法

import kotlinx.browser.*

import kotlinx.html.*

import kotlinx.html.dom.*



fun main() {

    document.body!!.append.div {

        h1 {

            +"Welcome to Kotlin/JS!"

        }

        p {

            +"Fancy joining this year's "

            a("https://kotlinconf.com/") {

                +"KotlinConf"

            }

            +"?"

        }

    }

}

swiftUI的语法

import SwiftUI



struct ContentView: View {

    var body: some View {

        VStack(spacing: 16) {

            Text("Hello SwiftUI")

                .font(.largeTitle)

                .fontWeight(.bold)



            Text("Welcome to SwiftUI world")



            Button("Click Me") {

                print("Button clicked")

            }

        }

        .padding()

    }

}

flutter的语法

class MyApp extends StatelessWidget {

  const MyApp({super.key});



  @override

  Widget build(BuildContext context) {

    return MaterialApp(

      home: Scaffold(

        body: Center(

          child: Column(

            mainAxisSize: MainAxisSize.min,

            children: [

              const Text(

                "Hello Flutter",

                style: TextStyle(fontSize: 28, fontWeight: FontWeight.bold),

              ),

              const SizedBox(height: 12),

              const Text("Welcome to Flutter world"),

              const SizedBox(height: 16),

              ElevatedButton(

                onPressed: () {

                  print("Button clicked");

                },

                child: const Text("Click Me"),

              )

            ],

          ),

        ),

      ),

    );

  }

}

鸿蒙 arkts

@Entry

@Component

struct Index {

  @State message: string = 'Hello ArkUI'



  build() {

    Column() {

      Text(this.message)

        .fontSize(28)

        .fontWeight(FontWeight.Bold)



      Text('Welcome to HarmonyOS')

        .margin({ top: 12 })



      Button('Click Me')

        .margin({ top: 16 })

        .onClick(() => {

          console.log('Button clicked')

        })

    }

    .padding(20)

  }

}

原理实现

简述一下实现原理，就是通过parser支持了新语法，然后将新语法转义为 iife包裹的vue的h函数

为什么要iife包裹

因为要支持不渲染代码块

ovs图中的代码对应的编译后的代码是这样的

import {defineOvsComponent} from "/@fs/D:/project/qkyproject/test-volar/ovs/ovs-runtime/src/index.ts";

import {$OvsHtmlTag} from "/@fs/D:/project/qkyproject/test-volar/ovs/ovs-runtime/src/index.ts";

import {ref} from "/node_modules/.vite/deps/vue.js?v=76ca4127";

export default defineOvsComponent(props => {

  const msg = "You did it!";

  let count = ref(0);

  const timer = setInterval(() => {

    count.value = count.value + 1;

  },1000);

  return $OvsHtmlTag.div({class:'greetings',onClick(){

    count.value = 0;

  }},[

    $OvsHtmlTag.h1({class:'green'},[msg]),

    count,

    $OvsHtmlTag.h3({},[

      "You've successfully created a project with ",

      $OvsHtmlTag.a({href:'https://vite.dev/',target:'_blank',rel:'noopener'},['Vite']),

      ' + ',

      $OvsHtmlTag.a({href:'https://vuejs.org/',target:'_blank',rel:'noopener'},['Vue 3']),

      ' + ',

      $OvsHtmlTag.a({href:'https://github.com/alamhubb/ovsjs',target:'_blank',rel:'noopener'},['OVS']),

      '.'

    ])

  ]);

});

parser是我自己写的，抄了 chevortain 的设计，写了个subhuti，支持定义peg语法

github.com/alamhubb/ov…

slimeparser，支持es2025语法的parser，基于subhuti，声明es2025语法就行

github.com/alamhubb/ov…

然后就是ovs继承slimeparser，添加了ovs的语法支持，并且在ast生成的时候将代码转为vue的渲染函数，运行时就是运行的vue的渲染函数的代码，所以完美支持vue的生态

感兴趣的可以试试，入门教程

github.com/alamhubb/ov…

由于本人能力有先，文中存在错误不足之处，请大家指正，有对新语法感兴趣的欢迎留言和我交流

你有没有经历过这样的场景？点击“上传头像”，选了一张照片，页面却毫无反应——没有提示，没有图像，只有一个静默的按钮。你开始怀疑：是没选上？网速慢？还是系统出错了？于是你犹豫要不要再点一次，甚至直接关掉页面。

而如果在你选择文件的瞬间，一张清晰的缩略图立刻出现在眼前，哪怕后端还在处理，你也会安心地等待下去。

不是用户没耐心，而是他们需要一点“确定性”来支撑等待的理由。

图片预览，正是那个微小却关键的信号：你的操作已被接收，一切正在按预期进行。

得到程序正在运行的信号之后用户才会有等待的欲望。

今天，我们就来亲手实现一个图片预览功能。
先思考：要让一张用户选中的本地图片显示在网页上，我们到底需要做些什么？

第一步：我们要显示图片，那肯定得有个 <img> 标签吧？

没错。想在页面上看到图片，最直接的方式就是用 <img :src="xxx" />。但问题来了：用户刚从电脑里选了一张照片，这张照片还在他本地硬盘上，还没传到服务器，也没有公开 URL。那 src 该填什么？

这时候你可能会想：“能不能把这张本地文件直接塞进 src？”

答案是：不能直接塞 File 对象，但——我们可以把它“变成”一个 URL。

第二步：用户选了图，我们怎么拿到它？

通常我们会用 <input type="file" accept="image/*"> 让用户选择图片。在 Vue 中，为了能“拿到”这个 input 元素本身（而不仅仅是它的值），我们会用到 ref。

<input 

  type="file" 

  ref="uploadImage" 

  accept="image/*"

  @change="updateImageData"

/>

这里，ref="uploadImage" 就像给这个 input 贴了个标签。之后在 script 里，我们就能通过 uploadImage.value 拿到它的真实 DOM 引用。

于是，在 updateImageData 函数里，我们可以这样取到用户选中的文件：

const input = uploadImage.value;

const file = input.files[0]; // 用户选的第一张图

注意：不是 input.file，而是 input.files —— 这是一个常见的笔误，也是很多初学者卡住的地方。

第三步：有了 File 对象，怎么变成 <img> 能识别的 src？

现在我们手里有一个 File 对象，但它不能直接赋给 img.src。我们需要把它转成一种浏览器能直接渲染的格式。

这时候，FileReader 就登场了。

const reader = new FileReader();

reader.readAsDataURL(file);

readAsDataURL 会把文件内容读取为一个 Data URL，格式类似：

data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAA...

这串字符串可以直接作为 <img> 的 src！是不是很巧妙？

那什么时候能拿到这个结果呢？FileReader 是异步的，所以我们监听它的 onloadend 事件：

reader.onloadend = (e) => {

  imgPreview.value = e.target.result; // 这就是 Data URL

}

而我们的模板中早已准备好了一个 <img>：

<img :src="imgPreview" alt="" v-if="imgPreview" />

当 imgPreview 有值时，图片就自动显示出来了！

完整逻辑串起来

把这些碎片拼在一起，整个流程就清晰了：

这整个过程完全在前端完成，不需要上传到服务器，也不依赖任何第三方库——只用了浏览器原生 API 和 Vue 的响应式系统。

最后：完整实例

在vue中实现图片预览的完整代码及效果

1. 引言：设计系统的“寒武纪大爆发”与 Arco 的陨落

在 2019 年至 2021 年间，中国前端开发领域经历了一场前所未有的“设计系统”爆发期。伴随着企业级 SaaS 市场的崛起和中后台业务的复杂度攀升，各大互联网巨头纷纷推出了自研的 UI 组件库。这不仅是技术实力的展示，更是企业工程化标准的话语权争夺。在这一背景下，字节跳动推出了 Arco Design，这是一套旨在挑战 Ant Design 霸主地位的“双栈”（React & Vue）企业级设计系统。

Arco Design 在发布之初，凭借其现代化的视觉语言、对 TypeScript 的原生支持以及极具创新性的“Design Lab”设计令牌（Design Token）管理系统，迅速吸引了大量开发者的关注。它被定位为不仅仅是一个组件库，而是一套涵盖设计、开发、工具链的完整解决方案。然而，就在其社区声量达到顶峰后的短短两年内，这一曾被视为“下一代标准”的项目却陷入了令人费解的沉寂。

截至 2025 年末，GitHub 上的 Issue 堆积如山，关键的基础设施服务（如 IconBox 图标平台）频繁宕机，官方团队的维护活动几乎归零。对于数以万计采用了 Arco Design 的企业和独立开发者而言，这无疑是一场技术选型的灾难。

本文将深入剖析 Arco Design 从辉煌到停摆的全过程。我们将剥开代码的表层，深入字节跳动的组织架构变革、内部团队的博弈（赛马机制）、以及中国互联网大厂特有的“KPI 开源”文化，为您还原整件事情的全貌。

2. 溯源：Arco Design 的诞生背景与技术野心

要理解 Arco Design 为何走向衰败，首先必须理解它诞生时的宏大野心及其背后的组织推手。Arco 并不仅仅是一个简单的 UI 库，它是字节跳动为了解决特定业务线极其复杂的后台需求而孵化的产物。

2.1 “务实的浪漫主义”：差异化的产品定位

Arco Design 在推出时，鲜明地提出了“务实的浪漫主义”这一设计哲学。这一口号的提出，实际上是为了在市场上与阿里巴巴的 Ant Design 进行差异化竞争。

• Ant Design 的困境：作为行业标准，Ant Design 以“确定性”著称，其风格克制、理性，甚至略显单调。虽然极其适合金融和后台管理系统，但在需要更强品牌表达力和 C 端体验感的场景下显得力不从心。


• Arco 的切入点：字节跳动的产品基因（如抖音、TikTok）强调视觉冲击力和用户体验的流畅性。Arco 试图在中后台系统中注入这种基因，主张在解决业务问题（务实）的同时，允许设计师发挥更多的想象力（浪漫）。

这种定位在技术层面体现为对 主题定制（Theming） 的极致追求。Arco Design 并没有像传统库那样仅仅提供几个 Less 变量，而是构建了一个庞大的“Design Lab”平台，允许用户在网页端通过可视化界面细粒度地调整成千上万个 Design Token，并一键生成代码。这种“设计即代码”的早期尝试，是 Arco 最核心的竞争力之一。

2.2 组织架构：GIP UED 与架构前端的联姻

Arco Design 的官方介绍中明确指出，该系统是由 字节跳动 GIP UED 团队 和 架构前端团队（Infrastructure FrontEnd Team） 联合推出的。这一血统注定了它的命运与“GIP”这个业务单元的兴衰紧密绑定。

2.2.1 解密 GIP：通用信息平台 (General Information Platform)

GIP 全称为 General Information Platform（通用信息平台）。这是字节跳动早期的核心业务支柱，主要包含以下以“图文与中长视频”为核心的信息分发产品：

• 今日头条：字节跳动的起家之作，智能推荐资讯平台。


• 西瓜视频：中长视频平台。


• 番茄小说：免费网文阅读平台。

2.2.2 业务对技术的反哺与制约

GIP 的业务特点是高信息密度。今日头条的内容审核后台、广告投放系统（早期巨量引擎）、创作者管理平台（头条号后台）都需要处理海量的文本数据和复杂的表格操作。因此，Arco Design 从诞生起就带有浓重的“B 端中后台”基因，强调紧凑、理性和高效率，这正是为了服务于 GIP 庞大的内部系统需求。

在 2019-2020 年，GIP 仍是公司的绝对核心与营收主力。Arco Design 的推出，实际上是字节跳动“长子”（头条系）试图确立公司内部技术标准的一次有力尝试。

2.3 黄金时代的技术堆栈

在 2021 年左右，Arco Design 的技术选型是极具前瞻性的，这也是它能迅速获得 5.5k Star 的原因之一：

• 全链路 TypeScript：所有组件均采用 TypeScript 编写，提供了优秀的类型推导体验，解决了当时 Ant Design v4 在某些复杂场景下类型定义不友好的痛点。


• 双框架并进：@arco-design/web-react 和 @arco-design/web-vue 保持了高度统一的 API 设计和视觉风格。这对于那些技术栈不统一的大型公司极具吸引力，意味着设计规范可以跨框架复用。


• 生态闭环：除了组件库，Arco 还发布了 arco-cli（脚手架）、Arco Pro（中后台模板）、IconBox（图标管理平台）以及 Material Market（物料市场）。这表明团队不仅是在做一个库，而是在构建一个类似 Salesforce Lightning 或 SAP Fiori 的企业级生态。

然而，正是这种庞大的生态铺设，为日后的维护埋下了巨大的隐患。当背后的组织架构发生震荡时，维持如此庞大的产品矩阵所需的资源将变得不可持续。

3. 停摆的证据：基于数据与现象的法医式分析

尽管字节跳动从未发布过一份正式的“Arco Design 停止维护声明”，但通过对代码仓库、社区反馈以及基础设施状态的深入分析，我们可以断定该项目已进入实质性的“脑死亡”状态。

3.1 代码仓库的“心跳停止”

对 GitHub 仓库 arco-design/arco-design (React) 和 arco-design/arco-design-vue (Vue) 的提交记录分析显示，活跃度在 2023 年底至 2024 年初出现了断崖式下跌。

3.1.1 提交频率分析

虽然 React 版本的最新 Release 版本号为 2.66.8（截至文章撰写时），但这更多是惯性维护。

• 核心贡献者的离场：早期的高频贡献者（如 sHow8e、jadelike-wine 等）在 2024 年后的活跃度显著降低。许多提交变成了依赖项升级（Dependabot）或极其微小的文档修复，缺乏实质性的功能迭代。


• Vue 版本的停滞：Vue 版本的状态更为糟糕。最近的提交多集中在构建工具迁移（如迁移到 pnpm）或很久以前的 Bug 修复。核心组件的 Feature Request 长期无人响应。

3.1.2 积重难返的 Issue 列表

Issue 面板是衡量开源项目生命力的体温计。目前，Arco Design 仓库中积累了超过 330 个 Open Issue。

• 严重的 Bug 无人修复：例如 Issue #3091 “tree-select 组件在虚拟列表状态下搜索无法选中最后一个” 和 Issue #3089 “table 组件的 default-expand-all-rows 属性设置不生效”。这些都是影响生产环境使用的核心组件 Bug，却长期处于 Open 状态。


• 社区的绝望呐喊：Issue #3090 直接以 “又一个没人维护的 UI 库” 为题，表达了社区用户的愤怒与失望。更有用户在 Discussion 中直言 “这个是不是 KPI 项目啊，现在维护更新好像都越来越少了”。这种负面情绪的蔓延，通常是一个项目走向终结的社会学信号。

3.2 基础设施的崩塌：IconBox 事件

如果说代码更新变慢还可以解释为“功能稳定”，那么基础设施的故障则是项目被放弃的直接证据。

• IconBox 无法发布：Issue #3092 指出 “IconBox 无法发布包了”。IconBox 是 Arco 生态中用于管理和分发自定义图标的 SaaS 服务。这类服务需要后端服务器、数据库以及运维支持。


• 含义解读：当一个大厂开源项目的配套 SaaS 服务出现故障且无人修复时，这不仅仅是开发人员没时间的问题，而是意味着服务器的预算可能已经被切断，或者负责运维该服务的团队（GIP 相关的基建团队）已经被解散。这是项目“断供”的最强物理证据。

3.3 文档站点的维护降级

Arco Design 的文档站点虽然目前仍可访问，但其内容更新已经明显滞后。例如，关于 React 18/19 的并发特性支持、最新的 SSR 实践指南等现代前端话题，在文档中鲜有提及。与竞争对手 Ant Design 紧跟 React 官方版本发布的节奏相比，Arco 的文档显得停留在 2022 年的时光胶囊中。

4. 深层归因：组织架构变革下的牺牲品

Arco Design 的陨落，本质上不是技术失败，而是组织架构变革的牺牲品。要理解这一点，我们需要将视线从 GitHub 移向字节跳动的办公大楼，审视这家巨头在过去三年中发生的剧烈动荡。

4.1 战略重心的转移：从“头条”到“抖音”

2021 年底至 2024 年，字节跳动进行了多次大规模的组织架构调整。其中最关键的变化是战略重心从图文资讯（今日头条）全面转向短视频与直播（抖音/TikTok）以及后来的 AI 大模型。

• GIP 的边缘化：随着移动互联网进入存量时代，今日头条和西瓜视频的用户增长见顶，战略地位从“增长引擎”退化为“现金牛”甚至“存量维持”业务。


• 资源的抽离：GIP UED 和相关前端团队面临缩编或重组。维护 Arco Design 这样一套庞大的开源系统需要持续的人力投入。当母体部门本身都在进行“去肥增瘦”时，一个无法直接带来商业增量的开源 KPI 项目，自然成为了裁员的首选目标。

4.2 内部赛马机制：Arco Design vs. Semi Design

字节跳动素以“APP 工厂”和“内部赛马”文化著称。这种文化不仅存在于 C 端产品中，也渗透到了技术基建领域。Arco Design 的停摆，很大程度上是因为它在与内部竞争对手 Semi Design 的博弈中败下阵来。

4.2.1 Semi Design 的崛起

Semi Design 是由 抖音前端团队 与 MED 产品设计团队 联合推出的设计系统。

• 出身显赫：与 GIP 不同，Semi Design 背靠的是字节跳动的绝对核心——抖音。抖音前端团队拥有极其充裕的资源和稳固的业务地位。


• 技术路线之争：Semi Design 在架构上更为先进，采用了 Foundation/Adapter 模式，实现了逻辑与渲染分离，能以更低的成本适配不同框架。同时，Semi 深度集成了 D2C（Design-to-Code）工具链，更符合公司对 AI 和人效的追求。

4.2.2 为什么 Arco 输了？

在资源整合期，公司高层显然不需要维护两套功能高度重叠的企业级 UI 库。

• 业务绑定：Semi Design 宣称服务了内部 10 万+ 用户和近千个平台产品，深度嵌入在抖音的内容生产与运营流中。


• 结局：随着 GIP 业务权重的下降和团队的调整，Arco Design 失去了维护的资源，而 Semi Design 成为了事实上的内部标准。

4.3 中国大厂的“KPI 开源”陷阱

Arco Design 的命运也折射出中国互联网大厂普遍存在的“KPI 开源”现象。

• 晋升阶梯：在阿里的 P7/P8 或字节的 2-2/3-1 晋升答辩中，主导一个“行业领先”的开源项目是极具说服力的业绩。因此，很多工程师或团队 Leader 会发起此类项目，投入巨大资源进行推广（刷 Star、做精美官网）。


• 晋升后的遗弃：一旦发起人成功晋升、转岗或离职，该项目的“剩余价值”就被榨干了。接手的新人往往不愿意维护“前人的功劳簿”，更愿意另起炉灶做一个新的项目来证明自己。


• Arco 的轨迹：Arco 的高调发布（2021年）恰逢互联网泡沫顶峰。随着 2022-2024 年行业进入寒冬，晋升通道收窄，维护开源项目的 ROI（投入产出比）变得极低，导致项目被遗弃。

5. 社区自救的幻象：为何没有强有力的 Fork？

面对官方的停摆，用户自然会问：既然代码是开源的（MIT 协议），为什么没有人 Fork 出来继续维护？调查显示，虽然存在一些零星的 Fork，但并未形成气候。

5.1 Fork 的现状调查

通过对 GitHub 和 Gitee 的检索，我们发现了一些 Fork 版本，但并未找到具备生产力的社区继任者。

• vrx-arco：这是一个名为 vrx-arco/arco-design-pro 的仓库，声称是 "aro-design-vue 的部分功能扩展"。然而，这更像是一个补丁集，而不是一个完整的 Fork。它主要解决特定开发者的个人需求，缺乏长期维护的路线图。


• imoty_studio/arco-design-designer：这是一个基于 Arco 的表单设计器，并非组件库本身的 Fork。


• 被动 Fork：GitHub 显示 Arco Design 有 713 个 Fork。经抽样检查，绝大多数是开发者为了阅读源码或修复单一 Bug 而进行的“快照式 Fork”，并没有持续的代码提交。

5.2 为什么难以 Fork？

维护一个像 Arco Design 这样的大型组件库，其门槛远超普通开发者的想象。

因此，社区更倾向于迁移，而不是接盘。

6. 用户生存指南：现状评估与迁移策略

对于目前仍在使用 Arco Design 的团队，局势十分严峻。随着 React 19 的临近和 Vue 3 生态的演进，Arco 将面临越来越多的兼容性问题。

6.1 风险评估表

6.2 迁移路径推荐

方案 A：迁移至 Semi Design（推荐指数：⭐⭐⭐⭐）

如果你是因为喜欢字节系的设计风格而选择 Arco，那么 Semi Design 是最自然的替代者。

• 优势：同为字节出品，设计语言的命名规范和逻辑有相似之处。Semi 目前维护活跃，背靠抖音，拥有强大的 D2C 工具链。


• 劣势：API 并非 100% 兼容，仍需重构大量代码。且 Semi 主要是 React 优先，Vue 生态支持相对较弱（主要靠社区适配）。

方案 B：迁移至 Ant Design v5/v6（推荐指数：⭐⭐⭐⭐⭐）

如果你追求极致的稳定和长期的维护保障，Ant Design 是不二之选。

• 优势：行业标准，庞大的社区，Ant Gr0up 背书。v5 版本引入了 CSS-in-JS，在定制能力上已经大幅追赶 Arco 的 Design Lab。


• 劣势：设计风格偏保守，需要设计师重新调整 UI 规范。

方案 C：本地魔改（推荐指数：⭐）

如果项目庞大无法迁移，唯一的出路是将 @arco-design/web-react 源码下载到本地 packages 目录，作为私有组件库维护。

• 策略：放弃官方更新，仅修复阻塞性 Bug。这需要团队内有资深的前端架构师能够理解 Arco 的源码。

7. 结语与启示

Arco Design 的故事是现代软件工程史上的一个典型悲剧。它证明了在企业级开源领域，康威定律（Conway's Law） 依然是铁律——软件的架构和命运取决于开发它的组织架构。

当 GIP 部门意气风发时，Arco 是那颗最耀眼的星，承载着“务实浪漫主义”的理想；当组织收缩、业务调整时，它便成了由于缺乏商业造血能力而被迅速遗弃的资产。对于技术决策者而言，Arco Design 的教训是惨痛的：在进行技术选型时，不能仅看 README 上的 Star 数或官网的精美程度，更要审视项目背后的组织生命力和维护动机。

目前来看，Arco Design 并没有复活的迹象，社区也没有出现强有力的接棒者。这套组件库正在数字化浪潮的沙滩上，慢慢风化成一座无人问津的丰碑。

你有没有在写前端的时候，突然迷糊了：

• 为啥这张图片能直接 src="https://xxx.jpg" 就能展示？


• 为啥有时候图片是乱七八糟的一串 Base64？


• 有的还整出来个 Blob，看不懂但好像很高级？


• 有时还来个 ArrayBuffer，这又是哪位大哥？


• 最离谱的是：我本地图片路径写进去，怎么就不生效？

这些，其实都和“图像在前端的存在形式”有关。今天咱们就像唠家常一样，一口气整明白这几个常见的前端图像形式，用最接地气的方式讲明白，配上实例、场景分析，帮你彻底建立系统认知！

一、网络 URL：最熟悉的那张脸

<img src="https://example.com/image.jpg" />

这就是我们最常见的方式：网络地址。

📦 本质上是啥？

一个 HTTP(S) 请求，浏览器去服务器上拉图片回来。

👍 优点：

• 用起来最简单，能连网就能显示


• 浏览器会缓存，提高加载效率


• 图片不占你的 HTML 或 JS 文件大小

👎 缺点：

• 依赖网络，断网就 GG


• 跨域可能出问题（特别是 canvas 想处理图片时）


• 没法离线用

🧩 常见场景：

• 图床、CDN 图片


• 用户头像、商品封面等动态内容

二、本地 URL（相对路径）：常被坑的老兄

<img src="./images/logo.png" />

听起来像本地文件，实际上也是被打包进项目的资源文件路径。

⚙️ 本质上是啥？

开发时是相对路径，生产环境通常会被 Webpack、Vite 等构建工具“处理成”一个真实可访问的路径，比如 dist/assets/logo.abcd1234.png。

👀 你可能踩过的坑：

• 路径写错，或者构建工具没配置资源处理，图片加载失败


• 静态服务器没开，直接打开 HTML 无法访问文件（浏览器出于安全考虑禁止 file 协议访问）

💡 使用建议：

• 放到 public 目录，或者使用 import 静态资源方式处理


• 建议使用构建工具配置 alias 简化路径

三、Base64：字节转码“图片串”

<img src="data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAA..." />

这是把图片数据编码成 Base64 的字符串，直接塞进 HTML 或 JS 文件里。

🔬 本质上是啥？

Base64 是一种将二进制数据编码成 ASCII 字符串的方式。

✅ 优点：

• 免请求！嵌入式图片，一起打包进页面


• 没有跨域问题


• 非常适合小图标、loading 动画、SVG

❌ 缺点：

• 体积暴涨，大概比原图多 33%


• 可读性差，不利于维护


• 页面初始加载变慢

🧩 常见场景：

• CSS background-image


• 富文本编辑器中的粘贴图像


• 邮件嵌入图像

四、Blob：文件对象，前端造图必备

const blob = new Blob([arrayBuffer], { type: 'image/png' });

const url = URL.createObjectURL(blob);

img.src = url;

这是处理文件流时常见的一种格式。

🔍 本质上是啥？

Blob 是浏览器提供的一种二进制大对象，可以把它看作 JS 里的“文件”。

💪 优点：

• 可由 JS 动态生成，支持下载、预览、上传


• 可控制 MIME 类型，灵活性强


• 可以通过 URL.createObjectURL() 生成临时地址

📉 缺点：

• 是内存对象，页面刷新就没了


• 不能跨页面共享（临时的）