企业官网建设流程全解析

最近需要给一个 Vue 3 项目补上聊天能力，我原本以为工作量主要在 SDK 接入：登录、建连、收消息、发消息。真正把需求拆开后才发现，SDK 只是开始。

会话列表要处理未读数、置顶和草稿；消息区要考虑历史消息加载、滚动位置、发送状态、撤回和引用；图片、语音、文件各有一套交互；到了移动端，还会遇到安全区、软键盘和长按菜单。

这些功能都能自己写，但很难一次写完整。更现实的问题是：它们并不是产品真正想做出差异化的部分，却会持续占用大量开发时间。

我换了个思路，直接体验并梳理了一遍环信 Vue3 UIKit（@easemob-community/uikit-im）。环信 Vue3 UIKit 是基于easemob-websdk（SDK5）构建的 Vue 3 UI 组件库。它把「会话列表、聊天页、通讯录、群管理、消息收发、已读回执、主题、H5 适配」这些每个 IM 产品都要重做一遍的东西，做成了一套开箱即用的组件。

我的目标不是看它的 Demo 漂不漂亮，而是解决以下三个实际问题：

1. 要快：IM功能从零开始，多久能实现可用的聊天界面？
2. 要全：默认能力是否足够完整，还是只能做演示？
3. 要灵活：真正接进业务后，好不好改，还是最后仍然要 Fork 源码？

下面是这次实操体验后的记录。

文中的界面截图都来自环信线上 Demo。如果对某项能力感兴趣，可以直接打开验证。

一、接入有多简单？三行代码起步

// main.tsimport{createApp}from'vue'import{createPinia}from'pinia'importUIKitfrom'@easemob-community/uikit-im'import'@easemob-community/uikit-im/websdk5'// 注册 SDK 适配器import'@easemob-community/uikit-im/theme'// 引入主题样式constapp=createApp(App)app.use(createPinia())app.use(UIKit)app.mount('#app')

然后在页面里放一个容器组件，一个完整的聊天应用就立起来了：

<template> <EmUIKitProvider app-key="your-app-key" :auto-init="true" enable-contact enable-presence> <EmConversationContainer /> <EmChatContainer /> </EmUIKitProvider> </template>

对比一下自研的成本：会话列表的未读数与置顶排序、消息气泡的十几种状态、历史消息的分页加载与滚动锚定、断线重连后的数据恢复……每一项都是以「周」为单位的工程量，而在这里它们是默认值。

当然，“三行代码接入”不等于项目从此不需要开发。登录体系、用户数据、权限规则和业务消息仍然要接。但至少 IM 界面中最通用的部分，不用再从消息气泡开始造一遍。

第一步：先把最小聊天页面跑起来

接入过程比我预想的快。安装 UIKit、Pinia 和 Vue：

pnpmadd@easemob-community/uikit-im pinia vue

然后在入口文件里注册 UIKit，并引入 SDK 适配器和主题：

// main.tsimport{createApp}from'vue'import{createPinia}from'pinia'importUIKitfrom'@easemob-community/uikit-im'import'@easemob-community/uikit-im/websdk5'import'@easemob-community/uikit-im/theme'constapp=createApp(App)app.use(createPinia())app.use(UIKit)app.mount('#app')

然后在页面里放一个容器组件，一个完整的聊天应用就立起来了：

<template> <EmUIKitProvider app-key="your-app-key" :auto-init="true" enable-contact enable-presence> <EmConversationContainer /> <EmChatContainer /> </EmUIKitProvider> </template>

做到这里，出来的并不是两块静态 UI，而是已经串起来的会话列表和聊天页。对于技术验证阶段，这一点很重要：我可以先确认账号、会话、消息链路是否符合需求，再决定要不要继续投入，而不是先花一两周搭页面骨架。

当然，“几行代码接入”不等于项目从此不需要开发。登录体系、用户数据、权限规则和业务消息仍然要接。但至少 IM 界面中最通用的部分，不用再从消息气泡开始造一遍。

真正让我省心的，是那些需求文档里经常漏掉的细节

一开始我最关注的是消息类型，实际体验后反而觉得，会话状态和消息交互的完整度更有价值。

