Golang聊天室表情支持需服务端做语义识别与安全替换：用map映射标识到Unicode/路径，正则预处理避免误匹配，不生成HTML，先过滤再转义非表情部分，确保XSS安全且前后端解耦。
在 Golang 实现的聊天室中支持表情，核心不是引入图形渲染，而是对文本消息中的表情标识（如 :smile:、[dog]）做语义识别与安全替换。关键在于：解析规则要明确、替换过程要可控、输出要防 XSS、前端需配合渲染。
定义表情映射规则
用 map 建立文本标识到实际表示的映射，推荐使用 Unicode 表情或 SVG/图片路径（由前端决定如何展示）：
示例（服务端只管替换，不生成 HTML）：
var emojiMap = map[string]string{
":smile:": "?",
":heart:": "❤️",
":rocket:": "?",
"[dog]": "?",
"[coffee]": "☕",
}
注意：避免硬编码大量表情，可从 JSON 文件加载，便于运营维护。
消息接收时做轻量预处理
在消息入库或广播前，对 content 字段执行一次正则替换，仅替换已知表情标识，跳过 HTML 标签和 URL 中的误匹配：
- 用
regexp.MustCompile编译一次正则，例如`:[a-zA-Z0-9_+-]+:` 或 `\[([a-zA-Z0-9_+-]+)\]` - 使用
ReplaceAllStringFunc或ReplaceAllString配合回调函数，确保只替换完整匹配项（防止:smile:ing被误替） - 不直接拼接 HTML，返回纯文本（含 Unicode 表情）或带语义标记的结构体（如
{"type":"emoji","value":"smile"}）
前后端协作建议
服务端不负责渲染，但需为前端提供可扩展的格式支持：
- 若前端用纯文本显示：服务端替换为 Unicode 即可，兼容性好、零额外请求
- 若前端需自定义图标（如加载 SVG）：服务端保留原始标记（如
:smile:），并在响应中加字段"has_emoji": true，由前端用库（如 EmojiOne 或 interweave）解析并渲染 - 务必对用户输入做基础过滤（移除 script 标签、onxxx 属性），再进行表情替换，防止绕过
避免常见坑
别在服务端生成 HTML 片段返回给客户端 —— 这会增加 XSS 风险且耦合前后端。也别用 html.EscapeString 全局转义后再替换表情，否则 Unicode 表情会被破坏。正确做法是：
- 先提取并验证所有表情标记
- 对非表情部分做 HTML 转义
- 将已知表情按映射插入，保持其原始 Unicode 或占位结构
- 最终组合成安全、可渲染的字符串或结构化消息
