前言

在过去的几年里，前端开发经历了从手写每一行 HTML/CSS 或使用组件库（Ant Design, Element Plus），到 AI 辅助编程（GitHub Copilot, Cursor）的巨大跨越。然而，2025 年以来的技术浪潮正将我们推向一个新的阶段：从 “AI 辅助” 向 “AI Agent（智能体)” 转型。

在这种模式下，开发者不再只是接收代码建议，而是为 AI 提供一系列“技能包（Skills）”，让 AI 能够理解复杂的框架逻辑、项目结构乃至视觉审美。

什么是Skills? 用一句话概括就是： Skills = 领域专业知识 + 你的项目偏好 + 严厉的审查官。

1. 为什么需要 Skills？

在 AI 编程的语境下，Skills 的出现是为了解决大模型（LLM）“博而不精”的天然缺陷。

1.1 通才 AI：知识的“图书馆”

一个没有安装 Skills 的大模型（如 GPT-5 或 Claude 4.5）就像一个读过全世界所有代码的毕业生：

• 广度惊人：它知道几百种编程语言，甚至能背出 2014 年的过时语法。


• 深度断层：它不知道你公司内部的封装规范，不知道你的组件命名习惯，更不知道你项目中那个“不能动的老 Bug”。


• 执行模糊：给它一个需求，它会从 100 种可能的解法中随机选一个给你，不管这是否符合你现在的工程环境。

1.2 专才 AI：自带“十年工龄”的骨干

安装了 Skills 的 AI（Agent），则完成了从“大模型”到**“领域智能体”**的进化：

安装了 Skills 之后， 它不再是那个满嘴跑火车的机器人，而是一个被你强制要求“必须按这套规约写代码”的资深开发。

2. Skills 里面到底装了什么

一个 Skills 文件夹里通常不是深奥的代码，而是三样东西：

如果说通才 AI 提供的是“概率” （它觉得这段代码看起来像对的），那么 Skills 提供的就是“确定性”。它把行业内顶尖架构师的经验，封装成了 AI 触手可及的“条件反射”。

本文将分享前端高频使用的三个核心技能包：vue-skills、react-skills（agent-skills）以及 ui-skills（uipro-cli），剖析它们如何通过标准化的指令集，彻底改变我们的开发流。

Vue-Skills

Vue-Skills涵盖了 Vue 3 项目的最佳实践、TypeScript 类型安全增强、IDE 性能优化以及现代 Vue 编码模式。它们旨在解决大型 Vue 项目中常见的开发痛点，如 IDE 卡顿、类型推断错误、构建配置以及代码可维护性问题。

1.1 核心规则

可以将这些规则概括为以下 5 个主要方面：

1. 开发体验与 IDE 性能优化 (IDE & Performance)

关注如何解决大型项目中 VSCode 和 Volar 插件的性能问题。

• codeactions-save-performance.md: 解决在大型 Vue 项目中保存文件时耗时过长（30秒+）的问题，建议禁用或限制耗时的 Code Actions。


• volar-3-breaking-changes.md: 针对 Volar 升级带来的变更进行适配，确保插件功能正常。


• vue-directive-comments.md: 介绍了@vue-ignore, @vue-skip,@vue-expect-error等指令注释，用于在模版中精细控制类型检查行为（类似 @ts-ignore）。

2. TypeScript 类型安全与配置 (Type Safety & Configuration)

致力于提升 Vue 模版和组件的类型检查严格度，减少运行时错误。

• vue-tsc-strict-templates.md: 推荐开启 strictTemplates，在编译时捕获模版中未定义的组件和属性错误。


• vue-router-typed-params.md: 解决unplugin-vue-router,导致的路由参数类型丢失问题（Property does not exist），推荐更严格的路由参数类型定义。


• data-attributes-config.md: 配置 vueCompilerOptions 以支持 data-*属性的类型检查，避免误报类型错误。


• ** module-resolution-bundler.md**: 推荐在 tsconfig.json 设置 "moduleResolution": "bundler"
  以适配现代构建工具。


• with-defaults-union-types.md: 修复在defineProps中使用联合类型（如 string | false）配合withDefaults 时的虚假警告问题。

3. Vue 3 现代编码模式 (Modern Patterns)

推广 Vue 3.4+ 的新特性及更优雅的代码组织方式。

• define-model-update-event.md: 推荐使用 Vue 3.4 的 defineModel()宏，替代手写的props+ emit('update:modelValue')模式。


• extract-component-props.md: 建议将复杂的defineProps类型提取为独立的 TS 接口，提高代码可读性和复用性。


• script-setup-jsdoc.md: 规范 <script setup>中的 JSDoc 使用，增强组件文档和类型提示。


• fallthrough-attributes.md: 关于 inheritAttrs: false和透传属性（Attributes Fallthrough）的最佳实践。

4. 运行时陷阱与调试 (Runtime Caveats & Debugging)

解决特定场景下的怪异 bug 和运行时问题。

• deep-watch-numeric.md: 警告在侦听（watch）数字数组时使用 deep: true的陷阱（新旧值相同），建议使用深拷贝。


• duplicate-plugin-detection.md: 防止 Vue 插件（如 Pinia）在微前端或特定环境下被重复注册。


• hmr-vue-ssr.md: 处理服务端渲染（SSR）场景下的热更新（HMR）问题。

5. 测试与样式 (Testing & Styling)

• pinia-store-mocking.md: 关于如何在测试中正确 Mock Pinia Store 的指南。


• strict-css-modules.md: 开启 CSS Modules 的严格模式，防止使用未定义的 class 名。

1.2 安装方法

通过简单的命令，你可以将此技能植入到你的 AI 工作流中：

npx add-skill hyf0/vue-skills

执行上面的指令后，会自动检查IDE，终端环境

选择安装在当前项目，还是对所有项目生效

选择下载一份每个项目建立软链接，还是将规则文件复制在每个项目下

安装完成之后的显示

1.3 实战案例

案例展示了当 AI Agent 加载了 vue-best-practices 技能包后，如何通过 “提取组件属性 (Extract Component Props)” 规则，优雅地解决二次封装组件时的类型继承问题。

场景描述：我们正在基于一个第三方库的 BaseButton.vue 组件，封装一个我们项目专用的 ProButton.vue。我们需要让 ProButton 继承 BaseButton 的所有属性（Props），同时增加一个自定义属性 loading。

1. 优化前：常规“盲写”模式

现象：如果没有技能包指导，开发者往往会手动重复定义属性，或者使用不推荐的 Vue 内部实例类型。

<!-- ProButton.vue -->

<script setup lang="ts">

// ❌ 错误做法 1：手动重复定义，维护成本极高

interface Props {

  text: string;

  color?: string;

  loading: boolean; // 自定义属性

}



// ❌ 错误做法 2：使用 InstanceType，会包含大量的 Vue 内部属性，干扰类型提示

import type BaseButton from "./BaseButton.vue";

type BaseProps = InstanceType<typeof BaseButton>["$props"];



defineProps<BaseProps & { loading: boolean }>();

</script>

2. 优化后：使用 vue-component-type-helpers

技能规则应用：

• 规则名称：extract-component-props.md


• 核心逻辑：利用 vue-component-type-helpers 库精确提取组件定义的 Props，排除内部干扰项。

重构结果：代码简洁，类型提示完美，且具备 100% 的继承安全性。

<!-- ProButton.vue -->

<script setup lang="ts">

import type { ComponentProps } from "vue-component-type-helpers";

import BaseButton from "./BaseButton.vue";



// ✅ 符合最佳实践：精确提取子组件的 Props 类型

type BaseButtonProps = ComponentProps<typeof BaseButton>;



// 扩展基础组件的属性

interface Props extends BaseButtonProps {

  loading?: boolean;

  size?: "sm" | "md" | "lg";

}



const props = withDefaults(defineProps<Props>(), {

  loading: false,

  size: "md",

});

</script>



<template>

  <div class="pro-button">

    <!-- 将剩余属性透传给基础组件 -->

    <BaseButton v-bind="$attrs" :loading="loading">

      <slot />

    </BaseButton>

  </div>

</template>

3.核心价值总结

提示：安装技能包后，当你在写高阶组件（HOC）或二次封装组件时，AI 会自动识别场景并提示你使用 vue-component-type-helpers 进行类型提取，确保你的 TypeScript 链路在全项目保持强类型约束。

2.1 核心功能

1. React 组件组合模式 (vercel-composition-patterns)

适用场景：

• 组件重构：当核心组件因布尔属性（Boolean props）爆炸（如 isLoading, isSmall 等）而难以维护时。


• 库级开发：构建需要高度灵活、可扩展 API 的企业级 UI 组件库。


• 复杂交互设计：实现具有强父子联动逻辑的复合组件（如 Tabs, Select, Menu）。

核心规则：

