js 原生的数字计算是一个令人头痛的问题，最常见的就是浮点数精度丢失。

// 1. 加减运算

0.1 + 0.2 // 结果：0.30000000000000004（预期 0.3）

0.7 - 0.1 // 结果：0.6000000000000001（预期 0.6）



// 2. 乘法精度偏移

0.1 * 0.2 // 结果：0.020000000000000004（预期 0.02）

3 * 0.3   // 结果：0.8999999999999999（预期 0.9）



// 3. 除法结果异常

0.3 / 0.; // 结果：2.9999999999999996（预期 3）

1.2 / 0.2 // 结果：5.999999999999999（预期 6）

在金额计算的场景中出现这种问题是很危险的，例如「0.1 元 + 0.2 元」本应等于 0.3 元，原生计算却会得出 0.30000000000000004 元，直接导致金额显示错误或支付逻辑异常。

不少人会用toFixed四舍五入，保留 2 位小数来格式化数字，它本质上是 字符串格式化工具，而非精度修复工具，而且还会带来新的精度问题 —— toFixed的四舍五入规则是 “银行家舍入法”，无法解决底层计算的精度误差。

// 问题1. 四舍五入规则不符合预期

1.005.toFixed(2); // 结果："1.00"（预期 "1.01"）

2.005.toFixed(2); // 结果："2.00"（同样问题）

1.235.toFixed(2); // 结果："1.23"（预期 "1.24"）



// 问题2. 无法修复底层计算误差

const sum = 0.1 + 0.2; // 0.30000000000000004

sum.toFixed(2); // 结果："0.30"（表面正确，但误差仍存在，后续再运算仍然有问题）

sum.toFixed(10); // 结果："0.3000000000"（仅隐藏误差，未消除）

而 number-precision 能解决这些问题。

number-precision 的优势在哪？

• 轻量化，大小仅 1kb


• API 极简化，只有加减乘除和四舍五入


• 专注精度问题，无额外心智负担


• 兼容性好，无额外依赖

适用场景

• 中小型项目、仅需解决基础加减乘除精度问题的场景（如电商、金融类简单计算）


• 对包体积敏感的前端项目。

如何使用？

pnpm install number-precision

import NP from 'number-precision'



NP.strip(0.09999999999999998); // = 0.1

NP.plus(0.1, 0.2);             //加法计算 = 0.3, not 0.30000000000000004

NP.plus(2.3, 2.4);             //加法计算 = 4.7, not 4.699999999999999

NP.minus(1.0, 0.9);            //减法计算 = 0.1, not 0.09999999999999998

NP.times(3, 0.3);              //乘法计算 = 0.9, not 0.8999999999999999

NP.times(0.362, 100);          //乘法法计算 = 36.2, not 36.199999999999996

NP.divide(1.21, 1.1);          //除法计算 = 1.1, not 1.0999999999999999

NP.round(0.105, 2);            //四舍五入，保留2位小数 = 0.11, not 0.1

混合的计算：

import NP from 'number-precision'



// (0.8-0.5)x1000，保留2位小数

NP.round(NP.times(NP.minus(0.8, 0.5), 1000), 2)

// 计算股票收益率

NP.round(NP.times(NP.divide(NP.minus(+price, +cost), +cost), 100),2)

更复杂的计算场景用什么

number-precision有短小精悍的优势在，基本的运算都能拿捏，但那些要求更高的计算场景用什么库呢？

总结了目前社区流行的几款计算库，大家按需取用。

附上地址：

number-precision：github.com/nefe/number…

big.js：github.com/MikeMcl/big…

decimal.js：github.com/MikeMcl/dec…

math.js：github.com/josdejong/m…

作品推荐

Haotab 新标签页，一个优雅的新标签页

chrome 商店
| edge 商店
| 在线版

静待你的体验❤

在前端开发中，大屏适配一直是个让人头疼的问题。领导总是要求大屏既要不留白，又要不变形，还要没有滚动条。这看似简单的要求，实际却压根不可能。今天，我们就来聊聊大屏适配的四种常见模式，以及如何根据实际需求选择合适的方案。

一、大屏适配的困境

在大屏项目中，适配问题几乎是每个开发者都会遇到的挑战。屏幕尺寸的多样性、设计稿与实际屏幕的比例差异，都使得适配变得复杂。而领导的“既要...又要...还要...”的要求，更是让开发者们感到无奈。不过，我们可以通过合理选择适配模式来尽量满足这些需求。

二、四种适配模式

在大屏适配中，常见的适配模式有以下四种：

（以下截图中模拟视口1200px*500px和800px*600px，设计稿为1920px*1080px）

1. 拉伸填充（fill）

• 特点：内容会被拉伸变形，以完全填充视口框。这种方式可以确保视口内没有空白区域，但可能会导致内容变形。


• 适用场景：适用于对内容变形不敏感的场景，例如全屏背景图。

2. 保持比例（contain）

• 特点：内容保持原始比例，不会被拉伸变形。如果内容的宽高比与视口不一致，会在视口内出现空白区域（黑边）。这种方式可以确保内容不变形，但可能会留白。


• 适用场景：适用于需要保持内容原始比例的场景，例如视频或图片展示。

3. 滚动显示（scroll）

• 特点：内容不会被拉伸变形，当内容超出视口时会添加滚动条。这种方式可以确保内容完整显示，但用户需要滚动才能查看全部内容。


• 适用场景：适用于内容较多且需要完整显示的场景，例如长列表或长文本。

4. 隐藏超出（hidden）

• 特点：内容不会被拉伸变形，当内容超出视口时会隐藏超出部分。这种方式可以避免滚动条的出现，但可能会隐藏部分内容。


• 适用场景：适用于内容较多但不需要完整显示的场景，例如仪表盘。

三、为什么不能同时满足所有要求？

这四种适配模式各有优缺点，但它们在逻辑上是相互矛盾的。具体来说：

• 不留白：要求内容完全填充视口，没有任何空白区域。这通常需要拉伸或缩放内容以适应视口的宽高比。


• 不变形：要求内容保持其原始宽高比，不被拉伸或压缩。这通常会导致内容无法完全填充视口，从而出现空白区域（黑边）。


• 没滚动条：要求内容完全适应视口，不能超出视口范围。这通常需要隐藏超出部分或限制内容的大小。

这三个要求在逻辑上是相互矛盾的：

• 如果内容完全填充视口（不留白），则可能会变形。


• 如果内容保持原始比例（不变形），则可能会出现空白区域（留白）。


• 如果内容超出视口范围，则需要滚动条或隐藏超出部分。

四、【fitview】插件快速实现大屏适配

fitview 是一个视口自适应的 JavaScript 插件，它支持多种适配模式，能够快速实现大屏自适应效果。

github地址：github.com/pbstar/fitv…

在线预览：pbstar.github.io/fitview

以下是它的基本使用方法：

配置

• el: 需要自适应的 DOM 元素


• fit: 自适应模式，字符串，可选值为 fill、contain（默认值）、scroll、hidden


• resize: 是否监听元素尺寸变化，布尔值，默认值 true

安装引入

npm 安装

npm install fitview

esm 引入

import fitview from "fitview";

cdn 引入

<script src="https://unpkg.com/fitview@[version]/lib/fitview.umd.js"></script>

使用示例

<div id="container">

  <div style="width:1920px;height:1080px;"></div>

</div>

const container = document.getElementById("container");

new fitview({

  el: container,

});

五、总结

大屏适配是一个复杂的问题，不同的项目有不同的需求。虽然不能同时满足“不留白”“不变形”和“没滚动条”这三个要求，但可以通过合理选择适配模式来尽量满足大部分需求。在实际开发中，我们需要根据项目的具体需求和用户体验来权衡，选择最合适的适配方案。

在选择适配方案时，fitview 这个插件可以提供很大的帮助。它支持多种适配模式，能够快速实现大屏自适应效果。如果你正在寻找一个简单易用的适配工具，fitview 值得一试。你可以通过 npm 安装或直接使用 CDN 引入，快速集成到你的项目中。

希望这篇文章能帮助你更好地理解和选择大屏适配方案。如果你有更多问题或建议，欢迎在评论区留言。

如果你正在做官网开发，还在辛苦的手动实现那些动画特效，那今天推荐的这个库，至少让你提前4小时开始摸鱼!

以前，面对设计师的那些炫酷动画，实现起来是最耗头发的；产品经理还时不时的说一下，这效果不好看，我要的是五彩斑斓的黑！

还抱着 Element UI + Animate.css 在那里辛苦调试，苦苦思考好好的效果怎么到了 safari 就变形了呢 ？

现如今，时代变了！

什么是 Inspira UI

Inspira UI 是专门为 Vue3/Nuxt 开发的可复用的动画组件集合。

