我们最近刚把一个后台系统从 element-plus 切成了完全自研组件，CSS 层统一用 Tailwind。全员同意设计稿一致性提升了，但代码里怨言开始冒出来。

这篇文章不讲原理，直接上代码对比和团队真实使用反馈，看看是谁在享受，谁在撑着。

1.组件内样式迁移

原先写法（BEM + scoped）：

<template>

  <div class="card">

    <h2 class="card__title">用户概览</h2>

    <p class="card__desc">共计 1280 位</p>

  </div>

</template>



<style scoped>

.card {

  padding: 16px;

  background-color: #fff;

  border-radius: 8px;

}

.card__title {

  font-size: 16px;

  font-weight: bold;

}

.card__desc {

  color: #999;

  font-size: 14px;

}

</style>

Tailwind 重写：

<template>

  <div class="p-4 bg-white rounded-lg">

    <h2 class="text-base font-bold">用户概览</h2>

    <p class="text-sm text-gray-500">共计 1280 位</p>

  </div>

</template>

优点：

• 组件直接可读，不依赖 class 定义


• 样式即结构，调样式时不用来回翻

缺点：

• 设计稿变了？全组件搜索 text-sm 改成 text-base？


• 无法抽象：多个地方复用 .text-label 变成复制粘贴

2.复杂交互样式

纯 CSS（原写法）

<template>

  <button class="btn">提交</button>

</template>



<style scoped>

.btn {

  background-color: #409eff;

  color: #fff;

  padding: 8px 16px;

  border-radius: 4px;

}

.btn:hover {

  background-color: #66b1ff;

}

.btn:active {

  background-color: #337ecc;

}

</style>

Tailwind 写法

<button

  class="bg-blue-500 hover:bg-blue-400 active:bg-blue-700 text-white py-2 px-4 rounded">

  提交

</button>

问题来了：

• ✅ 简单 hover/active 很方便


• ❌ 多态样式（如 disabled + dark mode + hover 同时组合）就很难读：

<button

  class="bg-blue-500 text-white disabled:bg-gray-300 dark:bg-slate-600 dark:hover:bg-slate-700 hover:bg-blue-600 transition-all">

>

  提交

</button>

调试时需要反复阅读 class 字符串，不能直接 Cmd+Click 查看样式来源。

3.统一样式封装，复用方案混乱

原写法：统一样式变量 + class

$border-color: #eee;



.panel {

  border: 1px solid $border-color;

  border-radius: 8px;

}

Tailwind 使用中经常出现的写法：

<div class="border border-gray-200 rounded-md" />

问题来了：

设计稿调整了主色调或边框粗细，如何批量更新？

BEM 模式下你只需要改一个变量，Tailwind 下必须靠 @apply 或者手动替换所有 .border-gray-200。

于是我们项目里又写了一堆“语义类”去封装 Tailwind：

/* 自定义 utilities */

@layer components {

  .app-border {

    @apply border border-gray-200;

  }

  .app-card {

    @apply p-4 rounded-lg shadow-sm bg-white;

  }

}

最后导致的问题是：我们重新“造了个 BEM”，只不过这次是基于 Tailwind 的 apply 写法。

🧪 实测维护成本：100+组件、多人协作时的问题

我们项目有 110 个组件，4 人开发，统一用 Tailwind，协作两个月后出现了这些反馈：

• 👨‍💻 A 开发：写得很快，能复制设计稿的 class 直接粘贴


• 🧠 B 维护：改样式全靠人肉找 .text-sm、.p-4，没有结构命名层


• 🤯 C 重构：统一调整圆角半径？所有 .rounded-md 都要搜出来替换

所以我们内部的结论是：

Tailwind 写得爽，维护靠人背。它适合“一次性强视觉还原”，不适合“结构长期型组件库”。

🔧 我们后来的解决方案：Tailwind + token 化抽象

我们仍然使用 Tailwind 作为底层 utilities，但同时强制使用语义类抽象，例如：

@layer components {

  .text-label {

    @apply text-sm text-gray-500;

  }



  .btn-primary {

    @apply bg-blue-500 hover:bg-blue-600 text-white py-2 px-4 rounded;

  }



  .card-container {

    @apply p-4 bg-white rounded-lg shadow;

  }

}

模板中统一使用：

<h2 class="text-label">标题</h2>

<button class="btn-primary">提交</button>

<div class="card-container">内容</div>

这种方式保留了 Tailwind 的构建优势（无 tree-shaking 问题），但代码结构有命名可依，后期批量维护不再靠搜索。

📌 最终思考

Tailwind 是给设计还原速度而生的，不是给可维护性设计的。
设计师爱是因为它像原子操作；
开发者撑是因为它把样式从结构抽象变成了“字串组合游戏”。

如果你的团队更在意开发效率，样式一次性使用，那 Tailwind 非常合适。
如果你的组件系统是要长寿、要维护、要被多人重构的——你最好在 Tailwind 之上再造一层自己的语义层，或者别用。

分享完毕，谢谢大家🙂

📌 你可以继续看我的系列文章

• 《用了三年 Vue，我终于理解为什么“组件设计”才是重灾区》


• 《我为什么觉得 React 正在逐渐失去吸引力？》


• 《为什么越来越多 Vue 项目用起了 UnoCSS？》


• 《为什么我放弃使用 Pinia？》


• 《为什么我不再相信 Tailwind？三个月重构项目教会我的事》

简单写个自我介绍。

我在团队里算不上的管理层，没有人事权，也不决定谁走谁留，但我参与的项目一旦出问题，最后都会落到我这里。进度卡住、需求反复、线上事故，会议上可以绕一圈再绕一圈，最终还是要有人把代码改完、把锅兜住。我清楚自己的位置，用武之地比较多的一个“多功能开发者”而已。还依稀记得，当初总部另外一个项目的入侵测，找的还是我，而不是再招一个人。

所以我很少参与评价人，只谈事，谈事实，谈项目是怎么一步步偏离轨道的。

先直接告诉大家结果吧，他被辞退了。

当初公司决定要不要这个人的时候，无意中跟我提到过。我只讲述了几个项目事故，以及其他同事和他合作时的态度。至于留不留他，我不想决定，也决定不了。

那个项目经理，其实并不“坏”。他不吼人，也不甩脸色，会议纪要写得很勤，群里回复永远是“收到”“我跟一下”。问题出在另一层面：需求变更没有留痕，风险评估永远是“可控”，节点延期总能找到外部理由。

上面看到的是一条被不断抚平的曲线，下面看到的是每天被推翻重来的开发计划。我们不是没提醒过，只是提醒被整理成了更好看的版本，再往上递的时候，已经失去了原本的锋利。当然，这些最后都会被归结为一句话——开发同学多努努力，多扩展下思维，补补这个缺点就好了。

但我认为，有些问题其实在内部一直被反复提起，只是从来没有被真正放到台面上说过。

团队里的其他项目经理，大多都有过开发背景。哪怕代码早就不写了，对功能复杂度、实现成本、技术边界心里都是有尺度的。评估的时候会留余量，也知道什么时候该踩刹车。

只有他完全没有开发经验，对一个需求的理解停留在“看起来不难”的层面。既怕自己显得不专业，又怕在会上被认为拖进度，于是每次评估都偏向最激进的版本，功能报得满，时间压到极限。

开发这边明知道不现实，那又怎么办呢？你能说得过他吗？况且领导也是只看结果，活干得快，公司赚得多，干得慢赚得少。所以开发也只能硬着头皮往前推。

一次延期还能解释成意外，两次三次之后，延期就成了默认选项。项目表面上在跑，实际上每一步都在透支客户的耐心。

他甚至能把一个月的功能，压成 7 个工作日。

结果显而易见。项目连夜上线，第二天直接崩溃：APP、小程序白屏，数据无法保存，ToC 的用户一个都打不开。我们凌晨 4 点发完版本，早上 6 点半问题出现，7 点钟起床开始处理。

我起床的时候就已经料到了。项目有他管控着，您就放一万个心吧，麻烦肯定少不了。

当时写功能的时候，有个同事请了丧假。他来了句逆天发言：“到时候你能把电脑带上吗？有事可以找你。”

我当时真想告诉他，兄弟，全公司不是只有他一个前端，这个项目也不是只有他一个前端。人家就请假 3 天，已经很紧张了，还让人把电脑带着，真特么丧良心。

真正的转折点，是那次 A 项目上线。

我没有提任何人的名字，也没有用情绪化的词，只是把时间线拉直：哪一天确认需求，哪一天推翻，哪一天出 PRD，哪一天出 UI，最终导致了什么结果。那份文档写得很长，不好读，也不“体面”，但它有一个特点——每一个问题，都自然地指向了同一个岗位职责。

我提交的时候，甚至没多想，只觉得这次总算把事情说清楚了。

事后我想过，如果我当初不写那份复盘，不跟领导说这些事，会不会结果不同。答案大概是否定的。项目不会因为沉默变好，问题也不会因为不点名而消失。

那天没人替他说话，并不是因为他人缘差，而是因为在那个位置上，他已经很久没有为任何人、任何结果，真正说过一句“这是我的责任”。

系统从来不需要情绪，它只是在某个时刻，停止了包容。

我后来也明白了一件事：在很多公司里，项目经理这个角色，本质上是一个缓冲层。缓冲需求、缓冲压力、缓冲管理层的焦虑。

但一旦缓冲只剩下过滤，没有承担，系统就会重新校准。

那天被裁的不是一个人，而是一种失效的角色设计。而这件事，迟早会发生在任何一个不再为结果站出来的位置上。

🎯 总结对比

1️⃣ TypeIt（超强大，推荐！）

🎉 特点：高自定义、易用、支持暂停、删除、换行等丰富动画

安装：

npm install typeit

# 或直接用 CDN

简单用法：