• 架构优先组合：严禁无限制叠加布尔属性，推崇使用 复合组件 (Compound Components) 和 Context 共享状态。


• 接口解耦：Provider 集中管理状态逻辑，子组件仅通过约定的 Context 接口进行交互。


• 显式变体 (Explicit Variants)：与其给一个组件加 10 个布尔值，不如创建明确命名的变体组件（如 PrimaryButton, IconButton）。


• 组合优于配置：优先通过 children 进行 UI 拼装，而非通过庞大的配置对象或大量的 renderX Props。

2. React & Next.js 性能最佳实践 (vercel-react-best-practices)

适用场景：

• 性能调优：页面响应慢、首屏渲染 (LCP) 时间长或存在明显的交互延迟。


• 现代 Web 构建：基于 Next.js App Router 架构的全栈开发。


• 大规模数据处理：需要并行获取多个 API 数据且必须避免渲染阻塞的场景。

核心规则：

• 消除瀑布流 (Waterfalls)：性能优化的 头等大事。强制要求并行化独立异步操作，并利用 Suspense 实现流式 (Streaming) 内容分发。


• 打包体积压缩：禁用 Barrel Files (单一入口导出文件) 以保护 Tree-shaking；强制使用 next/dynamic 进行代码分割。


• 服务端性能 (RSC)：利用 React.cache() 进行请求级数据去重，最小化传输至客户端的序列化数据量。


• 重渲染控制：避免在 Effects 中处理同步状态，提倡使用派生状态 (Derived State)；利用 startTransition 处理非紧急更新。

3. React Native & Expo 移动开发指南 (vercel-react-native-skills)

适用场景：

• 移动端丝滑体验：针对 iOS 和 Android 优化长列表滑动和复杂手势动画。


• 跨端性能消除：解决由于 JS 线程与 UI 线程通信延迟导致的性能瓶颈。


• 原生功能集成：在 Expo 或原生环境中处理多媒体、字体和原生组件的高性能接入。

核心规则：

• 列表性能 (最关键)：强制使用 FlashList 替代 FlatList；列表项必须经过 memo 处理以减少多余重绘。


• GPU 加速动画：动画属性仅限在 transform 和 opacity 上操作，确保逻辑在 UI 线程直接执行。


• 原生 UI 适配：始终使用 expo-image 优化图片加载；优先使用 Pressable 替代 TouchableOpacity 以获得更好的响应响应。


• 渲染规范：文本必须且只能包裹在 Text 组件内；禁止在条件渲染中使用 &&（防止在移动端渲染出数字 0）。

4. Web 界面设计指南 (web-design-guidelines)

适用场景：

• UI/UX 审计：项目发布前检查 UI 间距、颜色 Token 和视觉输出的一致性。


• 无障碍性 (A11y)：确保网站符合 Web 辅助功能标准，提升产品包容性。


• 自动化 UI 审查：在 Code Review 阶段快速发现硬编码和非标准交互实现。

核心规则：

• 动态合规检查：通过远程拉取最新的设计系统准则，确保证审视标准始终是最新的。


• 无障碍强制约束：严格检查颜色对比度、ARIA 标签完整性以及键盘导航流程。


• 高精度反馈：能够精确到代码行指出不符合设计系统规范（如未使用的 Design Tokens）的地方。

2.2 安装方法

npx add-skill vercel-labs/agent-skills

可以只选择安装其中的一个规则集，比如说vercel-react-best-practices

其余步骤，与Vue-Skills的问询问题一模一样，不再赘述。

2.3 用法示例

在一个 Next.js App Router 项目的个人中心页面中，我们需要同时获取用户信息、订单列表和优惠券信息。

1. 优化前：串行瀑布流 (Sequential Waterfall)

现象：如果没有技能包约束，AI 可能会写出标准的串行代码。这种方案下，总耗时是三个接口请求时间的累加（T1 + T2 + T3）。

// ❌ 不符合最佳实践：串行阻塞

export default async function ProfilePage() {

  // 请求 1：获取用户信息

  const user = await fetchUser();



  // 请求 2：依赖于 user.id，但在请求 1 完成前无法开始

  const orders = await fetchOrders(user.id);



  // 请求 3：不依赖于前二者，却被白白阻塞

  const coupons = await fetchCoupons();



  return (

    <div>

      <UserInfo user={user} />

      <OrderList orders={orders} />

      <CouponList coupons={coupons} />

    </div>

  );

}

2. 优化后：并行获取 + 组件组合 (Parallel & Composition)

技能规则应用：

• async-parallel：识别出不互相关联的请求，并并行启动。


• server-parallel-fetching：利用服务器组件的组合特性，减少主线程阻塞。

重构结果：页面总耗时缩短为（T1 + Max(T2, T3)），且实现了流式分发。

// ✅ 符合最佳实践：并行获取与解耦渲染

import { Suspense } from "react";



export default async function ProfilePage() {

  // 1. 同时启动互不关联的异步任务，不加 await

  const userPromise = fetchUser();

  const couponsPromise = fetchCoupons(); // 并行开始



  // 2. 仅等待必要的基础数据

  const user = await userPromise;



  return (

    <div>

      {/* 优先渲染用户信息 */}

      <UserInfo user={user} />



      {/* 3. 将耗时较长的“订单列表”逻辑下移至组件内部，并行获取 */}

      <Suspense fallback={<Skeleton />}>

        <OrderDataLayer userId={user.id} />

      </Suspense>



      {/* 4. 将预启动的“优惠券”Promise 传入组件 */}

      <Suspense fallback={<Skeleton />}>

        <CouponDataLayer promise={couponsPromise} />

      </Suspense>

    </div>

  );

}



// 独立的异步数据层组件

async function OrderDataLayer({ userId }) {

  const orders = await fetchOrders(userId); // 并行进行的请求

  return <OrderList orders={orders} />;

}



async function CouponDataLayer({ promise }) {

  const coupons = await promise; // 使用外部传入的 Promise

  return <CouponList coupons={coupons} />;

}

3. 核心价值总结

结论：通过注入 vercel-react-best-practices 技能，AI Agent 从一个简单的“代码生成器”转变为具备“性能自觉”的高级架构师。

三、 UI-Skills

如果说前两个工具解决了“逻辑”问题，那么 uipro-cli 及其关联的 ui-skills 则是为了解决“审美与交付”问题。 UI/UX Pro Max：赋能 AI Agent 的专业设计大脑。uipro-cli 是一个功能强大的命令行工具，专门用于为各种 AI 编程助手（如 Claude Code, Cursor, Windsurf, Antigravity 等）一键注入 UI/UX Pro Max 专家级技能。它让 AI 不仅能写代码，更能像资深设计师一样思考。

2.1 核心功能

1. 多元化视觉风格 (67 种 UI 风格)

UI/UX Pro Max 内置了 67 种最前沿的视觉设计风格，确保 AI 生成的界面告别“通用感”。

• 现代趋势：支持 Glassmorphism（玻璃拟态）、Claymorphism（粘土拟态）、Minimalism（极简主义）。


• 特色风格：包括 Brutalism（新野兽派）、Neumorphism（新拟物化）、Bento Grid（便当网格）以及针对 AI 产品的 AI-Native UI 风格。

2. 行业深度色彩与排版 (96 行业色板 + 57 字体配对)

• 精准色板：提供 96 套针对特定行业（如 SaaS, 电商, 医疗, 金融金融, 美妆）优化的专业色板。


• 字体艺术：内置 57 组精心挑选的字体组合，无缝集成 Google Fonts，从视觉底层提升产品质感。

3. 跨平台技术栈适配 (13 种主流技术栈)

支持从 Web 到移动端的 13 种主流技术架构，生成的代码即学即用。

• Web 端：React, Next.js, Vue, Nuxt.js, Astro, Svelte, HTML+Tailwind, shadcn/ui。


• 移动端：React Native, Flutter, SwiftUI, Jetpack Compose 等。

4. 专家级 UX 准则与设计推理 (100+ 准则与推理规则)

内置专业的设计逻辑，让 AI 具备“审美自觉”：

• UX 指南：涵盖 99 条 UX 最佳实践、反模式规避和 A11y 无障碍规则。


• 设计推理：拥有 100 条行业推理规则（例如：金融类应用严禁使用 AI 风格的紫粉渐变，以确保稳重感），自动进行交付前的 UI/UX 质量自检。

2.2 安装方法

通过 uipro-cli，你可以在几秒钟内完成技能初始化：

1. 全局安装工具

npm install -g uipro-cli

2. 为指定编辑器初始化技能

# 为 Claude Code 初始化

uipro init --ai claude



# 为 Cursor 初始化

uipro init --ai cursor



# 为所有支持的 AI 助手同时初始化

uipro init --ai all

3. 实战案例

场景描述： 用户需要为一个 AI 内容创作平台设计一个数据看板（Dashboard）。用户希望界面现代、直观，并且符合当前流行的审美趋势。