• 完全免费和开源


• 完美支持 vue3/Nuxt3


• 包括按钮、输入框、背景、卡片、设备模拟、光标、2D/3D效果等120+ 个特效组件


• 样式基于 TailwindCSS


• 动画使用 motion-v、gsap 实现


• 对移动设备特别优化

来欣赏一下效果：

视频文字

图库

3d文字

走马灯

spline

Inspira UI 的优势

1.兼顾视觉与功能

以**「轻量动效组件库」为定位，核心组件覆盖基础 UI（按钮、输入框等）和模块（3D 交互、动态背景等），所有组件均内置微交互**设计。动效无需额外开发完美适配企业官网、电商页面等需视觉增强的场景，实现 “拿即用” 的开发体验。

Liquid Logo

2.基于Tailwind CSS V4

底层基于 Tailwind CSS 构建组件基础样式，确保原子类叠加的灵活性；支持浅色、深色模式一键切换；支持 ypeScript，所有组件与 API 均提供完整类型定义。

浅色模式

3.深度兼容 Vue/Nuxt 生态，性能提升

无论是 Vue 单页应用还是 Nuxt 服务端渲染项目，都能无缝融入现有技术栈，降低开发者的学习与迁移成本。

同时基于 Vue 3.4+ 新增的 defineModel 与 watchEffect 语法重构，减少了至少 30% 的响应式依赖开销;

4.多端性能优化

对于 3D 组件，在支持 WebGPU 的浏览器中，渲染帧率较旧版 WebGL 提升 2-3 倍.

而对于移动端设备、低配置设备会自动调节动效帧率，性能大大提高；同时，对所有组件做了 “懒加载 + 预渲染” 优化，首屏加载速度较旧版提升 35%

如何使用？

Inspira UI 官方文档支持中文，写的也很接地气，通俗易懂 5 分钟就能上手！

• 安装依赖

    # 安装 tainlwind

    pnpm install tailwindcss @tailwindcss/vite



    # 安装 tailwindcss 库和实用工具

    pnpm install -D clsx tailwind-merge class-variance-authority tw-animate-css



    # 安装 VueUse 和其他支持库

    pnpm install @vueuse/core motion-v

• 配置 vite

    import { defineConfig } from 'vite'

    import tailwindcss from '@tailwindcss/vite'



    export default defineConfig({

      plugins: \[

        tailwindcss(),

      ],

    })

• 配置主题

可以根据需要自由配置主题色。

    @import tailwindcss;

    @import tw-animate-css;

    @custom-variant dark (&:is(.dark *));



    :root {

      --card: oklch(1 0 0);

      --card-foreground: oklch(0.141 0.005 285.823);

    }

    .dark {

      --background: oklch(0.141 0.005 285.823);

      --foreground: oklch(0.985 0 0);

    }

    @theme inline {

      --color-background: var(--background);

    }

    @layer base {

      * {

        @apply border-border outline-ring/50;

      }

      body {

        @apply bg-background text-foreground;

      }

    }

    html {

      color-scheme: light dark;

    }

    html.dark {

      color-scheme: dark;

    }

    html.light {

      color-scheme: light;

    }

最后一步，可以复制源码或者通过 Cli 来安装。

• 直接使用源码

找到想要的组件，复制粘贴到自己的项目中即可。

• 通过 Cli 安装

    pnpm dlx shadcn-vue\@latest add "https://registry.inspira-ui.com/gradient-button.json>"

然后，你就有了一个炫酷的按钮。

Gradient Button 效果

最后

Vue3/Nuxt3开发者再也不用羡慕 React生态的 Aceternity UI、Magic UI 了。

Inspira UI 直接填补了 vue3 生态中动效开发这一块的缺陷，可以将这些奇妙的设计应用在企业官网、特效开发中，大大节省开发成本。

让 Vue3 生态再一次得到加强，快去试试这个炫酷的项目把！

附上官网地址：inspira-ui.com/docs/cn

作品推荐

Haotab 新标签页，一个优雅的新标签页

chrome 商店
| edge 商店
| 在线版

静待你的体验❤

一、前端动画的"至暗时刻"：每个像素都在燃烧经费

618 前夕，我的 PM 突然发来灵魂拷问："菜鸡，这个购物车弹性动画，为什么安卓和 iOS 的抖动幅度不一样？还有这个圣诞飘雪特效，为什么 iPhone 13 Pro Max 的耗电量能煎鸡蛋？"

我默默擦掉额头的冷汗，回想起被这些需求支配的恐惧：

直到某天，隔壁组的前端突然拍案而起："用Lottie！这玩意能直接吃AE动画！" —— 那一刻，我仿佛看到了前端动画的文艺复兴曙光。

二、Lottie：动画界的 Rosetta Stone（罗塞塔石碑）

1. 打破巴别塔诅咒的技术本质

Lottie的魔法可以拆解为三个核心环节：

• 魔法卷轴（JSON文件）：
  
  设计师在AE中使用 Bodymovin插件 导出的动画配方，包含所有图层、关键帧、路径等元数据，体积通常只有GIF的1/10


• 咒语解析器（Lottie Runtime）：
  
  各平台的解析引擎（Web/iOS/Android/Flutter等），像精密的手术刀般逐帧解析JSON指令


• 元素召唤阵（Canvas/SVG/OpenGL）：
  
  根据设备性能自动选择最优渲染方案，低端机用轻量SVG，旗舰机秀Canvas魔法

2. 那些年被 Lottie 拯救的惨案现场

三、Lottie 的文艺复兴之路：从加载动画到元宇宙门票

1. 业务舞台的常青树场景

• 轻量级演出：
  
  Loading 动画、按钮微交互、表情包（微信的[呲牙]动画仅28KB）


• 重量级剧场：
  
  新手引导流程、电商促销动效、直播礼物特效（某直播平台的火箭升空动画仅182KB）


• 沉浸式演出：
  
  游戏化运营活动、元宇宙3D场景过渡（某电商 App 的虚拟试衣间加载动画）

2. 那些让程序员笑醒的代码片段

Web 端 React 全家桶套餐：

import { Player } from '@lottiefiles/react-lottie-player';



<Player

  src="/emoji.lottie.json"

  style={{ height: '300px' }}

  autoplay

  loop

  onEvent={event => {

    if (event === 'complete') console.log('老板说这个动画要播10086遍')

  }}

/>

Vue3 优雅食用姿势：

<template>

  <Lottie :animation-data="rocketJSON" @ready="startLaunch" />

</template>



<script setup>

import { Lottie } from 'lottie-web-vue';

import rocketJSON from './rocket-launch.json';



const startLaunch = (anim) => {

  anim.setSpeed(1.5);

  anim.play();

}

</script>

微信小程序性能优化版：

<lottie 

  animationData="{{lottieData}}"

  path="https://static.example.com/animations/coupon.json"

  autoPlay="{{true}}"

  css="{{'width: 100%; height: 300rpx;'}}"

  bind:ready="onAnimReady"

/>

四、打开 Lottie 的正确姿势：从青铜到王者的进阶之路

1. 设计师的防跑偏指南

• AE图层命名规范：禁止出现"最终版-真的不改了-V12"这类薛定谔命名


• 合理使用预合成：嵌套层级不要超过俄罗斯套娃的极限


• 动态属性标记：需要运行时修改的颜色/文字要提前标注

2. 工程师的性能调优包

压缩黑科技三件套：

# 使用 lottie-tools 进行瘦身

npx lottie-tools compress animation.json -o animation.min.json



# 删除无用元数据

npx lottie-tools remove-unused animation.json



# 提取公共资源

npx lottie-tools split animation.json --output-dir ./assets

按需加载策略：

const loadLottie = async () => {

  const animation = await import(

    /* webpackPrefetch: true */ 

    /* webpackChunkName: "lottie-animation" */ 

    './animation.json'

  );

  lottie.loadAnimation({

    container: document.getElementById('lottie'),

    animationData: animation.default

  });

}

五、当Lottie遇到次元壁：那些年我们填过的坑

1. 跨平台兼容性排雷手册

2. 性能优化急救包

// 帧率节流大法

animation.addEventListener('enterFrame', () => {

  if(performance.now() - lastTime < 16) return;

  lastTime = performance.now();

  // 真正执行渲染逻辑

});



// 内存泄漏防护

useEffect(() => {

  const anim = lottie.loadAnimation({...});

  return () => anim.destroy(); // 比卸载微信还干净

}, []);

六、未来展望：Lottie的元宇宙野望

当我在AR眼镜里看到Lottie渲染的3D购物动画时，突然意识到这个技术正在打开新次元：

也许不久的将来，我们能用Lottie在元宇宙里复刻《盗梦空间》的折叠城市动画——当然，得先确保产品经理不会要求实时修改地心引力参数。