<div id="typeit"></div>

<script src="https://cdn.jsdelivr.net/npm/typeit@8.8.3/dist/typeit.min.js"></script>

<script>

  new TypeIt("#typeit", {

    strings: ["Hello, 掘金！", "我是打字机效果~"],

    speed: 100,

    breakLines: false,

    loop: true

  }).go();

</script>

2️⃣ Typed.js（最流行的打字机插件）

🚀 轻量、简单、社区大，支持多字符串轮播

安装：

npm install typed.js

# 或 CDN

用法：

<span id="typed"></span>

<script src="https://cdn.jsdelivr.net/npm/typed.js@2.0.12"></script>

<script>

  new Typed('#typed', {

    strings: ['欢迎来到掘金！', '一起学习前端吧~'],

    typeSpeed: 80,

    backSpeed: 40,

    loop: true

  });

</script>

3️⃣ t-writer.js（国人开发，API友好）

🔥 支持多种打字动画，API 设计简洁

安装：

npm install t-writer.js

用法：

<div id="twriter"></div>

<script src="https://cdn.jsdelivr.net/npm/t-writer.js/dist/t-writer.min.js"></script>

<script>

  const target = document.getElementById('twriter');

  const writer = new TypeWriter(target, {

    loop: true,

    typeColor: 'blue'

  })

  writer

    .type('你好，掘金！')

    .rest(500)

    .changeOps({ typeColor: 'orange' })

    .type('打字机效果轻松实现~')

    .rest(1000)

    .clear()

    .start()

</script>

4️⃣ ityped（极简小巧）

⚡️ 零依赖，体积小，适合极简需求

安装：

npm install ityped

用法：

<div id="ityped"></div>

<script src="https://unpkg.com/ityped@1.0.3"></script>

<script>

  ityped.init(document.querySelector("#ityped"), {

    strings: ['Hello 掘金', '前端打字机效果'],

    loop: true

  })

</script>

🛠️ 补充：用原生 JS 实现简单打字效果

如果你不想引入第三方库，也可以用 setTimeout/async 实现基础打字动画：

<div id="simpleType"></div>

<script>

  const text = "Hello, 掘金！这是原生JS打字机效果~";

  let i = 0;

  function typing() {

    if (i < text.length) {

      document.getElementById('simpleType').innerHTML += text[i];

      i++;

      setTimeout(typing, 100);

    }

  }

  typing();

</script>

🌟 结语

• 需要高级动画，选 TypeIt/t-writer.js


• 需要轻量简单，选 Typed.js/ityped


• 只需基础效果，也可以原生 JS 10 行搞定！

在经济下行的大背景下，越来越多的中小型企业开始放弃“前后端分离”的人员配置，开始采用“全栈式开发”的模式来进行研发费用的节省。

这方法真那么好吗？

作为一名从“全栈开发”自我阉割成“前端开发”的逆行研发，我有很多话想说。

先从一个活生生的真实案例开始吧。

我认识一个非常优秀的全栈开发，因为名字最后一个字是阳，所以被大家称为“阳神”。

1. “阳神”的“神狗二相性”

阳神当然是牛逼的。

他不仅精通后端开发，更是对前端了解的非常深。这样来说吧:

当他作为后端开发时，他可以是那群后端同事里库表设计最清晰，代码最规范，效率最高的后端。

当他作为前端开发时，他除了比几位高级别前端稍逊一点外，效率和UI还原性都非常高，还会主动封装组件减少耦合。

但是非常奇怪的事情总是会发生，因为一旦阳神不是全职的“后端”或者“前端”时，一旦让他同时操刀“后端+前端”开发任务，作为一名“全栈”来进行业务推进时，他的表现会让人感到惊讶：

他会写出设计糟糕，不规范，职责混乱的代码。

这个现象我把他戏称为“阳神”的“神狗二相性”，作为单一职责时他是“阳神”，同时兼任多职时，他就有非常大的可能降格为“阳狗”。

为什么呢？这是阳神主观上让自己写更糟糕的代码吗？

不是的兄弟，不是的。

这是系统性的崩塌，几乎不以人的意志为转移。换我去也是一样，换你去也是一样。

2. 分工粗化必然导致技术细节的差异

从前，在软件开发的古老行会里，一个学徒需要花很多年才能出师，专门做一把椅子，或者专门雕一朵花。现在，你被要求从伐木到抛光，从结构力学到表面美学，全部一手包办。

生产力在发展，对人的技能要求也在发展。

因此“分工细化”成为了工业革命之后完全不可逆的趋势。

在 IT 产业上也是如此。

“软件开发”经过多年被细化出了前端开发、后端开发、客户端开发、大数据开发 等等多种不同的细分职业。

但是现在有人想通过 粗化 职业分功来达到 “提效” 的目的，在我眼中这就是和客观规律对着干。

人的精力是守恒的。当你需要同时关心useEffect的依赖数组会不会导致无限渲染，和kubectl的配置能不能正确拉起Pod时，你的注意力就被稀释了。你不再有那种“针对一个领域，往深里钻，钻到冒油”的奢侈。

当你脑袋里冒出了一个关于前端工程化优化的问题时，身为全栈的你会本能地冒出另一个念头：

在整个全栈体系内，前端工程化优化是多么边角料且无关痛痒的问题啊，我去深入研究和解决它的性价比实在太低了，算了不想了。

如此一来，无论是后端的性能问题还是前端的性能问题都会变得无关紧要。

结果是，只有业务问题是全栈开发要关心的问题。

2. “岗位对立”与“自我妥协”

在日常开发中，前端开发和后端开发之间互相吐槽争论是再正常不过的话题，而且争论的核心非常简单易懂：

前端：这事儿不能在后端做吗？

后端：这事儿前端不能做吗？

可以的，兄弟，最后你会发现都是可以的，代码里大部分的事情无论是在浏览器端完成还是在服务器里完成都是可行的。

但是，总有一个“哪方更适合做”吧？

• 一个大屏页面的几万几十万条的数据统计，是应该后端做还是前端做？


• 业务数据到Echarts展示数据的格式转换应该后端做还是前端做？


• 用户数据权限的过滤应该后端做还是前端做？


• 一个列表到底要做真分页还是假分页？


• 列表已经返回了全量实体信息，为什么还要再增加一个详情接口？

这都是日常开发时前端和后端都会去争论思考的问题，身处不同的职位，就会引入不同的立场和思考。

• 前端需要去思考页面刷新后状态的留存，js单线程下大量数据处理的卡顿，页面dom树爆表的困境。


• 后端也需要思考并发下服务器资源和内存的分配，可能的死锁问题，以及用户的无状态token如何处理等。

前后端的“争吵”和观点输出是不可避免的。

真理总是越辩越清晰的，后续讨论出的结果多半是最有利于当前现状的。

但如果“前后端”都是同一个人呢？

全栈模式，完美地消灭了这种“有益的摩擦”。当你自己和自己联调时，你不会给自己提挑战灵魂的问题。你不会问：“这个API设计是否RESTful？”因为你赶时间。你也不会纠结：“这个组件的可访问性够好吗？”因为你还得去部署服务器。

这两种思想在你的大脑里打架，最终往往不是最优解胜出，而是最省事的那个方案活了下来。

于是，你的代码里充满了“差不多就行”的妥协。这种妥协，一两个无所谓，当成百上千个“差不多”堆积起来时，质量的基础就酥了。

内部摩擦的消失，使得代码在诞生之初就缺少了一道质量校验的工序。它顺滑地流向生产环境，然后，在某个深夜，轰然引爆。

3. 工程的“不可能三角”

软件开发领域有一个著名的“不可能三角”：

快、好、省，你只能选两样。

全栈模式，在管理者眼中，完美地实现了“省”（一个人干两个人的活）和“快”（省去沟通成本）。那么，被牺牲掉的是谁？

雪崩时，没有一片雪花是无辜的。但更重要的是，当结构性雪崩发生时，问责任何一片雪花，都意义不大。

至于“快、好、省”这三兄弟怎么选？

那主要看老板的认知和他的钱包了。

系列回顾（性能·错误·埋点三部曲）：不做工具人｜从 0 到 1 手搓前端监控 SDK

在前三篇文章中，我们搞定了性能、行为和错误的采集。但有掘友在评论区灵魂发问：“数据是抓到了，
发不出去有啥用？进电梯断网了咋办？页面关太快请求被掐了咋办？”

今天这篇，我们就来聊聊如何上报数据？

• 用什么方式上报最稳、最省事?


• 什么时候上报最合适?


• 遇到断网/弱网/关页怎么兜底?

一、上报方式与策略：如何选出最优解？

我们平时上报数据主要有三种方式：Image（图片请求）、sendBeacon 和 XHR/Fetch。

1. 三种上报方式详解

1. GIF/Image

这招就是利用图片请求（new Image().src）来传数据。

• 原理很简单：把要上报的数据拼在 URL 后面（如 https://log.demo.com/gif?id=123），浏览器发起请求，服务器解析参数拿到数据，然后返回一张 1×1 的透明GIF图（体积小、看不见），浏览器收到后触发 onload 回调即完成上报。


• 特点：天然支持跨域，绝无“预检”请求（因为是简单请求）。


• 局限：只能发 GET 请求，URL 长度有限（通常 < 2KB），无法携带大数据。

2. sendBeacon

• 原理：navigator.sendBeacon(url, data)。浏览器会将数据放入后台队列，即使页面关闭了，浏览器也会尽力发送。


• 特点：异步非阻塞（不卡主线程），且可靠性极高。


• 局限：数据量有限（约 64KB），且无法自定义复杂的请求头。

3. XHR / Fetch

普通的网络请求。

• 原理：使用 XMLHttpRequest 或 fetch 发送 POST 请求。


• 特点：容量极大（几兆都没问题），适合发送录屏、长堆栈。