1. 传统 AI 生成：平庸且缺乏设计感

现象：如果没有加载专业 UI 技能包，AI 通常只会根据组件库（如 shadcn/ui）的基础示例，堆砌出缺乏灵魂的列表和卡片。色调单一（通常只用蓝色或灰阶），布局死板。

// ❌ 传统 AI 的“直觉”：基础的 Grid 布局，没有任何样式特色

export default function Dashboard() {

  return (

    <div className="grid grid-cols-3 gap-4 p-4">

      <Card title="总收入" value="$12,000" />

      <Card title="活跃用户" value="1,240" />

      <Card title="API 调用" value="45.2k" />

      <div className="col-span-3">主要统计图表</div>

    </div>

  );

}

2. UI/UX Pro Max 介入：具备“审美自觉”的设计

技能规则应用：

• 风格锁定：选择了 Bento Grid（便当网格） 布局。


• 行业色板：套用了 SaaS 行业高阶调色盘。


• 设计推理：AI 会自动添加微交互动画、圆角分层（Glassmorphism 效果）以及符合产品气质的字体排版。

重构指令：

“使用 UI/UX Pro Max 技能，为我的 AI 创作平台设计一个 Bento Grid 风格的统计看板。色调选用‘高级钛金灰’配合‘赛博蓝’点缀，并要求包含毛玻璃质感。”

重构结果（语义描述与关键代码片段）：

// ✅ 符合设计的组件 (自动生成的 Tailwind 样式)



// 使用了 Bento Grid 非对称网格布局

export function BentoDashboard() {

  return (

    <section className="bg-slate-950 p-8 min-h-screen font-sans text-slate-100">

      <div className="max-w-7xl mx-auto grid grid-cols-1 md:grid-cols-4 gap-6">

        {/* 高度分层的毛玻璃卡片 (Glassmorphism) */}

        <div

          className="md:col-span-2 md:row-span-2 bg-slate-900/50 backdrop-blur-xl border border-white/10 rounded-3xl p-8 

                        hover:bg-slate-800/60 transition-all duration-300 group"

        >

          <header className="flex justify-between">

            <h3 className="text-xl font-bold tracking-tight">创作产出分析</h3>

            <div className="h-2 w-2 bg-cyan-400 rounded-full animate-pulse" />

          </header>

          {/* AI 自动推荐的图表配色与坐标轴样式 */}

          <MainAnalyticChart color="#22d3ee" />

        </div>



        {/* 紧凑型统计卡片 */}

        <div className="bg-slate-900/50 backdrop-blur-md rounded-3xl p-6 border border-white/5">

          <Subtitle>API 余额</Subtitle>

          <Value className="text-3xl font-mono">84.2%</Value>

        </div>



        {/* 动态微交互元素 */}

        <div className="bg-cyan-500/10 rounded-3xl p-6 border border-cyan-500/20 text-cyan-400">

          <div className="text-sm font-semibold mb-2">服务状态</div>

          <div className="text-lg">系统运行正常</div>

        </div>



        {/* 更多 Bento 网格单元... */}

      </div>

    </section>

  );

}

3.核心价值总结

结语：前端开发者的角色转变

随着 vue-skills、react-skills 和 ui-skills 的普及，前端开发者的角色正在发生深刻变化。我们正在从 “代码编写者（Coder）” 转变为 “AI 指令师（Prompt Engineer）” 和 “技术评审员（Reviewer）” 。

传统的 AI 辅助仅仅是“搜索”的变种，而 Skills 模式代表了 “领域知识的预装载” 。

掌握这些 Skills 并不意味着放弃底层的学习，相反，只有深刻理解 Vue/React 原理和 UI 规范的人，才能通过这些技能包更好地引导 AI，释放出前所未有的生产力。

大家好😁

如果你是一个前端，尤其是在B端（中后台）领域，Ant Design（antd）这个名字，你不可能没听过。

在过去的5年里，我们团队的所有新项目，技术选型里的第一行，永远是antd。它专业、开箱即用、文档齐全，拥有一切你想要的组件, 帮我们这些小团队，一夜之间就拥有了大厂的专业门面。

我们靠它，快速地交付了一个又一个项目。

Antd 虽好，但魔改样式确实让人头秃，转向 Headless UI 又怕重复造轮子。想兼顾灵活定制与开发效率？试试 RollCode 低代码平台，利用 自定义组件 快速封装 Headless 逻辑，通过 私有化部署 沉淀企业级资产，更能一键 静态页面发布（SSG + SEO），让 UI 自由不再昂贵。

但是，从去年开始，我发现，这个曾经的经典，正在变成我们团队脖子上最重的枷锁。

Ant Design，这个我们当初用来解决技术债的核心组件库，现在，却成了我们最大的技术债本身😖。

这是一篇团队血泪史, 讲一讲感想🤷‍♂️。

我们为什么会爱上 AntD？

我们必须承认，从无到有阶段，antd是无敌的。

你一个3人的小团队，用上antd，做出来的东西，看起来和阿里几百人团队做的系统，没什么区别。

Table、Form、Modal、Menu... 你需要的一切，它都以一种极其标准的方式给你了。你不再需要自己造轮子。

当你发现@ant-design/pro-components时，一个ProTable，直接帮你搞定了请求、分页、查询表单、工具栏... 你甚至都不用写useState了。

在那个阶段，我们以为我们找到了大结局。

当个性化成为 我们的 KPI

美好可能是短暂的，从我们的产品经理和UI设计师开始👇：

能不能...不要长得这么 Ant Design？🤣

这是我们设计师，在评审会上，小心翼翼提出来的第一句话。

老板也说：我们要做自己的品牌，现在的系统，太千篇一律了!!!

于是，我们接到了第一个简单的需求：把全局的主题色，从橙色改成我们的品牌红。

这很简单，不就是 ConfigProvider嘛🤔。我们改了。

然后，第二个需求来了：这个Modal弹窗的关闭按钮，能不能不要放在右上角？我们要放在左下角，和确认按钮放在一起。(有点反人类🤷‍♂️)

灾难，就从这里开始了。

antd的Modal组件，根本就没提供这个插槽或prop。我们唯一的办法，是 强改。

于是，我们的代码里，开始出现这种恶臭的CSS：

/* 一个高权重的全局CSS文件 */

.ant-modal-header {

  /* ... */

}



/* 嘿，那个右上角的关闭按钮，给我藏起来！ */

.ant-modal-close-x {

  display: none !important; 

}

为了把那个 X 藏起来，我们用了!important。我们亲手打开了潘多拉魔盒。

这个表格的筛选图标，能换成我们自己画的吗？😖

antd的Table，是一个重灾区。它太强大了，也很黑盒。

我们设计师，重新画了一套筛选、排序的图标。但我们发现，antd的Table组件，根本没想过让你换这个。

我们唯一的办法，就是用 CSS选择器，一层一层地穿进antd的DOM结构里，找到那个<span>，然后用background-image去盖掉它。

/* 另一个人写的，更恶臭的CSS */

.ant-table-thead > tr > th.ant-table-column-has-filters .ant-table-filter-trigger {

  /* 妈呀，这是啥？ */

  background: url('our-own-icon.svg') !important;

}



.ant-table-thead > tr > th.ant-table-column-has-filters .ant-table-filter-trigger > svg {

  /* 藏起来，藏起来！ */

  display: none !important;

}

我们被拖累了。

我们花在 覆盖antd默认样式上的时间，已经远远超过了我们自己写一个组件的时间。

压死骆驼的最后一根稻草

我们用了ProTable，它的查询表单和表格是强耦合的。当产品经理提出一个我希望查询表单，在页面滚动时，吸附在顶部的需求时... 我们发现，我们改不动。我们被ProComponents的黑盒，锁死了。

然后我们的vendor.js打包出来，2.5MB。用webpack-bundle-analyzer一看，antd和@ant-design/icons，占了1.2MB。我们为了一个Button和Icon，引入了一个全家桶。antd的按需加载？别闹了，在ProComponents面前，它几乎是全量的。

而且 antd从v3到v4，我们花了一个月。从v4到v5，我们花了半个月。每一次升级，都是一次大型重构，因为我们那些写法一样被CSS覆盖，在新版里，全失效了🤷‍♂️。

我们本想找一个可靠的组件库，这么久过来，结果它成了债主。

我们真正需要的可能是轮子

我终于想明白了。

Ant Design，它不是一个组件库（Library），它是一个UI框架（Framework）。它是一套解决方案，它有它自己强势的 设计价值观。

当你的需求，和它的价值观一致时，它就是圣经。
当你的需求，和它的价值观不一致时，它就变成枷锁。

我们当初要的，其实是一个带样式的Button；而antd给我的，是一个内置了loading、disabled、onClick时会有水波纹动画、并且必须是蓝色或白色的Button。

我们的自救之路

在我们新的项目中，我忍痛做出了一个决定🤷‍♂️：