总结

从被 GIF 支配的恐惧，到用 JSON 驾驭动画的自由，Lottie 让我们离"设计即代码"的理想国又近了一步。下次当设计师又甩来 500MB 的 AE 工程时，你可以优雅地打开 Bodymovin 插件："亲爱的，这次咱们换个姿势加载。"

前言

之前我们公司有个项目组搞了个 AI 大模型推荐功能，眼看就要上架了，结果产品突然找过来说：

“那个 AI 推荐的模块先别放了，先隐藏吧，怕上架审核出问题。”

为了赶时间，技术那边就临时加了个判断，把入口在前端藏起来，赶紧发了个版本，算是暂时搞定。

结果没过几天，又说要发版本。我一问咋了？技术一脸生无可恋：

“产品又说 AI 那个功能现在可以公测了，要放出来了。”

好吧，那就再发一次......

然后没几天，产品又说要隐藏掉，说模型结果不稳定要临时下线。

“先别公测了，发现有问题，先关掉再说。”

听说那天技术已经气到跟产品去厕所单挑了……

我当时的内心 OS 是：这也太反复了吧？到底是想上还是不想上？

这种“上线前隐藏，上线后又展示，再隐藏”的操作，不是一次两次了。

所以我们当时就想了：

既然这些需求只是改个显示开关、调个默认值，为啥不干脆给他们一个“自助按钮”？别每次都让我们改代码发版本，产品自己调着玩不好吗？

于是我们开始在后台做一套简单的业务配置中心，目标就是：

• 产品、运营可以自己配置功能开关、文案、参数，不用找开发


• 配置修改能实时生效，不用再发版本


• 支持输入类型、下拉选项、开关按钮、范围数值，想怎么配就怎么配

这不是为了什么“大中台”，就是想解决那些一天三改、两小时一调的需求，把这些琐碎从开发日常里剥离出去。

这些配置，说改就改，好烦人

其实像上面的这个事情 在我们日常开发中太常见了。

举几个我亲身经历的例子就知道为啥我们非得搞个配置中心：

• 登录要不要加图形验证码？
  
  一开始为了用户体验不加，结果突然哪天注册量暴涨，一查是黑产在刷。产品急了：“赶紧加验证码！”
  
  技术临时改、测试、上线……黑产已经溜了，下次再刷又得重来一遍。为啥不做个开关自己控制？


• 推荐功能的参数一天一个样
  
  有一版产品说“默认推荐 5 个兴趣标签”，隔两天又改成 3 个，再过几天又要回 4 个，说“现在运营数据反馈不一样了”。
  
  我寻思你都能自己看数据了，那你为啥不能自己改参数？


• 短信通道经常切换
  
  阿里、腾讯、网易云信……一个月能换仨。原因也很实在，要么是价格问题，要么是运营说“昨天验证码收不到”。
  
  每次换通道都得技术去代码里改 templateId、signName，我真想把接口都写成配置项，让你们爱换谁换谁。


• 活动逻辑说改就改
  
  运营：“这个弹窗逻辑改一下，注册就弹。”
  
  上了之后运营又说：“太打扰用户了，还是调成登录 3 天之后再弹。”
  
  这不就一行逻辑的事，但每次都要发版真心烦。

像这些情况，改的不是业务逻辑，就是个值、个条件、个开关。但只要没抽出来配置，就只能靠技术手动改代码，一点都不优雅，还特别浪费时间。

所以后来我们就想，还是干脆统一搞个配置后台吧，把这些“天天改、随时调”的破事都收进去，让配置能看得见、改得了、控得住，技术这边也能轻松点。

之前我们配置到底怎么管的？说实话，说出来都不太好意思：

• 有的直接写死在代码里，变量名都不带解释的，谁写的谁才知道啥意思；


• 稍微规范一点的，会统一搞个 config 文件，但也只是“技术自己看得懂”的那种；


• 更混乱的是，有的配置写在 yml，有的塞在数据库，还有的干脆“哪里用到就哪里写”，找都找不到；


• 最离谱的是：业务运营类的配置和技术底层的配置，全堆一起，切短信通道这种运营配置放在 core-service 的 application.yml 里，看得人脑壳疼。

等到要改配置的时候，产品和运营根本不知道去哪改，开发也得翻半天才能定位是哪段逻辑控制的，甚至还会不小心把技术底层配置给动了……这种时候就明白了，没有一套清晰、隔离、可视化的配置系统，迟早乱套。

配置也要讲规矩，不能啥都往后台扔

当然，配置中心也不是说所有配置都往后台一丢就完事了。

我们踩过这个坑。

最早的时候我们也想偷懒，把所有配置（技术的、业务的、运营的）都塞在统一的配置文件里，比如 config.php 或 application.yml 里，统一读就完了，听起来挺美的。

但实际用下来，真的是——乱！成！一！锅！粥！

一方面，业务/运营配的东西，是给人看的，得讲人话。

比如：

• 推荐位默认展示几个内容？


• 某个功能在特定版本下是否开启？


• 发奖的触发条件设置为几天内登录？

这些运营同学自己都能理解，也希望自己能控制，那就该做成后台可配置、能预览、能实时生效的。

但另一方面，有些配置就不能乱动，或者干脆不应该给后台看到：

• MQ 消费 topic 名


• 数据库连接池配置


• 是否启用 debug 模式


• 线上某些敏感接口的限频值

如果我们把这些放给业务方看，他们可能都不知道是干嘛的，不小心点了一下，系统都能给整崩了……

所以后来我们就统一了一套大致的“配置分级规则”：

有些配置是纯技术底层的，比如 MQ 的 topic 名、接口限流的阈值、日志采样比例、数据库连接池大小……

这些属于“动一下系统都可能出事”的类型，不给任何后台入口，完全由技术团队内部维护，最好写死或写进 yml 里。

然后是那种纯运营向的配置，比如功能开关、首页推荐展示几个卡片、某段文案内容、活动弹窗的显示时间等等。

这些配置逻辑上不会出啥大问题，但会被运营天天来回调整，必须放后台让他们自己搞，不然技术早晚被烦死。

还有一种是产品经常会动的业务规则类配置，比如：

• 某个功能灰度给哪些版本开放；


• 某个打点逻辑的间隔时间怎么设；


• 是否对新用户显示某个引导。

这些其实也不属于“技术配置”，而是产品为了做 A/B 测试、做用户分群、验证效果临时改的，技术只负责“支持能力”，真正的“值”还是应该交给产品自己配。

我们就按照这个思路，把技术底层的隐藏掉，只暴露运营类和业务类配置给后台，谁负责谁管理。改错了好歹还能找到人。

这样一来，配置中心的边界清晰了，技术也不用再被无限兜底，系统也能跑得更稳定，团队分工也更顺。

配置中心该长啥样？我们定了几个目标

前面说了那么多需求、痛点、吵架场面（划掉），那我们到底想要一个什么样的配置中心呢？

说白了，我们的目标很简单：

能分清模块，分清人，分清配置类型，能改能看能预览，最好技术都不用管。

那我们是怎么拆功能的呢？最初的设计版本是这样的：

1. 配置要能分模块

不能全堆一起。

我们一个项目，最少有这些模块：系统相关、用户系统、运营活动、AI 任务、通知推送、发奖逻辑……每个模块都有自己的配置。

所以我们一开始就支持“按模块分组”，一个模块里挂多个配置项，清清楚楚谁负责啥，谁爱改啥自己管。

2. 每个配置项要有“类型”

这个最开始我们踩过坑。

最初只做了输入框，结果运营输入一堆错格式的东西，改出 bug。后来我们就定了：所有配置项必须类型化，根据使用场景来限定可选值/格式。

目前我们支持的类型大概是这几种：

• 输入框：最普通的文本输入，比如标题、url、提示语。


• 范围值：像“10~100”这种，就搞个最小|最大格式，自动校验。


• 下拉框：适合选模板、选模型、选渠道。


• 单选框：跟下拉差不多，看场景展示方式不同。


• 开关：很直观，是否开启、是否显示，一眼看懂。


• 多选框：比如支持多个渠道、多种规则生效。

每种类型不仅能展示、还能实时预览效果，这样产品在后台改的时候，不会因为“看不懂这个字段到底是啥”而填错。

3. 每个配置项还要有说明、默认值、排序、是否启用这些“附加属性”

比如说明字段是给人看的，告诉我们这个配置是干嘛的。

默认值是防止读取失败时兜底的。

排序值让我们在后台列表里好找，不然一堆配置乱七八糟的。

“是否启用”是加的一个保险，有些配置值可以保留但临时不生效，方便灰度切换或者留作备选。

4. 最重要的：配置改完必须能“立刻生效”

