企业官网建设流程全解析

上周帮同事看一个线上问题：他在el-color-picker的 change 回调里直接发保存请求，用户拖一次色相滑块，后端日志里刷刷刷多出三十多条记录。他以为是组件重复触发，其实是把active-change该干的活派给了change，两个事件的触发时机根本不是一回事。颜色选择器在后台系统里出镜率极高——主题配置、标签色、商品色号、图表配色，凡是让用户挑颜色的地方基本都有它，但它也属于"看着简单、用起来到处是细节"的那类组件：color-format选哪个、开了show-alpha之后值会变成什么样、两百行的表格里挂两百个会不会卡、表单校验怎么接，这些文档里都写得比较轻。这篇把我这些年在项目里和它相关的坑整理一遍，Element UI 和 Element Plus 两个版本的差异也一并说清楚，刚上手的前端可以照着抄，用了几年的人也能挑出几条没注意过的。

1. 一次拖动触发三十次请求：先拆开 el-color-picker 的 DOM 结构

很多人用这个组件的方式是"扔一个 v-model 上去，能用就行"，直到遇到样式改不动、定位偏了、页面卡了，才开始回头研究它到底渲染了什么。我建议一开始就把它当成两个独立区域来看：一个是常驻在文档流里的触发块，另一个是按需显示的弹层。理解这个划分，后面章节里的绝大部分问题都能自己推出来。

1.1 触发块和弹层，是两套独立的渲染逻辑

触发块就是页面上那个小方块，它的背景色跟着 v-model 走。当值为空（null 或空字符串）时，方块会显示成一个带斜线的空状态；当值带透明度（alpha 为 0 或者颜色本身就是 transparent）时，方块底下会铺一层灰白棋盘格，用来暗示"这里是透明的"。这一步是纯 CSS 实现的，没有额外的 DOM 开销。

弹层里则是真正干活的部分：一块饱和度和明度平面、一根色相滑条、一根透明度滑条（show-alpha为 true 时才出现）、一个可手动输入的文本框、一排预设色块，以及底部一个清空按钮。这块面板的 DOM 结构比触发块重得多，里面挂着若干绝对定位的滑块和输入控件。关键在于：每个 color-picker 实例都会渲染自己的一份面板 DOM，哪怕你从来没点开过它。这个特性在单页面上放一两个时毫无感觉，放到表格里就是另一回事了，第 6 章会详细说。

另外，弹层默认是挂到 body 下面的（Element Plus 里由teleported控制，默认 true）。所以你在组件外面包一层overflow: hidden的容器，面板不会被裁掉；但也正因为挂在 body 上，弹层和触发块之间隔了好多层 DOM，想用普通的父子选择器改面板样式是改不动的，必须走popper-class。

1.2 属性清单：哪些是必看，哪些可以先放

把常用属性过一遍，心里有个数：

我自己最常调整的是popper-class和color-format这两个，前者决定面板长什么样，后者决定数据怎么流进后端。其余的属性大部分情况下保持默认就行。

1.3 Element UI 和 Element Plus 的差异，迁移前先对一遍

项目从 Vue 2 升到 Vue 3、组件库从 Element UI 换成 Element Plus 的时候，颜色选择器这块有几个地方会直接报错或者行为变了，我在迁移时踩过：

size那一栏是最容易在迁移时漏掉的，因为 Vue 2 时代的size="mini"写得到处都是，升上去以后直接失去效果，而且不会报错，只有当你对着设计稿量尺寸时才发现不对。习惯做法是全局搜一遍size="mini"和size="medium"，统一换成small和large，或者干脆不写 size，用 CSS 控制。

2. color-format 的三个选项：hex、rgb、hsl 到底该选哪个

这个属性看起来只是个格式化开关，实际它同时影响三件事：v-model 写回的值、输入框里显示的内容、change 和 active-change 事件里带出来的参数。选错了，后端存进去的数据格式就会五花八门。

2.1 面板内部算的是 HSV，对外输出才是你选的那个格式