• 局限：跨域时通常会触发 OPTIONS 预检（成本高），且页面关闭时请求容易被掐断（fetch需配合 keepalive）。

注: 所谓的预检，就是浏览器在发送跨域且非简单请求前，先偷偷发个 OPTIONS 问服务器：“大佬，我能发这个请求吗？”。只要你用了自定义 Header 或 application/json 就会触发。这会导致请求量直接翻倍，在弱网下多一次往返就多一分失败的风险。

2. 策略篇：如何组合使用？

怎么选并不是随意决定的，而是为了解决两个核心痛点：

基于这两个维度，我们将三种方式排个序，也就形成了我们的降级策略：

1. 首选方案：sendBeacon（六边形战士）

这是现代浏览器的首选方案。

• 优势：专为监控设计，页面关闭了也能发（浏览器将其放入后台队列）。


• 特点：容量适中（~64KB），且通常不触发预检，完美平衡了“存活”与“成本”。


• 适用：绝大多数监控事件。

2. 降级方案：GIF/Image（老牌救星）

当 sendBeacon 不可用（如 IE）或数据极小的时候用它。

• 优势：天然跨域，绝无预检。利用 new Image().src 发起请求，服务器返回一张 1x1 透明图即可。


• 特点：兼容性无敌，但数据量受 URL 长度限制（~2KB），且页面关闭时发送成功率低。


• 适用：PV、点击、心跳等轻量指标。

3. 兜底方案：XHR / Fetch

只有前两招搞不定时（数据量太大）才用它。

• 优势：容量极大，适合传录屏、大段错误堆栈。


• 劣势：跨域麻烦（需配 CORS），有预检成本。


• 注意：使用 Fetch 时务必加 keepalive: true，告诉浏览器“就算页面关了也别杀我”，尽量提升卸载时的成功率。

选型对比表

总结我们的代码套路（降级策略）：

下面是封装好的 transport上报函数，直接拿去用：

const REPORT_URL = 'https://log.your-domain.com/collect'; 

const MAX_URL_LENGTH = 2048;

const MAX_BEACON_BYTES = 64 * 1024;



function byteLen(s) {

  try {

    return new TextEncoder().encode(s).length;

  } catch (e) {

    return s.length;

  }

}



/**

 * 通用上报函数

 * @param {Object|Array} data - 上报数据

 * @returns {Promise<void>} - 成功 resolve，失败 reject

 */

function transport(data) {

  const isArray = Array.isArray(data);

  const json = JSON.stringify(data);



  return new Promise((resolve, reject) => {

    // 1. 优先尝试 sendBeacon

    // 注意：sendBeacon 是同步入队，返回 true 仅代表入队成功，不一定是发送成功

    if (navigator.sendBeacon && byteLen(json) <= MAX_BEACON_BYTES) {

      const blob = new Blob([json], { type: 'text/plain' });

      // 如果入队成功，直接 resolve（乐观策略）

      if (navigator.sendBeacon(REPORT_URL, blob)) {

        resolve();

        return;

      }

      // 如果入队失败（如队列已满），不 reject，而是继续往下走降级方案

      console.warn('[Beacon] 入队失败，尝试降级...');

    }



    // 2. 单条小数据尝试 Image (GET)

    if (!isArray) {

      const params = new URLSearchParams(data);

      params.append('_ts', String(Date.now()));

      const qs = params.toString();

      const sep = REPORT_URL.includes('?') ? '&' : '?';

      

      if (REPORT_URL.length + sep.length + qs.length < MAX_URL_LENGTH) {

        const img = new Image();

        img.onload = () => resolve(); // 成功

        img.onerror = () => reject(new Error('Image 上报失败')); // 失败

        img.src = REPORT_URL + sep + qs;

        return;

      }

    }



    // 3. 兜底方案：Fetch > XHR

    if (window.fetch) {

      fetch(REPORT_URL, {

        method: 'POST',

        headers: { 'Content-Type': 'text/plain' },

        body: json,

        keepalive: true, // 关键：允许页面关闭后继续发送

      })

        .then((res) => {

          if (res.ok) resolve();

          else reject(new Error(`Fetch 失败: ${res.status}`));

        })

        .catch(reject);

    } else {

      // IE 兼容

      const xhr = new XMLHttpRequest();

      xhr.open('POST', REPORT_URL, true);

      xhr.setRequestHeader('Content-Type', 'text/plain');

      xhr.onload = () => {

        if (xhr.status >= 200 && xhr.status < 300) resolve();

        else reject(new Error(`XHR 失败: ${xhr.status}`));

      };

      xhr.onerror = () => reject(new Error('XHR 网络错误'));

      xhr.send(json);

    }

  });

}

二、上报时机：不阻塞主线程干扰业务，断网了也不丢数据

1. 调度层：区分优先级，关键时刻不等待

不是所有数据都适合“攒着发”。我们需要根据重要程度将日志分为两类：

• 即时上报（Immediate）：收集到立即上报。
  
  
  
  
  • 场景：JS 报错阻断了流程、用户点击了“支付”按钮、接口返回 500 等。
  
  
  • 原因：这些数据对实时性要求极高，或者关系到监控系统的报警（比如线上白屏了，你得马上知道），不能因为攒着发而耽误了。
  
  
  
  


• 批量上报（Batch）：攒一波再发。
  
  
  
  
  • 场景：用户点击、滚动、性能指标、API 成功日志。这类数据量大但实时性要求低
  
  
  • 策略：“量”与“时”双重触发（竞态关系）。比如：攒够 10 条立马发（防止堆积太多），或者每隔 5 秒发一次（防止数量不够一直不发）。
  
  
  
  

代码怎么写？其实就是一个简单的双保险调度器：

let queue = [];

let timer = null;

const QUEUE_MAX = 10;

const QUEUE_WAIT = 5000;



function flush() {

  if (!queue.length) return;

  

  // 1. 把当前队列的数据复制出来

  const batch = queue.slice();

  

  // 2. 清空队列与定时器

  queue.length = 0;

  clearTimeout(timer);

  timer = null;



  // 3. 利用空闲时间发送（性能优化点）

  if ('requestIdleCallback' in window) {

    requestIdleCallback(() => transport(batch), { timeout: 2000 });

  } else {

     // 降级兼容

    setTimeout(() => transport(batch), 0);

  }

}



function report(log, immediate = false) {

  // 1. 紧急情况：绕过队列，直接发

  if (immediate) {

    transport(log);

    return;

  }



  // 2. 普通情况：进入队列（如 点击、PV）

  queue.push({ ...log, ts: Date.now() });

  

  // 3. 检查触发条件（双重保险）

  if (queue.length >= QUEUE_MAX) {

    flush();

  } else if (!timer) {

    timer = setTimeout(flush, QUEUE_WAIT);

  }

}



// 4. 临终兜底：页面关闭/隐藏时，强制把剩下的都发走

document.addEventListener('visibilitychange', function () {

  if (document.visibilityState === 'hidden') flush();

});

window.addEventListener('pagehide', flush);

整体思路：队列暂存 + 多重触发

我们用一个数组（queue）来暂存日志，然后通过 “量够了”、“时间到了”或“页面要关了” 这三个时机来触发发送，确保既不积压也不频繁打扰服务器。

性能优化：闲时优先

发送时，我们首选 requestIdleCallback。告诉浏览器你先忙你的（渲染、响应点击），等你有空了再帮我发监控数据

• 这样能最大限度减少对业务主线程的阻塞，让用户感觉不到监控的存在。


• 当然，如果浏览器不支持这个 API，我们再降级用 setTimeout 兜底。

2. 容灾层：断网了，日志怎么办？

如果在电梯里断网了或者弱网环境下，请求发不出去怎么办？日志丢了怎么办。
我们的策略是 “先记在本子上，等有网了再补交作业”：

具体怎么判断有没有网呢？

通常我们用 navigator.onLine 来看。如果返回值是 false ，那肯定是没网，直接存本地。

但坑就坑在，这玩意儿有时候会 “撒谎” —— 比如连上了酒店 WiFi 但没登录，或者宽带欠费了。这时候它虽然显示 true （在线），但其实根本上不了网。

所以咱们得留一手：
哪怕它说“在线”，我们也先试着上报一下。 要是报错了发不出去，别管三七二十一，先把这条日志存本地保底（千万别丢数据），然后再去 Ping 一下看看到底是不是真断网了 ，顺便更新一下网络状态。这样最稳。

1. 网络状态的检测

NetworkManager这个模块专门负责盯着网络，它很聪明，只有在发送日志失败的时候才会去复核网络真伪。

const NetworkManager = {

  online: navigator.onLine,

  

  // 初始化：盯着系统的 online/offline 事件

  init(onBackOnline) {

    window.addEventListener('online', async () => {

      // 别高兴太早，先看看是不是真的能上网

      const realWait = await this.verify();

      if (realWait) {

        this.online = true;

        onBackOnline(); // 真的回网了，赶紧补传！

      }

    });

    window.addEventListener('offline', () => this.online = false);

  },



  // “测谎仪”：发个 HEAD 请求看看

  async verify() {

    try {

      // 请求个 favicon 或者 1x1 图片，只要响应了说明网通了

      await fetch('/favicon.ico', { method: 'HEAD', cache: 'no-store' });

      return true;

    } catch {

      return false;

    }

  }

};

2. 核心上报：能发就发，不行就存本地

上报函数现在变得非常有弹性。

