零售电商解决方案与 Live 集成指南
方案简介
直播电商是一种融合实时音视频互动与在线交易的新型电子商务模式，主播通过直播间向观众实时展示和讲解商品，并通过弹幕、店铺客服私聊等方式与用户互动，从而提升用户参与感和购买转化率。在零售电商场景中，直播系统通常需要同时具备低延迟音视频能力、高并发即时通信能力以及丰富的互动和业务消息同步能力，才能满足商品展示、用户互动、订单通知和营销活动等复杂需求。
本方案基于 Tencent RTC 相关产品（Live、Chat）梳理了搭建电商直播系统过程中常见的需求及解决方案，方便开发者在保持高度自定义能力的前提下快速搭建电商直播系统。方案同时提供了 Beauty AR 高级美颜特效集成指引，支持美颜、滤镜和动效贴纸等，满足零售电商直播对主播形象和互动体验的高要求，适用于品牌自营电商、私域直播、跨境电商及商城内嵌直播等多种业务场景。
整体架构设计
电商直播系统并不只是一个“带购物功能的直播间”，而是由多个独立子系统协作构成的复合型业务平台。本章从全局视角出发，先梳理完整的系统边界和核心子系统，再深入到 Live 无 UI 集成方案 AtomicXCore SDK 的内部架构，帮助开发者在动手编码之前就建立清晰的全局认知。
系统全景架构
一个完整的电商直播系统至少涉及五大业务域，每个业务域有独立的技术栈和数据模型，但在直播场景中需要紧密协作：
业务域 | 核心职责 | 技术基座 | 提供方 |
直播域 | 音视频推拉流、实时互动、房间管理 | AtomicXCore SDK | 腾讯云 |
电商交易域 | 商品管理、库存控制、订单处理、支付结算、售后流转 | 业务自建（电商中台、支付平台） | 客户侧 |
营销域 | 活动编排、优惠发放、流量运营 | 业务自建（营销平台） | 客户侧 |
客服域 | 用户咨询、智能路由、多端应答 | 腾讯云智能客服（Desk） | 腾讯云 |
用户域 | 账号体系、粉丝运营、私域社群 | Live / Chat SDK | 腾讯云 |
客户端分层架构
从客户端视角看，整个电商直播 App 一般按以下五个层级组织：
各层级职责说明：
Client Layer：基于声明式框架构建（例如 Android 使用 Jetpack Compose，iOS 使用 SwiftUI），负责所有页面的响应式渲染。直播间页面是最复杂的 UI 场景，需要在视频流之上叠加弹幕、商品弹窗、礼物动画、连麦浮窗等多个交互层。
ViewModel：遵循 MVVM 架构，每个页面对应独立的 ViewModel。ViewModel 的核心工作是组合来自不同数据源的状态，例如直播间 ViewModel 需要同时订阅 AtomicXCore Store 的直播状态（房间信息、连麦状态、弹幕列表等）和业务 Repository 的电商数据（当前讲解商品、购物车数量等）。
Core SDK：直播能力由 AtomicXCore SDK 的 Store 体系提供（如 LoginStore、DeviceStore、BarrageStore 等）；业务能力由开发者自建的 Repository 层提供，每个 Repository 封装对应服务端 API 的网络调用、数据缓存和错误处理（如 ProductRepository 封装商品查询接口）。
Server Layer：集成腾讯云底层的实时音视频（Tencent RTC）、即时通讯（Tencent Chat）和美颜（TEBeautyKit）能力，以及支付等第三方 SDK。开发者通常不需要直接操作该层，而是通过 L3 的 Store 和 Repository 间接调用。
Business：承载所有服务端业务逻辑，客户端通过 REST API 或 WebSocket 与之通信。
服务端架构概览
服务端建议按微服务或模块化方式组织，核心服务拆分如下：
服务 | 核心职责 | 对外接口 | 依赖的云能力 |
直播服务 | 房间管理、房间成员管理、连麦管理、消息管理 | REST API | Live 服务端 API |
鉴权服务 | UserSig 生成与刷新、凭证管理 | REST API | RTC/Chat 鉴权服务 |
商品服务 | 商品 CRUD、库存管理、价格策略 | REST API | 业务数据库 |
订单服务 | 下单、支付回调、退款、佣金结算 | REST API + 异步消息 | 支付平台 |
营销服务 | 优惠券、秒杀、抽奖、活动编排 | REST API | 业务数据库 |
客服服务 | 会话路由、机器人接待、智能应答 | REST API + Webhook | 智能客服 Desk |
用户服务 | 账号体系、会员等级、粉丝关系 | REST API | Live/Chat 共用账户体系 |
推送服务 | 开播提醒、营销推送（优惠/秒杀/活动预热）、交易通知、离线触达 | REST API | TIMPush |
数据服务 | 直播数据统计、转化分析、用户画像 | 异步消息 + 批处理 | 数据仓库 |
核心子系统拆解
直播子系统
Store-Driven 架构
AtomicXCore SDK 采用 Store-Driven 架构，各功能以独立 Store 形式提供状态与操作 API，通过响应式数据流对外暴露业务状态，并通过 Listener 分发实时事件，开发者可按需获取对应 Store 进行调用。全局 Store 在应用级共享，房间级 Store 按 liveID 管理生命周期，退出房间时需主动释放监听与资源。
Store 模块分类
SDK 中的 Store 模块按生命周期可以分为两类：全局单例 Store、房间维度 Store。全局单例 Store 在应用生命周期内共享，适用于跨房间的通用能力管理；房间维度 Store 通过
create(liveID) 获取，内部实现为同一 liveID 返回同一实例。Store/Component | 功能描述 | API 文档 |
LiveCoreView | 直播视频流展示与交互的核心视图组件：负责视频流渲染和视图挂件处理，支持主播直播、观众连麦、主播连线等场景。 | |
LiveListStore | 直播间全生命周期管理：创建 / 加入 / 离开 / 销毁房间，查询房间列表，修改直播信息（名称、公告等），监听直播状态（如被踢出、结束）。 | |
DeviceStore | 音视频设备控制：麦克风（开关 / 音量）、摄像头（开关 / 切换 / 画质）、屏幕共享，设备状态实时监听。 | |
CoGuestStore | 观众连麦管理：连麦申请 / 邀请 / 同意 / 拒绝，连麦成员权限控制（麦克风 / 摄像头），状态同步。 | |
CoHostStore | 主播跨房连线：支持多布局模板（动态网格等），发起 / 接受 / 拒绝连线，连麦主播互动管理。 | |
BattleStore | 主播 PK 对战：发起 PK（配置时长 / 对手），管理 PK 状态（开始 / 结束），同步分数，监听对战结果。 | |
GiftStore | 礼物互动：获取礼物列表，发送 / 接收礼物，监听礼物事件（含发送者、礼物详情）。 | |
BarrageStore | 弹幕功能：发送文本 / 自定义弹幕，维护弹幕列表，实时监听弹幕状态。 | |
LikeStore | 点赞互动：发送点赞，监听点赞事件，同步总点赞数。 | |
LiveAudienceStore | 观众管理：获取实时观众列表（ID / 名称 / 头像），统计观众数量，监听观众进出事件。 | |
AudioEffectStore | 音频特效：变声（童声 / 男声）、混响（KTV 等）、耳返调节，实时切换特效。 | |
BaseBeautyStore | 基础美颜：调节磨皮 / 美白 / 红润（0-9 级），重置美颜状态，同步效果参数。 |
电商交易子系统
电商交易子系统通常由业务层自建，AtomicXCore SDK 不提供对应的专属 Store。不过您仍然可复用 AtomicXCore 的自定义元数据（
MetaData）能力，在房间内存储和同步任何业务相关的信息；复用自定义消息（CustomMessage）能力，在房间内广播任何业务相关的消息。功能模块 | 核心能力 | 与直播间的联动方式 |
商品管理 | 商品 CRUD、SKU、分类、搜索 | 进房时拉取商品列表；主播切换讲解商品时通过自定义消息广播 |
购物车 | 加购、数量修改、价格预估 | 直播间内轻量加购，不强迫离开直播间 |
订单系统 | 下单、支付、退款、物流 | 订单携带 liveId、anchorId 用于转化归因 |
库存控制 | 实时扣减、预占、超卖防护 | 秒杀/限时活动场景需与直播节奏同步 |
营销子系统
功能模块 | 核心能力 | 与直播间的联动方式 |
优惠券 | 发券、领券、核销、有效期管理 | 通过自定义消息在直播间广播优惠券发放通知 |
秒杀活动 | 倒计时、库存锁定、抢购控制 | 与商品上架弹窗联动，同步倒计时和库存状态 |
抽奖 | 参与资格校验、开奖、奖品发放 | 直播间内展示抽奖入口和中奖结果 |
客服子系统
功能模块 | 核心能力 | 与直播间的联动方式 |
智能客服 | 生成式 AI 自动应答、意图识别 | 直播间商品卡内嵌"咨询"入口，跳转客服会话 |
人工客服 | 会话路由、人工坐席分配 | 携带商品/订单上下文进入客服会话 |
订单卡片 | 在会话中展示结构化订单信息 | 减少客服与用户的反复确认成本 |
服务评价 | 满意度评分、质检分析 | 会话结束后闭环收集 |
用户与社群子系统
功能模块 | 核心能力 | 与直播间的联动方式 |
账号体系 | 注册、登录、实名认证 | 为直播观看、交易行为提供身份基础 |
会员等级 | 积分、等级、权益 | 影响客服优先级、优惠力度、连麦资格 |
粉丝社群 | Community 群组、话题、公告 | 直播预热、福利发放、用户沉淀 |
推送触达子系统
功能模块 | 核心能力 | 与直播间的联动方式 |
直播预告 | 直播预约、开播提醒 | 通过在离线推送服务触达关注用户 |
营销推送 | 优惠/秒杀/活动预热 | 通过营销活动推送唤醒非活跃用户，提高转化 |
交易通知 | 订单提醒、物流通知 | 实时通知用户在直播间下单的商品动态和订单消息 |
互动消息 | 个人消息、店铺客服消息 | 实时通知用户个人消息、商品店铺客服等互动消息 |
直播间功能开发指引
本章将提供直播间常见功能的开发指引，帮助您更快地找到对应功能的说明文档。
基础使用：开播及观看。
直播互动：弹幕消息、送礼点赞、单房间连麦、跨房连线 / PK。
成员管理：用户等级/身份、禁言与封禁/踢人、在线观众列表、在线人数。
直播间管理：直播间列表、直播间审核、直播监播、直播间公告、直播统计。
场景指引：电商场景、直播间弹幕抽奖、红包秒杀/福袋。
准备工作
在开始之前，你需要先完成开通服务、导入 AtomicXCore、实现登录逻辑等准备工作。
开通服务：登录 Tencent RTC 控制台，创建互动直播 Live 应用，领取体验版或购买正式版。
导入 AtomicXCore：在当前项目中导入 AtomicXCore，添加 AtomicXCore SDK 依赖。
实现登录逻辑：在您的项目中调用
LoginStore 完成登录，这是使用 AtomicXCore 所有功能的关键前提。说明：
主播端完整实现
主播开播流程如下，您只需执行以下几步操作，即可快速实现主播视频直播。
说明：
LiveCoreView 集成
层级 | 作用 | 说明 |
底层 | LiveCoreView | 承载本地预览或远端视频 |
中层 | 主播信息、商品卡、在线人数 | 常驻轻交互信息 |
上层 | 弹幕、礼物、连麦弹窗 | 高频动态交互 |
顶层 | 结束直播确认、异常提示 | 阻断式操作与兜底提示 |
设备管理
管理项 | 说明 |
麦克风管理 | 打开/关闭麦克风，设置采集音量和输出音量 |
摄像头管理 | 打开/关闭摄像头，切换前后摄像头，设置镜像和视频质量 |
音频路由 | 切换扬声器和听筒 |
屏幕分享 | 开启和关闭屏幕分享功能 |
网络状态 | 实时监控网络质量信息 |
创建直播间
模式一：客户端创建房间
该模式适用于轻量验证或运营管控较少的场景，特点是接入快、链路短，但业务系统对房间元数据的统一约束较弱。
模式二：服务端创建房间
该模式的核心价值不是"多绕一次接口"，而是把房间生命周期、商品绑定、主播权限、活动状态统一放到服务端进行管理。
结束直播间
模式一：客户端结束直播
该模式适用于一般的轻量直播场景，仅客户端就能独立完成关播动作，无需服务端参与。
模式二：服务端销毁房间
该模式适用于较为复杂的直播场景，服务端可统一管控直播间生命周期，并在关播时结算关联业务。
观众端完整实现
观众观看流程如下，通过简单几步操作，即可实现观众观看直播。
说明：
进入直播间
进入直播间成功后，还需要注意业务数据的同步完成，例如弹幕区、商品卡、客服入口等。
退出直播间
退出直播间成功后，还需要注意停止房间相关监听和消息订阅，清理房间级 Store，回到直播列表或推荐页。
观众连麦互动实现
连麦是电商直播中增强互动性的重要功能，允许观众与主播进行实时音视频通话。AtomicXCore 提供了 CoGuestStore 模块，专门用于管理观众连麦的完整业务流程。CoGuestStore 支持两种最主流的连麦场景：观众申请上麦、主播邀请上麦。
观众申请上麦
观众主动发起连麦请求，主播在收到请求后进行同意或拒绝。
主播邀请上麦
主播可以主动向直播间内的任意一位观众发起连麦邀请，观众在收到邀请后进行同意或拒绝。
说明：
主播连线 PK 实现
一次完整的“主播连线 PK”通常包含四个核心阶段，其整体流程如下：
1. 跨房连线：两个主播建立连线，画面出现在同一个视图中。
2. 发起 PK：连线成功后，任意一方可以发起 PK 挑战。
3. PK 对战：双方进行 PK 对战，实时更新 PK 分数。
4. 结束 PK 连线：互动结束后，主播需要按照逻辑顺序先结束 PK 状态，再断开跨房连线。
说明：
实时弹幕系统实现
弹幕是电商直播中最重要的互动形式之一，它承载着用户的即时反馈、商品咨询和情感表达。使用
AtomicXCore 框架中的 BarrageStore 模块，能为您的直播应用快速集成功能丰富、性能卓越的弹幕系统。
消息分层
客户端建议按消息类型进行分流：文本消息、自定义消息、本地提示等。
类型 | 用途 | 展示方式 |
普通文本消息 | 咨询、互动、情绪表达 | 弹幕列表 / 飘屏 |
自定义消息 | 礼物、商品讲解、优惠券提醒 | 卡片 / 特效弹幕 |
本地提示 | 进入房间、连麦状态、风控提示 | 系统消息 |
用户等级/身份标识
用户等级与身份标识功能是直播互动场景中的重要组成部分，用于区分不同用户角色、特权等级和身份状态，从而实现差异化的界面展示、交互权限和功能访问控制。LiveKit 默认不提供基础的身份标识框架，但您可以参考以下方式进行实现：
1. 在您的业务后台，根据您需要的用户等级/身份相关逻辑，自行维护并存储与每个用户 UserID 相对应的等级/身份。
2. 发送消息接口选择
BarrageStore.sendCustomMessage()，其中 data 设置为您从业务后台获取到的需要展示的等级/身份等信息。收到消息时，解析 data 为您的等级/身份信息，之后自行在弹幕列表上渲染。以下为用户等级/身份标识消息结构示例：{"businessID": "user_identity","content": "大家好，欢迎来到直播间！","userIdentity": {"level": 32,"levelName": "钻石","levelIconUrl": "https://your-cdn.com/icons/level_diamond.png","badges": [{"type": "vip","name": "年度VIP","iconUrl": "https://your-cdn.com/icons/badge_annual_vip.png","color": "#FFD700"},{"type": "fan","name": "铁粉","iconUrl": "https://your-cdn.com/icons/badge_fan.png","color": "#FF69B4"}],"nameColor": "#FFD700","bubbleStyle": "golden_frame"}}
弹幕列表 UI 性能优化
弹幕列表的性能优化是高并发直播场景下的关键挑战。建议采用以下策略：
优化策略 | 实现方式 | 效果 |
列表长度限制 | 保留最近 500 条消息，超出部分从头部移除 | 控制内存占用 |
批量渲染 | 每 300ms 批量更新一次 UI，而非逐条刷新 | 减少 UI 重绘次数 |
视图复用 | 使用 RecyclerView/UITableView 的复用机制 | 降低对象创建开销 |
异步加载 | 图文、自定义字体或复杂布局的视图异步绘制 | 避免主线程阻塞 |
说明：
礼物赠送系统实现
礼物系统是互动直播变现的重要渠道，也是活跃直播间氛围的有效手段。
GiftStore 是 AtomicXCore 中专门负责管理直播间礼物功能的模块。通过它，您可以为您的直播应用构建一套完整的礼物系统，实现丰富的营收和互动场景。
礼物素材配置
您需要自定义直播间可用的礼物种类、分类、名称、图标、价格以及动画效果，以满足运营需求和品牌特色。
1. 服务端配置：使用 LiveKit 服务端 REST API 管理礼物信息、分类、多语言等。请参考 礼物配置指引文档。
2. 客户端拉取：在客户端调用
refreshUsableGifts 获取配置数据。3. UI 展示：使用拉取到的
List<GiftCategory> 数据填充礼物面板。
对于 SDK 内置礼物列表无法覆盖的高度定制化场景（如拍卖出价、自定义特效触发等），可以通过
BarrageStore.sendCustomMessage() 发送自定义消息作为补充。以下为自定义礼物消息结构示例：{"type": "live_gift","giftId": "rocket_001","giftName": "火箭","giftCount": 1,"giftValue": 1000,"effectUrl": "https://example.com/effects/rocket.json","senderId": "user_123","senderName": "xx用户","senderAvatar": "https://example.com/avatar.jpg"}
计费与送礼扣费流程
当观众赠送礼物时，需要确保其账户余额充足，并完成实际的扣费操作，然后才能触发礼物特效的播放和广播。
1. 后台配置回调：在 LiveKit 后台配置您的自建计费系统的回调 URL。请参考 回调配置文档。
2. 客户端发送：客户端调用
sendGift。3. 后台交互：LiveKit 后台调用您的回调 URL，您的计费系统执行扣费并返回结果。
4. 结果同步：扣费成功，AtomicXCore 广播
onReceiveGift 事件；扣费失败，sendGift 的 completion 收到错误。
电商核心功能开发指引
本章所涉及的商品管理、购物车管理、订单流程、优惠券等电商核心功能均属于业务层自建范畴，AtomicXCore SDK 不提供对应的专属功能模块。开发者需要自行搭建或利用 AtomicXCore 现有 Store 实现。以下是电商直播业务全流程示例图。
商品列表/购物车
商品列表管理是商品管理的基础功能，主要包括商品的添加、删除、修改和查询等功能。通常会在后台数据库中存储商品的各种信息，例如商品名称、描述、价格、库存、图片等。在前端，您可以通过您的 API 接口获取这些信息，并以列表的形式展示给用户。当然对于当场直播有限的商品列表，您也可以选择复用 AtomicXCore 的自定义元数据（
MetaData）能力，在房间内存储和同步商品列表信息。注意：
1.
MetaData 仅存储直播间 ID 和商品列表 ID 的映射关系，当用户点击商品列表按钮后，您的客户端需向服务端请求进行对应商品信息的展现。2. 库存与价格属于强时效数据，建议以服务端为准，客户端不做最终决策。
商品弹窗管理
在直播带货过程中，伴随着主播对商品的讲解与上架，通常需要在观众端弹出对应的商品信息，以便提示观众浏览和购买。商品信息弹窗可以通过向直播间内发送自定义消息 的方式实现，直播间观众收到自定义消息后进行解析和展示。您也可以通过您的业务侧自行实现自定义消息的收发。
核心需求
主播在直播过程中点击“上架弹窗”后，需要将商品信息推送至所有观众端并展示弹窗，需满足以下要求：
实时性：已在直播间的观众即时收到通知。
可靠性：中途加入的观众同样能获取当前上架商品信息。
唯一性：每位观众对同一次上架事件仅展示一次弹窗，不重复触发。
双通道同步机制
1. 通道 A — 自定义消息（推模型）
通过服务端 REST API 调用
send_custom_msg 向直播间内广播商品弹窗的自定义消息。该方式具备毫秒级实时性，适用于针对在线观众的即时通知，但不支持离线存储，后进入房间的用户无法获取历史消息。商品弹窗自定义消息数据结构示例如下：{"eventId": "evt_prod_001_1773321389000","type": "GOODS_ON_SHELF","goodsId": "prod_001","goodsName": "Vintage Watch","goodsNameZH": "复古手表","goodsNameEN": "Vintage Watch","price": 9900,"priceUSD": 99.0,"priceCNY": 712.8,"imageUrl": "/static/products/watch.png","serverTs": 1773321389000,"startTimestamp": 1773321389000}
2. 通道 B — 房间元数据（拉模型）
通过服务端 REST API 调用
set_room_metadata 将商品上架状态写入房间元数据。该方式支持随直播间生命周期持久化存储，适用于新加入直播间后主动拉取直播间信息，但非实时推送，依赖客户端主动查询。商品弹窗房间元数据数据结构示例如下：{"goods_id": "prod_001","goods_name": "Vintage Watch","goods_name_zh": "复古手表","goods_name_en": "Vintage Watch","price": 9900,"price_usd": 99.0,"price_cny": 712.8,"image_url": "/static/products/watch.png","start_timestamp": 1773321389000,"status": "active"}
注意：
房间元数据中不包含
eventId 字段。客户端解析时需自行生成，格式为 attr_{goods_id}_{start_timestamp}，前缀 attr_ 与自定义消息的 evt_ 区分，避免去重冲突。双通道协作流程
步骤 | 操作 | 说明 |
1 | 服务端写入房间元数据 | 确保持久化数据先就位，后进用户可获取 |
2 | 服务端/客户端发送自定义消息 | 实时推送给当前在线观众 |
3 | 在线观众收到自定义消息 → 展示弹窗 | 通道 A 触发 |
4 | 新观众进房 → 查询房间元数据 → 展示弹窗 | 通道 B 触发 |
商品跳转与支付
直播间内的观众完成商品挑选后，需要通过点击商品链接，跳转到具体的电商店铺进行订单的确认及支付。这里的电商店铺可以是平台内店铺，或是集成的第三方平台店铺。待用户支付完成后，还需要获取支付结果，以便更新商品的销售状态和库存信息等。
说明：
上述商品管理模块仅供参考，实际应用中您需要结合业务需求自行设计并部署。
直播间弹幕抽奖
直播间弹幕抽奖是指用户发送特定内容的 弹幕消息 参与直播间抽奖。实现思路为业务后台群内发言消息后回调请求获取弹幕消息内容，符合特定内容的消息发送者将加入奖池，否则不做处理。回调使用见 群内发言之后回调。
红包秒杀/福袋发放
红包秒杀和福袋发放是电商直播中常见的营销互动功能，能有效提升用户参与度和购买转化率。TUILiveKit（AtomicXCore） 不直接提供此功能，但您可基于其底层通信能力，结合您的业务后台来实现。
活动创建与通知
用户参与逻辑
观众端收到活动通知后，解析并展示参与入口。用户点击后，向您的业务后台发起参与请求。业务后台负责验证用户资格、记录参与信息，同时可以实时更新参与人数。
抽奖与结果公布
奖励发放
业务后台根据中奖结果，向用户的账户发放相应的奖励（例如优惠券、积分、余额等）。这一步通常与您的账户或营销系统对接。
关键技术点
自定义消息：整个功能的核心是定义和收发不同类型的自定义消息，用于同步活动状态（例如“活动开始”、“结果公布”）。客户端需要根据消息类型来展示不同的 UI 效果。
业务后台：所有活动管理、用户参与、抽奖和发奖的逻辑都由您的业务后台处理，确保流程的安全和可靠。
说明：
上述红包/福袋模块仅供参考，实际应用中您需要结合业务需求自行设计并部署。
Chat 功能开发指引
在电商直播生态中，即时通讯（Chat）不仅承载着直播间内的实时互动，更是私域运营、客户服务和精准营销的核心基础设施。为了保持架构的清晰与高效，本方案建议采用分层整合策略：
直播间内互动：继续使用 AtomicXCore 封装的
BarrageStore 处理弹幕、点赞、礼物及商品上架通知，确保音视频与消息的高度同步。直播间外服务：商家客服、粉丝社群、营销活动及推送触达建议直接使用腾讯云 Chat SDK 独立实现，以获得更完整的社交功能支持。
建议在 AtomicXCore 的 Store 体系之外，建立独立的
ChatService 模块，负责全局 Chat 状态监听及非直播间维度的消息处理。
商家客服系统
商家客服是连接流量与转化的关键纽带。在电商场景中，用户常有以下诉求：
售前咨询：商品规格、库存查询、尺码建议、材质说明
订单查询：物流进度、发货时间、订单状态
售后服务：退换货流程、质量问题反馈、退款进度
自动化运营与系统消息场景
在首次会话或关键业务节点，用户点击咨询进入到聊天窗口后，您业务的服务端可通过 Chat RESTful API 主动向用户发送单聊消息，用于下发欢迎语、服务指引或交易提示，适合自动化运营与系统消息场景。
商家人工回复
自定义卡片信息
买卖双方使用 C2C 单聊会话进行沟通，订单相关信息可通过
createCustomMessage 构建自定义消息体，并调用 sendMessage 发送。自定义消息中可包含订单号、商品信息、价格状态及跳转链接，客户端解析后渲染为订单卡片。详见 C2C 客户端消息接口说明。粉丝社群运营
社群聊天功能通过构建一个高粘性的互动功能，极大地提升了电商用户的复购率：
从单向推销变为双向互动，建立信任感。 传统的营销推送是单向的，而社群聊天创造了品牌与粉丝、粉丝与粉丝之间直接沟通的场景。这种实时的问答、晒单和口碑分享，能极大地增强用户对品牌的信任，而信任是重复购买的基础。
创造“限时专属”的社群氛围，刺激冲动消费。 在社群内，可以频繁、精准地发布专属优惠券、秒杀链接和新品预告。这种“群体效应”和“专属感”能有效激发用户的购买冲动，将单纯的购物需求转化为及时的消费行动。
将用户沉淀为社群资产，提升生命周期价值。 当用户加入社群，就意味着从一次性的流量变成了可长期运营的“资产”。通过日常内容维持社群活跃度，品牌能持续占据用户心智，引导其从首次购买转向习惯性复购，最终最大化每个用户的长期价值。
创建群聊与群成员管理
采用 Community 群类型，Community 类型支持一个群最大100万人，当您的粉丝越来越多时，不用担心群人数容量的问题。您可以使用 客户端/服务端 接口来创建群聊，通过 客户端/服务端 接口禁言、踢人、设置管理员和获取群在线人数等能力，通过 客户端/服务端 邀请成员。
群资料配置
商品购物车
营销活动
在电商直播场景中，营销活动通常可分为两大类：
直播外营销活动（以应用为单位）：如营销通知、活动提醒等 推送触达，侧重于用户召回与活动预热，增强用户参与度。
推送触达
集成 Push 产品，只需进行简单配置，即可一键式集成接入多个厂商的推送服务。Push 通知消息更注重即时性（及时触达），不具备存历史漫游特性（即 Push 产品的推送通知消息不会存入到聊天 Chat 的会话系统里）。
服务端推送运营消息
客户端自定义跳转界面
推送触达效果追踪
高级美颜集成指引
美颜产品说明
在 LiveKit / AtomicXCore 体系中，需要先区分基础美颜 与 高级美颜两条能力线：
基础美颜：使用
BaseBeautyStore，适合只需要磨皮、美白、红润的场景；参数范围为 0 - 9，包含在 LiveKit 基础能力内，无需额外购买高级美颜 License。高级美颜：使用
TEBeautyKit，适合需要 V 脸、眼距、瘦鼻、滤镜、动效贴纸、美妆、背景分割等增强效果的场景；需额外购买 Beauty AR License，并按官方文档完成资源与鉴权配置。因此，电商直播场景应按需求分层接入：
1. 只做基础磨皮/美白/红润：优先使用
BaseBeautyStore，实现成本最低。2. 需要高级美型、滤镜、贴纸、美妆：在主播端额外接入
TEBeautyKit。3. 不要混淆两套接口：集成
TEBeautyKit 之后，高级效果应通过 TEBeautyKit 的接口与面板管理，不再使用 BaseBeautyStore。TEBeautyKit 采用外置插件化架构，通过相机纹理处理回调将视频帧插入“采集 → 美颜处理 → 渲染 / 推流”链路。
美颜功能模块与资源清单
TEBeautyKit 提供的能力应和资源配置、套餐授权保持一致。推荐按“功能模块 + 必要资源”方式整理：功能模块 | 典型能力 | 主要资源 / 配置 |
基础美颜 / 美型 | 磨皮、美白、红润、瘦脸、大眼等 | beauty.json |
滤镜 | 风格滤镜、色调调整 | lut.json + 对应滤镜素材 |
动效贴纸 | 2D/3D 贴纸、手势贴纸 | motion_2d.json、motion_3d_gesture.json + 对应素材 |
虚拟背景 / 分割 | 背景分割、背景替换 | segmentation.json + 对应资源 |
面板图标 | 面板入口与功能图标 | panel_icon |
LiveCoreView 集成美颜
LiveCoreView 与 TEBeautyKit 的集成，本质上是把官方 process(...) 纹理处理流程封装进你自己的直播渲染链路。推荐接入顺序
1. 主播进入准备页后创建
LiveCoreView。2. 完成资源准备、License 校验和
TEBeautyKit.create(...)。3. 在
LiveCoreView 的视频处理回调中调用 beautyKit.process(...)。4. 先在预览态验证效果，再进入正式推流态。
5. 页面暂停、恢复、销毁时同步处理美颜生命周期。
集成时的关注点
onDestroy() 必须在 GL 线程调用，不能直接在主线程销毁，否则容易出现黑屏、白屏或资源泄漏。美颜问题优先排查三类内容：资源目录、License、纹理回调链路。
若设备性能不足，应先降低默认美颜参数，再裁剪高阶特效，而不是直接让整条主播链路承压。