会话列表不是简单地循环一个数组

UIKit 的EmConversationContainer已经处理了全部、未读、@我、单聊和群组等分栏，也带有搜索、未读徽标、置顶、免打扰、草稿提示和下拉刷新，每一项都可以通过 props 开关或定制。

如果自己实现，这些功能看起来都不难，麻烦的是组合在一起：新消息到达后未读数要变，置顶会话仍要按规则排序，草稿不能被最后一条消息覆盖，筛选结果还要同步刷新。UIKit 的意义，是把这些相互关联的状态放进了一套现成逻辑里。

消息菜单的完成度，比我预想的高

EmChatContainer是真正的重头戏。长按或右键消息后，可以看到引用、复制、转发、多选、编辑、撤回、置顶、翻译和删除等操作。转发也不只支持单条消息，还包括逐条转发和合并转发。

消息类型覆盖文本、图片、语音、视频、文件、位置、合并转发和自定义消息。输入区自带 Emoji 与 IP 表情包面板。

群聊里的成员昵称、消息时间分组和气泡状态也有默认处理，不需要为了群聊再拼一套页面。

这里有几个细节让我觉得它不只是为了截图做出来的 Demo：

• 截图后可以直接用Cmd/Ctrl + V粘贴图片，发送前会出现预览确认；
• 自己发送的图片在远程地址回填前会先预加载，减少明显的闪白；
• 单聊有已读回执，群聊可以查看已读人数和详情；
• 会话内搜索可以高亮关键词，并按文本、图片、视频、文件和位置筛选；
• 如果产品不需要已读能力，可以用enableReadReceipt全局关闭。

单看其中任何一项都不算“黑科技”，但如果自己补齐，每一项都会带来状态、异常路径和测试成本。组件库的价值，恰恰体现在这些不值得重复开发、又不能做得太糙的地方。

通讯录和群管理，不用等到第二阶段再补

不少聊天 UI 方案只把重点放在消息页，真正接入时才发现联系人、好友申请、黑名单和群管理都要自己做。

这套 UIKit 的EmContactContainer已经包含好友、群组、新请求和黑名单视图。好友列表有搜索和字母索引，联系人详情里可以备注、发消息、拉黑和删除。

群详情抽屉里则可以管理成员、群名称、群公告和群文件，也包括免打扰、置顶、清空记录与解散群聊。

这部分给我的感受是：它提供的不是一个孤立聊天窗口，而是一套相对完整的 IM 前端闭环。做技术验证时，可以直接从联系人进入会话，再完成群聊管理，不必用临时页面把流程拼起来。

我最担心的定制问题，实际有三层解法

用现成 UIKit，我通常最担心两件事：默认样式和产品不搭，以及业务需求一来就必须改源码。

实际看下来，这套组件把定制分成了三层。

第一层：改主题，不动结构

UIKit 使用--uikit-*CSS 变量，并可以通过themeprop 或useTheme()调整预设、明暗模式、主色、字号、界面密度、头像形状和聊天背景。

<EmUIKitProvider :theme="{ preset: 'default', // default / business / fresh 预设 mode: 'dark', // light / dark / auto 跟随系统 primaryColor: 150, // 主色色相：改一个数字，全局换肤 fontSize: 'large', // 字号档位（适老化友好） density: 'compact', // 密度：compact / normal / comfortable avatarShape: 'square', // 头像形状全局统一 chatBg: 'linear-gradient(...)', // 聊天背景支持渐变/图片 }" >

我比较喜欢primaryColor的设计：改一个色相值，按钮、链接、选中态和气泡会一起变化，不需要逐个查选择器覆盖。暗色模式也不是简单给页面套一层反色。

线上 Demo 左下角有一个特性设置面板，可以直接调整外观、会话、聊天和通讯录选项。准备接入前先在这里试一遍，基本就能判断默认设计离自己的产品风格有多远。

第二层：用插槽换掉局部区域

如果改颜色和圆角还不够，可以通过插槽接管具体区域：