export async function reportData(data) {

  // 1. 如果明确知道没网，直接存本地 (省一次请求)

  if (!NetworkManager.online) {

    saveToLocal(data);

    return;

  }



  // 2. 尝试发送

  try {

    await transport(data);

  } catch (err) {

    console.error('上报请求失败:', err);

    

    // 3. 不管是因为断网、超时、还是服务器挂了

    // 只要没成功，第一件事就是存本地！保证这条日志不丢！

    saveToLocal(data);



    // 4. 然后再来诊断网络，决定后续策略

    // 只有当是网络层面的错误（如 fetch throw Error）才去怀疑网络

    // 如果是 500 错误，其实网是通的，不用 forceOffline

    if (isNetworkError(err)) {

       // 5. Ping 确认

        NetworkManager.verify().then(res => NetworkManager.online = res);

    }

  }

}



/**

 * 判断是否为网络层面的错误

 */

function isNetworkError(err) {

  // 原生 fetch 的网络错误通常是 TypeError: Failed to fetch

  // 如果是使用 Axios，则可以通过 !err.response 来判断

  return err instanceof TypeError || (err.request && !err.response);

}



const RETRY_KEY = 'RETRY_LOGS';

const RETRY_MAX_ITEMS = 1000;

function saveToLocal(data) {

  const raws = localStorage.getItem(RETRY_KEY);

  const logs = raws ? JSON.parse(raws) : [];

  logs.push(data);

  if (logs.length > RETRY_MAX_ITEMS) {

    logs.splice(0, logs.length - RETRY_MAX_ITEMS);

  }

  localStorage.setItem(RETRY_KEY, JSON.stringify(logs));

}

3. 补传逻辑：别把服务器干崩了

等到网络恢复，本地攒了一堆“欠账”，千万别一股脑儿全发过去（万一本地存了 500 条，一次全发会把服务器打爆的）。

我们要有节奏地补传：

async function flushLogs() {

  let logs = JSON.parse(localStorage.getItem('RETRY_LOGS') || '[]');

  if (!logs.length) return;



  console.log(`[回血] 发现 ${logs.length} 条欠账，开始补传...`);



  while (logs.length > 0) {

    // 1. 每次只取 5 条，小碎步走

    const batch = logs.slice(0, 5);

    

    try {

      // 2. 调用上报中心

      await transport(batch); 

      

      // 3. 只有成功了，才把这 5 条从 logs 里剔除

      logs.splice(0, 5);

      localStorage.setItem(RETRY_LOGS, JSON.stringify(logs));

    } catch (err) {

      // 4. 如果失败了（断网或服务器挂了）

      // 此时 logs 里面还保留着那 5 条数据，所以不用担心丢失

      // 记录一下状态，直接跳出循环，等下次 NetworkManager 唤醒

      console.error('补传中途失败，保留剩余欠账');

      break; 

    }

    

    // 2. 歇半秒钟，给正常业务请求让个道

    await new Promise(r => setTimeout(r, 500));

  }

}

三、总结与实战建议

监控上报这事儿看着不难，其实门道不少。要在数据不丢和不打扰用户之间找平衡，咱们得来一套“组合拳”：

最后，给开发者的 3 个避坑小贴士：

• 不要迷信 navigator.onLine：它只能判断有没有连接到局域网，不能判断是否真的能上网。一定要配合实际的请求探测。


• 控制补传节奏：网络恢复后，千万别一次性把积压的几百条日志全发出去，这属于“DDoS 攻击”自家服务器。要分批、甚至加随机延迟发送。


• 隐私与合规：上报数据前，务必对敏感信息（如 Token、用户手机号）进行脱敏处理，这是红线。

如果你有更好的思路，欢迎在评论区交流！

前言

大语言模型（LLM）在早期阶段主要以对话机器人的形式出现，用户通过自然语言向模型提问，模型返回一段看似智能的文本结果。这一阶段，模型能力的发挥高度依赖用户如何提问，同一个问题，用不同的描述方式，往往会得到质量差异巨大的结果。

在这种背景下，提示词工程作为一门面向大语言模型的输入设计方法论逐渐成型，本篇文章主要帮助大家快速了解提示词工程的本质以及在书写技巧。

什么是提示词工程？

提示词工程的本质就是在有限上下文窗口内，最大化模型输出的确定性与可用性，减少模型自由发挥的空间。简单来说，就是提供一种提示词书写范式来确保大模型能够精准地按照用户的要求输出高质量的内容。

❌ 差提示词

帮我做一个个人待办清单页面

对于这段提示词，AI 不知道用什么技术、什么风格、要哪些功能、有什么限制。结果就是 AI 自由发挥，生成的代码和项目规范不符合。

✅ 好提示词

## 角色

你是一个擅长 React 和用户体验设计的前端开发者。



## 背景

我需要做一个个人待办清单网页，用来记录每天的待办任务，现在已经完整基本功能的开发。



## 任务

实现任务的"拖拽排序"功能，让用户可以通过拖拽调整任务顺序。



## 要求

- 拖拽时被拖动的任务半透明

- 放置位置有明显的视觉指示线

- 拖拽完成后顺序立即更新



## 约束

- 技术栈为 React + TypeScript + Tailwind CSS

- 不使用第三方拖拽库（如 react-beautiful-dnd）

- 用原生 HTML5 拖拽 API

- 代码要有详细注释，我是拖拽 API 的初学者



## 输出格式

完整的 React 组件代码，包含：

1. 组件文件（TypeScript）

2. 关键逻辑的中文注释

3. 简单的使用说明

提示词常见问题

在实际使用中，提示词的质量参差不齐，以下是几类最常见的问题及其本质原因。

信息量过多

我想让 AI 帮我做一个待办清单应用，于是将所有想法一次性列出：

帮我做一个待办清单应用，要有添加任务、删除任务、编辑任务、

标记完成、设置优先级、设置截止日期、分类标签、搜索功能、

数据统计、导出功能，还要有暗黑模式，最好能同步到云端，

支持多设备使用，界面要好看，用 React 写，要有动画效果。

问题本质：无结构、无重点。AI 可能会忽略关键信息，输出与某些要求冲突。

信息量太少

我想让 AI 帮我写个按钮组件，只有一句需求，没有任何背景：

帮我写一个按钮组件

问题本质：缺少上下文。上下文可能是：

• 项目的技术栈


• 按钮需要的功能


• 期望的样式风格

最终 AI 只能给一个通用的结果。

没有目标

我想让 AI 帮我优化代码，但不给优化目标：

帮我优化一下这段代码：

[粘贴了一段代码]

问题本质：只有动作，没有结果。优化指代不明确——是体积、性能还是可读性？最终输出的结果必然不符合预期。

没有约束

我想让 AI 帮我写一个输入框组件，但是没有添加相关约束：

帮我写一个输入框组件。



技术栈：React + TypeScript + SCSS

问题本质：AI 容易引入额外的假设，例如：

• 使用不兼容的 ui 组件库，例如 antd。


• 使用复杂的状态管理机制。

导致最终输出不可控，隐性引入错误假设。

提示词模板

了解了常见问题后，我们需要一套结构化的方法来避免它们。这就是提示词模板的价值所在。

提示词的困扰

我们现在知道在使用 AI 时，提供的上下文越清晰，AI 给出的回答就会越符合预期。但是每次写提示词的时候，我们大概率还是会陷入这样的状态：

我要先给 AI 指定一个角色，告诉他背景和任务，还有约束、要求、技术栈……约束要包含什么内容？要求要写什么？技术栈要放到哪里？

这会给 AI 使用者带来很大的认知负担，我们同时要思考"说什么"和"怎么说"。而模板的价值，就是把"怎么说"变成固定格式，让你专注于"说什么"。

这与前端的开发框架（React/Vue）很类似：在没有框架之前，开发者既要关注业务，同时还需要关注 DOM 更新及性能问题；随着框架的推出，前端开发者能把更多的精力放到业务功能开发上。

模板目标

提示词模板的目标是减少使用者的思考负担并提高 AI 输出的稳定性。但模板并不是终极目标，因为固定的模板反而会限制灵活性。因此在不同阶段、不同场景，使用者可以对模板进行调整：

推荐模板

模板结构：

模板示例：

## 角色

你是一个擅长 React 和组件开发的的前端开发者。



## 背景

我使用 react 开发了一个基础组件库，里面包含了xx个组件，组件名称如下xxx。



## 任务

帮我为每个组件生成一份 mdr 文件，表示该组件的使用详细说明。



## 要求

- 文档要包含组件的 API、使用示例、xxx。



## 约束

- 使用 md 语法。

- 必须保证 API 的完整，不能漏掉内容。



## 输出格式

Title: 组件名称



description: 组件描述



API：

xxx



Examples：

xxx



## 示例



Title: Alert



description: 警示组件



API:



| 参数 | 说明 | 类型 | 默认值 | 版本 |

| --- | --- | --- | --- | --- |

| action | 自定义操作项 | ReactNode | - | 4.9.0 |

| afterClose | 关闭动画结束后触发的回调函数 | () => void | - |  |

| banner | 是否用作顶部公告 | boolean | false |  |

进阶提示词技巧

Few-shot Prompting

Few-shot 的核心思想就是给 AI 几个例子，让他先按照例子学习，理解任务处理流程及最终的内容输出。这种模式能够更高效的让 AI 理解用户的意图，这和人学习新东西一样，直接看示范比读文档更高效。

任务：为 React 组件生成 TypeScript Props 类型定义



示例1：

组件描述：一个显示任务标题的组件，标题必填，可选显示完成状态

输出：

interface TaskTitleProps {

  title: string;           // 任务标题，必填

  isCompleted?: boolean;   // 完成状态，可选

}



示例2：

组件描述：一个按钮组件，显示文字必填，点击事件必填，可选禁用状态

输出：

interface ButtonProps {

  label: string;           // 按钮文字，必填

  onClick: () => void;     // 点击事件，必填

  disabled?: boolean;      // 禁用状态，可选

}

示例虽然能够更高效的帮助 AI 理解任务，但是过多的示例也会加大 token 的消耗，因此示例不是越多越好，要遵循少而精的原则，通过 2～5 个例子将典型的场景、多样性场景以及边界场景列举出来。