不管是哪种输出格式，面板内部用的都是 HSV 模型来做交互：拖动饱和度和明度平面改的是 S 和 V，拖色相条改的是 H。之所以内部不用 RGB，是因为在 RGB 空间里拖滑块，颜色的变化非常不直观，用户想调一个"暗一点的蓝"，在 HSV 里只要把 V 往下拉，在 RGB 里就得同时改三个通道，体验完全不一样。

只有在你确认颜色、或者面板内部状态发生变化时，组件才会把 HSV 转成你指定的格式往外抛。所以换个角度理解：color-format是出口格式，不是内部数据结构。这意味着你可以放心地根据业务需要选格式，不用担心影响交互。

选型上我的经验是这样的：需要存数据库、需要写进配置文件、需要跟设计规范里的色值对齐的，一律用hex；需要直接拼进 CSS 变量或者 canvas 上下文的，用rgb能少一次转换；hsl在需要做"同色系微调"的场景里很好用，比如生成一组同色相不同明度的图表系列色，直接对 H 和 L 做加减法比在 RGB 里算要轻松得多。

2.2 带透明度的 hex 是 8 位，别被后端的正则拦下来

这是我最想强调的一个点。开着show-alpha且color-format为hex的时候，我实测过的几个版本里，写回的值会变成 8 位十六进制，形如#409EFF80，最后两位就是 alpha 通道。而很多后端同学在写校验规则时，脑子里想的是 6 位：

// 只认 6 位的正则，遇到 8 位直接判非法 const COLOR_RE = /^#([0-9a-fA-F]{6})$/;

结果就是前端页面上用户选了个半透明色，提交时接口报参数不合法，而前端同学看着控制台一脸茫然。这个问题排查起来不难，但发现之前会浪费不少时间。我的处理办法是在前端做一次收敛，无论组件吐出什么，统一转换成后端认的格式再提交。

顺带一提rgb格式在开启透明度后的输出形态是rgba(64, 158, 255, 0.5)，字符串里带逗号和空格，如果后端字段长度卡得很紧（比如 varchar(7)），同样会写不进去。数据库字段建议至少给到 32 位，避免以后加透明度时还要改表。

2.3 一套颜色工具函数，把各种输出格式收敛到一种

与其在每个业务页面里各写各的转换，不如在项目里放一个统一的颜色工具模块。下面这几段是我现在项目里在用的，可以直接拿去：

// 6 位 hex 转 rgb 对象 function hexToRgb(hex) { const clean = hex.replace('#', '') const full = clean.length === 3 ? clean.split('').map(c => c + c).join('') : clean.slice(0, 6) return { r: parseInt(full.slice(0, 2), 16), g: parseInt(full.slice(2, 4), 16), b: parseInt(full.slice(4, 6), 16) } } // rgb 转 6 位 hex function rgbToHex(r, g, b) { const toHex = n => Math.round(n).toString(16).padStart(2, '0') return `#${toHex(r)}${toHex(g)}${toHex(b)}`.toUpperCase() } // 取出 8 位 hex 里的 alpha，返回 0~1 的数值 function alphaFromHex8(hex) { const clean = hex.replace('#', '') if (clean.length !== 8) return 1 return parseInt(clean.slice(6, 8), 16) / 255 } // 统一收敛：不管进来什么格式，都输出 #RRGGBB 大写 function normalizeColor(input) { if (!input) return '' if (input.startsWith('#')) { const clean = input.replace('#', '') if (clean.length === 3) { return `#${clean.split('').map(c => c + c).join('')}`.toUpperCase() } return `#${clean.slice(0, 6)}`.toUpperCase() } const match = input.match(/rgba?\(([^)]+)\)/) if (match) { const [r, g, b] = match[1].split(',').map(v => parseFloat(v)) return rgbToHex(r, g, b) } return input }

这套函数的关键是normalizeColor这个统一入口：组件输出什么格式都往里丢，出来永远是标准 6 位大写 hex。业务层只认这一种格式，后端校验规则也只需要维护一条。透明度如果确实要保留，就单独存一个 alpha 字段，比塞在颜色字符串里更利于查询和统计——毕竟在数据库里对#409EFF80做分组统计是很别扭的。

3. change 和 active-change 的分工：一个用于提交，一个用于预览

回到开头那个问题。这两个事件的名字起得很接近，功能描述读起来也像，但触发频率差了不止一个数量级。

