IM 聊天中的表情消息怎么实现：Emoji 直发与自定义表情包两种方案
内容提要
ZIM表情消息有两种实现路径：系统emoji走文本消息，由SDK原生透传，成本最低；品牌表情包用自定义消息（type=200）承载，消息体仅含表情ID、URL和宽高，资源由CDN托管以避免重复上传。表情库维护与渲染由业务侧自建。接入时需注意消息体瘦身、subType规划、宽高占位、限频节流及低版本降级。
延伸解读
表情消息的选型逻辑：从成本与品牌出发
文章指出，系统 emoji 直接走文本消息，SDK 原生透传，接入成本最低；品牌表情包则需自定义消息承载，资源由 CDN 托管。选型时需权衡：若只需系统 emoji，文本方案零额外接入；若追求品牌化、大贴图或 GIF，则必须自建表情库并采用引用式设计。两种路径并非互斥，可并存，但需明确各自边界，避免将表情包当图片上传导致存储浪费。
引用式设计的核心优势与实现要点
自定义表情包采用引用式设计，消息体仅含表情 ID、URL 和宽高，资源本体由 CDN 承载。这样同一表情发送多次也只产生轻量消息，避免重复上传占用富媒体存储。实现时需注意消息体瘦身，默认上限 2 KB，切勿将 base64 图片塞入；同时规划独立 subType 区分其他自定义消息，并携带宽高以便接收端占位，防止聊天页滚动跳动。
低版本兼容与降级策略
接收端 SDK 版本直接影响自定义表情消息的解析。文章明确：≥2.8.0 可正常解析；[2.0.0, 2.8.0) 能收到消息但类型未知，应显示“[表情]”占位并引导升级；1.x.x 则收不到消息。因此接入时需做好降级处理，避免对未知类型消息强行解析。同时，发送端应设置 searchedContent，确保本地搜索能命中表情消息。
表情库维护与历史消息处理
ZIM 不提供表情资源管理，表情库的清单下发、版本管理、增量下载需业务侧自建。发送时只引用 emojiId 和 url；接收时优先查本地缓存，未命中再走 CDN 并回写。下架表情时，从清单移除即可，历史消息仍可按 URL 加载；若需彻底失效，需 CDN 撤资源，但需注意历史消息观感。此外，连发表情受 10 次/秒限频，面板应做点击节流。
Q&A
IM聊天中发送表情消息有哪两种实现方案？
ZIM中表情消息有两种实现路径：系统emoji直接作为文本消息（type=1）发送，由SDK原生透传，成本最低；品牌自定义表情包则用自定义消息（type=200）承载，消息体只包含表情ID、资源URL和宽高，资源由CDN托管。
为什么自定义表情包要用引用式设计而不是直接上传图片？
因为表情是引用型资源，同一表情会被成千上万次发送。如果每次发送都上传图片，会占用大量富媒体存储；而自定义消息只发引用（表情ID+URL+宽高），同一表情发送一万次也只有一万条小消息，资源本体始终只有CDN上一份。
发送emoji文本消息有哪些限制需要注意？
文本消息默认上限2KB（可配置至32KB），emoji采用UTF-8编码后单字符最多4字节，2KB约可容纳500个emoji+文字；发送限频10次/秒，连发表情需客户端节流；空内容返回错误6000001，纯emoji属于合法内容可正常发送；渲染兼容性与ZIM无关，老操作系统可能显示方框，建议按客户端操作系统版本过滤表情面板。
接收端SDK版本不同时，自定义表情消息会有什么表现？
接收端SDK版本≥2.8.0可正常收到自定义消息并按subType解析渲染；版本在[2.0.0, 2.8.0)之间可收到消息但类型未知、无法获取内容，UI显示“[表情]”占位并引导升级；1.x.x版本收不到该消息，无需处理。
业务侧自建表情库需要实现哪些核心动作？
表情库维护由业务侧自建，核心包括四个动作：清单下发（启动或进入表情面板时请求表情包清单，按version对比本地缓存，增量下载新表情）；发送只引用（只引用emojiId+url，不携带资源本体）；接收回写缓存（优先查本地表情库，本地没有再按url走CDN加载并写回缓存）；下架处理（清单中移除即可，历史消息按URL仍可加载，彻底失效需CDN撤资源）。
接入表情消息时有哪些最佳实践要点？
接入最佳实践包括：消息体瘦身（只放ID+URL+宽高，不要塞base64图片）；subType规划（表情包消息分配独立subType如3，与红包、投票等区分）；宽高占位（消息体带width/height，接收端先占位再异步加载，避免滚动跳动）；GIF注意（ZIM不做GIF解析，播放由客户端UI组件实现，大GIF建议压缩后上传CDN）；限频与节流（连发表情受10次/秒限频，表情面板建议做点击节流）；历史消息（可存储为历史消息，按URL/本地缓存渲染）；低版本降级（接收端<2.8.0显示“[表情]”占位，不要解析未知类型消息）；设置searchedContent（如“[表情:开心]”），本地搜索才搜得到。
