优先用 COPY 部署静态资源，因其行为明确、无自动解压、缓存稳定；仅当需构建时自动解压本地 tar 包才用 ADD，并确保路径干净、上下文精简、多阶段构建优化。
用 ADD 指令部署静态网站资源确实快，但要注意它隐含的行为和潜在风险——比如自动解压、路径处理不透明、缓存干扰等。真正“快速又可靠”的关键，是用对指令、控制好上下文、避免副作用。
ADD vs COPY：优先选 COPY 部署静态资源
ADD 功能多，但多数静态网站部署只需复制文件。COPY 行为明确、无自动解压、更易预测，Docker 官方也推荐在非归档场景下优先使用它。
- 如果只是把
dist/或public/目录放进镜像，写COPY ./dist /usr/share/nginx/html/更安全 -
ADD遇到本地 tar 文件（如site.tar.gz）会自动解压，容易误触发；而你通常并不需要这个行为 -
COPY的构建缓存更稳定——只要源文件没变，后续构建直接复用层
真要用 ADD？只在明确需要自动解压时才用
极少数情况适合 ADD：比如 CI 流水线产出的是压缩包，且希望构建时原地解压，省去 RUN tar -xzf 步骤。
- 示例：
ADD site-build.tar.gz /usr/share/nginx/html/→ 自动解压到目标目录 - 注意：源路径必须是构建上下文内的本地文件，不能是远程 URL（Docker 23.0+ 已弃用
ADD下载远程文件的能力） - 确保压缩包内路径结构干净，避免解压出多余嵌套层级（例如不要解出
site-build/xxx.html，而应是xxx.html）
静态资源部署的实用建议
别只盯着 ADD/COPY，整体流程顺了才真的“快”：
- 构建前清理无关文件：在
.dockerignore中排除node_modules/、.git/、src/等，减小上下文体积，加速构建 - 用多阶段构建分离构建与运行环境：前端项目可在 builder 阶段装依赖、执行
npm run build，再COPY --from=builder复制产物，镜像更小更干净 - 验证资源是否正确落位：构建后运行容器，执行
docker run --rm -it your-image ls -la /usr/share/nginx/html快速检查
不复杂但容易忽略：ADD 的便利性常让人跳过路径校验和缓存逻辑，结果改了一张图片却重跑整个构建。用对指令，配合好上下文管理，静态网站部署才能既快又稳。