要是改完还得等发版、等服务重启，那这配置中心跟笔记本有啥区别？

所以我们后面加了热更新机制（这部分我后面会细讲），让配置一改，业务侧立刻拿到新值。

配置中心的数据库设计，我们是这么搞的

配置中心的本质，其实就是“配置的结构化存储 + 可控修改 + 有上下文管理”。

所以数据库是核心。我们一共设计了两个主表：模块表 + 配置项表。当然后续可以加变更记录表之类的，这里先讲核心结构。

1. 模块表：配置的分组归属

配置不能全堆一起，所以我们做了个“模块管理”表，每个模块代表一类业务，比如用户系统、AI 推荐、通知设置、发奖逻辑等。

表结构像下面这样：

CREATE TABLE `config_module` (

  `id` int(10) unsigned NOT NULL AUTO_INCREMENT,

  `name` varchar(100) NOT NULL COMMENT '模块名称',

  `sort` int(11) DEFAULT '0' COMMENT '排序值，越小越靠前',

  `status` tinyint(4) DEFAULT '1' COMMENT '状态 1启用 0禁用',

  `create_time` int(11) NOT NULL,

  `update_time` int(11) DEFAULT NULL,

  PRIMARY KEY (`id`)

) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='配置模块分组';

字段说明一下：

• id 就是主键


• name 是模块名，比如“用户系统”、“活动发奖”


• sort 控制在前端显示顺序，方便找


• status 是不是启用这个模块的配置


• 时间字段保留是为了后续查操作记录

2.配置项表：一条配置的所有核心信息

模块分好了之后，接下来就是每个模块下面的具体配置项。我们所有的配置内容，都存在这张 config 表里。

我们当时在设计的时候，就围绕几个问题来定字段的：

• 这个配置是给谁看的？（产品、运营、开发）


• 他们需要怎么填？（输入框？下拉？多选？）


• 填的时候怎么确保不出错？（要不要加参数说明？校验？默认值？）


• 配置项能不能启用/禁用？排序顺序怎么控制？


• 有没有必要展示说明/备注？

最终我们定下了下面这个表结构：

CREATE TABLE `config` (

  `id` int(10) unsigned NOT NULL AUTO_INCREMENT COMMENT '主键ID',

  `pid` int(10) unsigned NOT NULL DEFAULT '0' COMMENT '所属模块ID',

  `name` varchar(100) NOT NULL COMMENT '配置项名称（展示用）',

  `key` varchar(100) NOT NULL COMMENT '配置项key（英文唯一标识）',

  `value` text COMMENT '配置项当前值',

  `input_type` tinyint(4) NOT NULL DEFAULT '1' COMMENT '输入类型：1输入框 2范围 3下拉 4单选 5开关 6多选',

  `param` text COMMENT '参数说明：选项或范围，如 "A-1|B-2|C-3"',

  `desc` varchar(255) DEFAULT '' COMMENT '配置项说明/备注',

  `sort` int(11) DEFAULT '0' COMMENT '排序值（越小越前）',

  `status` tinyint(4) DEFAULT '1' COMMENT '状态：1启用 0禁用',

  `create_time` int(11) NOT NULL,

  `update_time` int(11) DEFAULT NULL,

  PRIMARY KEY (`id`),

  UNIQUE KEY `key` (`key`)

) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='系统配置项表';

字段说明：

• id：自增主键，没啥说的。


• pid：配置项属于哪个模块（模块表里的 id）。


• name：配置项的中文名，比如“是否展示弹窗”。


• key：这个是英文标识，用来在代码里读取，比如 home.pop.enabled。


• value：配置的当前值，比如 1（开启）或 {"a":1,"b":2}。


• input_type：决定这个配置项在后台怎么展示：
  
  
  
  
  • 1 = 输入框
  
  
  • 2 = 范围（比如“10|100”）
  
  
  • 3 = 下拉框
  
  
  • 4 = 单选按钮
  
  
  • 5 = 开关
  
  
  • 6 = 多选框
  
  
  
  


• param：这个字段就很灵活了，用来定义下拉/单选/多选的选项，或者范围的上下限，比如：
  
  
  
  
  • "中文-zh|英文-en"
  
  
  • "10|100"
  
  
  
  


• desc：配置项的说明，告诉用户这个配置干嘛的，防止乱填。


• sort：排序值，配置项多了之后按顺序展示比较清楚。


• status：这个配置当前是否启用，方便临时关闭某个配置而不删除它。


• create_time / update_time：时间戳，用来做修改记录、日志追踪之类的。


• UNIQUE KEY (key)：保证每个配置 key 唯一，不会撞名。

总体来说，这张表的核心就是：一个配置项，长什么样、值是多少、长得像啥、能不能动，都在这张表里写清楚了。

模块设计：把配置管得清清楚楚，落到后台页面里

前面我们提到，配置中心一定要支持“按模块分组”，不然配置一多，找起来比翻快递单还费劲。

这里就简单说下我们是怎么把“模块”这个概念，真正落到后台界面和数据库结构里的。

我们每个模块其实就是一个大分类，比如：

• 系统配置


• 用户配置


• AI 相关配置


• 活动发奖配置


• 通知推送相关……

每个模块下可以挂多个配置项，类似“一个文件夹里放一类东西”。

我们后台页面上的模块管理界面，大概就长这样：

这里我们可以设计的支持排序、状态控制、修改、删除这些操作。

点击“新增模块”就会弹出这个表单：

看起来非常简洁对不对。上面的模块表结构对应的核心字段就三个：

• 模块名称：展示用，方便识别


• 排序值：用来控制前端列表显示顺序


• 是否启用：可以临时禁用整个模块下的配置项

后台页面支持模块的增删改查，基础功能已足够覆盖大多数业务配置需求。

当然，如果业务后续需要更复杂的结构（比如“系统配置 → 登录模块 → 登录相关配置”这种），我们也可以扩展支持二级模块或模块分组。当前只是保留了基础能力，足够轻量、上手快。

配置项怎么设计的？

有了模块分组之后，接下来的重头戏就是：配置项的核心玩法。

每个配置项，本质上就是一个“可调参数”。比如这些熟悉的问题：

• 用户登录要不要启用谷歌验证？


• 运营活动的推荐数值范围是多少？


• 发奖逻辑该切哪个短信商？

以前这些配置，不是写死在代码里，就是散落在 yml、env 文件里，甚至不同环境各一份，改一次还得发版，改完还得祈祷别出问题。

这次我们干脆做成可视化配置项，页面上就能：

新增、修改、启用/禁用

设置不同类型的输入方式

即填即预览，所见即所得

我们支持的配置类型包括：

• 输入框：适合输入纯文本，比如一个 URL、token、默认值等。


• 范围：用 最小值|最大值 格式，比如推荐人数限制就写成 10|100。


• 下拉选择：多个固定选项，用 | 分隔，比如 中文-zh|英文-en。


• 单选按钮：和下拉差不多，但前端展示为横向圆点，更直观。


• 开关：布尔值场景，1 是开启，0 是关闭。


• 多选框：允许选多个选项，比如某功能适用于多个角色、多个平台。

每种类型在新增配置时都有专属提示，比如范围要填最小|最大，下拉要写选项清单，填完之后还能看到实时预览，确保填的值就是我们想要的。

接下来我们就一个个举例，一边介绍场景，一边实际新增配置项来看效果。

类型一：输入框

适用场景：

输入框是最通用、最基础的配置类型，适合填写纯文本、数字、链接、key 等，不需要做复杂校验，直接存直接用。

常见场景举例：

• default_jump_url：默认跳转链接，比如用户扫码登录后跳去哪个页面。


• login_timeout：用户登录状态超时时间，单位秒。


• system_notice：系统公告文案。


• token_prefix：JWT 或其它 token 的前缀标识。

我们现在来新增一个配置项：

• 所属模块：系统配置


• 配置名称：登录超时（秒）


• 配置 Key：login_timeout


• 输入类型：输入框


• 默认值：600


• 参数说明：留空（输入框不需要）


• 描述：用户登录后多少秒内无操作将自动退出


• 排序值：0


• 是否启用：是

类型二：范围（最小值 | 最大值）

适用场景：

范围类型适合那种“值不能随便填，必须在某个区间内”的配置，比如：

• 推荐系统中：每天最多推荐多少次？


• 活动配置中：用户每次最多能抽几次奖？


• 发奖逻辑中：奖励金额必须在一个上下限之间。

用配置来写这种规则，业务方只要改数字就行，不用再去翻代码或改逻辑，非常方便。

示例配置：推荐数值范围

假设我们现在要配置一个推荐值范围：

• 所属模块：系统配置


• 配置名称：每日推荐数量范围


• 配置 Key：recommend_count_range


• 输入类型：范围


