会话列表的排序规则看似简单，实际上牵涉到时间戳大小、未读数状态以及对用户注意力的引导。很多即时通讯产品不会只依赖最后消息时间倒序，因为一条未读消息如果来自半小时前的会话，其紧急程度可能高于刚刚收到的一条已读回执。React组件里实现这个需求，不只是在sort函数里写一行比较逻辑，还需要考虑数据不可变、useMemo缓存、服务端分页和稳定排序等问题。本文从实际聊天场景出发，给出一个可复用的排序模型与实现方式。
先定义排序维度与优先级模型
在动手写代码前，需要先明确排序的参与字段。一个典型的会话对象至少包含 id、title、lastMessageTime、unreadCount 和 pinned。其中 lastMessageTime 通常使用毫秒时间戳，unreadCount 是数字，pinned 表示是否置顶。排序目标可以描述为：未读会话优先展示，同一未读状态下按最后一条消息时间从新到旧排列；如果未来有置顶需求，置顶项需要排在最前。
const conversations = [
{
id: '1',
title: '产品群',
lastMessageTime: 1715000000000,
unreadCount: 3,
pinned: false
}
];
为什么不能只写 b.lastMessageTime - a.lastMessageTime？这个写法在处理数字时间戳时没问题，但一旦时间戳以字符串形式返回，例如 ISO 8601 字符串，减法会得到 NaN，导致排序结果完全不可控。更重要的是，它完全没有考虑未读数。假设一个会话最后消息是 10 分钟前且未读 5 条，另一个会话最后消息是刚刚但已经全部读完，用户很可能希望先处理前者。只用时间排序就会让未读会话沉到列表下方。
常见的排序设计有两种：分层比较和加权打分。分层比较的思路很直接，先按未读状态分组，有未读的排前，组内再按时间倒序。加权打分则是把未读状态映射成一个较大权重分，再加上归一化后的时间分。两种方案都能满足需求，但分层比较代码更直观，容易调试，也方便后续加入置顶、免打扰等维度。
在React中用useMemo实现高效排序
确定比较规则后，React里的实现要考虑性能与不可变数据。假设 conversations 数组来自组件状态或上层 props，直接调用 conversations.sort() 会修改原数组，违背React数据流原则。正确做法是先创建副本再排序：[...conversations].sort(compareConversations)。如果 conversations 长度不大，这样已经足够；但当组件频繁渲染时，每次渲染都执行排序会浪费计算。useMemo 可以缓存排序结果，只有 conversations 变化时才重新计算。
const sortedConversations = useMemo(() => {
return [...conversations].sort(compareConversations);
}, [conversations]);
compareConversations 接收两个会话对象，先比较未读状态。aUnread 和 bUnread 被转换为数字，如果 a 有未读而 b 没有，返回正数会让 a 排在 b 前面。这里用 bUnread - aUnread 简化了条件判断。接着比较时间戳，b.lastMessageTime - a.lastMessageTime 表示时间越新越靠前。最后用 id 做最终比较，避免时间相同的列表顺序不稳定。
function compareConversations(a, b) {
const aUnread = a.unreadCount > 0 ? 1 : 0;
const bUnread = b.unreadCount > 0 ? 1 : 0;
if (aUnread !== bUnread) {
return bUnread - aUnread;
}
const timeDiff = b.lastMessageTime - a.lastMessageTime;
if (timeDiff !== 0) {
return timeDiff;
}
return a.id.localeCompare(b.id);
}
在类型方面，lastMessageTime 建议在进入组件前统一为数字。如果服务端返回的是字符串，例如 2025-04-18T10:00:00Z，可以在数据请求层用 Date.parse 转换，或者写一个 normalizeConversation 工具函数。sort 比较器内部不要做过多转换，否则每次比较都会产生额外开销。
当用户打开某个会话并清除未读时，必须创建新数组和新对象，例如 setConversations(prev => prev.map(item => item.id === openedId ? { ...item, unreadCount: 0 } : item))。如果直接修改 item.unreadCount，useMemo 的依赖 conversations 引用没有变化，排序结果不会更新。这个细节在处理未读清零时非常关键。
稳定排序、置顶扩展与服务端协作
现代 JavaScript 引擎的 sort 方法在多数环境中已经稳定，但稳定排序并不是规范强制要求。为了防止不同环境下列表顺序抖动，比较器最后返回 id 比较是一个低成本保险。id 通常是字符串，可以使用 localeCompare，也可以直接比较 id。
置顶需求会改变优先级顺序。扩展比较器时，先比较 pinned，再比较未读，再比较时间。置顶会话内部仍然可以按未读和时间排序，这样用户不会因为置顶项过多而失去未读提示。代码如下：
function compareConversationsWithPin(a, b) {
if (a.pinned !== b.pinned) {
return b.pinned ? 1 : -1;
}
const aUnread = a.unreadCount > 0 ? 1 : 0;
const bUnread = b.unreadCount > 0 ? 1 : 0;
if (aUnread !== bUnread) {
return bUnread - aUnread;
}
const timeDiff = b.lastMessageTime - a.lastMessageTime;
if (timeDiff !== 0) {
return timeDiff;
}
return a.id.localeCompare(b.id);
}
如果会话列表数据量很大，前端排序可能只适合已加载到内存的全量数据。分页场景下，前端无法对服务端尚未返回的会话进行全局排序，此时应当把排序参数交给服务端，由服务端根据 sortField 和 sortOrder 返回排好序的页。React组件中只负责展示和交互，不要把全量排序的压力都放在浏览器端。
加权打分方案与测试验证
如果不想用分层比较，还可以使用加权分数。核心思路是为未读状态分配一个足够大的权重分，再把时间戳归一化到较小范围。比如未读计 100000 分，时间计数按毫秒时间戳除以 10^12，这样未读状态起主导作用，时间只影响同组内部的细排序。
function getSortScore(item) {
const unreadWeight = item.unreadCount > 0 ? 1 : 0;
const timeWeight = item.lastMessageTime / 1000000000000;
return unreadWeight * 100000 + timeWeight;
}
getSortScore 返回的数字越大越靠前。由于未读权重远大于时间权重的最大值，无未读会话的时间分即使再高，也很难超过有未读会话。但这种方案对变量范围敏感：如果时间戳单位不是毫秒而是秒，1000000000000 的除数就需要调整。项目维护者必须清楚归一化系数，否则容易出现分数误差。对比之下，分层比较器没有这种魔法数字，代码可读性更高。
验证排序逻辑时，可以准备四条数据：A 无未读但刚刚收到消息，B 有未读且最后消息 5 分钟前，C 有未读但最后消息 1 小时前，D 无未读且最后消息 2 小时前。期望顺序是 B、C、A、D。如果加入置顶 E，则 E 应排第一。这样的手工测试可以快速发现比较器遗漏的边界问题。更严格的场景可以把 compareConversations 抽取为独立模块，使用 Jest 或 Vitest 编写断言，保证排序逻辑在后续迭代中不被破坏。
会话列表排序不是一个一次性写完就结束的任务。置顶、免打扰、会话类型、消息发送状态都可能进入优先级体系。React中的实现要点集中在三处：比较器保持纯函数、排序结果用useMemo缓存、数据更新必须创建新引用。先把未读和时间这两个核心维度处理好，再逐步扩展复杂规则，可以避免排序逻辑失控，让聊天应用在信息密集时依然保持清晰的会话层级。
React会话列表排序未读数优先级最后消息时间修改时间：2026-10-04 20:57:17