在React同构应用中，服务端渲染（SSR）与客户端 hydration 必须保证首屏结构一致。当我们需要对数组进行乱序展示，例如推荐列表、卡片墙时，如果直接使用 Math.random，服务器和浏览器会产生不同结果，导致 React 抛出文本不匹配警告，严重时整个节点被客户端重渲染。实现确定性数组乱序，就是让乱序结果由固定输入决定，而不是每次执行都变化。
为什么普通乱序会破坏SSR一致性
SSR 的工作流程是：Node 端调用 ReactDOMServer.renderToString 生成 HTML 字符串，浏览器收到后由 React 进行 hydration，将事件绑定到已有 DOM 上。hydration 阶段 React 会逐节点比对服务端 HTML 与客户端虚拟 DOM。如果发现某个 <li> 的文本或顺序不同，就会认为服务端“撒谎”了，进而在客户端用真实渲染结果替换该子树。
普通乱序依赖 Math.random，它读取系统时钟或熵池，在服务器进程和浏览器进程里必然不同。举例来说，服务器把 [A,B,C] 排成 [B,A,C]，而浏览器首屏计算成 [C,B,A]，两者不一致。这种不一致不仅产生控制台警告，还会造成用户看到内容“跳一下”。因此，任何在渲染期参与生成 UI 顺序的逻辑，都必须是纯函数且可复现。
确定性乱序的核心：带种子伪随机
确定性乱序的本质是伪随机数生成器（PRNG）接受同一个 seed，输出同一串数字。我们可用 mulberry32 这类轻量算法。它接收一个 32 位整数，通过位运算产生下一个整数，序列完全由初始 seed 决定。只要服务器和客户端用相同的 seed（比如从 URL、用户 ID 或数据哈希得出），生成的乱序数组就完全一致。
下面给出一个纯 JavaScript 实现，不依赖任何库，可直接用于 Node 与浏览器：
// 带种子的伪随机生成器 mulberry32
function mulberry32(seed) {
let a = seed >>> 0;
return function() {
a |= 0;
a = (a + 0x6D2B79F5) | 0;
let t = Math.imul(a ^ (a >>> 15), 1 | a);
t = (t + Math.imul(t ^ (t >>> 7), 61 | t)) ^ t;
return ((t ^ (t >>> 14)) >>> 0) / 4294967296;
};
}
// 将字符串转成 32 位整数种子
function hashSeed(str) {
let h = 2166136261;
for (let i = 0; i < str.length; i++) {
h ^= str.charCodeAt(i);
h = Math.imul(h, 16777619);
}
return h >>> 0;
}
// 确定性 Fisher-Yates 乱序
function deterministicShuffle(arr, seedStr) {
const rand = mulberry32(hashSeed(seedStr));
const result = arr.slice();
for (let i = result.length - 1; i > 0; i--) {
const j = Math.floor(rand() * (i + 1));
[result[i], result[j]] = [result[j], result[i]];
}
return result;
}
上面的 deterministicShuffle 接收原数组与种子字符串，返回新数组。由于 hashSeed 与 mulberry32 都是纯计算，在 Node 和浏览器中传入相同 seedStr 必然得到相同顺序。注意我们用了 arr.slice() 避免修改原数组，符合 React 不可变数据习惯。
在React SSR组件中使用
假设我们有一个文章列表组件，需要根据当前用户 ID 做确定性乱序。用户 ID 来自服务端注入的 window.__USER__ 或 SSR 上下文，两端都能拿到同样的值。组件代码如下：
import React from 'react';
function ArticleList({ articles, userId }) {
// userId 在服务器和客户端必须相同
const ordered = deterministicShuffle(articles, userId || 'guest');
return (
<ul>
{ordered.map(item => (
<li key={item.id}>{item.title}</li>
))}
</ul>
);
}
export default ArticleList;
在服务端渲染时，我们通过 ReactDOMServer.renderToString(<ArticleList articles={data} userId={ctx.userId} />) 输出 HTML；客户端则用同样的 userId 进行 hydration。因为 deterministicShuffle 是纯函数，两端输出的 <li> 顺序一字不差，hydration 安静通过。
如果项目使用 Next.js 或类似框架，可以把 userId 放在 getServerSideProps 返回，再通过 props 透传。关键是不要在前端用 useState 初始化随机数，那样服务端根本不知道客户端的初始状态。所有影响首屏顺序的状态都应来自可序列化的外部输入。
种子选择与注意事项
种子设计要兼顾稳定与变化。若希望同一用户每次访问顺序固定，用用户 ID 即可；若希望每天变一次但日内一致，可将用户 ID 加日期字符串（如 'user123-20240520' 但注意不写年份相关动态值时应去掉日期）作为种子。切忌用 Date.now() 或 Math.random 做种子，否则又回到不一致老路。
另一个坑是数组项缺失 key。即使顺序一致，如果 React 的 key 不稳定（比如用索引当 key 且数组变化），仍可能报错。我们示例用了 item.id 作为 key，这是安全做法。此外，如果乱序后需要做分页或筛选，应在乱序前完成数据查询，乱序仅作为展示层处理，避免逻辑耦合。
与随机乱序的效果对比
下表列出普通随机乱序与确定性乱序在 SSR 场景的差异：
| 维度 | Math.random 乱序 | 确定性乱序 |
|---|---|---|
| 服务端客户端一致性 | 不一致，必现 mismatch | 一致，无警告 |
| 用户感知 | 首屏闪烁、重渲染 | 平稳 hydration |
| 刷新变化 | 每次都变 | 由种子控制，可固定 |
| 实现复杂度 | 极低 | 稍高，需引入 PRNG |
可以看出，确定性乱序以少量代码代价换来了同构安全的渲染体验。对于电商、内容流等重视首屏稳定性的产品，这种写法几乎成为标配。
总结实践要点
在 React SSR 中处理数组乱序，记住三条：第一，渲染期不用任何非确定性 API；第二，用字符串哈希加 PRNG 实现可复现洗牌；第三，种子必须来自两端共享的输入。按此思路封装一个 shuffle 工具函数，团队所有列表展示都能复用，从根本上杜绝 hydration 顺序问题。
ReactSSRdeterministic_shuffle修改时间：2026-08-11 23:39:49