原则上，不再使用antd。

我们新的技术栈，转向了：
Tailwind CSS + Headless UI 方案（比如Radix UI）

这个组合，才是我们想要的：

• Headless UI：它只提供功能和无障碍。比如，一个Dialog（模态框），它帮我搞定了按Esc关闭、焦点管理。但它没有任何样式。


• Tailwind CSS：我拿到了这个无样式的Dialog，然后用Tailwind的class，在5分钟内，在AI的帮助下，把它拼成了我们设计师想要的、独一无二的弹窗。

我们拿回了CSS的完全控制权，同时又享受了 AI + 组件开发的便利。

我依然尊敬Ant Design，它在前端B端历史上，是个丰碑。
对于那些从0到1的、对UI没有要求的内部系统，我可能依然会用它。

但对于那些需要品牌、体验、个性化的核心产品，我必须和它说再见了。

因为，当你的组件库开始控制你的设计和性能时，它就不是你的资产了。

而变成你最大的技术债🙌。

一、达成的结果

app嵌套h5 加载效率提升了62%。时间从平均2.259s 降到了0.852s

二、优化过程

思路：优化原生webview+h5 ，先测试webview点击到创建时间 120ms（无需优化）。webview 提供了 api 测试 加载url 的进度。但是没提供具体的类似pc端网络的工具。所以就通过ai搜索一些工具。发现阿里云的arms 方便引入。

测试设备 android荣耀50、华为meta9、华为p40、oppo

开发环境测试

测试样本：优化前后各测试10次。

测试移动端h5 引入了阿里云的arms arms.console.aliyun.com/ 可以查看加载某个url的时候 请求的js css、图片、网络请求 跟网页版的网络类似。

import ArmsRum from '@arms/rum-browser'



ArmsRum.init({

	pid: 'ha63j3v892@efe71d242023cd5',

	endpoint: 'https://ha63j3v892-default-cn.rum.aliyuncs.com',

	// 设置环境信息，参考值：'prod' | 'gray' | 'pre' | 'daily' | 'local'

	env: 'prod',

	// 设置路由模式， 参考值：'history' | 'hash'

	spaMode: 'hash',

	collectors: {

		// 页面性能指标监听开关，默认开启

		perf: true,

		// WebVitals指标监听开关，默认开启

		webVitals: true,

		// Ajax监听开关，默认开启

		api: true,

		// 静态资源开关，默认开启

		staticResource: true,

		// JS错误监听开关，默认开启

		jsError: true,

		// 控制台错误监听开关，默认开启

		consoleError: true,

		// 用户行为监听开关，默认开启

		action: true,

	},

	// 链路追踪配置开关，默认关闭

	tracing: false,

})



export default ArmsRum

步骤一、懒加载echarts

以前的代码

import Api from '@/api'

import * as echarts from 'echarts'

import dayjs from 'dayjs'

export default {

}

现在的代码

async getRepairChart() {

			const echarts = await import('echarts')

			// xxx

			const chartDom = document.getElementById('repairChart')

			const myChart = echarts.init(chartDom)

			const option = {

			}

			myChart.setOption(option)

		},

通过F12查看网络 发现加载列表的时候有出现echartsxxx.js 而且有800多k ,所以就考虑加载列表不应该去加载数据看板的数据。

优化前，测试前日志打印

平均是3.234s 然后 当然还测试了华为p40 、oppo机器 由于系统不一样时间有些差别

测试后日志打印

平均是1.71s

华为meta9 9年前的老手机打印log

平均也2s多

优化后

不到0.8s

步骤二、禁用预加载、路由懒加载

通过查看网络发现请求dev-haolipei.cias.cn/app/#/takeO… 超级多的js 跟css

一张图都截取不完。当时就感觉肯定请求了很多无关紧要的资源。

npm run build 执行后查看dist目录index.html 的确很触目惊心 加载了太多没必要的资源了。

module.exports = {

	publicPath,

	devServer: {

		disableHostCheck: true,

		// host: 'localhost.cias.cn',

		proxy: {

			'/api': {

				target,

				changeOrigin: true,

				// 	cookieDomainRewrite在手机调试时用得上

				// cookieDomainRewrite: '',

				pathRewrite: {

					'^/api': '',

				},

			},

			'/media': {

				target,

				changeOrigin: true,

				pathRewrite: {

					'^/media': '',

				},

			},

		},

	},

	chainWebpack: config => {

		// 禁用预加载

		config.plugins.delete('preload')

		config.plugins.delete('prefetch')

	},

}

禁用它们的核心好处

1. 减少不必要的网络请求，节省带宽

• preload 可能会强制加载一些 “非关键资源”（如配置不当的情况下，预加载了体积大但当前页面暂时用不到的资源），导致带宽浪费。


• prefetch 会预加载未来可能访问的路由 chunk（如用户可能不会点击的低频页面），如果用户最终没有访问这些页面，预加载的资源就成了 “无效请求”，尤其对移动端用户（流量有限）不友好。

禁用后，资源仅在明确需要时才会加载（如用户进入对应路由时），避免 “提前加载但用不上” 的浪费。

2. 避免阻塞关键资源加载，提升首屏速度

• 浏览器对同一域名的并发请求数有限制（HTTP/1.1 通常为 6 个）。preload 加载的资源会占用并发名额，可能阻塞当前页面真正需要的关键资源（如核心 JS/CSS），导致首屏渲染延迟。


• 例如：若 preload 预加载了一个 2MB 的非关键 chunk，可能会挤占首屏 JS 的加载带宽，导致页面 “白屏时间” 变长。

禁用后，浏览器的并发资源会优先分配给当前页面的核心资源，减少阻塞。

3. 避免缓存资源被 “无效资源” 占用

浏览器缓存空间有限，prefetch 预加载的大量 “未来可能用到” 的 chunk 会占用缓存空间，可能导致真正需要长期缓存的核心资源（如 chunk-vendors.js）被挤出缓存，下次访问时需要重新加载。

禁用后，缓存可优先保留关键资源，提升二次访问速度。

4. 适配低网速 / 弱网环境

在 3G、偏远地区等弱网环境下，preload/prefetch 的预加载行为会加剧网络拥堵：

• 预加载的资源可能耗时过长，导致当前页面的核心资源加载超时。


• 禁用后，资源加载更 “轻量化”，优先保证当前页面可用，符合弱网环境的用户体验需求。

5. 减少开发环境的冗余加载

在开发环境中，Webpack 会频繁编译资源，preload/prefetch 可能导致每次热更新时加载大量无关资源，拖慢开发服务器响应速度，影响开发体验。禁用后可简化开发环境的资源加载逻辑，提升热更新效率。

注意：并非所有场景都适合禁用

preload/prefetch 本身是性能优化手段，若项目存在以下情况，可能需要保留或部分配置：

• 首屏依赖的关键资源（如核心 CSS、字体）体积大，preload 可加速其加载。


• 高频访问的路由（如首页→列表页），prefetch 可提前加载列表页 chunk，提升跳转速度。

因此，禁用的合理性取决于项目场景：资源体积大、用户网络不稳定、低频路由多的项目（如移动端 H5）更适合禁用；高频路由明确、网络环境好的项目可选择性保留。

路由懒加载

必须写上 /* webpackChunkName: "system-setting" */

以前的代码

	{

				path: '/takeOrder',

				name: 'HomeTakeOrder',

				component: () =>

					import(

						'@/views/baosi/orderList.vue'

					),

				meta: {

					title: '推返修列表',

					keepAlive: true,

				},

  }

懒加载路由模式

const HomeTakeOrder = () =>

	import(/* webpackChunkName: "take-order" */ '@/views/baosi/orderList.vue')



  {

				path: '/takeOrder',

				name: 'HomeTakeOrder',

				component: HomeTakeOrder,

				meta: {

					title: '推返修列表',

					keepAlive: true,

				},

			},

这样的好处 打包后 会有路由名称

对比

继续测试打印log

可以看看网络请求 就只有5个js文件 总体积不到300k

平均是0.852，基本达成要求

通过npm run build 本地打包看看文件对比大小。

1、体积巨减！！！

2、加载的文件名称是路由名称+hash值

优化前

优化后

三、内部项目具体实践

（增值移动端h5项目可以参考以下操作）

1、禁用预加载

module.exports = {

	publicPath,

	devServer: {

		disableHostCheck: true,

		// host: 'localhost.cias.cn',

		proxy: {

			'/api': {

				target,

				changeOrigin: true,

				// 	cookieDomainRewrite在手机调试时用得上

				// cookieDomainRewrite: '',

				pathRewrite: {

					'^/api': '',

				},

			},

			'/media': {

				target,

				changeOrigin: true,

				pathRewrite: {

					'^/media': '',

				},

			},

		},

	},

	chainWebpack: config => {

		// 禁用预加载

		config.plugins.delete('preload')

		config.plugins.delete('prefetch')

	},

}

