消息列表气泡布局本身和 WebSocket 无关，但渲染逻辑必须配合 onmessage 事件触发时机与 DOM 更新节奏，否则会出现错位、重复、滚动异常等现象；推荐用独立 div 包裹每条消息，通过 class 控制方向，避免 ul 动态追加导致重排跳动，且 scrollTop = scrollHeight 失效主因是执行时机不当或容器高度未正确计算。
直接说结论：消息列表气泡布局本身和 WebSocket 无关，但渲染逻辑必须配合 onmessage 事件触发时机与 DOM 更新节奏，否则会出现错位、重复、滚动异常等现象。
为什么用 div + class 气泡比用 ul/li 更稳妥
多数人习惯用列表结构组织聊天消息，但 ul 在动态追加时容易因浏览器重排导致滚动条跳动或焦点丢失；而纯 div 块级流更可控。关键点在于：
- 每条消息用独立
div包裹，通过class="msg-bubble msg-left"或class="msg-bubble msg-right"控制方向与样式 - 避免在
ul内反复innerHTML += ...—— 这会销毁旧节点并重建全部子元素，中断 CSS 动画、丢失 focus 状态 - 推荐用
messagesContainer.appendChild(newMsgDiv)追加单个节点，性能稳定且兼容性好 - 若需支持“已读回执”或“编辑状态”，
div结构也更容易插入额外 DOM 元素（如小图标、时间戳、状态 badge）
scrollTop = scrollHeight 失效的常见原因
这行代码本意是让消息容器自动滚到底部，但实际常失效，根本原因是执行时机不对或容器未正确计算高度：
- 必须确保
newMsgDiv已真实插入 DOM 后再调用scrollHeight，否则值为 0 或旧值 - 如果容器设置了
height但没设overflow-y: auto，scrollTop不起作用 - 使用
flex布局时，父容器若设了align-items: flex-start，可能导致子元素高度塌陷，影响scrollHeight计算 - 更健壮写法：
messagesContainer.scrollTop = messagesContainer.scrollHeight - messagesContainer.clientHeight;
（显式减去可视区高度，避免依赖初始值）
消息方向判断不能只靠发送者身份
前端无法 100% 可靠识别“谁发的消息”，尤其在群聊或代理转发场景下。真正可行的判断依据只有两个：
立即学习“前端免费学习笔记（深入）”；
- 服务端在推送消息时，明确附带
"from": "self"或"from": "other"字段 —— 这是最干净的方式 - 客户端本地缓存当前用户 ID（如
currentUser.id），和服务端返回的senderId对比，相等则为右气泡（自己发的） - 绝对不要用连接 session ID、WebSocket URL 参数、IP 地址等不可靠字段做判断
- 注意：WebSocket 是全双工，同一连接既收又发，
ws.send()不代表这条消息就该显示为右气泡 —— 它只是发出去的动作
气泡边距、圆角、阴影这些细节最容易被忽略
视觉上“像聊天软件”的关键不在动画，而在微小的物理感设计：
- 左右气泡的
margin-left/margin-right必须不同，否则会挤成一列（例如左气泡margin-right: 60px，右气泡margin-left: 60px） - 圆角建议用
border-radius: 18px 18px 18px 4px（左气泡）和border-radius: 18px 18px 4px 18px（右气泡），模拟真实对话气泡的“指向性” - 阴影别用统一
box-shadow，右气泡可略强（0 2px 6px rgba(0,0,0,0.12)），左气泡稍弱（0 1px 4px rgba(0,0,0,0.08)），增强视觉层次 - 文字换行用
word-break: break-word而非white-space: pre-wrap，后者在长 URL 或无空格字符串下会溢出容器
