Node.js 26 测试随机化怎么落地：固定种子、顺序依赖与失败复现

测试在本地跑全是绿的，一切到CI环境偶尔就崩，最头疼的还不是流水线亮红灯，而是再跑一次失败直接消失，连现场都找不到。Node.js 26 内置的 node:test 已经自带测试顺序随机化和可复现种子能力，完全可以把之前摸不着头绪的“顺序依赖偶发故障”，变成可以精准回放的明确问题。

先用 --test-randomize 放大测试之间的隐性耦合，再把输出里的 seed 固定下来复现；随机化负责发现问题，固定种子负责定位问题。

先把“偶发失败”变成可记录的命令

假设项目的测试文件都放在 test/*.test.js 路径下，平时跑测试的默认命令是 node --test。先在本地跑一遍开启随机化的版本：

node --test --test-randomize

Node.js 会在诊断输出里直接显示本次随机化使用的 seed 值。遇到失败别只截个图就往工单里贴，至少存好当前的Node版本、完整执行命令、对应seed和失败的测试名；少任意一个字段，后面大概率没法复现故障。

固定种子，复现同一次测试排列

拿到失败对应的seed之后，直接把它填进命令行参数里：

node --test --test-random-seed=184729

固定种子不只是“把测试再跑一遍”而已。它会把所有测试文件的运行顺序、还有单个文件内排队的子测试执行顺序全部锁死，你就能顺藤摸瓜找到前一个测试到底留下了什么脏状态：没关掉的定时器、被改了数据的共享数据库行、被篡改的环境变量，或者没还原的假计时器。

这步先别急着改业务代码。先把故障范围缩小到两个测试：保留失败的那个测试，和它运行顺序里最后一个通过的前置测试，中间的文件逐步删掉。如果删掉前置测试之后故障直接消失，那问题基本就是状态泄漏，和测试本身的断言逻辑没关系。

在测试文件里显式管理共享状态

顺序依赖的问题大多出在模块级别的单例上。比如前面一个测试把 process.env.FEATURE_X 改成了 on，后面的测试又默认这个环境变量不存在。这类场景要在钩子函数里主动保存并还原状态，别指望测试运行器会自动帮你清理：

import test from 'node:test';
import assert from 'node:assert/strict';

const original = process.env.FEATURE_X;

test.afterEach(() => {
  if (original === undefined) delete process.env.FEATURE_X;
  else process.env.FEATURE_X = original;
});

test('feature flag is isolated', () => {
  process.env.FEATURE_X = 'on';
  assert.equal(process.env.FEATURE_X, 'on');
});

数据库、临时文件夹和监听端口的处理思路完全一样：每个测试单独分配自己的命名空间，执行结束后主动释放所有资源；如果确实需要全局公共fixture，就把对应的创建和销毁逻辑写进 globalSetup/globalTeardown，同时在失败日志里把用到的资源标识打印出来。

把随机化放进 CI，但不要让它吞掉确定性检查

一套好用的流水线可以拆成两道独立校验环节：

# 每次提交：稳定、快速、容易读日志
node --test

# 合并请求：专门寻找顺序依赖
node --test --test-randomize --test-reporter=spec

如果CI跑随机化测试失败，直接把对应的seed作为构建产物上传留存，让自动化机器人在工单评论里附上可以直接复制运行的复现命令。别遇到失败就自动换个新seed重跑，拿第二次跑出来的绿色结果当成功，那样直接就把最有排查价值的原始现场给覆盖掉了。

修复后的验收要看三层结果

第一层验证用原始失败的seed跑能直接通过，证明这次修复确实覆盖了已知故障。第二层换三个不同的固定seed跑全量测试仍然全部通过，避免只针对某一个特殊排列写了补丁，没根除问题。第三层检查测试进程是否能干净退出：没关掉的句柄、残留的定时器和没释放的服务端，会让测试看起来全部通过，最后在CI超时阶段莫名失败。

Node.js 26.1.0 起还支持 --test-randomize 与 --test-random-seed 组合回放。如果团队同时在维护LTS和Current两个大版本的Node环境，要在日志里打印当前实际运行的Node版本，别把不同版本的测试随机规则混在一起当成同一份结论。

常见问题

只使用 --test-random-seed 就够了吗？

完全可以。指定seed的时候就会自动开启随机化，同时把排列顺序固定下来；只是为了代码可读性更高，CI脚本里还是可以显式带上 --test-randomize 参数，让后续维护的人一眼就看懂逻辑。

随机化失败是不是说明测试顺序一定有问题？

不一定，也有可能是时间波动、网络波动或者资源竞争导致的。先用同一个seed连续多跑几次确认能稳定复现，再把外部依赖全部隔离，才能把顺序依赖导致的状态泄漏，和真正的并发不稳定问题区分开。

修复后要不要永久保留失败 seed？

建议在缺陷记录里存好对应的执行命令和seed，但别把这一个seed永久当成唯一的测试排列。等回归验证通过之后，后续正常跑测试还是要用新的随机seed轮询检查，避免漏过新的耦合问题。

总结

测试随机化的价值根本不是让CI跑测试的过程更“随机”，而是让测试之间隐藏的共享状态问题尽早暴露出来。用随机运行发现问题，用固定seed回放故障现场，用资源隔离和清理钩子修复根本问题，最后再用多组不同seed做验收，基于Node.js搭建的测试流水线才能真正具备排查顺序依赖故障的能力。