launch.json的program路径错误会伪装成时钟偏差，实际是program指向不存在文件导致调试静默失败；必须用${workspaceFolder}/src/index.js等绝对路径，不可写src/index.js或./src/index.js。
launch.json 的 program 路径错误会伪装成时钟偏差
VSCode 调试卡在“正在启动调试器”、断点变灰、控制台无输出，常被误判为系统时钟不准，实际是 program 指向了不存在的文件。VSCode 不报错，只静默失败。
-
program必须是绝对路径，推荐用${workspaceFolder}/src/index.js，不能写src/index.js或./src/index.js - 确认该 JS 文件真实存在，且不是未编译的 TS 源码（TS 项目需先
tsc或改用type: "pwa-node"+sourceMaps: true） - 终端执行
node -v和which node，确保 VSCode 启动方式能继承 PATH；macOS/Linux 建议从终端运行code .启动
Node 进程启动后修改 TZ 环境变量完全无效
process.env.TZ = 'Asia/Shanghai' 在代码里赋值毫无作用——Node.js 自 v10 起已废弃此行为。进程启动时已固化时区信息，后续任何运行时修改（包括改系统时区、重设 process.env.TZ）都不会影响 new Date().getHours() 等本地时间方法。
- 必须在启动前设置环境变量：Linux/macOS 使用
TZ=Asia/Shanghai node server.js，Windows 用set TZ=Asia/Shanghai && node server.js - npm script 封装更可靠：
"start": "TZ=Asia/Shanghai node server.js" - Docker 用户注意 Alpine 镜像需额外安装时区数据：
RUN apk add --no-cache tzdata
Assertion failed: new_time >= loop->time 是计时器漂移，不是代码问题
这个 Windows 下常见崩溃（src\win\core.c, line 327）本质是 libuv 对系统单调时钟的要求被打破，和你的 JS 逻辑无关。典型诱因包括：系统时间不同步、快速启动功能残留、或旧版 Node 在新 CPU 上的硬件计时抖动。
- 立即生效：以管理员身份运行 PowerShell，执行
w32tm /resync强制校准；若失败，先重置时间服务并换阿里云 NTP：w32tm /config /manualpeerlist:"ntp.aliyun.com,0x8" /syncfromflags:manual /reliable:yes /update - 根治方案：升级 Node.js 至 v16.14.0+、v18.20.4+ 或 v20.12.2+，新版 libuv 加入了 clock drift tolerance 机制
- 笔记本用户务必关闭“快速启动”：电源选项 → 选择电源按钮的功能 → 更改当前不可用的设置 → 取消勾选“启用快速启动”
倒计时或定时任务出现累积偏差，别依赖 setInterval
用 setInterval(fn, 1000) 实现倒计时，几小时后可能差出十几秒——这是事件循环延迟叠加导致的，和系统时钟无关，但表现类似“时间跑偏”。
- 每次更新都基于当前真实时间计算剩余量：
const remaining = endTime - Date.now()，而非靠递减变量 - 高精度场景优先用
requestAnimationFrame替代setInterval，它由浏览器渲染节奏驱动，抖动更小 - Node.js 后端若需长期稳定定时，避免
setTimeout链式调用，改用node-schedule或bullmq这类带误差补偿的库
时区、计时器、调试配置这三块最容易相互干扰，排查时一定要分清：是调试器连不上？是 new Date() 输出不对？还是倒计时越走越慢？它们的修复路径完全不同。
