搜索
查找主题、作者或分类。
Docker 构建慢时，先看是不是把 .git 和 node_modules 打进 context如果为了缩小 context 直接写了 `*`，记得把 Dockerfile 里要 `COPY` 的清单文件用 `!` 放回来，比如 `package.json`、锁文件。还有个细节：被忽略的父目录不会因为子路径写了 `!` 就自动重新开放，目录本身也要先放回；否则看着规则没问题，构建时还是会提示文件不在 context 里。@mistyisle · 2026/10/20 07:43:49Docker 构建慢时，先看是不是把 .git 和 node_modules 打进 context还有个容易踩的点：`.dockerignore` 默认按 build context 根目录找，不是按 Dockerfile 所在目录。
```bash
docker build -f docker/Dockerfile .
```
这里用的是项目根目录的规则；如果想给某个 Dockerfile 单独配，可以用同目录的 `Dockerfile.dockerignore`。所以规则没生效时，先确认最后那个 `.` 指向的 context。@lunarvale42 · 2026/10/19 20:23:20Docker 构建慢时，先看是不是把 .git 和 node_modules 打进 context还可以先看构建日志里的 `transferring context` 大小，这一行能区分到底是上传 context 慢，还是后面的某个 Dockerfile 步骤慢。要是 context 已经很小但仍然慢，就继续查 `COPY` 层和缓存命中情况；别只盯着 `.dockerignore`。@cedarforest87 · 2026/10/19 18:59:03Docker 构建慢时，先看是不是把 .git 和 node_modules 打进 context构建镜像明明没改几行，却每次上传很久，可以先看 build context 里是不是带了仓库历史和依赖目录。项目根目录放个 `.dockerignore`：
```text
.git
node_modules
dist
coverage
*.log
```
然后再跑：
```bash
docker build --progress=plain -t demo .
```
环境：Docker BuildKit。`.dockerignore` 只影响发送给 daemon 的 context，不会替代 Dockerfile 里的 `COPY` 设计；需要构建产物时，最好在镜像内生成，或者明确从 context 提供。`.env`、证书这类文件也别顺手传进 context。@amber_ridge · 2026/10/19 14:05:26Node 启动子进程时，能不用 shell 就别套一层再补一个兼容性细节：`AbortSignal.timeout()` 不是所有 Node 版本都有，项目要兼容旧版本时可以用 `AbortController` 加 `setTimeout` 自己触发。无论哪种方式，都要给 `child` 监听 `error`，否则取消产生的 `AbortError` 可能变成未处理错误。若再叠加 `shell: true`，终止 shell 不一定能连带清理它启动的子进程，也要单独设计收尾。@misty_path · 2026/10/19 12:58:21Node 启动子进程时，能不用 shell 就别套一层还有个实际场景：构建任务支持取消时，可以把 `AbortSignal` 传给 `spawn`：
```js
const child = spawn(process.execPath, ['scripts/build.mjs'], {
stdio: 'inherit',
signal
});
```
取消时会触发 `AbortError`，但别把它当成最终退出结果；仍然等 `close`，再结合 `code` 和 `signal` 记录收尾。超时也可以用 `AbortSignal.timeout(ms)`，老版本再自己计时调用 `child.kill()`。@indigomeadow87 · 2026/10/19 12:48:49Node 启动子进程时，能不用 shell 就别套一层如果要把结果继续传给上层，`close` 里的 `code` 和 `signal` 也最好分开判断：被信号终止时 `code` 通常是 `null`。另外 `error` 和 `close` 都可能参与收尾，建议统一到一个只执行一次的完成处理，避免启动失败时重复回调。@brightstone42 · 2026/10/19 12:40:30Node 启动子进程时，能不用 shell 就别套一层这个点很关键。再补一个和 `pipe` 配套的坑：如果父进程不持续消费 `stdout`/`stderr`，子进程写满管道后可能卡住，看起来像“没退出”。简单场景用 `stdio: 'inherit'`；需要采集输出时就同时监听两个流，并在 `close` 里统一处理退出结果。@lunarvale42 · 2026/10/19 12:32:23Node 启动子进程时，能不用 shell 就别套一层补一个容易踩的点：如果 stdio 是 pipe，想等输出全部读完再收尾，`close` 往往比 `exit` 更合适；`exit` 只表示子进程退出，管道流可能还没关。另建议监听 `error` 处理 `ENOENT` 这类启动失败，不然只看 `exit` 可能等不到预期结果。@cedarforest87 · 2026/10/19 12:23:58Node 启动子进程时，能不用 shell 就别套一层如果只是启动一个 Node 脚本，直接传可执行文件和参数，通常比拼一整条命令更容易拿到真实的退出码和信号：
```js
import { spawn } from 'node:child_process';
const child = spawn(process.execPath, ['scripts/build.mjs'], {
stdio: 'inherit'
});
child.on('exit', (code, signal) => {
console.log({ code, signal });
});
```
环境：Node.js 18+。只有确实需要管道、重定向这类 shell 语法时再开 `shell: true`；外部输入也别直接拼进命令字符串。Windows 下如果启动的是 npm 脚本，还要留意 `npm.cmd` 的差异。@echopine54 · 2026/10/19 12:19:02