2、将路由全部改成懒加载

并且路由需要/* webpackChunkName:"take-order" */

	{

				path: '/takeOrder',

				name: 'HomeTakeOrder',

				component: () =>

					import(

						/* webpackChunkName:"take-order" */ '@/views/baosi/orderList.vue'

					),

				meta: {

					title: '推返修列表',

					keepAlive: true,

				},

  }

3、组件懒加载

以前常见写法 就是一进来 把所有组件的都加载进来

比如这个车牌号组件有120k 对于比较大一点的组件可以用懒加载 。

	<van-popup v-model="showPlatePopup" position="bottom" :overlay="false">

			<keyboard

				v-model="baseInfo.plateNumber"

				:show.sync="showPlatePopup"

				@input="handlePlateInput"

			></keyboard>





      import Keyboard from '@/components/numberplate/vnp-keyboard.vue'



      export default {

  	name: 'CreateOrder',

  	components: {

  		MultiSelectPopup,

  		DispatchingPopup,

  		DispatchFailPopup,

  		DispatchFinishPopup,

  		Keyboard,

  	},

    

    }

懒加载代码

用这个方式可以直接在网络中查看到对应组件的名称和大小

<van-popup

			v-if="showPlatePopup"

			v-model="showPlatePopup"

			position="bottom"

			:overlay="false"

		>

			<keyboard

				v-model="baseInfo.plateNumber"

				:show.sync="showPlatePopup"

				@input="handlePlateInput"

			></keyboard>

		</van-popup>



    export default {

	name: 'CreateOrder',

	components: {

		MultiSelectPopup,

		DispatchingPopup,

		DispatchFailPopup,

		DispatchFinishPopup,

		Keyboard: () =>

			import(

				/* webpackChunkName: "keyboard" */

				'@/components/numberplate/vnp-keyboard.vue'

			),

	},

}

还有 特别大的第三方库 echart 懒加载 按需引入

四、总结

目前通过禁用预加载、路由懒加载、和第三方组件懒加载使用方式 基本能达到很大程度的优化效果。

但是看图 每次加载前面2个文件一个683k 另外一个285k 还是压缩了的文件 ，

我猜应该是main.js 引入了很多东西，后续还可以有优化空间。移动端的h5 入口文件尽量简洁。

(自己写的页面 一定多注意看一下 网络 有多少个js 和css 图片) 资源过大就要考虑优化了。

性能优化一定要多测试验证、多测试验证、多测试验证，保证业务正常情况下优化性能。

性能优化参考。

juejin.cn/post/718889…

近日在使用小米AI大模型MIMO时，被其顶部的透视跟随动画深深吸引，移步官网（ mimo.xiaomi.com/zh/ ）

效果演示

1. 交互梳理

现在基于这个交互的拆解，逐步来复刻交互效果

2. 组件结构与DOM设计

2.1 模板结构

采用「静态底层+动态上层」的双层视觉结构，通过CSS绝对定位实现图层叠加，既保证初始状态的视觉完整性，又能让交互效果精准作用于上层，不干扰底层基础展示。两层分工明确，具体如下：

2.2 核心 DOM 结构

<div class="container" @mouseenter="onMouseEnter" @mouseleave="onMouseLeave" @mousemove="onMouseMove">

  <!-- 底层内容 -->

  <div class="z-1">

    <div class="line" v-for="line in 13">

      <span class="line-item" v-for="item in 13">HELLO</span>

    </div>

  </div>

  <h1 class="title-1">你好，世界！</h1>

  

  <!-- 上层交互内容 -->

  <div class="z-2" :style="{ 'clip-path': circleClipPath }">

    <div class="hidden-div">

      <div class="line" v-for="line in 13">

        <span class="line-item" v-for="item in 13">HELLO</span>

      </div>

    </div>

    <h1 class="title-2">Hello , World!</h1>

  </div>

</div>

关键说明：hidden-div用于包裹上层文字矩阵，配合.z-2的定位规则，确保遮罩效果精准覆盖；两层文字矩阵尺寸一致，保证视觉对齐，增强透视沉浸感。

3. 技术实现

3.1 核心功能模块

3.1.1 轨迹点系统

轨迹点系统是实现平滑鼠标跟随效果的核心，通过维护6个轨迹点的位置信息，创建出具有弹性延迟的跟随动画。

// 轨迹点系统 

const trailSystem = ref({

  targetX: 0,

  targetY: 0,

  trailPoints: Array(6).fill(null).map(() => ({ x: 0, y: 0 })),

  animationId: 0,

  isInside: false

});

设计思路：6个轨迹点是兼顾流畅度与性能的平衡值——点太少则拖尾效果不明显，点太多则增加计算开销，配合递减阻尼系数，实现“头快尾慢”的自然跟随。

3.1.2 动态 Clip-Path 计算

通过计算鼠标位置和轨迹点的关系，动态生成 clip-path CSS 属性值，实现跟随鼠标的圆形/椭圆形遮罩效果。

// 计算clip-path值

const circleClipPath = computed(() => {

  if (!showCircle.value) {

    return 'circle(0px at -300px -300px)'; // 完全隐藏状态

  }



  // 复制轨迹系统数据进行计算

  const system = JSON.parse(JSON.stringify(trailSystem.value));

  

  // 更新轨迹点

  for (let t = 0; t < 6; t++) {

    const prevX = t === 0 ? system.targetX : system.trailPoints[t - 1].x;

    const prevY = t === 0 ? system.targetY : system.trailPoints[t - 1].y;

    const damping = 0.7 - 0.04 * t; // 阻尼系数，后面的点移动更慢

    

    const deltaX = prevX - system.trailPoints[t].x;

    const deltaY = prevY - system.trailPoints[t].y;

    

    // 平滑插值

    system.trailPoints[t].x += deltaX * damping;

    system.trailPoints[t].y += deltaY * damping;

  }

  

  // 获取第一个点（头部）和最后一个点（尾部）

  const head = system.trailPoints[0];

  const tail = system.trailPoints[5];

  

  const diffX = head.x - tail.x;

  const diffY = head.y - tail.y;

  const distance = Math.sqrt(diffX * diffX + diffY * diffY);

  

  let clipPathValue = '';

  

  if (distance < 10) { // 如果距离很近，显示圆形

    clipPathValue = `circle(200px at ${head.x}px ${head.y}px)`;

  } else {

    // 创建椭圆形的polygon，连接头尾两点

    const angle = Math.atan2(diffY, diffX); // 连接角度

    const points = [];

    

    // 从头部开始，画半个椭圆

    for (let i = 0; i <= 30; i++) {

      const theta = angle - Math.PI / 2 + Math.PI * i / 30;

      const x = head.x + 200 * Math.cos(theta);

      const y = head.y + 200 * Math.sin(theta);

      points.push(`${x}px ${y}px`);

    }

    

    // 从尾部开始，画另半个椭圆

    for (let i = 0; i <= 30; i++) {

      const theta = angle + Math.PI / 2 + Math.PI * i / 30;

      const x = tail.x + 200 * Math.cos(theta);

      const y = tail.y + 200 * Math.sin(theta);

      points.push(`${x}px ${y}px`);

    }

    

    clipPathValue = `polygon(${points.join(', ')})`;

  }

  

  return clipPathValue;

});

3.1.3 鼠标事件处理

实现了完整的鼠标交互逻辑，包括鼠标进入、离开和移动时的状态管理和动画控制。

4. 技术亮点

4.1 轨迹点系统算法

核心原理：使用6个轨迹点，每个点跟随前一个点移动，并应用不同的阻尼系数，实现平滑的拖尾效果。

技术优势：

• 实现了自然的物理运动效果，比简单的线性跟随更具视觉吸引力


• 通过阻尼系数的递减，创建出层次感和深度感


• 算法复杂度低，性能消耗小，适合实时交互场景

4.2 动态 Clip-Path 技术

核心原理：利用CSS clip-path属性的动态特性，结合轨迹点位置计算，实时生成不规则遮罩，替代Canvas/SVG的图形绘制方案，用更轻量化的方式实现复杂视觉效果。

技术优势：

• 无依赖轻量化：无需引入任何图形库，纯CSS+JS即可实现，减少项目依赖体积，降低集成成本


• 平滑过渡无卡顿：通过数值插值计算，实现圆形与椭圆形遮罩的无缝切换，无帧断裂感，视觉连贯性强


• 渲染性能优化：配合 will-change: clip-path 提示浏览器，提前分配渲染资源，减少重排重绘，提升动画流畅度

5. 性能优化

6. 总结与扩展

本次复刻的小米MiMo透视动画，核心价值在于“用简单技术组合实现高级视觉效果”——无需复杂图形库，仅依托Vue3响应式能力与CSS clip-path属性，就能打造出兼具质感与性能的交互组件。其核心亮点可概括为三点：

