在一段对话里，连续出现两条“明天确认”，随后有人引用其中一条回复“可以”。如果系统只保存那几个字，读者无法知道回复针对哪条消息；如果保存的是列表第 20 项，加载更早记录后，第 20 项又可能变成另一条。
引用回复要解决的并不只是排版问题，而是三个不同的问题：回应的是谁、当前能展示什么、点击后能否找回上下文。 把它们合成一段固定摘要，很容易在分页、撤回或访问条件变化时出现误导。
米米商聊的产品方手机端功能资料确认，消息操作包含引用、撤回等功能。本文以引用这一真实功能为分析背景，讨论同类聊天系统的设计问题。资料没有说明其引用字段、撤回后的引用样式或桌面端完整操作，本文不对这些行为下结论。下面的字段、代码和图均为独立教学示例，不是产品源码或实际架构。文章与配图使用 AI 辅助，代码另做独立验证。
1. 摘要、位置和消息标识解决不同的问题
设想一个纯教学场景：同一会话的 m17 与 m18 内容都为“明天确认”。回复 r3 指向的是 m17。
| 保存的内容 | 能做什么 | 容易出错的地方 |
|---|---|---|
| 摘要“明天确认” | 让人快速理解大致主题 | 同文消息无法区分，无法据此定位 |
数组位置 20 | 在当前这份列表里找一项 | 插入、过滤、排序和分页会改变位置 |
消息标识 m17 | 表达回复与原消息的关系 | 仍需明确标识的作用域和访问条件 |
因此可以把“引用关系”建模为会话标识与消息标识的组合。本文使用 (conversationId, messageId)，是为了适配“消息标识只在会话内唯一”的教学假设。实际系统若采用全局唯一标识，仍应核对该消息与目标会话的关系，不能把随机性或唯一性当作访问授权。
这不是凭空规定的产品协议。作为公开协议的对照，Matrix 的 Rich replies 通过 m.in_reply_to.event_id 表达回复指向的事件，而不是依靠正文片段匹配。它支持“引用关系应有明确目标”的论点；本文的字段和状态模型并不是 Matrix 协议的实现，也不据此推断任何产品采用 Matrix。Matrix：Rich replies
消息标识还需要在发送确认后稳定下来。如果应用使用临时标识做本地回显，就要在确认后替换或维护到正式标识的映射；把已经失效的临时标识永久写进引用关系，会让后续设备无法解析。这是接入时的设计建议，下面的示例仅处理已经确定的标识。
2. 引用关系可以保留，原文却未必还能展示
“这条回复曾指向某条消息”与“此刻允许展示那条消息的原文”是两个判断。
对引用卡片而言，至少要区分以下状态：
| 查询结果 | 建议的界面行为 | 不应直接推断 |
|---|---|---|
| 原消息未加载 | 显示尚未加载，允许发起加载 | 原消息已删除 |
| 临时读取失败 | 显示暂时无法读取，提供重试 | 引用关系无效 |
| 找到且当前允许读取 | 展示受控摘要，允许定位 | 摘要就是完整上下文 |
| 原消息不可用或不允许读取 | 保留简洁占位，不展示原文 | 可以用旧缓存绕过限制 |
图：通用设计模型，四种展示结果与定位步骤分别处理；不是 App 界面或内部实现。
本地数组中 find 没找到，只能说明当前数组没有这条记录。若只加载了最近一页，不能把缺失直接变成“原消息已删除”。not-found 应由明确的查询结果产生，而不是由一页缓存推出来。
不可用占位可以统一为“原消息当前不可用”，避免把权限拒绝、缺失等内部原因逐项暴露给不应知道这些信息的人。内部诊断可以记录经过权限控制的原因，用户界面不必全部展示。
引用关系保留也不意味着永久保留原文。若产品选择保存摘要快照，需要事先明确它在撤回、内容修订和访问条件变化后的展示规则。快照只是另一份数据，不能自动获得比原消息更宽的展示权限；已经被人看见或另行保存的内容，也不能由一次界面隐藏保证被收回。本文示例选择在当前不可读取时隐藏摘要，不从引用对象里的旧文本回退。
3. 一个只负责展示决策的 JavaScript 模型
下面的函数接受引用关系、当前会话与查询层给出的结果，返回展示状态。它不请求网络、不访问真实聊天记录、不计算账号权限，也不执行滚动。
查询层的 canRead 必须来自可信的访问判断；客户端自己填一个 true 不能证明有权读取。展示函数再次检查它，只是防止把错误结果展示出来。服务端读取原消息及周边上下文时仍应逐次校验访问条件，这与 OWASP 对每次请求检查权限的建议一致。OWASP：Validate the Permissions on Every Request
function validId(value) {
return typeof value === "string" && value.length > 0 &&
value === value.trim();
}
function quoteView(ref, currentConversationId, result) {
const unavailable = () => ({
kind: "unavailable", text: "原消息当前不可用", canLocate: false
});
const retry = () => ({
kind: "retry", text: "暂时无法读取原消息", canLocate: false
});
if (!ref || !validId(ref.conversationId) || !validId(ref.messageId) ||
!validId(currentConversationId) ||
ref.conversationId !== currentConversationId) {
return unavailable();
}
if (result?.status === "not-loaded") {
return { kind: "pending", text: "原消息尚未加载", canLocate: false };
}
if (result?.status === "not-found" || result?.status === "denied") {
return unavailable();
}
if (result?.status !== "loaded") return retry();
const message = result.message;
if (!message || message.id !== ref.messageId ||
message.conversationId !== ref.conversationId ||
message.canRead !== true || message.state === "removed") {
return unavailable();
}
if (message.state !== "active" || typeof message.text !== "string") {
return retry();
}
const points = Array.from(message.text);
const text = points.slice(0, 120).join("") +
(points.length > 120 ? "…" : "");
return { kind: "ready", text, canLocate: true };
}
这里有几项刻意的取舍：
- 限定会话后再处理结果。 即使不同会话里都有
m17，也不能把另一会话的同号记录拿来展示。查询结果返回了错误的消息标识，同样不能接受。 - 展示状态不只有“有/无”。
pending留给加载动作，retry留给失败恢复；两者都不表示已确认删除。removed是查询层已确认不可展示的示例状态，不区分真实产品的删除与撤回规则。 - 未知格式不当作正常原文。 本示例只处理文本消息；图片、文件等需要单独定义受控预览，不能直接把对象转成字符串。
- 摘要最多取 120 个 Unicode 码点。 这是教学尺寸，不是产品限制。
Array.from避免拆开代理对，但仍可能拆开由多个码点组成的组合字符或表情；需要按用户感知字符截断时，应另用字素分割并测试。
函数输出的是文本数据。Web 界面展示纯文本摘要时应使用文本节点或 textContent，不要把消息内容直接塞进 innerHTML。这项渲染建议可参考 MDN 对两者的区别说明；下面的纯函数测试没有验证实际 DOM 渲染。MDN：textContent 与 innerHTML
4. 用反例验证边界，而不是只看一次正常回复
将下面代码接在前一段后，用 Node.js 运行即可。标识、消息与摘要均为教学数据。
const assert = require("node:assert/strict");
const ref = { conversationId: "room-a", messageId: "m17" };
const loaded = extra => ({ status: "loaded", message: {
id: "m17", conversationId: "room-a", canRead: true,
state: "active", text: "明天确认", ...extra
} });
const cases = [
["正常引用", ref, "room-a", loaded(), "ready", "明天确认"],
["尚未加载", ref, "room-a", { status: "not-loaded" },
"pending", "原消息尚未加载"],
["网络失败", ref, "room-a", { status: "error" },
"retry", "暂时无法读取原消息"],
["确认缺失", ref, "room-a", { status: "not-found" },
"unavailable", "原消息当前不可用"],
["访问拒绝", ref, "room-a", { status: "denied" },
"unavailable", "原消息当前不可用"],
["原文不可展示", ref, "room-a", loaded({ state: "removed" }),
"unavailable", "原消息当前不可用"],
["已缓存但无权读取", ref, "room-a", loaded({ canRead: false }),
"unavailable", "原消息当前不可用"],
["权限未知", ref, "room-a", loaded({ canRead: undefined }),
"unavailable", "原消息当前不可用"],
["当前会话不符", ref, "room-b", loaded(),
"unavailable", "原消息当前不可用"],
["结果来自另一会话", ref, "room-a", loaded({ conversationId: "room-b" }),
"unavailable", "原消息当前不可用"],
["结果标识不符", ref, "room-a", loaded({ id: "m18" }),
"unavailable", "原消息当前不可用"],
["空标识", { ...ref, messageId: "" }, "room-a", loaded(),
"unavailable", "原消息当前不可用"],
["非文本类型", ref, "room-a", loaded({ text: {} }),
"retry", "暂时无法读取原消息"],
["未知消息状态", ref, "room-a", loaded({ state: "unknown" }),
"retry", "暂时无法读取原消息"],
["旧摘要不能回退", { ...ref, snapshot: "旧原文" }, "room-a",
{ status: "denied" }, "unavailable", "原消息当前不可用"],
["没有查询结果", ref, "room-a", undefined,
"retry", "暂时无法读取原消息"]
];
for (const [name, r, room, result, kind, text] of cases) {
assert.deepEqual(quoteView(r, room, result),
{ kind, text, canLocate: kind === "ready" }, name);
}
// 同文、同号与插入列表：按会话和标识定位，不能按内容或位置。
const rows = [loaded().message,
{ ...loaded().message, id: "m18" },
{ ...loaded().message, conversationId: "room-b", text: "另一会话" }];
const findTarget = list => list.find(m =>
m.id === ref.messageId && m.conversationId === ref.conversationId);
const original = findTarget(rows);
rows.unshift({ ...loaded().message, id: "earlier" });
assert.equal(findTarget(rows), original);
// 截断完整的补充平面字符，省略号另占一个码点。
const longView = quoteView(ref, "room-a", loaded({ text: "😀".repeat(121) }));
assert.equal(longView.text, "😀".repeat(120) + "…");
// 函数不应为了展示而改写引用或查询结果。
const input = loaded();
const before = JSON.stringify({ ref, input });
quoteView(ref, "room-a", input);
assert.equal(JSON.stringify({ ref, input }), before);
console.log("16组结果检查与3组边界检查通过");
本轮实际运行文章这两个代码块，环境为 Node.js v24.19.0，16 组明确预期检查与 3 组边界检查通过。验证范围是独立展示决策函数及教学定位条件，未测试产品客户端、真实消息接口、访问控制服务或设备间同步，也未把函数通过当作端到端引用功能验收。
5. 点击引用后，仍要完成一次上下文定位
canLocate: true 只表示根据当前结果可以提供定位入口，并不意味着原消息已经出现在可滚动区域。
对使用分页或虚拟列表的客户端，建议把点击流程拆开：先按目标会话和消息标识获取原消息附近的记录，再合并进当前列表，等待目标节点进入渲染范围，最后滚动并短暂高亮。找不到节点时，应报告定位尚未完成，而不是静默跳到列表底部，造成“已经找到原消息”的错觉。
加载到定位之间还可能发生会话切换。一次点击可以携带目标会话与本次操作标识，异步完成时再次核对当前目标；旧会话的结果不应把用户拉回去。这里仅说明引用定位所需的验收条件，未实现异步请求控制。
权限也可能在卡片展示后发生变化。再次读取原消息和相邻上下文时，应以该次请求的访问判断为准；周边记录不能因为“顺便加载上下文”就跳过各自的访问规则。即使原文不可用，用户自己已经发送的回复正文仍可按自身规则展示，避免把“引用源失效”错误处理成“整条回复消失”。这些都是设计建议，不代表某一产品现有行为。
6. 回到开头：让回复始终指向正确的对象
两条文字相同的消息，靠稳定标识区分；加载更早记录后，靠标识重新定位，而不是继续使用旧数组下标。原消息尚未加载时保留加载状态，临时失败时允许重试，确认不可用或不允许读取时保留占位并停止展示旧原文。
因此，引用回复可以分别设计“关系、展示、定位”三个契约：关系回答指向哪条消息，展示回答此刻能看什么，定位回答怎样回到允许访问的上下文。三者分开，才能在原消息状态变化后继续解释这条回复，而不是让一段摘要承担它无法承担的身份和权限判断。
参考资料
- 产品事实背景：产品方提供的手机端消息操作说明；仅采用已确认的引用功能，不将未验证的桌面流程或失效样式列为产品事实。
- Matrix v1.19 Client-Server API：Rich replies：回复关系的事件标识表达。
- OWASP Authorization Cheat Sheet：每次请求的访问检查。
- MDN：Node.textContent：纯文本与 HTML 渲染的区别。