• 默认值：50


• 参数说明：10|100 （表示最小值是 10，最大值是 100）


• 描述：控制推荐系统每天给用户推荐的最小/最大条数


• 排序值：0


• 是否启用：是

我们在页面中选择「输入类型：范围」之后，系统会提示填写参数格式为：

最小值|最大值，例如：10|100

类型三：下拉选择（select）

适用场景：

如果某个配置值只能从一组选项中选一个，比如：

• 默认语言：中文 / 英文 / 日文


• 消息推送渠道：极光 / 个推 / 小米推送


• 推荐策略：粗放型 / 精细化 / AB 测试组

这类配置，业务经常调整，但必须选“规定范围内”的值，用下拉最合适。

示例配置：默认语言设置

我们现在来配置一个「默认语言」的选项：

• 所属模块：系统配置


• 配置名称：默认语言


• 配置 Key：default_language


• 输入类型：下拉选择


• 默认值：zh


• 参数说明：中文-zh|英文-en|日文-jp


• 描述：系统默认语言，决定用户首次进入时的显示语言


• 排序值：0


• 是否启用：是

注意参数说明的格式：

每个选项写成“名称-值”，多个选项用 | 隔开，比如：

中文-zh|英文-en|日文-jp

我们可以随意扩展选项，只要格式统一就行。

类型四：单选按钮（radio）

适用场景：

单选按钮适合那种选项数量不多、用户希望“一眼看清楚当前选的是啥”的配置，比如：

• 登录方式：密码 / 验证码 / 三方授权


• 首页布局：列表 / 瀑布流


• 推送等级：重要 / 普通 / 弱提示

相比下拉，单选按钮更直接，不用点一下再展开，适合管理后台中高频使用的布尔或枚举项

示例配置：登录方式选择

假设我们想设置一个登录方式的配置：

• 所属模块：系统配置


• 配置名称：登录方式


• 配置 Key：login_method


• 输入类型：单选按钮


• 默认值：pwd


• 参数说明：密码登录-pwd|验证码登录-code|三方授权-oauth


• 描述：控制用户使用哪种方式登录


• 排序值：0


• 是否启用：是

参数说明格式：

和下拉一样，用 名称-值 的格式写选项，多个用 | 分隔：

密码登录-pwd|验证码登录-code|三方授权-oauth

类型五：开关（switch）

适用场景：

布尔型逻辑的最爱！

只要我们有 “开关类” 配置，比如：

• 是否开启 AI 推荐功能


• 是否启用登录验证码


• 是否允许用户取消订单


• 是否开启调试日志打印

这些“启用 / 禁用”型的业务控制，都可以直接用开关来配置，后台切换一次立即生效，不用发版，非常方便。

示例配置：启用登录验证码

这次我们来添加一个“是否启用图片验证码”的配置：

• 所属模块：系统配置


• 配置名称：启用图片验证码


• 配置 Key：login_captcha_enabled


• 输入类型：开关


• 默认值：1（1 表示启用，0 表示关闭）


• 参数说明：留空（开关类型不需要）


• 描述：是否对用户登录行为开启图形验证码验证


• 排序值：0


• 是否启用：是

这类配置用处非常多，一些 灰度开关、紧急兜底、临时下线功能 都可以通过这个来做，非常适合给非技术人员使用。

类型六：多选框（checkbox）

适用场景：

当我们希望用户可以勾选多个选项时，单选就不够用了，比如：

• 消息推送支持的渠道：短信 / App / 微信 / 邮件


• 用户允许绑定的第三方平台：微信 / QQ / 微博


• 内容推荐的标签：热门 / 最新 / AI / 精选

多选框让这些“可以组合”的配置变得灵活，谁要开就勾谁，要多选就多选，不受限制。

示例配置：允许的推送渠道

我们来配置一个「支持的消息推送渠道」：

• 所属模块：系统配置


• 配置名称：推送渠道


• 配置 Key：push_channels


• 输入类型：多选框


• 默认值：app,wechat（多个值用英文逗号隔开）


• 参数说明：短信-sms|App-app|微信-wechat|邮件-mail


• 描述：平台支持的推送方式，可多选


• 排序值：0


• 是否启用：是

参数说明格式 & 默认值说明

• 参数格式：展示文本-值 用 | 分隔
  
  

  短信-sms|App-app|微信-wechat|邮件-mail
  
  

  
  


• 默认值：用英文逗号 , 隔开多个值，必须是参数里定义过的值
  
  

  app,wechat
  
  

  
  

配置项列表展示效果（后台页面）

配置添加完以后，在后台配置中心的列表中展示是这样：

每一项都根据类型展示了不同的 UI 组件，页面清晰、可读、可点、可编辑，操作起来一目了然。

而我们的数据库记录示例（config 表）存储为这样的：

每条记录都绑定了模块 ID（这里都挂在“系统配置”模块下），并且通过 input_type 字段区分了类型，param 字段为配置项的结构补充说明（下拉/单选/多选专用），desc 字段用于给配置者提示用途。

至于页面上的 UI 展示逻辑、预览区域怎么动态渲染、后端接口怎么接收和保存这些配置，我这边就不展开一一举例了。

说到底，这套配置中心的重点不是“多高级的交互”，而是“足够简单、稳定、好用”，让我们能快速落地配置项、快速修改参数，而不是天天写死在代码里改个值还要发版。

给产品和运营用的“安全编辑页”

配置项都建好了，页面也能预览，那产品和运营想调参数的时候，是直接去编辑配置项吗？

当然不能。

你想啊，运营只是想把推荐数从 100 调成 50，结果点到 key 了，把 recommend_range 改成 recommend_rang，那后端一拿不到值，整个推荐系统直接罢工了。

所以我们专门做了一套“参数调整页”，就像上图这样的界面，产品和运营只需要点点选项、输个值、开个关，完全不用接触 key 和底层结构，修改也更安全。

这个页面其实是对配置项的“业务层封装”——模块和配置项的创建，还是需要研发来做的。因为只有开发才能知道每个 key 该怎么在代码里接，哪些是支持实时生效的，哪些改了之后要重启服务，业务逻辑怎么走，这些都不是运营自己能处理的。

换句话说：

• 配置项创建时，研发定义 key + 类型 + 默认值 + 参数说明。


• 产品和运营后续修改时，只改值，不动结构，不容易出错。

那我们既然添加了配置项之后，下一步就是把它展示出来，让运营和产品能方便地修改配置、实时查看效果。

我们设计了一个专门的页面，用来承载这些配置项的「操作界面」。页面整体是按模块分 tab 展开的，每个模块下展示自己对应的配置项，表单类型跟配置项定义时保持一致，比如输入框、开关、下拉、多选等一应俱全。

如下图所示，就是我们系统初版配置模块下的实际页面效果：

当然如果某个模块配置太多我们也可以切换为纵向展示：

从上图我们可以看到：

• 每个配置项都有自己的「说明文案」，方便使用者理解配置含义；


• 类型化配置项有明确的 UI 控件，比如「每日推荐数量范围」就是滑动条；


• 实时编辑，保存即生效（根据配置项定义的类型和读取方式）；


• 页面左上角还能切换模块，快速定位。

这个页面是专门为非技术人员设计的，不需要他们懂 key 是什么，也不用关心类型怎么定义，他们只管调值就行了，一切都变得可控又安全。

有了这个配置页之后，产品和运营基本上就能脱离研发，自主修改参数了。接下来我们来聊聊配置值在后端是怎么被接入的。

配置中心只是“存”，真正怎么“用”还得看后端

配置中心做得再强大，最终目的还是要服务业务逻辑。

页面上填的那些 key 和 value 并不是为了好看，它们必须在后端代码里“用起来”，才算真正落地。

那后端是怎么接这些配置的呢？其实就两件事：

比如我们在后台新增了一个配置项：

key: enable_google_auth

value: 1

表示用户登录时是否开启 Google 验证。那后端代码里就可能是这样写的：

func ShouldUseGoogleAuth() bool {

    val := configService.Get("enable_google_auth")

    return val == "1"

}

而且每次新建一个配置项，一定要先让开发把读取逻辑写好，配置才能真正生效。不然页面配得再漂亮，后端代码不接，等于白改。

因此，我们建议配置项的新增一定要有“二次审核”机制——业务逻辑没走通之前，别急着让配置项上线。

配置读取：要读得快，还要改得稳

我们虽然只是做了一个小小的配置中心，但依旧严格遵守几个“配置铁律”：

所以我们最后的设计是：

所有配置值都先读 Redis，Redis 没有再查数据库，查出来的值再写回 Redis。

我们可以简单封装了一个方法来统一读取配置：