Chain of Thought

Chain of Thought 的核心思想是告诉 AI 让他一步步思考推理，输出推理内容，而不是直接给答案。就像解数学题一样，把解题的每一步都写出来，这样往往能让 AI 输出更准确的答案。

## 角色

你是一个擅长 React 和组件开发的的前端开发者。



## 背景

我使用 react 开发了一个基础组件库，里面包含了xx个组件。



## 任务

帮我给修改的 react 组件补充新的单测。



### 修改点分析步骤

- 分析组件的 props，找出新增/删减/修改的参数，并输出出来。

- 分析组件的内部逻辑，找出新增/删除/修改的逻辑，并输出出来。

这种模式在复杂的场景中会大大提升输出效果，但是也存在一些局限：

• 输出内容的长度会大大增加，增加 Token 的消耗。


• 对于某些简单任务，强行使用该模式可能反而会降低效果。


• 如果推理的过程中某一步出错，可能会导致接下来步骤都会出错，需要配合 Self-Critique 来检查。

Self-Critique

与人类一样，AI 并非总能在首次尝试时就生成最佳输出，Self-Critique 的核心思想是在 AI 生成内容之后，让 AI 再自我检查一遍，发现并修复问题。这个和我们考试答题一样，做完之后再检查一遍往往能发现遗漏的细节或者写错的题。

## 角色

你是一个擅长 React 和组件开发的的前端开发者。



## 背景

我使用 react 开发了一个基础组件库，里面包含了xx个组件。



## 任务

帮我给修改的 react 组件补充新的单测。



## 修改点分析步骤

- 分析组件的 props，找出新增/删减/修改的参数，并输出出来。

- 分析组件的内部逻辑，找出新增/删除/修改的逻辑，并输出出来。



## 要求



- 生成完之后，请严格自查

	- 是否覆盖了所有修改点。

	- 每个修改点是否覆盖了所有边界情况（空值、空字符串、只有空格）

这种模式下会让 AI 扮演一个审查者的角色重新审下生成的内容，提高内容的准确性，但是也有它的局限：

• 增加 Token 的消耗，这种模式更推荐在复杂的场景中使用。


• AI 可能出现自我认可的偏差，认为输出是没问题的，此时需要严格给 AI 设定审查者的角色。

总结

本文围绕「提示词工程」展开，从背景、核心目标、常见问题、结构化模板，到 Few-shot、Chain of Thought、Self-Critique 等进阶技巧，系统性地说明了一件事：

提示词工程的本质，不是“如何把话说得更漂亮”，而是如何通过结构化上下文，降低大模型输出的不确定性。

然而，这种提示词优化的思路也带来了新的工程问题：提示词越来越长、结构越来越复杂，最终直接反映为 Token 体积的持续膨胀。

因此，在实际工程中，提示词优化并不等同于写得越详细越好，而是需要在信息充分性与 Token 成本之间取得平衡。如何控制上下文规模、避免无效信息堆积、并在复杂任务中持续提供刚刚好的上下文，成为提示词工程之后必须面对的核心问题。

参考资料

• OpenAI Prompt Engineering Guide


• Anthropic Prompt Engineering


• Few-shot Prompting


• Chain of Thought


• Self-Critique

提到 Zorin OS 这个操作系统，可能不少喜欢折腾 Linux 系统的小伙伴之前有尝试过。

作为一款以 UI 交互和颜值著称的 Linux 发行版系统，Zorin OS 也曾一度被广大爱好者们称为 Windows 系统的开源替代方案。

Zorin OS 旨在简单易用，用户无需学习任何新知识即可上手，同时 Zorin OS 作为一款 Linux 发行版系统，专为从 Windows 迁移的用户设计，提供类似 Windows 的图形界面与操作逻辑，并且支持一键切换为 Windows 系统风格。

前段时间，Zorin OS 团队在其官博正式宣布，最新的 Zorin OS 18 已经正式突破了 100 万次下载。

并且据官博数据显示，这些下载中有超过 78% 是来自于 Windows 系统的用户，这也再次印证了其可以满足从 Windows 桌面系统迁移到 Linux 发行版的用户需求。

作为一个长期关注 Linux 桌面系统的博主，其实这次 Zorin OS 18 大版本更新刚出来那会我就关注了，不过一直没有抽出时间来写文章、来梳理，所以今天这篇文章正好把这件事情给安排了！

总体来讲，这次的 Zorin OS 18 是以 Ubuntu 24.04 LTS 为基础并由 Linux 6.14 内核提供支持。

并且这次的 Zorin OS 18 是继之前 17 版本以来的一次大版本迭代，带来了诸多新特性和改进。

所以接下来我们也来梳理一下这次 Zorin OS 18 所带来的一些重点更新和变化。

视觉与交互进化

众所周知，Zorin OS 一直以来都以其独特的个性和简约的美学设计风格而著称。

那这次更新后的新外观给人最直观的感受就是圆润和通透。

任务栏这一次采用了全新的悬浮圆角面板设计，不再是死板地贴在屏幕边缘，而是像 macOS 的控制中心一样有一种轻盈的漂浮感。

另外这一次大版本还推出了新主题颜色，新增了黄色和棕色两种主题色，视觉层次更加丰富。

选中元素的色调更加淡雅，背景和侧边栏颜色更深，长时间盯着屏幕写代码或处理文档，眼睛会舒服很多。

另外 Pro 版里还提供了更多可切换的桌面布局。

除此之外，很多经常使用的日常应用也进行了诸多设计调整和改进。

比如文件管理器的侧边栏重新设计了，操作控件更直观，搜索功能支持了全文搜索，找文件效率大增。

日历应用增加了侧边栏，月份和事件视图也一目了然。

相机应用也做了更新，新相机应用界面简洁，支持多摄像头切换，这对于现在动不动就开视频会议的环境非常友好。

Web 应用深度集成

对于用户来说，最大的痛点往往不是系统本身，而是数据迁移和应用生态，那 Zorin OS 18 在这方面下了不少功夫。

首先就是与 Web 应用程序无缝集成。

众所周知，现在很多应用都构建在云端，这些渐进式 Web 应用与原生应用之间的用户体验正逐渐融合。

这次 Zorin OS 18 全新内置的「Web Apps」工具非常强大，它可以将 Web 应用转换为桌面应用，用户的 Web 应用将可以显示在开始菜单中，使用起来与原生应用无异。

「Web Apps」工具可以作为后端与各种热门 Web 浏览器集成，同时也允许用户自定义对应 Web 应用内的体验。

多任务处理：原生窗口平铺

这次 Zorin OS 18 的多任务处理变得好用多了。

Zorin OS 18 引入了一款功能强大的窗口平铺管理器，它能帮助用户更高效地工作，同时上手起来也十分简单。

用户只需要把窗口拖到屏幕顶部，系统就会自动弹出布局选择器。

预设布局支持左右分屏、三栏布局、角落停靠等，同时在智能建议这块，系统也可以根据用户当前所打开的窗口，智能推荐最佳的排列组合。

除此之外它还支持高度自定义，创建用户自己的平铺布局。

这个新特性无论对新手还是资深玩家都非常直观易用，从而定制和提升每个用户的生产力。

迁移神器：Windows 应用支持

用户可以从内置的软件商店发现适用于 Zorin OS 系统的各类应用，这是在 Zorin OS 中安装应用的推荐方式。

其软件商店可让用户开箱即用地从 Zorin OS 与 Ubuntu APT 仓库、Flathub 以及 Snap Store 安装应用。

而如果用户是刚从 Windows 转过来，看到满硬盘的 .exe 安装包肯定会头疼。

Zorin OS 18 的处理方式非常聪明。

系统内置了一个庞大的软件数据库（覆盖超过 170 款软件），当用户双击一个 Windows 安装包（如 setup.exe）时，系统不会直接报错，而是弹出一个友好的对话框。

如果有 Linux 原生版本，它就会引导你安装原生版本应用；如果没有原生版的话，它就会推荐你使用 Web 版，或者利用兼容层运行。

在兼容层优化这一块，Zorin OS 18 深度集成了 Wine，对于一些必须在 Windows 下运行的行业软件或游戏，它提供了一个“Windows 应用支持”层。虽然不能保证 100% 兼容，但对于很多老旧的 .exe 工具，它能让你在不装虚拟机的情况下应急使用。

性能与硬件支持

Zorin OS 18 基于 Ubuntu LTS 版本打造，同时它将获得直到 2029 年的稳定安全更新。

同时官方宣称它甚至可以在十几年前的古董机上流畅运行。最低配置仅需 1GHz 双核 CPU、2GB 内存。

同时从用户安装的实际表现来看，在现代硬件上，它的动画流畅度非常高，即便在老机器上，它运行起来也比 Windows 系统更加轻快。

写在最后

那以上就是关于此次 Zorin OS 18 大版本更新的一些梳理和总结，感兴趣的小伙伴也可以去体验一波。

总的来看，这次的 Zorin OS 18 不仅仅是一个 Linux 发行版，也像极了一个操作系统迁移解决方案。

另外这次 Zorin OS 18 的发布，也使得 Linux 桌面系统的易用性又向前迈进了一步。

文章的最后也期待 Linux 桌面系统在未来能百花齐放，发展得越来越好。

好了，那以上就是今天的内容分享了，希望能对大家有所帮助，我们下篇见。

注：本文在GitHub开源仓库「编程之路」 github.com/rd2coding/R… 中已经收录，里面有我整理的6大编程方向(岗位)的自学路线+知识点大梳理、面试考点、我的简历、几本硬核pdf笔记，以及程序员生活和感悟，欢迎star。

