客服、AI 助手、团队群聊——双方实时来回、需要保留上下文、状态和重试的场景。
界面与交互 · 内容与数据展示
聊天界面Chat UI
由消息列表、输入框和发送状态组成的可恢复对话界面——每条消息是个带归属、时间和状态的物件。
发送一条消息，看它怎样长在对话流里
聊天界面的核心不是输入框，而是那条会增长的消息流。亲手发一条，观察气泡带着发送状态出现；勾选模拟失败，再看失败气泡和重试。
第 0 步：这是一段客服对话。在输入框打字、按 Enter 发送（Shift+Enter 换行）， 看新消息作为气泡长在对话流里，并带上自己的发送状态。勾选「模拟下次失败」可看失败气泡与重试。
- 客服小夏 · 今天 10:20
你好，我是客服小夏。把订单号发我，我帮你查进度。
- 我 · 今天 10:21
订单 #A-204 还没送到，能帮忙看看吗？
✓ 已送达
对照：对话已就绪。原因：聊天是一条结构化的消息流，每条带归属、时间和发送状态。下一步：在输入框打字，Enter 发送，看新气泡怎样长出来。
失败的消息保留在流里；「重新发送」是本页唯一的主操作（红色）。
面板教会的知识点
把刚才操作里看到的现象命名为六条规则。
- 对话是结构化物件：消息列表用 role="log"，新消息长在前一条之后，aria-live 让读屏也能感知变化。
- 每条消息带归属：气泡区分「我」和「对方」，配头像、昵称，不能只靠气泡颜色区分发送方。
- 时间戳可读：每条消息标注时间，让用户回看对话时能定位「什么时候说的」。
- 发送状态长在气泡上：发送中、已送达、失败直接标在对应气泡，不只在底部提示。
- 失败保留并提供重试：失败的消息不清空、不静默，气泡带「重新发送」，让对话能继续。
- 对方正在输入：聊天独有的反馈，让等待回复变得可预期，区别于一次性表单。
什么时候用聊天界面
从交互是否双向、是否实时判断，而不是看控件长什么样。
一次性表单提交、单向通知（用 toast / alert）、静态评论列表（用 list）。没有双向实时沟通就别套聊天壳。
怎么用：从消息模型到发送恢复
最短路径——消息结构、输入、发送状态与重试一次到位。
- 把消息建成带 owner、text、time、status 的物件，列表用 role="log" + aria-live 渲染。
- 输入框支持 Enter 发送、Shift+Enter 换行；发送期间禁用发送键，防重复提交。
- 新消息先以「发送中」长在流里；成功转「已送达」并追加对方回复，失败转「失败」并保留。
- 失败气泡提供「重新发送」；对方回复前可显示「正在输入」作为等待反馈。
正反例：同一条「发送失败」消息
只改一个关键判断——失败后是否保留消息并提供重试。
用户写的内容不丢，状态标在气泡上；点一下就能重发，对话从失败处继续。
差异：失败可见、原因可读、动作可恢复。只弹一句「发送失败」，用户得凭记忆重打；常以为发出去了，对话断在半路。
差异：删掉保留与重试，聊天就不再可信。快速自测
你做了一个客服聊天窗，网络偶尔不稳定。发送失败时最该保证的是什么？
继续查证
术语的技术定义和行为以这些一手或权威资料为准。
下一步学
和本知识点经常一起出现的概念。