func (s *ConfigService) Get(key string) string {

    val, err := redisClient.Get(ctx, "config:"+key).Result()

    if err == redis.Nil {

        val = db.GetConfigFromDB(key)

        redisClient.Set(ctx, "config:"+key, val, time.Hour) // 缓存 1 小时

    }

    return val

}

这样做的好处：

• 性能好：Redis 读取速度快，尤其适合配置这种读多写少的场景；


• 调用方便：业务方不需要知道配置在哪，直接调 configService.Get()；


• 支持热更新：后台一改配置，Redis 一更新，后端逻辑立刻用上新的值。

配置改错了怎么办？我们加了「刷新机制」来兜底

想象一下，有个产品小哥在后台把短信通道从 A 改成了 B，然后 Redis 秒同步，结果是 B 接口根本没打通……

“线上短信全挂了”+“谁改的都不知道”+“运营拉着技术去机房单挑”

这事我们也不是没经历过。

为了防止“手滑即事故”，我们可以引入了 配置刷新机制。

也就是说，后台页面改配置只是“提交更新”，真正生效得靠一个“刷新动作” 。

我们可以设计一种配置刷新方案：保存 ≠ 生效，需要“手动刷新”才能同步

比如我们之前初版采用的模式，更保险一些：

优点是：

• 不怕误操作，有一步确认机会；


• 可接入审批流程；


• 所有操作都有记录，排查问题不含糊。

当然我们也可以设计一个“刷新 API”：

POST /api/config/refresh?key=xxx

POST /api/config/refresh_all

支持单个或批量刷新，用于后台管理或开发联调。

安全兜底机制

除了“刷新机制”，我们还需要做几件事：

总的来说呢，配置中心不是“你点保存我就给你改”，而是一个受控的配置发布系统。

读得快、改得稳、改完能溯源、有通知有审计——这才是一个靠谱的配置中心。

最后的碎碎念

说实话，这套配置中心，说难也不难，说重要吧，也不是业务核心。

但对我们来说，真的很刚需。纯粹就是日常工作中被“配置这点事儿”折磨太久了。 尤其是对业务开发流程不规范的公司来说。

以前在小公司，改个配置就得发版，发版就有几率中奖，一不小心就全服出事。久了大家都怕动，连产品都不敢随便提需求，说白了就是被流程和风险绑住手脚。

后来我们才想明白，像“推荐数量改一下”“开关先关一阵看看效果”这种，完全没必要动代码、改逻辑、走上线流程。给他们一个地方自己调就好了嘛。

所以这套配置中心，说不上啥高级架构，也不是啥大厂必备，但就是解决了我们日常那些“看起来不重要但天天遇到”的小问题。

业务推进更顺了，产品改需求也不再靠嘴说，技术也不用动不动上线连夜发包。这不比啥都强？

更多架构实战、工程化经验和踩坑复盘，我会在公众号 「洛卡卡了」 持续更新。

如果内容对你有帮助，欢迎关注我，我们一起每天学一点，一起进步。

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

Hello，兄弟们，我是V哥！

最近不少粉丝私信问我：“V哥，现在这行情卷得跟麻花似的，35岁危机就在眼前，你说咱们搞IT的，到了2026年还有出路吗？这技术迭代快得像坐火箭，我到底该往哪边押注？”

V哥我就一句话：焦虑个屁！机会全是给有准备的人留着的。

你们现在看是“寒冬”，V哥我看是“洗牌”。等到2026年，IT行业的格局早就翻天覆地了。那些只会写重复代码的“代码搬运工”确实该慌，但懂趋势、会借力的兄弟，那会儿绝对是香饽饽。

今天，V哥我就掏心窝子地聊聊，2026年咱们这行的几大“风口”。特别是最后两块大肉，听进去了，你下半年的年终奖就稳了。

一、 AI智能体开发：2026年的“新物种”

兄弟们，先把“ChatGPT”这种对话机器人放一边。V哥告诉你，2026年是AI智能体爆发的一年。

啥叫智能体？现在的AI像个博学的书呆子，你问它答。而智能体，那是带着“脑子”和“手脚”的打工人。它不仅能理解你的意图，还能自己拆解任务、自己去调用工具、自己反思纠错，最后把活儿干完了给你交差。

• 现在是： 你写代码，AI帮你补全一行。


• 2026年是： 你说“帮我做个电商后台”，智能体自己写代码、自己测、自己部署、甚至自己写文档。

V哥的研判：
到了2026年，不会开发智能体的程序员，就像2010年不会用智能手机的人一样落伍。你不需要自己去造一个大模型（那是大厂的事儿），你需要做的是做中间的“Controller”（控制器）。怎么用LangChain（或者那时候更牛的框架）把大模型串起来？怎么给智能体挂载API接口？怎么设计它的“记忆”和“规划”能力？

这块儿目前还是蓝海，谁能率先把“数字员工”搞定，谁就是那个省下百万人力成本的老板眼里的红人。

二、 鸿蒙开发：国产操作系统的“成年礼”

这块儿，V哥必须得敲黑板！这可能是未来几年里，中国普通程序员最大的红利期。

别总盯着Android和iOS卷了，那是存量市场，杀得头破血流。你看华为现在的动作，HarmonyOS NEXT（纯血鸿蒙） 已经切断了对安卓代码的依赖。这意味什么？意味着这不仅仅是换个皮肤，这是一套全新的、独立的生态！

V哥的预言：
到了2026年，鸿蒙不再是手机的配角，而是全场景（手机、车机、家电、工控）的霸主。

• 技术栈： 赶紧把ArkTS（Ark TypeScript）学熟了，ArkUI这套声明式开发范式非常顺手。


• 机会在哪？ 现在市面上大量的APP都需要重构鸿蒙原生版。这中间有一个巨大的缺口！前两年进去的那批人，现在都成技术总监了。2026年，随着万物互联真正落地，鸿蒙开发者的薪资会比同级别的安卓开发高出至少30%。

V哥我一直说，技术要跟着国运走。鸿蒙这条路，不仅是写代码，更是在参与基础设施建设。这碗饭，香！

三、 后端开发：告别“CRUD”，拥抱“编排”

兄弟们，别再笑话写Java/Go的后端枯燥了。虽然简单的增删改查（CRUD）真的会被AI干掉，但后端的逻辑核心地位永远不会动摇。

2026年的后端，不再是单纯的写接口，而是做“AI时代的管家”。

以前你的服务是给前端APP用的，2026年，你的服务大部分是给上面的“AI智能体”用的。智能体需要调用你的数据库、调用你的业务逻辑。你的接口设计得更规范、更原子化、响应更快。

V哥建议：
Go语言和Rust会在后端越来越火（因为性能好、并发强）。而且，后端得懂点云原生，容器化、Service Mesh（服务网格）这些都是标配。你得学会怎么把一个庞大的系统拆得碎碎的，还能用AI把它们管得服服帖帖。

四、 前端开发：从“画页面”到“造体验”

前端死了吗？V哥告诉你，前端才刚刚开始“性感”起来。

写HTML/CSS这种活儿，2026年估计UI设计师直接说一句话，AI就生成了。那前端干嘛？前端负责“交互的灵魂”。

随着WebGPU的普及，浏览器里能跑3D大作、能跑复杂的物理引擎。鸿蒙的ArkUI也是跨端的前端技术。未来的前端，更多是图形学、人机交互和3D可视化。你打开一个网页，不再是看图文，而是进入一个虚拟空间，这背后全是前端工程师的功力。

V哥一句话： 放下jQuery，搞深Three.js，搞透React/Vue原理，往图形学和全栈方向发展。

五、 嵌入式开发：软硬件结合的“硬核浪漫”

以前搞嵌入式感觉是“修收音机的”，2026年搞嵌入式那是“造智能机器人”的。

因为上面说的鸿蒙和AI，最后都要落脚到硬件上。智能眼镜、智能家电、自动驾驶，哪个离得开嵌入式？

重点来了： 嵌入式未来会和AI深度融合，叫TinyML（微型机器学习）。在芯片上跑小型的AI模型，让摄像头能识别人脸，让传感器能听懂声音。如果你既懂C语言底层，又懂一点AI算法部署，你是各大硬件厂抢着要的“国宝”。

六、 大数据开发：从“存数据”到“喂AI”

大数据没凉，只是换了个活法。

前几年大家搞Hadoop、Spark，是为了存日志、做报表。2026年，搞大数据主要是为了给AI当“饲养员”。

AI需要高质量的数据清洗、向量化处理。这就涉及到向量数据库、数据湖、实时计算流。怎么把企业的几十亿条数据，变成AI能看懂的“知识”，这是大数据工程师的新活儿。不懂AI的数据工程师，未来路会越走越窄。

七、 AI运维与 AI测试：机器管机器

最后说说这两个容易被忽视的领域。