3.1 两个事件的触发频率差多少

我的实测体会是：在面板里拖动色相条或者饱和度平面时，active-change会跟着鼠标连续触发，一秒内触发几十次很正常；而change是值确定下来之后才触发一次。所以判断标准很简单——这个回调里做的事情，能不能承受一秒执行三十次？

不能的话就放change。典型的错误用法包括：在active-change里发保存请求、在active-change里写 localStorage、在active-change里改全局主题变量并且触发大面积重排。这三种我都见过，前两种会把后端和浏览器存储写爆，第三种会让页面在拖动时明显掉帧。

反过来说，active-change有一个非常合适的用法：实时预览。用户拖动滑块的时候，页面上的预览区域跟着变色，用户能直观看到效果，等到松手或者确认时才真正提交。这种"所见即所得"的交互体验，用change是做不出来的，因为它在拖动过程中根本不触发。

3.2 实时预览主色的正确写法

假设你在做一个主题配置页，用户选的主色要实时反映到页面按钮上。直接这样写是有问题的：

// 不推荐：每次 active-change 都直接写变量 function onActiveChange(color) { document.documentElement.style.setProperty('--el-color-primary', color) // 还要重新计算 light-3、light-5 等一堆色阶... }

拖动时每秒写几十次 CSS 变量，浏览器要反复重新计算样式，在低端设备上会明显卡顿。改进的办法是用requestAnimationFrame做合并，保证一帧最多写一次：

