文档教程后端【免费下载链接】nodebestpractices✅ The Node.js best practices list (July 2026)项目地址https://gitcode.com/GitHub_Trending/no/nodebestpractices点击查看免费下载导读在 CI/CD 流水线中Node.js 应用的 Docker 镜像构建往往是耗时最长的环节之一。本指南基于 nodebestpractices 项目 Docker 最佳实践清单第 8.8 条Plan for efficient cachingREADME 目录系统讲解 Docker 分层缓存的工作原理、Dockerfile 指令排序的核心规则以及两类可直接落地的多阶段构建示例。读完本文你将掌握如何通过调整指令顺序让构建几乎瞬间完成并理解.dockerignore、npm ci、多阶段构建等配套实践为何能共同保护缓存链路。为什么 Docker 构建会慢分层机制与缓存命中Docker 镜像是若干**层layer**的组合Dockerfile 中的每一条指令都会创建一个新的层。构建时Docker daemon 会尝试复用之前构建产生的层——只要指令本身相同或在COPY/ADD场景下被复制的文件内容一致对应层就可以直接命中缓存而无需重新执行。这张经典的层示意图源自本项目 assets/images/docker_layers_schema.png直观展示了镜像如何由下至上堆叠成层理解缓存机制的关键在于失效的传染性⚠️ 如果某个层无法命中缓存它之后的所有层都会被一并作废。也就是说一旦缓存断链从失效点往下的每一层都要重新执行——包括最昂贵的npm install和应用代码构建。因此 Dockerfile 的指令顺序直接决定了缓存的可用率变化频率低、长期稳定的指令放在顶部如基础镜像、系统依赖安装、依赖清单复制频繁变化的指令放在底部如应用源码的COPY . .耗时长的操作尽量靠近顶部让它在依赖不变时始终命中缓存只有在真正必要时才重新执行。只要布局得当从缓存完整重建一个镜像几乎可以瞬间完成nearly instantaneous是原文档与 README 8.8 的原始表述前提是缓存确实命中。规则一避免使用频繁变化的 LABELLABEL指令也参与缓存计算。如果你在 Dockerfile 顶部放置一个携带构建号之类的标签而该标签每次构建都变化那么从这一层开始整条缓存链都会失效——即使应用代码根本没改。#Beginning of the file FROM node:10.22.0-alpine3.11 as builder # Dont do that here! LABEL build_number483 #... Rest of the Dockerfile正确做法是把这类易变元数据放到 Dockerfile 尾部或者根本不写入镜像标签而是通过 CI 平台的外部元数据如 registry 的 tag、annotations来记录构建号。规则二维护一份合格的 .dockerignore构建上下文中的文件会被打包并通过虚拟网络传给 daemon如果上下文中混入测试报告、日志、临时文件它们一旦在COPY层发生内容变化就会击穿缓存。更重要的是.dockerignore还是防止.npmrc、.aws、.env等敏感文件进入镜像的最后一道安全网——这一点在配套文档 Use .dockerignore to prevent leaking secrets 中有专门论述。本项目给出的 Node.js 默认.dockerignore模板可以直接作为起点**/node_modules/ **/.git **/README.md **/LICENSE **/.vscode **/npm-debug.log **/coverage **/.env **/.editorconfig **/.aws **/dist排除掉生产环境用不到的开发目录后构建器能更充分地利用缓存同时显著缩小上传的上下文体积。规则三优先安装系统级依赖Node.js 应用中常见的bcrypt、sharp、canvas等原生模块在alpine等精简基础镜像上需要编译工具链make、gcc、g。这些工具很少变化但安装耗时很长——如果它们的位置在COPY . .之后那么任何一次源码改动都会连带触发整条工具链重装。推荐做法提前固化一个包含全部系统包的基础镜像如果确实需要在应用 Dockerfile 中用apk/apt/yum安装应把它作为前几条指令之一并且只为真正需要的东西安装不要为图方便装额外包——这是生产镜像不是开发环境。FROM node:10.22.0-alpine3.11 as builder RUN apk add --no-cache \ build-base \ gcc \ g \ make规则四先只复制 package.json 与 lockfile再执行依赖安装package.json与package-lock.json或yarn.lock的变化频率远低于应用源码。把依赖安装放在源码复制之前是保护缓存的关键一步COPY package.json package-lock.json ./ RUN npm ci只要锁文件内容不变npm ci这一层就能稳定命中缓存node_modules无需重新下载与编译。这里必须强调使用npm ci而非npm installnpm ci严格以 lockfile 为唯一事实来源更快、更严格能消除开发机与 CI 之间的依赖不一致。这在配套文档 Use multi-stage builds 中同样被列为 CI 环境的推荐命令对应 Yarn 场景则使用yarn install --frozen-lockfile。规则五最后复制应用代码并执行构建依赖层之后才是变化最频繁的源码层COPY . . RUN npm run build此时只有真正的代码改动才会触发npm run build重新执行依赖安装层依然完好地在缓存中。如果项目使用 TypeScript如本仓库示例应用的package.json中build: tsc --outDir dist ...见 sections/examples/dockerfile/package.json这一步产出dist目录供运行时阶段使用。实战示例一node_modules 依赖系统编译工具的场景适用于bcrypt等需要原生编译、且运行阶段仍需要完整node_modules的应用#Create node image version alias FROM node:10.22.0-alpine3.11 as builder RUN apk add --no-cache \ build-base \ gcc \ g \ make USER node WORKDIR /app COPY package.json package-lock.json ./ RUN npm ci --production COPY . ./ FROM node as app USER node WORKDIR /app COPY --frombuilder /app/ ./ RUN npm prune --production CMD [node, dist/server.js]注意几点构建阶段以非 root 用户node运行遵循安全实践依赖安装在COPY . .之前保护npm ci --production缓存运行时阶段通过npm prune --production移除开发依赖控制镜像体积CMD直接使用node而非npm start保证信号能直达应用进程详见 Bootstrap container using node command instead of npm。实战示例二带构建步骤如 TypeScript的场景当应用需要npm run build产出编译产物时只把最终需要的文件复制进运行时阶段镜像更小、缓存更高效#Create node image version alias FROM node:10.22.0-alpine3.11 as builder RUN apk add --no-cache \ build-base \ gcc \ g \ make USER node WORKDIR /app COPY package.json package-lock.json ./ RUN npm ci COPY . . RUN npm run build FROM node as app USER node WORKDIR /app # Only copying the files that we need COPY --frombuilder /app/node_modules node_modules COPY --frombuilder /app/package.json . COPY --frombuilder /app/dist dist RUN npm prune --production CMD [node, dist/server.js]构建阶段完整安装依赖并产出dist运行时阶段只接收node_modules、package.json与dist三样东西COPY层因为内容少、变化可控也更利于缓存复用。仓库源码佐证多阶段构建 缓存排序的完整范例本仓库自带的示例应用 sections/examples/dockerfile/Dockerfile 是上述规则的完整落地它在构建阶段顶部先apk add系统编译依赖然后只复制package.json与package-lock.json执行npm ci之后才复制src并npm run build运行时阶段则复制node_modules、dist并执行npm prune --production。文件中以注释形式明确标注了与清单中第 8.8 条缓存、8.5 条npm ci、8.10 条精简基础镜像的对应关系是直接可参考的权威模板。配套实践让缓存收益最大化缓存优化并非孤立的一条指令它与 Docker 章节的以下实践相辅相成多阶段构建Use multi-stage builds将构建期与运行期分离只在构建阶段引入 TypeScript CLI 等开发依赖运行时镜像体积大幅收缩清理 npm 缓存Clean NODE_MODULE cachenpm ci后执行npm cache clean --force可剥离镜像中数十 MB 的冗余缓存--force用于避免非零退出码中断 CI多阶段构建下若末阶段不再安装新包则无需处理精简基础镜像smaller_base_images与镜像扫描、标签规范等实践共同决定镜像的安全与可维护性。小结构建缓存优化的本质是把 Dockerfile 当作一份按变化频率排序的指令清单稳定者居上、易变者居下。配合.dockerignore过滤无关文件、npm ci锁定依赖、多阶段构建精简运行时Node.js 应用的镜像构建可以从每次全量重来收敛为只重跑最后几层在 CI 高频构建场景中收益尤其明显。要验证效果可在依赖与源码均未变化时重复执行docker build观察每一层是否输出CACHE标记。赞分享文档教程后端【免费下载链接】nodebestpractices✅ The Node.js best practices list (July 2026)项目地址https://gitcode.com/GitHub_Trending/no/nodebestpractices点击查看免费下载相关推荐使用 ik_llama.cpp 的 Jeopardy 基准测试评估模型事实知识使用 ik_llama.cpp 的 Jeopardy 基准测试评估模型事实知识 导读 本文介绍 ik_llama.cpp 仓库中自带的 Jeopardy 知识问文档教程后端OpenWhispr企业版实战SSO、SCIM与Bedrock/Azure集中管控完整指南OpenWhispr企业版实战SSO、SCIM与Bedrock/Azure集中管控完整指南 OpenWhispr 是一款隐私优先的跨平台语音转文字Voice桌面应用AI 应用大模型语音本地部署AI Agentstable-diffusion-webui-docker镜像构建时间优化并行构建与缓存利用stable diffusion webui docker镜像构建时间优化并行构建与缓存利用 引言构建效率的痛点与解决方案 你是否还在忍受Stable Di人工智能媒体生成本地部署容器编排上一篇SMUDebugTool终极指南突破AMD Ryzen平台调试边界下一篇Tart 许可变更深度解读从 AGPL-3.0 到 Fair Source 100 的决策、条款与后续演进创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考