• 交互创新：轨迹点系统与动态clip-path结合，打破传统静态标题的交互边界，带来自然流畅的鼠标跟随体验


• 视觉精致：双层文字矩阵的分层设计，配合遮罩形变，营造出兼具深度感与品牌性的视觉效果


• 性能可控：轻量化技术方案+多维度优化策略，在保证视觉效果的同时，兼顾页面性能与可维护性

扩展方向

该组件的实现思路可灵活迁移至其他场景：

• 弹窗过渡动画：将clip-path遮罩用于弹窗进入/退出效果，实现不规则形状的过渡动画。


• 滚动动效：结合滚动事件替换鼠标事件，实现页面滚动时的元素透视跟随效果。


• 移动端适配：增加触摸事件支持，将鼠标交互替换为触摸滑动，适配移动端场景。

完整代码

<template>

  <div class="hero-container" @mouseenter="onMouseEnter" @mouseleave="onMouseLeave" @mousemove="onMouseMove">

    <div class="z-1">

      <div class="line" v-for="line in 13">

        <span class="line-item" v-for="item in 13">HELLO</span>

      </div>

    </div>

    <h1 class="title-1">你好，世界</h1>



    <!-- 第二个div，鼠标移入后需要显示的内容，通过clip-path:circle(0px at -300px -300px)达到隐藏效果 -->

    <div class="z-2" :style="{ 'clip-path': circleClipPath }">

      <div class="hidden-div">

        <div class="line" v-for="line in 13">

          <span class="line-item" v-for="item in 13">HELLO</span>

        </div>

      </div>

      <h1 class="title-2">HELLO , World</h1>

    </div>

  </div>

</template>



<script setup>

import { ref, computed, onMounted, onUnmounted } from 'vue'



const showCircle = ref(false)

const containerRef = ref(null)



const trailSystem = ref({

  targetX: 0,

  targetY: 0,

  trailPoints: Array(6)

    .fill(null)

    .map(() => ({ x: 0, y: 0 })),

  animationId: 0,

  isInside: false,

})



const circleClipPath = computed(() => {

  if (!showCircle.value) {

    return 'circle(0px at -300px -300px)'

  }



  // 复制轨迹系统数据进行计算

  const system = JSON.parse(JSON.stringify(trailSystem.value))



  // 更新轨迹点

  for (let t = 0; t < 6; t++) {

    const prevX = t === 0 ? system.targetX : system.trailPoints[t - 1].x

    const prevY = t === 0 ? system.targetY : system.trailPoints[t - 1].y

    const damping = 0.7 - 0.04 * t // 阻尼系数，后面的点移动更慢



    const deltaX = prevX - system.trailPoints[t].x

    const deltaY = prevY - system.trailPoints[t].y



    // 平滑插值

    system.trailPoints[t].x += deltaX * damping

    system.trailPoints[t].y += deltaY * damping

  }



  // 获取第一个点（头部）和最后一个点（尾部）

  const head = system.trailPoints[0]

  const tail = system.trailPoints[5]



  const diffX = head.x - tail.x

  const diffY = head.y - tail.y

  const distance = Math.sqrt(diffX * diffX + diffY * diffY)



  let clipPathValue = ''



  if (distance < 10) {

    // 如果距离很近，显示圆形

    clipPathValue = `circle(200px at ${head.x}px ${head.y}px)`

  } else {

    // 创建椭圆形的polygon，连接头尾两点

    const angle = Math.atan2(diffY, diffX) // 连接角度

    const points = []



    // 从头部开始，画半个椭圆

    for (let i = 0; i <= 30; i++) {

      const theta = angle - Math.PI / 2 + (Math.PI * i) / 30

      const x = head.x + 200 * Math.cos(theta)

      const y = head.y + 200 * Math.sin(theta)

      points.push(`${x}px ${y}px`)

    }



    // 从尾部开始，画另半个椭圆

    for (let i = 0; i <= 30; i++) {

      const theta = angle + Math.PI / 2 + (Math.PI * i) / 30

      const x = tail.x + 200 * Math.cos(theta)

      const y = tail.y + 200 * Math.sin(theta)

      points.push(`${x}px ${y}px`)

    }



    clipPathValue = `polygon(${points.join(', ')})`

  }



  return clipPathValue

})



// 动画循环函数

const animate = () => {

  if (showCircle.value) {

    // 更新轨迹点

    for (let t = 0; t < 6; t++) {

      const prevX = t === 0 ? trailSystem.value.targetX : trailSystem.value.trailPoints[t - 1].x

      const prevY = t === 0 ? trailSystem.value.targetY : trailSystem.value.trailPoints[t - 1].y

      const damping = 0.7 - 0.04 * t // 阻尼系数，后面的点移动更慢



      const deltaX = prevX - trailSystem.value.trailPoints[t].x

      const deltaY = prevY - trailSystem.value.trailPoints[t].y



      // 平滑插值

      trailSystem.value.trailPoints[t].x += deltaX * damping

      trailSystem.value.trailPoints[t].y += deltaY * damping

    }



    // 请求下一帧

    trailSystem.value.animationId = requestAnimationFrame(animate)

  }

}



const onMouseEnter = (event) => {

  const container = event.currentTarget

  const rect = container.getBoundingClientRect()

  const x = event.clientX - rect.left

  const y = event.clientY - rect.top



  showCircle.value = true



  // 初始化目标位置和轨迹点

  trailSystem.value.targetX = x

  trailSystem.value.targetY = y

  trailSystem.value.isInside = true



  // 初始化所有轨迹点到当前位置

  for (let i = 0; i < 6; i++) {

    trailSystem.value.trailPoints[i] = { x, y }

  }



  // 开始动画

  if (!trailSystem.value.animationId) {

    trailSystem.value.animationId = requestAnimationFrame(animate)

  }

}



const onMouseLeave = (event) => {

  const container = event.currentTarget

  const rect = container.getBoundingClientRect()

  const x = event.clientX - rect.left

  const y = event.clientY - rect.top



  showCircle.value = false

  trailSystem.value.isInside = false



  // 将目标点移出容器边界，使轨迹点逐渐拉回

  let targetX = x

  let targetY = y



  if (x <= 0) targetX = -400

  else if (x >= rect.width) targetX = rect.width + 400



  if (y <= 0) targetY = -400

  else if (y >= rect.height) targetY = rect.height + 400



  trailSystem.value.targetX = targetX

  trailSystem.value.targetY = targetY



  // 停止动画

  if (trailSystem.value.animationId) {

    cancelAnimationFrame(trailSystem.value.animationId)

    trailSystem.value.animationId = 0

  }

}



const onMouseMove = (event) => {

  if (showCircle.value) {

    const container = event.currentTarget

    const rect = container.getBoundingClientRect()

    const x = event.clientX - rect.left

    const y = event.clientY - rect.top



    trailSystem.value.targetX = x

    trailSystem.value.targetY = y

  }

}

</script>



<style scoped>

.hero-container {

  cursor: crosshair;

  background: #faf7f5;

  border-bottom: 1px solid #000;

  justify-content: center;

  align-items: center;

  width: 100%;

  height: 500px;

  display: flex;

  position: relative;

  overflow: hidden;

}



.z-1 {

  pointer-events: auto;

  -webkit-user-select: none;

  user-select: none;

  flex-direction: column;

  justify-content: flex-start;

  width: 100%;

  height: 100%;

  display: flex;

  position: absolute;

  top: 0;

  left: 0;

  overflow: hidden;

}



.z-1 .line {

  display: flex;

  align-items: center;

  white-space: nowrap;

  color: #0000000d;

  letter-spacing: 0.3em;

  flex-wrap: nowrap;

  font-size: 52px;

  font-weight: 700;

  line-height: 1.6;

  display: flex;

}



.z-1 .line-item {

  cursor: default;

  flex-shrink: 0;

  margin-right: 0.6em;

  transition:

    color 0.3s,

    text-shadow 0.3s;

  font-family: inherit !important;

}



.z-1 .line:nth-child(odd) {

  margin-left: -2em;

  background-color: rgb(245, 235, 228);

}



.title-1 {

  z-index: 1;

  color: #000;

  letter-spacing: 0.02em;

  text-align: center;

  margin: 0;

  font-size: 72px;

  font-weight: 700;

}



.z-2 {

  pointer-events: none;

  z-index: 10;

  will-change: clip-path;

  background: #000;

  justify-content: center;

  align-items: center;

  width: 100%;

  height: 100%;

  display: flex;

  position: absolute;

  top: 0;

  left: 0;

}



.z-2 .hidden-div {

  pointer-events: none;

  -webkit-user-select: none;

  user-select: none;

  flex-direction: column;

  justify-content: flex-start;

  width: 100%;

  height: 100%;

  display: flex;

  position: absolute;

  top: 0;

  left: 0;

  overflow: hidden;

}