let pending = null let rafId = 0 function applyPrimary(color) { pending = color if (rafId) return rafId = requestAnimationFrame(() => { rafId = 0 if (pending) { document.documentElement.style.setProperty('--el-color-primary', pending) // 色阶的计算放到这里统一做 } }) }

这个技巧在别的场景也通用：凡是高频事件里要做 DOM 写入或者样式计算的，先想一想能不能合并到帧里。写 CSS 变量本身很便宜，贵的是它引起的样式重算和重绘，合并之后拖动的顺滑度会有肉眼可见的改善。

3.3 提交侧要做防抖和去重

change虽然触发次数少，但不代表可以不做保护。用户完全可能选了一个颜色，想一想又选回原来的值，这时候change会带着相同的颜色再触发一次。如果每次 change 都发请求，就产生了无意义的重复写入。

let lastSubmitted = '' function onChange(color) { const normalized = normalizeColor(color) if (normalized === lastSubmitted) return lastSubmitted = normalized saveTheme(normalized) }

再叠一层 300 毫秒左右的防抖会更稳，防止用户快速点几个预设色块时连续发请求。另外要注意，如果这个颜色会从服务端拉取初始化，记得在初始化赋值时把lastSubmitted同步设成初始值，否则第一次拉到数据后紧接着触发一次 change，会把刚拉到的值原样再提交一遍。

4. predefine 预设色板：从随手填几个颜色到品牌规范落地

预定义色块是提升体验最快的一个配置。用户不想纠结具体的色值，只想快速挑一个"看起来合适"的，这时候一排预设色的价值就体现出来了。

4.1 predefine 接受什么，面板怎么排

predefine接收一个数组，里面放颜色字符串。实测下来带#的十六进制最稳，三位缩写和八位带 alpha 的写法我建议都别放，不同版本对它们的解析可能有细微差别，统一用六位大写最省心。数组长度控制在 8 到 16 个之间比较合适：8 个刚好排一行，16 个排两行。超过两行以后面板会变得很长，在小屏幕上可能超出视口，用户还得滚动才能看到输入框，反而不方便。

预设色块的点击行为也值得留意一下：点一下色块，值会立即更新，同时触发change。这意味着如果你的提交逻辑放在 change 里，用户点色块就等于直接提交了，不需要再点确认。这个行为符合大多数人的预期，但如果你的业务需要"选完再点保存"，就得把提交逻辑挪到自己的保存按钮上，change 里只做暂存。

4.2 用结构化字典管理预设色，而不是裸数组

一开始大家通常这么写：

// 能跑，但过一个月就没人记得每个色值代表什么了 const presets = ['#409EFF', '#67C23A', '#E6A23C', '#F56C6C', '#909399']

问题在于色值本身没有语义。运营问"我想加一个新品类的标签色"，你得先去翻设计稿找对应色值，再数一下它是第几个。改成结构化的写法就清楚多了：

const presetPalette = [ { name: '品牌主色', value: '#409EFF' }, { name: '成功', value: '#67C23A' }, { name: '警告', value: '#E6A23C' }, { name: '危险', value: '#F56C6C' }, { name: '信息', value: '#909399' } ] // 传给组件的还是纯色值数组 const predefineColors = presetPalette.map(item => item.value)

字典在业务层维护，传给组件的时候再 map 成数组。这样以后要做"鼠标悬停显示颜色名称"之类的小功能，数据是现成的；要跟设计系统对齐，也只需要维护这一份字典。我更推荐把这套色值从设计稿的变量文件里导出成 JSON，而不是手抄进代码，手抄的色值迟早会和设计稿漂移。

4.3 加一栏"最近使用"，注意去重时的三个坑

预设色之外，加上"最近使用过的颜色"是很讨喜的功能，实现思路也简单：在 change 里把颜色塞进一个数组，存进 localStorage，取前 N 个作为预设色的一部分。真正麻烦的是去重，这里有三个坑：

• 大小写不一致：#409eff和#409EFF是同一个颜色，但字符串比较不相等。去重前必须统一转成大写。
• 三位和六位混用：#fff和#ffffff也是同一个颜色。要么全部展开成六位，要么去重时做归一化。
• 带不带透明度：开了show-alpha之后，#409EFF和#409EFF80视觉上完全不同，这两个不应该算重复，但如果你用normalizeColor把它们都截成六位，就会误判成同一个颜色。这时候去重逻辑要基于原始值，而不是归一化后的值。

我的做法是去重时用一个"规范键"：六位 hex 加透明度后缀，但键的生成逻辑和用于显示的格式分开。看起来多写了几行，但避免了用户选了一个半透明色、下次打开发现它变成了不透明色这种诡异情况。

5. 接进 el-form 时的空值、校验和手输兜底

颜色选择器放进表单里，麻烦事就来了。它不是输入框，没有内置的clearable，空值的表现也和普通表单项不太一样。

5.1 null、空字符串和 undefined 在组件里的表现

组件内部做取值时，通常会把假值统一处理成空状态，所以null、undefined、空字符串三个值在触发块上的显示效果是一样的——都是那个带斜线的空方块。但它们在你自己的代码里含义完全不同：null通常表示"用户主动清空了颜色"，undefined表示"这个字段压根没赋值"，空字符串表示"接口返回的是空字符串"。

我的建议是业务层统一用 null 表示空。初始化时把接口返回的空字符串转成 null，提交时也把 null 原样传给后端，别混着用。混用的直接后果是判空逻辑到处漏，if (color)和if (color !== null)写得不一致，最后表单校验和防重复提交都会出问题。

至于清空的操作入口，面板底部有一个清空按钮，点下去之后会把值置成空。实测在不同版本里，置成的具体值是 null 还是空字符串有差异，所以别依赖这个细节，在 change 回调里先做一次归一：

function onChange(color) { // 空值统一收敛成 null const value = !color ? null : normalizeColor(color) form.color = value }

5.2 校验规则怎么写，trigger 用哪个

颜色字段的校验规则，我一般写两条：必填和格式。格式校验用正则比用内置的 type 更可靠，因为颜色字符串在表单校验体系里没有对应的类型。

const rules = { color: [ { required: true, message: '请选择主题色', trigger: 'change' }, { pattern: /^#([0-9A-Fa-f]{6})$/, message: '颜色格式不正确', trigger: 'change' } ] }

trigger用change就够了，因为颜色选择器不会触发 blur 相关的校验时机。如果开了show-alpha且允许半透明色，正则要放宽到 8 位，否则用户选完半透明色直接提示格式错误，体验很差。

还有一个点：validate-event这个属性控制的是"值变化时要不要顺手触发一次表单校验"。默认是 true，小表单里没问题；但如果你的校验规则里有异步请求（比如查颜色是否已被占用），或者在弹窗里做实时校验，建议把它设成 false，改成在提交前统一 validate，能省掉很多并发校验带来的状态混乱。

5.3 手输非法值的实际行为和后端兜底

面板上的输入框是允许手动输入的。用户在里面敲一段乱七八糟的字符是什么反应？实测是组件会尝试解析，解析不出来时不会把非法值写进 v-model，触发块的颜色也不变。也就是说前端的 v-model 里基本不会出现非法字符串，这是个让人安心的设计。

但"前端不会产生非法值"不等于"后端不用校验"。有几种情况前端管不住：用户直接调接口绕过页面、老数据里存着历史遗留的奇怪色值、数据迁移时格式没对齐。所以后端该有的正则校验一个都不能少，字段长度也要留足，前面提过的 8 位 hex 和 rgba 字符串都比 6 位长。

6. 长列表里的性能与定位：每个 picker 都自带一份面板 DOM

这是我在真实项目里被坑得最惨的一个点，值得单独拿出来说。

6.1 为什么两百行的表格会卡

前面说过，每个el-color-picker实例都会渲染一份完整的弹层 DOM，不管你打不打开。单页面上放三五个，这点开销可以忽略；放到表格的每一行里，就是另一番景象了。我在一台普通办公本上做过粗略对比：二十行左右基本感觉不出来，五十行开始切换标签页时能感到轻微的顿挫，两百行的时候整个页面打开要等上一两秒，滚动也不够跟手。

原因很好理解：两百个实例，每个都带一套滑块和输入框的 DOM 结构，再加上组件内部的响应式数据、事件监听和计算属性，初始化的工作量是线性叠加的。而这些面板里，用户实际操作的可能只有一两个。

6.2 用一个色块占位，面板按需渲染

既然瓶颈在"每个实例都预渲染面板"，思路就很自然了：行内只放一个纯 CSS 的色块，点击时才渲染真正的颜色选择器。具体做法有两种。

第一种是懒渲染：行内渲染一个 div，背景色绑当前值，点击时把这一行的 id 记下来，用一个v-if控制真正的 picker 渲染。缺点是每次点击都要重新创建组件，弹层有轻微的展开延迟。

第二种是我更推荐的复用方案：整个表格只保留一个 picker 实例，行内色块被点击时，把当前行的值和位置传给这个共享的 picker，让它弹在对应位置。这个方案省掉了所有多余实例，代价是要自己处理"当前编辑的是哪一行"这个状态，以及弹层定位的计算。实现上可以把 picker 放在 body 下，用鼠标点击时的getBoundingClientRect定位，关闭时把值写回对应行。

// 行内色块点击，记录当前编辑目标 function handleCellClick(row, event) { editingRowId.value = row.id anchorRect.value = event.target.getBoundingClientRect() // 触发共享 picker 显示 pickerVisible.value = true }

如果你的表格超过一百行、每行都有颜色字段，这个优化带来的收益非常明显。数据量小的时候别过度设计，直接放 picker 反而代码更简单。

6.3 弹层被裁掉或者位置跑偏，先查定位上下文

颜色选择器的面板默认挂在 body 下，所以一般的overflow: hidden容器裁不到它。但有一种情况例外：祖先元素上有 transform、filter 或者 will-change 属性。这几个属性会让内部的定位基准从视口变成该元素本身，表现就是弹层位置整体偏移，或者跟着页面滚动乱飘。

我在一个带侧滑动画的抽屉里遇到过这个问题：抽屉本身用了 transform 做位移动画，放进里面的颜色选择器弹层直接歪到了屏幕外面。排查思路是打开元素审查，先看弹层实际挂在哪个父节点下，再往上看这个父节点有没有 transform 相关的样式。解决方案要么是动画结束后移除 transform，要么是把 picker 写在不带 transform 的外层，通过外部状态控制它的位置。

还有一种情况是页面有多层弹窗嵌套，z-index 打架，面板被上层遮住。这种时候用popper-class给面板加一个更大的 z-index 就能解决，别去动全局的层级配置，那样很容易连锁影响其他组件。

7. 让用户选的主色长成一套色阶：CSS 变量的计算与落地

颜色选择器最典型的进阶用法，就是让用户挑一个主色，整个系统跟着变。只改一个变量是不够的，因为按钮的悬停态、禁用态、浅色背景、边框描边用到的都是不同深浅的色阶。

7.1 Element 用到的那几档色阶是怎么算出来的

如果你打开过主题相关的样式文件，会看到这么一组变量：--el-color-primary-light-3、light-5、light-7、light-8、light-9，以及--el-color-primary-dark-2。它们的生成规则是在主色里混入白色或黑色：

理解了这个规则，你就可以在运行时用 JavaScript 把这套色阶算出来，而不是依赖编译期的样式文件。数值越大越浅这个规律记住就行，light-9 已经非常接近白色了，通常用作浅色背景。

7.2 混色函数的实现和变量写入

function mixColor(baseHex, mixHex, weight) { const a = hexToRgb(baseHex) const b = hexToRgb(mixHex) const r = a.r * (1 - weight) + b.r * weight const g = a.g * (1 - weight) + b.g * weight const bl = a.b * (1 - weight) + b.b * weight return rgbToHex(r, g, bl) } const WHITE = '#FFFFFF' const BLACK = '#000000' function applyThemeColor(primary) { const root = document.documentElement const color = normalizeColor(primary) root.style.setProperty('--el-color-primary', color) root.style.setProperty('--el-color-primary-light-3', mixColor(color, WHITE, 0.3)) root.style.setProperty('--el-color-primary-light-5', mixColor(color, WHITE, 0.5)) root.style.setProperty('--el-color-primary-light-7', mixColor(color, WHITE, 0.7)) root.style.setProperty('--el-color-primary-light-8', mixColor(color, WHITE, 0.8)) root.style.setProperty('--el-color-primary-light-9', mixColor(color, WHITE, 0.9)) root.style.setProperty('--el-color-primary-dark-2', mixColor(color, BLACK, 0.2)) }

这套计算配合前面第 3 章的requestAnimationFrame合并，就能做出拖动滑块时整个页面主色实时变化的效果。实测算下来性能是可以接受的，一次色阶计算只有几次字符串解析和数值运算。

注意：这里用到的hexToRgb、rgbToHex、normalizeColor就是第 2 章里那几个函数，放在一个工具模块里复用，别在页面里重新实现一遍，不然混色结果和归一化结果容易对不上。

7.3 暗色模式的方向是反的，还有首屏闪烁

有两个地方必须提醒。第一是暗色模式。浅色主题下 light-3 到 light-9 是往白色方向混，因为背景是白的；到了深色背景上，这套浅色色阶会跟背景糊成一片，几乎看不见。所以暗色主题下这组变量需要重新算一遍，方向要反过来。官方的暗色主题是单独维护了这套变量的，你在做自定义主色的时候也要按同样的思路，根据当前主题模式选择混色目标。判断当前是不是暗色模式，通常看 html 上有没有暗色相关的类名，这个类名不同的集成方式不太一样，动手前先确认一下自己项目的约定。

第二是首屏闪烁。用户在设置页选了主色，你存进了 localStorage，下次打开应用时，如果在组件挂载之后才读取并应用，用户会先看到默认蓝色闪一下再变成自己的颜色。解决办法是在应用初始化阶段、页面渲染之前就把变量写进去，也就是从 localStorage 读值这一步要尽量早，最好是入口文件的最开头。用服务端渲染的项目还需要在返回的 HTML 里内联一段样式，把这个变量写死在初始 HTML 中，客户端接管之后再对齐，否则闪烁会更明显。

还有个边界情况：如果用户选的颜色非常接近白色，light-9会几乎完全变成白色，用作浅色背景倒是没问题，但如果用作文字或边框就会看不见。可以考虑对用户选的颜色做一次亮度检测，过浅或过深时给个提示，或者在生成边框色时换一档更深的色阶。

最后分享一个小细节，这个问题我调了挺久才发现：用popper-class覆盖面板样式时，如果你的项目开了样式作用域（scoped），写在这个类名下的样式是不会生效的，因为弹层挂在 body 下，跟组件的 scoped 属性对不上。解决办法是在一个不带 scoped 的全局样式文件里写这段覆盖，或者用穿透语法配合全局选择器。同理，面板内部的配色如果跟着暗色主题走，也要在全局样式里处理，别指望写在组件内部。