• AI运维： 以前服务器报警了，运维兄弟半夜爬起来看日志。2026年，AI运维系统会自动定位故障、自动修复、自动扩容。运维工程师不需要敲那么多命令了，而是负责训练这个“运维AI”，制定策略。这叫SRE（站点可靠性工程）的进化版。


• AI测试： 测试不仅是找Bug，更是“攻防演练”。用AI去生成几万条变态测试用例去轰炸你的系统，甚至用AI去对抗AI生成的代码。只有AI才能测出AI写的Bug。

V哥总结一下

兄弟们，2026年其实并不远。

V哥我看了一圈，未来的趋势就两个字：融合。

• 鸿蒙是万物互联的底座，必须要抓；


• AI智能体是提升效率的神器，必须要懂；


• 其他所有的后端、前端、嵌入式、数据，都要围绕着这两者去进化。

别再纠结Java还是Python，Go还是Rust了。语言只是工具，解决问题的思路才是王道。从今天起，试着用AI去帮你干活，试着去了解一下鸿蒙的ArkTS，试着把你的工作流程“智能化”。

等到了2026年，当别人还在为裁员瑟瑟发抖时，V哥希望看到你已经站在风口上，笑傲江湖！

我是V哥，带你不仅看懂技术，更看懂未来。

目前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

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

最近一个月地铁上，输出内容几乎都围绕着某个主题，于是本篇内容当中都有小标题。

1、读什么书可以让人变得平静、淡定？

以我的经验——过去5年，读了一些书，整个人变得内敛沉稳安静很多——来看，似乎变化与某一本书的关系不大，而仅仅只关于持续阅读这件事，只要持续阅读，过个三五年，整个人便会平静、淡定许多。

我这结论，大概是很主观的，我一时说不太清变化如何发生，但我将尽量将发生在我身上的变化说清楚。

首先，我以为仅仅读一本书，是不能做到改变的，不管是认知还是行为，都不行。

以《学习之道》和《人性的弱点》为例。

《学习之道》，是一位世界冠军两次夺得冠军的个人传记，作者在书中分享了他的学习之道——一切都基于重复练习，练习过程中需要辅以热爱。读完本书前后几个月，我是真有按照作者的分享去行事的，篮球从微小动作调整，台球也一点一滴进步，但这些微小调整只持续两三个月便被抛之脑后。

《人性的弱点》，是教导与人为善的一本书。阅读当时的我，天天脸带笑意，认真倾听，耐烦讨论。但这些善良的特点，在几个月后也慢慢消退。

即从书中收获的认知影响自己一段时间行为后，并不能持续。

然后，是“几乎所有的书都是有关联的”。这些慢慢退化的认知，在后来的读书当中，又被强化与巩固。

《天才假象》也在说重复练习与热爱，《乔布斯传》甚至将热爱化作极致，《废邮存底》说读书写作如是。总之，这“基于热爱的重复练习是成功/熟练的必要条件”认知，慢慢在我内心变得巩固。

类似的认知，如沉稳、如安静、如三思而后行、如换位思考……都在读书当中慢慢变得巩固。被巩固的认知，会不自觉体现在行为当中，于是，便自然而然的平静且淡定了。

这过程无关某一本书，只在于持续阅读。

2、看过的人物传记当中，你最推荐的是哪一本？

我目前看过的人物传记，有这样几本：《曾国藩传》《人生随时可以重来》《从文自传》《一个瑜伽行者的自传》《乔布斯传》《漫漫回家路》《为奴十二年》《多余的话》《人生由我》《我的前半生》以及《我曾走在崩溃的边缘》。

这些书当中，我最喜欢的，是沈从文先生的《从文自传》，喜欢的缘由很简单，一是沈先生的文字简单真实且真诚，二是从这传记当中所感受到的安静与顽强。

对的，沈先生生命中的那些变化，在他的文字当中显得安静自然；顽强，则来自于安静背后的变化，那些变化（比如真正成为一个靠文字养活自己的作家），是需要很强生命力很强执行力的。

这些书当中，我最想要推荐的，是溥仪先生的《我的前半生》。

诚然，末代皇帝做过许多于中国很不好的错事，但他终于在人生后半段意识到自己错误并反省并给予后人以反省。

我自己读《我的前半生》过程，恰似以第一人称视角看正发生的历史。皇帝到底每天在想什么？皇帝失势后会怎样？

原来皇帝也慌张荒唐，皇帝也会焦虑到睡不着觉。

我想自己，看到了一位很真实的皇帝。

到全书最末尾，溥仪先生有体验到一种人生真谛，即“吃得下饭，睡得着觉”是人生最完美状态。看完全书，我是有感受到自己多出一种“任其自然”态度的：“既然连皇帝都追求吃饱穿暖睡好，为何我自己不珍惜正拥有的人生状态呢？”

《我的前半生》已经看了许久，好些即时体验记不太住，但当下这一刻，它是我看过人物传记当中最被推荐的那本。

3、今年看了哪些书？

今年读完的书，大概（不确定的意思，是其中有两本书大概是前些年读完但没记录的）是25本，它们分作这样几个类别：

心理学有《行为主义》《无条件养育》《十分钟冥想》《幸福的勇气》《甘于平凡的勇气》《爱的艺术》和《亲密关系》。心理学书籍，依然帮助我更好的认识自己。

历史有《秦谜》《五代十国全史》《细说宋朝》。这些书，我依然对照着《国史大纲》来看，我以为现在的自己，虽然依然记不住五代十国有哪些人、宋朝如何变化，但心中对这两个朝代是多出许多印象的，五代十国最黑暗，而宋积贫积弱。

传记以及记录自己或他人生活事的书有《闭经记》《我曾走在崩溃的边缘》《瓦尔登湖》《初老的女人》《沈从文评传》《我的老师沈从文》。

我依然喜欢看人物传记，我以为读人物传记这选择真不错，它们总给予我一种借鉴：我经历过的，前人也经历过。

关于沈从文先生的书，我新加入书架的还有《执拗的拓荒者》以及《沈从文全传》。

小说有《额尔古纳河右岸》《活着》《多情剑客无情剑》《长安的荔枝》。这几本小说，都短短的；《额尔古纳河右岸》和《活着》，我都哭着读完。

其它类别暂时只有一本，只是《人体简史》，这是一本很值得推荐的关于人体的科普书。

我正在阅读，或许在不久将来会读完的书，有《我看见的世界》《苏东坡新传》《李自成》《安娜·卡列尼娜》《金钱心理学》以及《高效能人士的七个习惯》。

4、电子书有哪些优点？

对我来说，现在电子书已经完完全全代替了纸质书。我买纸质书，更多只为“收藏”，我想要的，只是在某个比较闲散时间，找一找翻书的感觉。

对我来说，电子书相较纸质书有以下优点：

首先，也是最重要的那一点，电子书很方便。现在我已经在《微信读书》上连续阅读三年多（之前在《京东读书》连续阅读一年多），我的碎片时间——地铁上、卫生间、等电梯——都能拿出手机看书，使用手机读书，那许多的碎片时间都慢慢攒成帮助我进步的阶梯。

其次，基于碎片化阅读，电子书更容易帮助养成读书习惯。不管纸质书或者Kindle，身上多带一个设备，看书的门槛总是高了许多。

然后，是电子书相较纸质书便宜许多。我在微读的第一年，买一年付费会员只花168元，这会员可以阅读所有在微读上架的出版书。后来，微读开通了50块钱挑战赛（花50块钱，每天阅读持续一年，累积时长达到300小时），我便只需要50块钱，便能读成千上万本我想读的书了。

然后，是笔记与重新翻阅的方便。微读上面读书，可以在给予自己感触内容下方划线或者写上自己的即时感悟，这些感悟被收集在一起，可以搜索，可以直接定位。当书中内容记不太清需要回顾时，直接搜索笔记，直接搜索全书即可。

总之，电子书于我，是方便许多的。

5、一篇日记

现在时间是晚上的9点05分，我已经在回家地铁上前进两站。三站过后我要转车，我打算再去拼一拼下一趟列车的及时——在它关门之前——上车，我于是站在距离转站路线最近那个口子，只待列车到站。

我的右手边，大概是两个小学生（或者是初中生）正坐地上，他们的对话内容，我有听到两三句：

“那个别人刚走了的座位还是热乎的，如果坐了就会长痔疮。”

“我下一站就到红旗河沟了。反正没作业……反正没作业。”

对于今天的准时上车，我是很有些骄傲的。我似乎已经好久好久，没有9点准时下班。

（我跑过换乘路线，下一趟列车还有一分钟，今天的换乘计划成功了。）

今天的工作，又是和提示词作斗争的一天。