.z-2 .hidden-div .line {

  white-space: nowrap;

  color: #ffffff1f;

  letter-spacing: 0.3em;

  flex-wrap: nowrap;

  font-size: 32px;

  font-weight: 700;

  line-height: 1.6;

  display: flex;

}



.z-2 .hidden-div .line:nth-child(odd) {

  margin-left: -0.5em;

}



.title-2 {

  font-size: 72px;

  color: #fff;

  letter-spacing: 0.02em;

  text-align: center;

  white-space: nowrap;

  margin: 0;

  font-size: 72px;

  font-weight: 700;

}

</style>

小米的前端一直很牛，非常有创意，我也通过F12学习源码体会到了新的思路，希望大家也多多关注小米和小米的技术～

Tailwind CSS的体量

Tailwind CSS有多火爆呢？

几组数据告诉你？

一组数据告诉你 Tailwind CSS 有多受欢迎：

1. github 86.1K的 Star, 足以证明它的受欢迎程度。
2. NPM 周下载量已突破 1000 万, 前端开发者的不二之选
3. 被无数大公司采用，如 GitHub、Vercel、Laravel 等。
4. 被很多框架和打包工具推荐，如Vite，Nuxt，React等

从数据上看，Tailwind CSS 已经成为前端开发的主流选择之一。

原子化CSS

什么是原子化CSS

原子化 CSS 是一种 CSS 架构，它提倡使用高度可复用的小类名，每个类名通常只控制单一的样式属性。例如：

<div class="text-red-500 font-bold p-4 text-[14px]">Hello Tailwinddiv>

其中：

• text-red-500: 代表文字颜色
• font-bold: 代表加粗
• p-4: 代表内边距
• text-[14px]: 代表字体大小为14px

这种方式避免了传统 CSS 中复杂的层叠规则，让样式控制更加直观。

原子化CSS和传统CSS的区别

说了这么一通，我相信用过的都说“真香”，用过一次后就离不开了。

关键是没用过的呢？是不是心里还在嘀咕。别急，正餐来了！

Tailwind CSS宝藏库

为什么说Tailwind CSS是一个宝藏，因为你担忧和抵触的地方，Tailwind CSS都给你解决了

类名难记

你可能在担忧，我是不是每次用都要查文档呢？那么多css好不容易记住了，现在又让我再学一遍？

答案是：不用。完全和你使用css一样简单。只需要记住几个关键字，智能提示帮你搞定

VS Code插件 - Tailwind CSS IntelliSense

HTML又长又乱

首先，不可否认，将所有的类名整合到html中，会让你的html变得比较长。但是，当你写的代码又长又乱的时候，你就要停下来想想

1. 是否违背了创作者的初衷
2. 架构是否设计不合理

为此，我们简单分析一下，到底是人的问题还是工具的问题。根据以上2点，分析一下你的HTML为什么又长又乱？

• 因为太长导致太乱

  没有合并之前，你的代码可能是这样的

  class="flex justify-center items-center">
  
      clsss="bg-blue-500 text-white py-2 px-4 rounded">提交
  
  
  
  

  合并后是这样的

  .flex-center {
  
    @apply flex justify-center items-center;
  
  }
  
  .btn-submit {
  
    @apply bg-blue-500 text-white py-2 px-4 rounded;
  
  }
  
  
  
  class="flex-center">
  
      clsss="btn-submit">提交
  
  
  
  

  现在是不是很清晰了呢？

  我敢说，只要你使用@apply合并类名，时刻记着复用样式，你的HMLT至少减少1/3，甚至也可以写出像诗一样的代码

• 因为没有分组和顺序性导致太乱

  没有顺序和分组的书写，是这样的

  <div class="p-2 font-bold text-[14px] mt-4 color-[#333333] bg-white">Hello world!div>
  
  

  想到哪写到哪，会让你的代码一眼望上去比较乱，时间长了，一眼看上去很难维护...

  下面我们就着手解决这2个问题

  1. 类排序

  使用 Prettier 进行类排序(Class sorting with Prettier)

  Tailwind CSS 维护了一个官方 Prettier 插件，它会自动按照我们的 推荐的类顺序 对你的类进行排序。

  使用插件后，代码这样的

  <div class="bg-white color-[#333333] mt-4 p-2 text-[14px] font-bold">Hello world!div>
  
  

  现在是不是清晰很多了呢？

  不过还不够

  2. 分组

我们根据样式进行的类别分组，比如颜色，字体，定位，间距等等，每个类别一行，这样你写出的代码会清晰无比