在日常的大前端需求开发中，我们常常需要同时兼顾UI还原和业务逻辑两部分工作。UI方面，就是要尽可能细致地还原设计稿上的每个细节；业务逻辑方面，则往往和需求复杂度以及项目代码规模正相关。今天，我们就来聊聊如何利用AI驱动，提升需求实现过程中的效率和体验。

UI设计稿还原

如今市面上已经有不少做得不错的AI设计稿转代码工具，比如v0、bolt.new、codefun等。对于一些个人独立项目来说，这些工具真心牛逼：只需传入设计稿，就可以快速生成模块化、精确的UI代码，而且还能通过对话式的交互来不断调整细节，直到完全符合预期。

但如果把这些工具直接应用于一个成熟项目中，就会暴露一些问题。首先，目前大部分工具主要支持vue和react，而我们的项目往往还涉及flutter、android、iOS等多端开发。其次，成熟项目中往往都有一套独特的代码规范和UI组件库，而这些工具生成的代码往往并不了解这些细节，直接将生成的代码拷贝进项目之后还得二次调整，额外的成本不可忽视。

那么有没有办法既能支持更多编程语言，又能在生成UI代码时就结合项目中已有的规范和组件库，从而减少二次调整成本呢？答案是有的！

目前，figma是市面上使用比较主流的设计稿工具。Builder.io最近发布了一款基于figma设计稿、AI驱动的前端代码生成插件——Visual Copilot。使用它，你只需要把figma切换到Dev Mode，然后选择设计稿中的任意图层，接着在Visual Copilot中直接导出代码。

Visual Copilot生成的代码不仅支持vue、react，还涵盖了其它几乎所有主流的大前端语言和框架，十分全面。你可以实时预览生成的效果，并进行细节调整，直到满意为止。

生成代码后，如何让这些代码完美融入到我们的项目规范中呢？ 这里就需要结合Visual Copilot与Cursor的配合来实现。

具体做法是：当Visual Copilot将设计稿图层转化成代码后，它会自动生成一个可远程执行的工作空间，并提供相关命令(图中红框所示)将工作空间的代码集成到我们项目中。

接下来，我们只需在Cursor的Terminal中运行指定指令，就能连接Visual Copilot的远程工作空间，实时获取生成的代码，同时通过交互指令界面明确我们后续的需求。

那么，最终生成的代码如何与项目中的各种规范结合呢？ 这就要用到Cursor的AI规则机制——CusorRules。你只需在项目根目录下配置一个.cursorrules文件，声明你的UI代码规范以及封装的组件信息。Cursor在生成代码时就会充分参照这些规则。同时，新版Cursor还支持配置一系列rule文件，你可以通过正则路径来指定规则应用于不同的模块或文件类型，整个过程非常灵活高效（具体可以参与Cursor官方文档）。

业务逻辑开发

在一些中小型规模的项目中，如果想在Cursor中高效地实现业务逻辑，我们需要关注两个关键点：

• CursorRule的应用
  
  和上文UI的规范梳理类似，我们还需要对项目各模块的架构规范等信息进行说明，这样可以让Curosr生成的代码能尽量保障和我们项目规范的一致性。


• 需求拆解：先构建框架，再处理细节
  
  对于较为复杂的需求，我们可以先把实际需求拆解成多个阶段。首先，构建大致的需求框架，并转换成一系列对Cursor友好的Prompt指令（要求简单、准确）。在Cursor的Compose Agent模式下，通过这些指令生成整体的业务逻辑框架。接下来，再利用Cursor Tab在编辑器区域快速完善那些生成时不够精准的细微逻辑。

在一些中小型项目中，通过以上两个关键点我们通常可以快速完成业务逻辑开发。但在一些大型项目中，会遇到Cursor生成的代码经常不尽如人意的问题。这主要是因为项目越大，整个代码库的复杂性增加，Cursor对项目的理解难度也随之上升，每次修改都可能会有不确定因素，提示词如果不能准确描述需要改动的部分，就容易出错。

此时，我们可以尝试另一种思路：用”软件架构师“与”开发者“角色区分需求规划与执行细节。应该怎么做呢？

我们可以将AI驱动的开发流程分为两个阶段：

这种方式的好处在于，只要“软件架构师”生成的提示词足够精准（即它能详细说明需要修改的文件、具体的改动内容和改动范围），那么“开发者”便能够依照这些提示词精确地进行代码修改，极大降低了因大范围理解产生的错误风险。所以这里的性能瓶颈就在于如何定义”软件架构师“角色以及让其接到需求后能生成精确的提示词。

在实际操作中，我们引入了一个“项目地图”的概念。所谓项目地图，就是为大型项目构建一个完整的文档体系（借助AI辅助生成也完全可行），其中包括了项目架构设计、开发流程、模块划分与用途、文件名和其功能说明等内容。这套文档体系可以独立于一个实际的Cursor项目存在，充当“软件架构师”的角色。也就是说，当遇到bug或新需求时，我们可以通过咨询这个“项目地图”，让AI回答问题并给出相对准确的修改思路。

举个例子，拿知名的fast-api项目来说，我为它生成了一个项目地图，其中包含了核心概念说明、系统设计、项目规范以及各模块和文件的用途说明等内容：

同时，在该项目的 .cursorrule 文件中，我详细规定了“软件架构师”如何根据实际需求生成精确的修改指令：

## 项目背景信息

项目名称：FastAPI

项目类型：Python Web 框架

项目地图：参考 fileNames.md

架构文档：参考 architecture/ 目录

编码规范：参考 guidelines/coding-standards.md



## 需求分析模板

1. 需求描述

[简要描述需要实现的功能或修改]



2. 涉及组件

- 核心组件：[列出受影响的核心组件]

- 依赖组件：[列出相关的依赖组件]

- 测试组件：[列出需要修改的测试]



3. 修改范围

- 主要文件：[列出需要修改的主要文件]

- 次要文件：[列出可能需要修改的次要文件]

- 文档文件：[列出需要更新的文档]



4. 技术要点

- 使用的框架特性：[列出需要使用的 FastAPI 特性]

- 数据验证：[描述数据验证要求]

- 兼容性考虑：[描述向后兼容性要求]



5. 潜在风险

[列出可能的风险点和注意事项]



## 执行指导模板



### 给大模型的执行指导



1. 修改步骤

[详细的步骤说明]



2. 验证点

[列出需要验证的关键点]



4. 测试建议

[提供测试建议和用例]





## 实际案例：添加用户电话号码字段



### 1. 需求分析



需求描述：

在用户模型中添加可选的 phone_number 字段，并在相关 API 端点中支持该字段。



涉及组件：

- 核心组件：用户模型（UserIn, UserOut, UserInDB）

- 依赖组件：无

- 测试组件：用户相关测试



修改范围：

- 主要文件：/docs_src/extra_models/tutorial001.py

- 次要文件：无

- 文档文件：API 文档可能需要更新



技术要点：

- 使用 Pydantic BaseModel

- 字段类型：Union[str, ]

- 保持向后兼容性



潜在风险：

- 确保不破坏现有的数据验证

- 保持与现有字段风格一致





### 2. 执行指导

给大模型的具体修改指导：



1. 修改步骤：

   a. 在 UserIn 模型中添加 phone_number 字段

   b. 在 UserOut 模型中添加对应字段

   c. 在 UserInDB 模型中添加对应字段

   d. 确保字段定义与 full_name 保持一致的风格





2. 验证点：

   - 字段是可选的

   - 类型提示正确

   - 与现有代码风格一致

   - 不影响现有功能



3. 测试建议：

   - 测试不提供电话号码的情况

   - 测试提供有效电话号码的情况

   - 测试提供无效数据的情况



## 使用说明



1. **分析阶段**

   - 使用项目背景信息了解上下文

   - 按需求分析模板进行分析

   - 生成详细的执行指导



2. **交付阶段**

   - 将执行指导传递给大模型

   - 确保指导清晰且可执行

   - 包含必要的验证点



3. **验证阶段**

   - 检查实施结果

   - 确认所有要求都已满足

   - 验证代码质量和一致性



4. **输出**

   - 输出执行指导，包括修改步骤、验证点和测试建议，新建analysis目录，在该目录下用一个独立的文件承载，文件名要求符合问题描述诉求<cursor-tools Integration>

# Instructions

基于这些配置，当提交需求时，AI生成的修改思路大致如下，它会精准指出应对哪些文件进行哪些具体改动。

# 需求分析



## 1. 需求描述

在高并发场景下，针对大量用户同时请求数据库导致的性能瓶颈，需要在应用程序中增加缓存机制，降低数据库查询次数，提升整体响应速度和系统稳定性。



## 2. 涉及组件

- 核心组件：数据查询相关业务逻辑（可能涉及CRUD操作的函数或类）

- 依赖组件：可能需要引入第三方缓存库（如 redis、in‐memory 缓存等）

- 测试组件：与数据库查询逻辑相关的测试用例



## 3. 修改范围

- 主要文件：核心业务逻辑所在模块（例如：/app/database.py 或 /app/services/xxx.py）

- 次要文件：如果需要封装缓存工具，则可能新增 /app/utils/cache.py

- 文档文件：如果提供额外的缓存配置，需要更新相关文档



## 4. 技术要点

- FastAPI 配合缓存解决方案（如 in‐memory 缓存、Redis、memcached 等）

- 选择合适的缓存失效策略（LRU、TTL、手动失效等）

- 线程安全、进程安全或分布式缓存方案

- 保证与现有数据校验和返回结构的一致性



## 5. 潜在风险

- 引入缓存后数据一致性问题（可能出现短时间的数据延迟）

- 缓存过期策略不当导致性能问题或脏数据

- 多节点部署时的缓存同步与一致性

- 第三方库的稳定性和可维护性



---



# 执行指导



## 1. 修改步骤

1. 确定缓存方案（例如：Redis 或者内存缓存），并根据业务需求配置失效策略。

