Node.js 定时器 unref：程序可以退出了，为什么回调有时仍然执行
命令行工具加了一个后台清理定时器，主任务结束后却迟迟不退出。给定时器调用 unref 后，工具能及时结束，于是有人把它当成取消操作。后来工具接入另一个活跃连接，原来那个定时器又执行了。unref 改变的是它是否要求事件循环继续存活，不会从计划中删除回调。
为了把其他活跃句柄隔离开，下面由主程序启动三个短命子进程，分别验证仅有 unref 定时器、另有保活任务、以及显式取消。保存为 demo.mjs，运行 node demo.mjs。只调用本机当前 Node 可执行文件，不联网，也不创建持久文件。
没有别的工作时，回调可能来不及运行
AI概念示意图：计时器与保活绳索脱开，钟表自身仍然保留，出口已经打开。图片不是运行截图。
import assert from "node:assert/strict";
import {spawnSync} from "node:child_process";
function run(source) {
const result = spawnSync(process.execPath, ["-e", source], {
encoding: "utf8", timeout: 5000
});
assert.equal(result.error, undefined);
assert.equal(result.status, 0, result.stderr);
assert.equal(result.stderr, "");
return result.stdout.trim().split("\n");
}
const alone = run(`
setTimeout(() => console.log("fired"), 1000).unref();
console.log("scheduled");
`);
assert.deepEqual(alone, ["scheduled"]);
const alive = run(`
setTimeout(() => console.log("fired"), 10).unref();
setTimeout(() => console.log("keeper"), 80);
`);
assert.deepEqual(alive, ["fired", "keeper"]);
const cancelled = run(`
const timer = setTimeout(() => console.log("fired"), 10);
timer.unref();
clearTimeout(timer);
setTimeout(() => console.log("keeper"), 80);
`);
assert.deepEqual(cancelled, ["keeper"]);
const timer = setTimeout(() => {}, 1000);
assert.equal(timer.hasRef(), true);
timer.unref();
timer.unref();
assert.equal(timer.hasRef(), false);
timer.ref();
assert.equal(timer.hasRef(), true);
clearTimeout(timer);
console.log("alone:", alone);
console.log("other work alive:", alive);
console.log("cancelled:", cancelled);
console.log("ref state checks passed");第一段子程序安排一秒后写出 fired，并马上 unref。它只输出同步的 scheduled，随后自然结束，没有等到那个回调。父程序既核对标准输出，也检查退出状态；如果子进程没有按预期结束，五秒保护超时会让测试失败，而不是一直挂着。
这证明在本实验中，不再被引用的定时器没有单独撑住进程。不能把它推广为“调用 unref 就立即终止进程”：其他连接、任务或保持活跃的句柄仍会影响生命周期。实际工具不退出时，需要继续定位剩余工作，而不是反复调用同一个定时器的 unref。
另有保活任务，原回调仍可正常触发
第二段子程序给短定时器调用 unref，同时保留一个较晚的普通定时器。因为后者使进程继续存活，前者到期后仍写出 fired，随后得到 keeper。这个反例直接说明 unref 没有取消回调，已经捕获在闭包中的业务动作仍可能发生。
第三段则对短定时器调用 clearTimeout，并同样保留后面的 keeper。输出只剩 keeper，才说明这次计划的回调被取消。需要阻止后续动作时应明确取消；若动作已经开始执行，清理定时器也不会自动回滚它已产生的结果。
hasRef 观察保活标志，ref 可以恢复它
主程序还检查了一个定时器从默认有引用，到 unref 后无引用，再到 ref 恢复的标志变化，最后用 clearTimeout 清理。多次调用 unref 不代表叠加多个“解除层级”，也无需用相同次数的 ref 才能恢复。这里的标志不是引用计数式的业务锁。
hasRef 为 false 并不证明定时器对象已销毁，hasRef 为 true 也不证明回调未来一定成功。取消、进程终止、回调异常以及程序主动退出都需要另外分析。排查时可以同时记录定时器是否仍计划执行、保活设置、以及实际回调是否进入。
后台尽力任务和必须完成的任务应分别设计
unref 适合允许进程结束时放弃的附属任务，例如某些非关键缓存清理。必须完成的文件写入、状态提交或交接动作，应建立明确的完成等待与错误处理，不要为了让命令快速退出而统一解除保活。否则表面上干净退出，实际工作可能尚未开始。
本实验使用不同的短延时建立先后关系，没有断言毫秒级精确触发时间。事件循环繁忙时回调可能延后，定时器不是实时调度保证。测试观察的是进程能否结束、回调是否出现以及最终输出顺序，这些证据足以区分保活与取消，却不用于测量调度性能。
资料核对日期：2026年10月2日（北京时间）。示例在 Node.js 24.19.0 中独立运行。
