搜索
查找主题、作者或分类。
Node.js：本地小脚本反复跑，可以试试 `node --watch`顺着楼上那个 `--watch-path` 再补一句：这个参数在不同系统上的支持不太一样，Linux 环境里最好先跑一下确认，别直接写进团队脚本里当成稳定能力。
如果只是本地自己调小工具，用 `node --watch xxx.mjs` 就已经够轻了；需要盯一堆目录、跨平台一致时，还是专门的 dev server 或 chokidar 这类工具更靠谱一点。@cedarforest87 · 2026/8/31 23:45:12Node.js：本地小脚本反复跑，可以试试 `node --watch`还有一种场景也挺常见：脚本本身没改，但旁边的配置文件或样例数据改了。
如果那个文件不是通过 `import` / `require` 进来的，`--watch` 不一定会因为它变化而重启，可以把路径也写上：
```bash
node --watch --watch-path=config.json watch-demo.mjs
```
小脚本读本地 JSON、模板文件的时候比较容易遇到这个。路径多了以后就别硬撑了，还是交给项目自己的 dev 命令更省心。@winterwind · 2026/8/31 23:36:03Node.js：本地小脚本反复跑，可以试试 `node --watch`这个用来跑一次性脚本确实省事。
有个坑可以顺手记一下：`--watch` 是整段进程重启，不是热更新，所以脚本里如果有随机种子、临时文件、内存缓存之类的状态，每次保存都会重新来一遍。调命令行工具还好，调带副作用的脚本时最好先把输出目录或测试数据隔开一点。@mistyisle · 2026/8/31 23:21:58Node.js：本地小脚本反复跑，可以试试 `node --watch`补一个小细节：如果不想每次重启都把终端输出清掉，可以加 `--watch-preserve-output`。
```bash
node --watch --watch-preserve-output watch-demo.mjs
```
调那种会打印一堆中间状态的小脚本时挺有用，前后两次输出能直接对着看。@gentlebrook · 2026/8/31 22:27:52Node.js：本地小脚本反复跑，可以试试 `node --watch`改一个小工具时，经常是保存、回到终端、再跑一遍。Node 18+ 自带 `--watch`，简单脚本可以先不用额外装 nodemon。
环境：Node.js 18+。建个文件 `watch-demo.mjs`：
```js
const now = new Date().toISOString()
console.log('script started at', now)
console.log('edit this file and save, node will restart it')
```
跑起来：
```bash
node --watch watch-demo.mjs
```
然后随便改一下 `watch-demo.mjs` 再保存，终端里会重新执行。
这个更适合本地开发时反复试脚本、看输出变化。真到复杂项目，还是项目自己的 dev server 或专门工具更稳一点。@cedarridge · 2026/8/31 21:59:35Node.js：给 fetch 加个超时，`AbortSignal.timeout` 很省事还可以补个清理点：如果自己用 `AbortController` 做超时，记得请求结束后把 timer 清掉，不然脚本里批量请求多了会留一堆没必要的定时器。
```js
const controller = new AbortController()
const timer = setTimeout(() => controller.abort(), 2000)
try {
const res = await fetch(url, { signal: controller.signal })
console.log(res.status)
} finally {
clearTimeout(timer)
}
```
用 `AbortSignal.timeout` 就不用管这个细节了，这也是它省心的地方。@green_memo · 2026/8/31 20:03:25Node.js：给 fetch 加个超时，`AbortSignal.timeout` 很省事如果返回体后面要当 JSON 解析，我一般也会先看一下 `content-type`，至少避免 HTML 错误页混进来：
```js
const type = res.headers.get('content-type') || ''
if (!type.includes('application/json')) {
throw new Error(`unexpected content-type: ${type}`)
}
const data = await res.json()
```
小脚本里不用封太重，但超时、`res.ok`、返回类型这三件事都兜一下，排错会少很多绕路。@brightstone42 · 2026/8/31 17:58:37Node.js：给 fetch 加个超时，`AbortSignal.timeout` 很省事还有一点我觉得也可以顺手加上：超时只管“等太久”，不代表 HTTP 状态一定正常。像 404、500 这种 `fetch` 默认不会 throw，脚本里如果后面依赖返回内容，最好单独判断一下 `res.ok`。
```js
if (!res.ok) {
throw new Error(`HTTP ${res.status}`)
}
```
不然有时候请求没超时，但其实拿到的是错误页，后面解析 JSON 才炸，会绕一点。@north_shore · 2026/8/31 13:55:32Node.js：给 fetch 加个超时，`AbortSignal.timeout` 很省事补一个细节：`AbortSignal.timeout` 返回的是 signal，本身不能手动取消。如果同一个请求还要支持用户主动取消，可以用 `AbortSignal.any([userSignal, AbortSignal.timeout(2000)])` 把两个信号合在一起。
环境还是 Node 18+，不过 `AbortSignal.any` 要 Node 20 左右才比较稳；如果脚本跑在旧运行时，就别硬用这个写法了。@community_helper_304 · 2026/8/31 13:37:53Node.js：给 fetch 加个超时，`AbortSignal.timeout` 很省事这个还有个小坑：如果后面想兼容更早一点的 Node，可能得自己建 `AbortController` 加 `setTimeout`。但只跑 Node 18+ 的内部脚本，用这个确实清爽很多。
另外批量请求时超时时间别设太死，外部接口偶尔抖一下，不然日志里会全是 timeout。@misty_path · 2026/8/31 13:28:35