2. 在核心数据库查询逻辑中添加缓存查询逻辑：

   - 查询前先在缓存中查找数据；

   - 如果未命中或缓存过期，则查询数据库并将结果写入缓存；

   - 如果命中，则直接返回缓存结果。

3. 为关键业务接口添加缓存逻辑（可封装成一个装饰器，或在查询函数内部实现）。

4. 在配置文件或环境变量中添加缓存相关配置，如主机、端口、缓存大小、过期时间等。

5. 编写或修改测试用例，确保在开启缓存后仍能正确测试业务逻辑。



## 2. 验证点

- 并发请求多时，数据库查询数量显著减少

- 当缓存命中时，响应速度显著提升

- 缓存失效策略（TTL 等）按预期生效

- 高并发情况下是否存在数据不一致或缓存击穿/雪崩问题



## 3. 测试建议

- 正常请求：依次验证在缓存未命中和命中时的响应时间与结果正确性

- 并发请求：使用压力测试工具（locust、JMeter 等）模拟大量请求并观察数据库查询次数与响应时间

- 失效测试：设置短 TTL 并观察缓存自动失效后对系统性能的影响

- 异常测试：故意使缓存服务不可用或网络异常，验证系统能否正常回退到直接查询数据库

随后，我们再将这些详细的提示应用到原项目中，通过AI进一步生成或补全代码，最终大大提高了开发效率和代码准确性。只要前期对项目地图、架构角色和开发规则进行充分准备，我们就能充分借助AI，把原本耗时、易出错的开发流程变得高效且精准。

结语

显而易见，尽管上文主要探讨了大前端领域的AI工作流，但这种思路其实完全可以迁移到其他开发领域。只要我们不断尝试和实践，总结出符合自身业务特点的AI工作模式，就能极大提升我们的工作效率。无论是前端、后端，还是其他技术领域，AI驱动的开发流程都能帮助我们更加精准、高效地解决各类需求和问题。

总之，拥抱AI技术，不断优化工作流程，是我们应对快速变化、不断增长的项目复杂度的关键所在。未来，随着技术的进一步成熟和实践经验的积累，我们必将迎来一个更智能、更高效的开发时代。

你有没有过这样的经历？
没登录淘宝逛了件卫衣，转头刷抖音、B 站，相似款式的推荐就精准找上门；
或者参与线上投票时，明明没注册账号，却提示 同一用户仅能投一次？

其实这背后藏着一个前端人绕不开的实用技术，浏览器指纹。哪怕你开着无痕模式、频繁切换网络，它依然一样精准识别你，而这门技术，不仅是日常上网的隐形推手，更是前端求职面试中的高频考点

一、浏览器指纹：到底是怎么认出你的？

核心逻辑很简单：世界上没有完全相同的浏览器环境，就像没有两片一模一样的树叶。

浏览器指纹会收集一系列设备和环境特征，再通过算法组合成唯一的 哈希值，这个哈希值就是你的专属 网络标识。这些特征包括但不限于：

• 基础信息：浏览器类型及版本 Chrome、Safari 等、操作系统Windows/macOS 等、屏幕分辨率、系统语言；


• 硬件细节：CPU 核心数、内存大小、显卡型号；


• 高级特征：Canvas 绘图差异 不同设备绘制同一图形，像素级有细微区别、WebGL 渲染信息、已安装字体列表；


• 动态信息：IP 地址 虽可变，但结合其他特征仍有识别价值。

举个直观的例子：Canvas 是 HTML5 的绘图功能，我们用一段简单代码就能提取它的指纹可直接在浏览器控制台运行：

function getCanvasFingerprint() {

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

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

  const text = 'frontend-fingerprint';

  

  ctx.textBaseline = 'top';

  ctx.font = '14px Arial';

  ctx.fillStyle = '#f60';

  ctx.fillRect(0, 0, 100, 60);

  ctx.fillStyle = '#069';

  ctx.fillText(text, 2, 15);

  

  return canvas.toDataURL();

}



function hashFingerprint(str) {

  let hash = 0;

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

    hash = (hash << 5) - hash + str.charCodeAt(i);

    hash |= 0;

  }

  return hash;

}



const dataUrl = getCanvasFingerprint();

const fingerprint = hashFingerprint(dataUrl);

console.log('Canvas指纹结果：', fingerprint);

试着在不同浏览器、甚至不同设备上运行，你会发现每次得到的数值都不一样

这就是浏览器指纹的识别核心。

二、前端人必须掌握的应用场景

浏览器指纹不是 黑科技，而是前端开发、风控、产品设计中高频用到的技术，面试时遇到相关问题，能说清这些场景直接加分：

对于前端求职者来说，这些场景不仅是面试高频题，更是实际工作中可能遇到的开发需求。如果能在简历中体现对浏览器指纹的理解，或在面试中清晰拆解实现逻辑，很容易让面试官眼前一亮 ，但很多同学要么不懂核心原理，要么不知道怎么把技术点转化为面试优势。

四、最后说句实在的

浏览器指纹是前端领域的 实用 技术，懂它不仅能解决实际开发问题，更能成为求职路上的加分项。但求职不止是懂技术，更要会 表达技术， 简历怎么写才能脱颖而出？面试怎么说才能打动面试官？这些都需要技巧和经验。

如果你正在为前端求职发愁，想让自己的技术优势被看到，不妨试试我的「前端简历面试辅导」和「前端求职陪跑」服务。从技术亮点提炼到面试答题技巧，从简历优化到 offer 谈判，我会全程帮你针对性提升，让你在众多求职者中脱颖而出，顺利拿下心仪岗位

大家好，我是 Sunday。

现在，用 AI 写代码，已经不算什么新鲜事了。写个组件、补个函数、改个 Bug，几句话交给模型就能搞定。

但是，大家有没有想过一个问题：如果我不只是用一个 AI，而是用一群 AI，会发生什么？

我们现在用 AI，本质上只是把它当成“高级工具”，即：我遇到问题 → 我问 AI → 它给我答案。

那么如果我们把脑洞放大一点呢？

既然我可以调用一个 AI，那是不是也可以 同时调用多个 AI ？既然 AI 可以写代码，那它是不是也可以完成：产品经理、设计师、测试、运维，甚至是 财务、人事 的工作？

换句话说： 我能不能，用一群 AI，组建一家“只有我一个人类员工”的公司？

多个 AI，各自承担不同角色：

• 产品负责拆需求：告诉产品我的需求，然后产品帮我把需求拆解成可以具体执行的步骤


• 开发负责编码：把具体的步骤告诉开发，开发负责把整个功能落地


• 测试负责验收：开发的代码，交给测试进行验收。验收失败则重新打回开发，开发负责修改 BUG


• 运维负责部署：最终完成的项目，运维负责部署上线，构建整个自动化部署的流程


• 财务负责算账：每天的 token 支出 和 营收，并给出更省钱的财务方案


• 人事负责管理：哪个 AI 员工“不合格”，人事负责把它“开掉”，并根据我的需求重新“招聘（生成）”新的 AI 员工

并且，我还希望它们之间可以独立思考，互相沟通，而我只负责：下目标、做决策。

如果这件事真的可行，那意味着什么？意味着一个人，或许可能真的可以撬动一整家公司级别的生产力。

说干就干。

AI 选择

市面上的 AI 模型已经非常多了：Claude、GPT Coder、Gemini、GLM、DeepSeek。。。有的贵，有的便宜，有的擅长推理，有的擅长编码。

最理想的状态其实很明确：

• 贵的 AI，承担复杂任务：产品设计、系统架构、核心编码


• 便宜的 AI，承担简单任务：统计、对账、流程、输出财务报表

只要这些 AI 之间可以互相沟通，以上这些都不是问题。

但是，Sunday 在经过一系列的测试之后，发现了一个很残酷的事，就是 不同模型的 AI 之间完全无法沟通。特别是不同厂商的 AI，每一个都被作为了独立的个体。虽然可以通过“协调者”方式强行拼接，但是实现复杂，并且效果也不理想。

额。。。好像这个一人公司的梦想就直接破灭了...

不行，不能那么容易放弃。

所以，在第一阶段，我只能选择一个更“粗暴但稳定”的方案：全部使用 Claude。

因为 Claude 提供了一个非常关键的工具：Claude Code：一个运行在纯终端里的 AI 编码智能体。我们只需要打开终端就可以直接通过语言对话的方式调用 AI 模型。

而接下来，我要做的事情是：用 Claude Code，一步步搭出一家“AI 员工公司”的雏形。

启动多个 AI 终端

一个终端窗口作为一个员工，如果我们想要多个员工那么就只需要启动多个终端就可以。然后我们要给他们赋予角色。一开始，我们可以先从最小可行方案开始：

我们先制定两个角色，他们分别是：

• 张三：产品经理


• 李四：程序员

然后，就出现了 大型翻车现场....

在我尝试给 Claude 提示词，让他变成 张三 的时候。Claude 给我的回复是：我是 Claude，我不是张三....

不是，咱说好的玩角色扮演呢...你就这么不配合的吗？

因为在我的设想里，这一步应该是最简单、最“理所当然”的：起个名字、设个背景、分配个角色。然后 AI 就会自动进入对应的工作模式。

结果现实就是这么现实：“我能帮你完成工作，但是我就不承认我是张三，我就是 Claude”

这不是能力问题，这赤裸裸的就是个 态度问题 啊！ 看来 AI 也不想当牛马啊。。。

没办法，我只能尝试修改下提示词：

好的，产品经理已就位。然后我们可以从一个小的 todolist 的需求开始：

现在我们已经有了一个 todolist 的需求文档了。接下来最好的方案就是 产品经理的 AI 可以直接通知 程序员 AI，完成代码实现。