• #header：替换聊天页头部；
• #notice：加入业务通知；
• #drawer：接管整个详情抽屉；
• #user-card、#group-card：自定义名片；
• #message-custom：渲染业务消息；
• #watermark：增加水印。

Demo 聊天区顶部的防诈骗提示，就是通过#notice插槽加进去的，不是写死在 UIKit 内部。

第三层：让业务逻辑进入消息链路

再往下，还有hooks.beforeSend / afterSend可以在发送前后做校验或增强；useChatPlugin能在扩展组件中拿到当前会话、当前用户和消息发送能力；useConversationTabs则可以扩展会话分栏。

这意味着快捷回复、AI 助手、商品卡片、订单消息或内容审核，不一定要侵入 UIKit 的内部状态。对我来说，这比“插槽数量很多”更重要，因为它直接关系到后续升级时会不会被自己改过的源码卡住。

H5：一个 prop，PC 移动端通吃

同一套组件在移动端视口会切换成单栏栈式导航，并出现返回按钮、底部 Tab 和移动端输入区。安全区、软键盘适配、下拉刷新等行为可以通过h5参数开启：

<EmUIKitProvider :h5="{ safeArea: true, keyboardAdapt: true, pullRefresh: 'auto', }" >

移动端会话列表	移动端聊天页

“一套代码覆盖 PC 和 H5”不代表所有业务页面都能完全不调，但会话导航、输入区、长按和安全区这些基础问题已经有了处理。至少不需要在 PC 版完成后，又从头搭一个移动端聊天框架。

真正的杀手锏：扩展机制

Demo 能跑只是第一关。真要放进项目，我还会关注类型、体积、兼容和排障。就目前提供的能力来看，有几个设计比较实用：

• 组件使用 TypeScript strict，props 和 emits 有类型定义；
• SDK 通过适配器隔离，引入websdk5使用 5.x，换成webim4可以接 4.x，UI 层无需跟着重写；
• 支持配合unplugin-vue-components和EasemobUIKitResolver按需引入；
• 联系人、黑名单、在线状态、草稿、@我、正在输入和已读回执等功能每个能力都有features开关，运行时切换即时生效。
• dataSource可以接管好友、黑名单和用户搜索等数据源；
• 内置中英文，并支持通过mergeLocaleMessages覆盖文案；
• 支持分级日志、IndexedDB 日志持久化和 SDK 日志捕获。

这些能力不如消息气泡直观，但会影响项目能不能长期维护。尤其是可替换数据源和日志留存：前者决定 UIKit 能否融入已有业务体系，后者决定出问题时是不是只能靠复现和猜测。

它适不适合你的项目？我的判断是这样的

如果团队正在做技术验证、MVP，或者要给现有 Vue 3 应用加入标准聊天能力，这套 UIKit 值得先试。它最大的优势不是某个单独功能多惊艳，而是把会话、消息、联系人、群组和 H5 这些原本分散的工作一次铺开了。

如果你的产品有很重的业务消息，也不必因为用了 UIKit 就放弃定制。主题、插槽、发送 Hooks 和插件上下文，已经给出了从轻到重的几种扩展路径。

但如果现有项目已经有一套深度定制、运行稳定的聊天前端，迁移价值就要重新计算。UIKit 更适合帮团队缩短从零到可用的距离，而不是为了“换技术”去替换已经成熟的实现。

最后：先亲手点一遍，再决定要不要接

如果你也在评估 Vue 3 项目的 IM 方案，我建议先打开线上 Demo，重点试几个容易暴露完成度的操作：

1. 搜索和切换会话，观察未读、草稿与置顶；
2. 试一次引用、撤回、合并转发和图片粘贴；
3. 进入群详情，看看成员与群设置是否覆盖你的需求；
4. 调整主题色和暗色模式；
5. 把浏览器缩到手机宽度，体验移动端导航与输入区。

体验地址：webim-vue3.easemob.com

我的结论很简单：它不会替你完成所有业务开发，但能把一大批“不难、很碎、必须做好”的 IM 基础工作先拿走。对于更想把时间花在产品本身的 Vue 3 团队，这就是它最实际的价值。

## 参考文档：

- 注册环信即时通讯IM