<div class="

    bg-white color-[#333333]

    mt-4 p-2

    text-[14px] font-bold">

Hello world!div>

现在代码是不是清晰的多了

全局类名

不用担心公共类的问题，@apply帮你搞定。

使用 @apply 合并类，前面已经讲过了，就不展开了

样式冲突

也许你还在担心tailwind 的 class 名和我已有的 class 冲突了咋办？我怎么处理兼容问题

别担心，给你的类名加个前缀prefix就搞定了

@import "tailwindcss" prefix(tw);



<div class="tw:flex tw:bg-red-500 tw:hover:bg-red-600"> div>

拥抱Tailwind CSS

Tailwind CSS为什么受到追捧

1. 再也不用忍受css上下切换的痛苦了
2. 再也不用花时间去取语义化类名了

   不用纠结container, wrapper, box等被使用的问题后，如何起名的问题了

3. 为了加权重，不断的加父级类名，甚至!important，永远不知道哪个样式起作用了。冗长的css让项目很难维护！
4. 简单完成伪类、伪元素、媒体查询等变体的书写

Tailwind CSS、PrimeFlex、UnoCSS评测

在CSS工具类框架中，除了Tailwind CSS之外，还有其他很多工具类。如PrimeFlex和UnoCSS，它们各有特点，下面我简单的评测一下

• PrimeFlex: 生态系统较小，多适用于Prime生态，如PrimevVue，PrimeReact。样式和较Tailwind CSS低。只能构建起简单样式框架。最让我吐槽的是，样式竟然用!important。你想替换某个属性，麻烦程度想骂人！

• UnoCSS: 未构建良好的生态系统，多用于自定义规则和项目优化

总结

TailwindCSS 已经成为前端开发的趋势之一，随着4.0 版本的发布，它的性能更强大、使用更方便。如果你还在抵触，不妨试试看，它可能会彻底改变你的 CSS 编写方式！

作者：高志小鹏鹏
来源：juejin.cn/post/7480734875723415552

前几天收到一个bug，说是后台管理系统每次切换标签栏后，xxx内容区自动刷新，操作进度也丢失了，给用户造成很大困扰。作为结丹期修士的我自然不容允许此等存在，开干！

问题分析

该后台管理系统基于 vue3 全家桶开发，多标签页模式，标签页默认 KeepAlive，本文以 demo 示例。

切换标签后内容区自动刷新，操作进度丢失？首先想到的是 KeepAlive 问题，但经过排查后才发现，KeepAlive 是正常的，异常的是内嵌于页面的 iframe 内容区，页面每次 onActivated 时，iframe 内容区都会重新加载一次，导致进度丢失。

iframe 并没有被 keep 住，为什么？

通过查阅 Vue 文档得知，KeepAlive缓存的只是 Vue 组件实例，组件实例包含组件状态和 VNode (虚拟 DOM 节点)等。当组件 activated 时，组件 VNode 已经转为真实 DOM 节点插入文档中了，而组件 deactivated 时，已经从文档中移除了组件对应的真实 DOM 节点并缓存组件实例。

VNode 是对真实 DOM 节点的映射，包含节点标签名、节点属性等信息。我们打开控制台选中 iframe 元素，右侧那栏就是其对应的 VNode 了。

从上图可看出，iframe 的内容并不属于节点信息，是个独立的 browsing context（浏览上下文），无法被缓存；iframe 每次渲染（如 DOM 节点插入、移动）都会触发完整的加载过程（相当于打开新窗口）。故组件每次 activated 时，iframe 都会重新加载，创建了新的上下文，之前的操作进度自然是丢失了。

至此，问题原因已找到，接下来看下如何处理。

解决方案

iframe 无法保存于 VNode 中，又不能将 iframe 从文档中移动或移除，那么就想办法在某个地方把 iframe 存起来，比如 body 节点下，然后通过样式控制 iframe 展示与隐藏，顺着思路捋一下整体流程。

有了上述流程，开始设计下细节。 Iframe 组件是对 iframe 操作流的封装，方便在 vue 项目中使用，内部涉及 iframe 创建、插入、设置样式、移除等操作，为方便操作，将其封装为 Iframe 类；分散的 Iframe 类操作，稍有不当可能造成内存占用过多，故为了统一管理，再设计一个 IframeManage 来统一管理 Iframe。

相关的类关系图如下

classDiagram

    class Iframe {

        -instance: HTMLIFrameElement

        -ops: IframeOptions

        +init()

        +hide()

        +show(rect: IFrameRect)

        +resize(rect: IFrameRect)

        +destroy()

    }



    class IFrameManager {

        +static frames: Map<string, Iframe>

        +static createFrame()

        +static showFrame()

        +static hideFrame()

        +static destroyFrame()

        +static resizeFrame()

        +static getFrame()

    }



    class VueComponent {

        -frameContainer: Ref

        +createFrame()

        +destroyFrame()

        +showFrame()

        +resizeFrame()

        -handleLoaded()

        -handleError()

    }



    VueComponent --> IFrameManager : 使用

    IFrameManager --> Iframe : 创建/管理

    Iframe --> HTMLIFrameElement : 封装

对应的时序图如下

sequenceDiagram

    participant VueComponent

    participant IFrameManager

    participant Iframe

    participant DOM

    

    VueComponent->>IFrameManager: createFrame()

    IFrameManager->>Iframe: new Iframe(ops)

    Iframe->>DOM: createElement('iframe')

    Iframe->>DOM: appendChild()

    VueComponent->>IFrameManager: resizeFrame()

    IFrameManager->>Iframe: resize()

    Iframe->>DOM: setElementStyle()

    VueComponent->>IFrameManager: destroyFrame()

    IFrameManager->>Iframe: destroy()

    Iframe->>DOM: remove()

至此思路清晰，开始进入编码

编码实战

首先是 Iframe 类的实现

interface IframeOptions {

  uid: string

  src: string

  name?: string

  width?: string

  height?: string

  className?: string

  style?: string

  allow?: string

  onLoad?: (e: Event) => void

  onError?: (e: string | Event) => void

}



type IframeRect = Pick<DOMRect, 'left' | 'top' | 'width' | 'height'> & { zIndex?: number | string }



class Iframe {

  instance: HTMLIFrameElement | null = null

  constructor(private ops: IframeOptions) {

    this.init()

  }

  init() {

    const {

      src,

      name = `Iframe-${Date.now()}`,

      className = '',

      style = '',

      allow,

      onLoad = () => {},

      onError = () => {},

    } = this.ops



    this.instance = document.createElement('iframe')

    this.instance.name = name

    this.instance.className = className

    this.instance.style.cssText = style

    this.instance.onload = onLoad

    this.instance.onerror = onError

    if (allow) this.instance.allow = allow

    this.hide()

    this.instance.src = src

    document.body.appendChild(this.instance)

  }

  setElementStyle(style: Record<string, string>) {

    if (this.instance) {

      Object.entries(style).forEach(([key, value]) => {

        this.instance!.style.setProperty(key, value)

      })

    }

  }

  hide() {

    this.setElementStyle({

      display: 'none',

      position: 'absolute',

      left: '0px',

      top: '0px',

      width: '0px',

      height: '0px',

    })

  }

  show(rect: IframeRect) {

    this.setElementStyle({

      display: 'block',

      position: 'absolute',

      left: rect.left + 'px',

      top: rect.top + 'px',

      width: rect.width + 'px',

      height: rect.height + 'px',

      border: '0',

      'z-index': String(rect.zIndex) || 'auto',

    })

  }

  resize(rect: IframeRect) {

    this.show(rect)

  }

  destroy() {

    if (this.instance) {

      this.instance.onload = null

      this.instance.onerror = null

      this.instance.remove()

      this.instance = null

    }

  }

}

其次是 IFrameManager 类的实现

export class IFrameManager {

  static frames = new Map()

  static createFame(ops: IframeOptions, rect: IframeRect) {

    const existFrame = this.frames.get(ops.uid)

    if (existFrame) {

      existFrame.destroy()

    }

    const frame = new Iframe(ops)

    this.frames.set(ops.uid, frame)

    frame.show(rect)

    return frame

  }

  static showFrame(uid: string, rect: IframeRect) {

    const frame = this.frames.get(uid)

    frame?.show(rect)

  }

  static hideFrame(uid: string) {

    const frame = this.frames.get(uid)

    frame?.hide()

  }

  static destroyFrame(uid: string) {

    const frame = this.frames.get(uid)

    frame?.destroy()

    this.frames.delete(uid)

  }

  static resizeFrame(uid: string, rect: IframeRect) {

    const frame = this.frames.get(uid)

    frame?.resize(rect)

  }

  static getFrame(uid: string) {

    return this.frames.get(uid)

  }

}

最后是 Iframe 组件的实现

<template>

  <div ref="frameContainer" class="k-frame">

    <span v-if="!src" class="k-frame-tips">

      <slot name="placeholder">暂无数据</slot>

    </span>

    <span v-else-if="isLoading" class="k-frame-tips">

      <slot name="loading">加载中... </slot>

    </span>

    <span v-else-if="isError" class="k-frame-tips"> <slot name="error">加载失败 </slot></span>

  </div>

</template>

<script setup lang="ts">

import { onActivated, onBeforeUnmount, onDeactivated, ref, watch } from 'vue'

import { IFrameManager, getIncreaseId } from './core'

import { useResizeObserver, useThrottleFn } from '@vueuse/core'



defineOptions({

  name: 'KFrame',

})



const props = withDefaults(

  defineProps<{

    src: string

    zIndex?: string | number

    keepAlive?: boolean

  }>(),

  {

    src: '',

    keepAlive: true,

  },

)



const emits = defineEmits(['loaded', 'error'])



const uid = `kFrame-${getIncreaseId()}`

const frameContainer = ref()

const isLoading = ref(false)

const isError = ref(false)

let readyFlag = false



const getFrameContainerRect = () => {

  const { x, y, width, height } = frameContainer.value?.getBoundingClientRect() || {}

  return {

    left: x || 0,

    top: y || 0,

    width: width || 0,

    height: height || 0,

    zIndex: props.zIndex ?? 'auto',

  }

}



const createFrame = () => {

  isError.value = false

  isLoading.value = true



  IFrameManager.createFame(

    {

      uid,

      name: uid,

      src: props.src,

      onLoad: handleLoaded,

      onError: handleError,

      allow: 'fullscreen;autoplay',

    },

    getFrameContainerRect(),

  )

}

const handleLoaded = (e: Event) => {

  isLoading.value = false

  emits('loaded', e)

}

const handleError = (e: string | Event) => {

  isLoading.value = false

  isError.value = true

  emits('error', e)

}



const showFrame = () => {

  IFrameManager.showFrame(uid, getFrameContainerRect())

}

const hideFrame = () => {

  IFrameManager.hideFrame(uid)

}

const resizeFrame = useThrottleFn(() => {

  IFrameManager.resizeFrame(uid, getFrameContainerRect())

})



const destroyFrame = () => {

  IFrameManager.destroyFrame(uid)

}



const getFrame = () => {

  return IFrameManager.getFrame(uid)

}



useResizeObserver(frameContainer, () => {

  resizeFrame()

})



onBeforeUnmount(() => {

  destroyFrame()

  readyFlag = false

})



onDeactivated(() => {

  if (props.keepAlive) {

    hideFrame()

  } else {

    destroyFrame()

  }

})



onActivated(() => {

  if (props.keepAlive) {

    showFrame()

    return

  }

  if (readyFlag) {

    createFrame()

  }

})



watch(

  () => [frameContainer.value, props.src],

  (el, src) => {

    if (el && src) {

      createFrame()

      readyFlag = true

    } else {

      destroyFrame()

      readyFlag = false

    }

  },

  {

    immediate: true,

  },

)



defineExpose({

  getRef: () => getFrame()?.instance,

})

</script>



<style lang="scss" scoped>

.k-frame {

  position: relative;

  display: flex;

  align-items: center;

  justify-content: center;

  width: 100%;

  height: 100%;



  &-tips {

    position: absolute;

    top: 50%;

    left: 50%;

    transform: translate(-50%, -50%);

  }

}

</style>

看看效果

小结

管理后台多页签切换，iframe 区操作进度丢失，根本原因在于 KeepAlive 缓存机制与iframe 的独立浏览上下文特性存在本质冲突。本文通过物理隔离与视觉映射的双重策略，将 iframe 的真实 DOM 节点与Vue 组件实例解耦，实现了 keepAlive 的效果。

当然，该方案在代码实现还有很大优化空间，如 IFrameManager 目前是单例模式、Iframe 池未设计淘汰缓存机制（如 LRU ）。嘀嘀嘀...产品催着上线了，没时间优化了，下次一定。

相关代码已上传只 github，欢迎道友们给个 star，在此谢过了

我们最近刚把一个后台系统从 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？三个月重构项目教会我的事》

🎯 总结对比

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 行搞定！

系列回顾（性能·错误·埋点三部曲）：不做工具人｜从 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、用户手机号）进行脱敏处理，这是红线。

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

在日常的大前端需求开发中，我们常常需要同时兼顾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 谈判，我会全程帮你针对性提升，让你在众多求职者中脱颖而出，顺利拿下心仪岗位

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