但是，可惜 不同窗口之间 AI 无法直接通讯。所以，我就必须要承担起这个通讯员的角色。

最终实现的效果如下：

整个功能完善、可用。并且还提供了 主题变化 的功能。。。

反思

可是如果我们仔细去分析上面整个流程，我们可以发现：这个流程远没有我们想象的那么顺畅。甚至有点 多此一举。

因为以上这些需求完全可以在一个 Claude code 中完成，没有必要进行这样的划分。甚至可以说：在任务简单时，多 AI 协作不仅没有提升效率，反而增加了沟通成本。

而这样的一种调度+协作的方式，如果任务变得复杂了，恐怕 AI 没有乱呢，我们自己就已经先手忙脚乱了。

这让我开始怀疑：最初设想的这种全 AI 员工的方式，会不会从一开始，就是错的？

但是，当我仔细思考过之后，我发现问题不在于“多角色”这个想法本身，而在于：当前这种“多终端 + 人工调度”的协作方式，本质上是一个非常低效的协作模型。

如果我们换一个角度，从“协作工具”入手，情况可能会完全不同。

这时，我注意到了一个开源项目：vibekanban。

它提供了一种非常典型的多人协作看板模式，和我们熟悉的 Teambition、Jira、Trello 几乎一致，包含了：任务可视化、状态流转清晰、每个角色只关注自己的列

通过 vibekanban 这种工具，我们至少可以做到：多任务并行更清晰、角色边界更稳定、协作过程可追踪、可回溯。

但即便如此，我很快又意识到一个更现实的问题：这，依然离“全 AI 员工的一人公司”，依旧差得很远。

全 AI 员工的难点在哪里？

根据 Sunday 的实验，其实我们可以发现，全 AI 员工的最大难点就是 如何高效的完成 AI 之间的自动协作。

更具体一点说，核心难点只有一个：如何让多个 AI，在几乎没有人工干预的情况下，自动完成“上下文传递 + 状态对齐 + 任务接力”？

那么这个功能可以实现吗？

答案是 绝对可以

学习过咱们的 商业级 AI 课程 的同学都知道，在 AI 的持续对话中，我们可以通过记录上下文的方式完成跨角色的连续对话。

那么同样的道理，如果我们可以记录不同 AI 沟通上下文的 关键内容，然后通过上述的同样逻辑呼叫下一个 AI（让代码通过指令自动传输关键上下文，并调起 AI 服务），那么全 AI 员工的功能就可以实现。只不过在这样的完美的流转过程中，我们还需要做很多的努力才可以。

总结

这一通折腾下来，收获还是很明显的。三个关键：

而这，也意味着：下一阶段的探索重点，已经不再是“哪个模型更强”，而是：如何设计一套真正可自动运行的“AI 组织系统”。

上午刷到32岁程序员周末猝死这条消息，其实我并不陌生。

这几年，程序员猝死、倒下、出事的新闻隔一段时间就会出现一次，圈子里的人早就麻木了。刷到的时候，最多叹口气，继续干活，很少真的往心里去。

看到他长期加班的细节时，我突然愣住了，因为太像了。

我也经常这样。

下午刷到他的妻子和对他的聊天记录，真的感觉很无奈，可惜，他再也回不来了......

我到不是加班，我是下班后干自己的事情，我比较卷。只有下班后的时间是真正属于自己的时间才刚开始。没有人打扰，安静下来，我会干自己的事情、学习、写代码，一不留神就到了凌晨两点。

那一刻，我才真正能进入自己的状态。

学习也好，干活也好，哪怕只是安静地敲键盘，都让我觉得踏实。

于是，凌晨两点成了常态

通过他这件事，我看到我也在里面，看见了自己。

我上一次写代码写到很晚是前几周，老大让我开发一个知识库RAG系统。

给我了我一周的时间，其实对于我是有难度的，因为接触这块不久，一周时间的话肯定弄不好。

后来那天，我连夜和AI 一些协作搞了6个小时左右，搞到了凌晨3点多，初版搞的差不多，那会心率也有点高了， 有点难受，就赶快休息了...

我们这一代程序员，真的太累了。

这种累，不只是加班，而是一种长期被推着往前，却不敢停下来的状态。

房贷在那儿。

家庭在那儿。

未来的不确定性在那儿。

我们很清楚，一旦慢下来，就意味着风险。

于是我们学会了忍。

忍困、忍累、忍身体发出的各种提醒。

程序员这个职业有个很危险的地方。

身体开始出问题的时候，能力往往还在线。

我们还能写代码，还能解决问题，还能在群里回一句：“好的，我看看”

所以你会误以为自己没事。

可身体不是系统，没有明显的报错提示。

等它真正崩的时候，往往没有给你回滚的机会。

今天刷到这个新闻消息对我来说，更像是一次提醒。我现在体检去，估计都是全红状态，我经常熬夜，现在锻炼的也少了....

我们这一代人，很努力。

努力工作，努力赚钱，努力让生活往前走。

可如果连身体都开始透支，那这条路，真的值得重新想一想。

不是他倒下了。

是我们这一代，真的太累了。

略想了一下才发现，自己好像有大半年都没有关注过 TIOBE 社区了。

TIOBE 编程社区相信大家都听过，这是一个查看各种编程语言流行程度和趋势的社区，每个月都有榜单更新，每年也会有年度榜单和总结出炉。

昨晚在家整理浏览器收藏夹时，才想起了 TIOBE 社区，于是打开看了一眼最近的 TIOBE 编程语言社区指数。

没想到，Java 居然已经跌出前三了，并且和第一名 Python 的差距也进一步拉开到了近 18%。

回想起几年前，Java 曾是何等地风光。

各种基于 Java 技术栈所打造的 Web 后端、互联网服务成为了移动互联网时代的中坚力量，同时以 Java 开发为主的后端岗位也是无数求职者们竞相选择的目标。

然而这才过去几年，如今的 Java 似乎也没有了当年那种无与争锋的强劲势头，由此可见 AI 领域的持续进化和繁荣对它的冲击到底有多大。

用数据说话最有说服力。

拉了一下最近这二十多年来 Java 的 TIOBE 社区指数变化趋势看了看，情况似乎不容客观。

可以明显看到的是一个：呈震荡式下降的趋势。

现如今，Java 日常跌出前三已经成为了常态，并且和常居榜首的 Python 的差距也是越拉越大了。

在目前最新发布的 TIOBE Index 榜单中排名前十的编程语言分别是：

• Python


• C++


• C


• Java


• C#


• JavaScript


• Visual Basic


• Go


• Perl


• Delphi/Object Pascal

其中 Python 可谓是一骑绝尘，与排名第二的 C++ 甚至拉开了近 17% 的差距，呈现了断崖式领先的格局。

不愧是 AI 领域当仁不让的“宠儿”，这势头其他编程语言简直是望尘莫及！

另外还值得一提的就是 C 语言。

最近这几个月 C 语言的 TIOBE Index Ratings 比率一直在回升，这说明其生命力还是非常繁荣的，这对于一个已经诞生 50 多年的编程语言来说，着实不易。

C 语言于上个世纪 70 年代初诞生于贝尔实验室，由丹尼斯·里奇（Dennis MacAlistair Ritchie）以肯·汤普森（Kenneth Lane Thompson）所设计的 B 语言为基础改进发展而来的。

就像之前 TIOBE 社区上所描述的，这可能主要和当下物联网（IoT）技术的发展繁荣，以及和当今发布的大量小型智能设备有关。毕竟 C 语言运行于这些对性能有着苛刻要求的小型设备时，性能依然是最出色的。

说到底，编程语言本身并没有所谓的优劣之分，只有合适的应用场景与项目需求。

按照官方的说法，TIOBE 榜单编程语言指数的计算和主流搜索引擎上不同编程语言的搜索命中数是有关的，所以某一程度上来说，可以反映出某个编程语言的热门程度（流行程度、受关注程度）。

而通过观察一个时间跨度范围内的 TIOBE 指数变化，则可以一定程度上看出某个编程语言的发展趋势，这对于学习者来说，可以作为一个参考。

Java：我啥场面没见过

曾经的 Java 可谓是互联网时代不可或缺的存在。早几年的 Java 曲线一直处于高位游走，彼时的 Java 正是构成当下互联网生态繁荣的重要编程语言，无数的 Web 后端、互联网服务，甚至是移动端开发等等都是 Java 的擅长领域。

而如今随着 AI 领域的发展和繁荣，曾经的扛把子如今似乎也感受到了前所未有的压力。

C语言：我厉兵秣马

流水的语言，铁打的 C。

C 语言总是一个经久不衰的经典编程语言，同时也是为数不多总能闯进榜单前三的经典编程语言。

自诞生之日起，C 语言就凭借其灵活性、细粒度和高性能等特性获得了无可替代的位置，就像上文说的，随着如今的万物互联的物联网（IoT）领域的兴起，C 语言地位依然很稳。

C++：我稳中求进

C++ 的确是一门强大的语言，但语言本身的包袱也的确是不小，而且最近这几年的指数趋势稳中求进，加油吧老大哥。

Python：我逆流而上

当别的编程语言都在震荡甚至下跌之时，Python 这几年却强势上扬，这主要和当下的数据科学、机器学习、人工智能等科学领域的繁荣有着很大的关系。

PHP：我现在有点慌

PHP：我不管，我才是世界上最好的编程语言，不接受反驳（手动doge）。

好了，那以上就是今天的内容分享了，感谢大家的阅读，我们下篇见。

注：本文在GitHub开源仓库「编程之路」 github.com/rd2coding/R… 中已经收录，里面有我整理的6大编程方向(岗位)的自学路线+知识点大梳理、面试考点、我的简历、几本硬核pdf笔记，以及程序员生活和感悟，欢迎star。

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哥，带你不仅看懂技术，更看懂未来。