今天的新闻，大概只有一条：我的同事说，他的一位朋友从外地回重庆，Offer年包已经过了60。啊哈？所以重庆还是开得起工资的？

嗐！又有人在地铁上开很大声的外放，他应该正在玩某一种打枪游戏。

说起地铁外放，我想重庆和北京（上周去了北京出差）是真有一些差距的，我在北京一周坐地铁次数不多（大概五六七次），从没听到过手机外放，而重庆？每一趟地铁，我都得和外放侠做一点小小斗争：那些不能专心的时间，我总告诉自己“没关系的，不听不听”。

最近两天的晚饭，都是地铁口的一碗洋芋，7块钱。吃洋芋很快，于是我可以在晚饭时间向家里打几个电话。身体健康，就该是最高优的事情。

还有其它的应该记录的内容么？好像没有的。

不对，还有一条。

最近的读书时间，全部给了小说，一本是《安娜·卡列尼娜》，一本是《李自成》。这两本小说，都好长好长。

6、读书会忘记应该怎么办呢？

基于我现在的读书认知（过去五年日均阅读一小时多一点，读书类型多种多样，累积读完大概120本书）来看，我以为记住书中内容这件事，仿佛是可以不需要刻意追求的。

那些我们想要记住的，总能够印象不熄。

以《学习之道》里面的“Zone概念”为例，投篮不管怎么投都有，台球不管怎么打都进，全没有技巧，只凭借着一种感觉，这种感觉是可以有方法做到频繁进入的。

如何进入，带着热爱，练习不止即可。

还有些内容，是读过便忘记的，但这忘记的内容，可以通过一种简单的方法被记住。这简单的方法是不停地读，读相关联的书，看相关联的内容。

这内容当中的一个示例，是算法“快慢指针”，最初我并不知道如何探测链表是否循环，第一次刷题后也很快忘记。直到在《剑指Offer》《我的第一本算法书》《程序员面试金典》中多次强化，它被刻在脑子里。

我想自己，读过书当中可能超过99％，是都被我忘记的。这些被忘记的内容，如何能够被更好的记住，我知道的方法来自于《津巴多普通心理学》名叫“精细复述”，即将自己学到的知识，用自己的话认真地重新组织一遍，这件事做完，便能将知识记得更久些。

这样记住的内容，有“将愤怒或者悲伤写成文字，能够缓解自己的情绪”“记忆能力可以不随年龄变化，只需要一些组装技巧”……

最后，现在的我真的以为“读书想要记住”这件事是可以不强求的，只要不停看，外加一些思考，就好的。

7、推荐几本能够快速读完的小书吧？

看到这个问题，我脑子里冒出来两三本小书，它们都是我读完认为不错不厚甚至很薄的三本小书：《宝贵的人生建议》《受戒》以及《活出生命的意义》。

《宝贵的人生建议》，是一位老者（作者名字以及生平我并不能记住，记住的只是作者是一位六十多岁的老人）写给他子女以及孙辈的人生建议。每一条建议，都不长。

我记住的建议有好些，比如老生常谈的“种一棵树的最好时机是十年前，其次是现在”，比如“写不出文章时，假装以讲故事形式说给朋友听，当写完后删去朋友名字，便是一篇不错草稿”。（此处只是自己的复述，并非书中原文。）

我以为《宝贵的人生建议》是一本好书的缘由在于作者在末尾所说“书中建议恰似帽子，可能并不适用每一个人，选择自己喜欢的那顶就好”，即作者并不强迫读者接受他的认知。

不强迫，便是长者风范。

《受戒》是汪曾祺先生的短篇小说，我大概看完过不下五遍，全书很短，或许不到一小时便能读完。每一遍阅读，我都感受到一种简单的美好：明子和英子的爱情，唯美、自然，充满活力。

《活出生命的意义》，是一本短短传记，我从书中收获的认知有两个：

以上三本书，如果快一点，或许一两天内可以全部读完。但回味无穷。

8、怎样做到坚持阅读？

大概靠一点惯性，一点贪念，以及对书中内容的许多期待。

惯性，来源于过去五年的作息，以及用手机的习惯。

过去五年以来，我有两年半上班通勤是坐地铁的。地铁上的时间，都被我用来看书，这时间的看书，毫无心理负担。

上班路上：“我正要去公司干活呢，现在通勤路上肯定不会有人找。”

下班路上：“今天的事情已经都有了交代，看点轻松的书打发下时间吧。”

于是看书，专注且有趣。

当看书次数变多，很自然便会打开手机上的《微信读书》，于是再看两分钟。

贪念，也可以说成是对认知的渴求。五年以前，我想着靠自己的生活日记换取流量，只写两周便发现没了东西可写，于是找书来看。

我的看书，是为写作言之有物，是为更新（我给自己定下目标，不管是怎样内容，每周必须完成一篇更新）有内容可写，是为内容能够被人阅读换成收入。

于是看书，与写作相辅相成，世俗又带目的。

期待，是对书中内容最纯粹的期待，我仅仅想知道，书中那人物、事物、理论的未来是怎样的。

《崇祯传》里的崇祯怎么就亡国了？《安娜·卡列尼娜》里的安娜和弗隆斯基有未来么？《我曾走在崩溃的边缘》中俞敏洪老师是怎样不崩溃的？《也许你该找个人聊聊》当中心理咨询师每天都做些什么？

总之，那些无尽的期盼与好奇牵着我，看书不停。

9、糖醋排骨怎么做呢？

最近刚刚试过再做一次糖醋排骨，不脆，但依然有点好吃。制作步骤如下，每一步骤后面括号中是我当下存在的疑惑：

选排骨。（这一步很重要，上一次做时排骨都骨头中间肉包周边，成品好看许多。这一次买的打六折的排骨，成品则很不规则。）

排骨洗净焯水再用热水洗一洗。（这个步骤我从网上学来的，其实没掌握原理，也不确定不焯水味道是否不一样？焯水出锅后用冷水洗是否真的会柴？甚至焯水之后有必要洗么？）

锅中放油，小火放糖，把糖炒出糖色。（这个步骤我想自己油放多了些而糖放少了点，于是糖色不黑，排骨不甜。当然，没有饭店里面的甜，却似乎更符合自己的口味。）

下排骨，不停地翻翻翻翻，直到排骨有些焦黄。

下入没过排骨再深一指的热水，加入调味的盐、醋、酱油，焖。（什么时候放盐依然是一个问题，我看到一条高赞视频说提前放盐排骨会柴，但真正制作时，会忘记这注意事项。又由于没有天天做，于是不能验证。）

水快干，再翻翻翻，收汁。尝一下，不够甜再加一点糖。出锅，撒一点葱粒、红椒粒，增香增色。

最终成品，不嫩，有一点柴，有嚼劲，颜色不深，但依然好吃的。

下次做时的优化：少一点油多一点糖。

10、最近正阅读的书有哪些？

我最近正阅读的书，是这几本：

《李自成》和《崇祯传》，《安娜·卡列尼娜》，《高效能人士的七个习惯》，以及《亲密关系》。

目前《李自成》刚刚看到四分之一，我对于书中作者对崇祯的评价——刚愎自用、犹疑猜忌——不太相信，于是先读《崇祯传》。

《崇祯传》也正读到四分之一处，崇祯灭了魏忠贤，已经杀掉袁崇焕，现在不信任大臣，正启用宦官到各处监督。

现在崇祯给予我的印象，是勤劳皇帝做了一个错误决定（杀袁崇焕），以及身边帮手很不够。

《安娜·卡列尼娜》正听到六分之五处，基迪和列文正在莫斯科等待他们的第一个小孩出生；安娜和弗隆斯基在乡下生活，弗隆斯基感受到安娜限制着他，安娜刚刚给丈夫卡列宁写信申请离婚。

到现在，我以为安娜和弗隆斯基之间，似乎也并非是真正的爱情，在最初的激情、温情过后，当真正回到生活当中，他们的关系也是并不稳定的。或许安娜并不是出轨状态，此种情况会好一些？

《高效能人士的七个习惯》已经看到最后一个习惯——不断更新——了。虽然我对作者在书中的那些佐证并不很信服，但随着阅读时长增加，我以为这七个习惯是真有效的，它们是智慧，来自于生活、历史中积攒的经验。

《亲密关系》，我之前已经听完一遍有声书，现在刚刚读到第二章。我想要的，是在未来将这本书中内容理解的更多些。

对的，《亲密关系》看两遍的原因是，它是我超级推荐的一本书，我想自己理解更多些后再给出有理有据的推荐理由。

对的，书读第二遍，速度慢许多许多。

最近接到一个安卓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动画和交互设计开辟了新的可能性。
随着浏览器支持的不断完善，我们可以期待：

• 更丰富的动画效果


• 更简洁的代码实现


• 更好的性能表现