同样用 Element Plus，为什么你的后台总有一股“模板味”？

一个后台页面，功能都做完了：筛选能查，表格能翻页，弹窗能保存。

查询是主按钮，新增是主按钮，每一行又摆着三四个蓝色操作；姓名、账号、状态、时间一样醒目；筛选一个框，表格一个框，外面再套一个框。

单独看，每个组件都没问题。放在一起，页面却没有重点。

这种“模板味”，往往就出在组件之间的关系还没有被设计。

这篇只拿一个用户管理页动手：保留 Element Plus，保留业务信息，把布局、表格和主题接起来。

两张图使用同一组数据，也都有姓名、账号、角色、状态和创建时间。查询、新增、编辑、分配角色、重置密码这些入口也保留了。

这组图是为本文制作的 Vue 3 + Element Plus 教学演示，使用虚构数据，并非某个项目改版前后的历史截图。示例中的操作频率是假设，实际项目需要根据用户工作流程决定。

把查询、重置、新增、导出放进同一排，开发起来很顺手。但它们并不属于同一件事。

查询和重置控制的是当前列表的筛选条件；新增是在创建一个新的业务对象。位置相邻，却不意味着职责相同。

这里省略了业务逻辑，只看页面结构：进入页面先知道自己在哪里，接着可以新增，也可以缩小列表范围，最后处理具体的一行。

在这个示例里，“新增”是页面级主操作，所以保留实心主按钮。“查询”紧挨着筛选字段，位置已经表达了用途，可以降低颜色权重。

这不是“每个页面只能有一个主按钮”的硬规则。如果你的页面是交易流水查询，用户大部分时间都在反复查数据，查询完全可以成为最突出的操作。

同样，行内操作也不能一律藏起来。这里假设编辑最常用，分配角色、重置密码相对低频，才把后两项放进“更多”。如果客服每天都在重置密码，把它收进去只会增加操作次数。

姓名和账号通常是在共同回答“这是谁”。把它们分开，用户要来回扫两列；合在一起，姓名负责识别，账号负责消除重名歧义。

同样的信息，现在有了阅读顺序。没有加插画，也不需要给每个人配一个随机颜色的头像。

但合并也有边界：如果用户经常单独按账号排序、批量复制账号，独立列可能更合适。视觉上更紧凑，不应牺牲实际任务。

让状态保留文字。“启用”“停用”即使加了颜色，也要能直接读出来。颜色辅助扫描，文字负责明确含义。不要为了整齐，把所有状态都刷成品牌色。

**按数据类型决定对齐。**金额通常右对齐，更容易比较位数；姓名和描述左对齐，方便连续阅读；时间可以使用 font-variant-numeric: tabular-nums，让支持等宽数字的字体保持数字宽度一致。不要为了看起来规整，把所有列都居中。

border、stripe 都有适用场景。宽表格里跨很多列比对数据，清晰的网格或斑马纹可能很有用。

但只有几个字段的用户列表，如果同时出现卡片阴影、外边框、纵向网格、斑马纹，再给每个状态套一个标签，装饰本身就会占掉不少注意力。

本文这张表可以只保留横向分隔与 Hover 反馈，把纵向关系交给对齐和间距。

Element Plus 表格提供了可覆盖的 CSS 变量。下面放在全局样式文件，并通过 .admin-table 限定到采用这套规范的表格：Table 文档。

变量处理颜色，后两个选择器处理单元格的空间。它们依赖组件内部类名，升级组件库时要一起检查；不要把这些覆盖复制到每个业务页面里。

如果放进 Vue 的 scoped 样式，内部节点可能无法被普通后代选择器命中。可以使用项目统一的组件覆盖文件；确实需要局部覆盖时，再按 Vue 的规则使用 :deep()。选一种明确的维护方式，别让同一张表被多个地方轮流覆盖。

来源：稀土掘金　原文