修改本地项目中的 Logo 文件后，网页仍显示旧图标，是因为 Docker 容器未重新构建镜像——必须显式执行 docker-compose up --build 强制重建，才能将新文件注入容器。
修改本地项目中的 logo 文件后，网页仍显示旧图标，是因为 docker 容器未重新构建镜像——必须显式执行 `docker-compose up --build` 强制重建，才能将新文件注入容器。
当你使用 docker-compose up 启动服务时，Docker 默认会复用已构建好的镜像（除非镜像不存在）。这意味着：即使你已替换项目目录下的 logo 图片（如 logo.png），只要镜像未重建，容器内运行的仍是旧镜像中打包的原始文件——因此浏览器始终加载旧 logo。
✅ 正确操作流程如下：
确保文件路径和命名完全一致
替换 logo 时，务必保持文件名、扩展名及相对路径与原文件完全相同（例如：./public/images/logo.png → 新图片也须保存为同名同路径）。-
强制重建并重启服务
在项目根目录下执行：docker-compose up --build -d
- --build：强制重新构建所有服务镜像（触发 Dockerfile 中的 COPY 或 ADD 指令，将最新源文件打包进镜像）；
- -d（可选）：后台运行，提升效率。
验证是否生效
重启后，建议清除浏览器缓存（或使用无痕模式访问 http://localhost:8080），避免因 HTTP 缓存导致误判。
⚠️ 注意事项：
- 若项目使用多阶段构建或静态资源由构建工具（如 Webpack、Vite）处理，请确认 logo 是否被构建产物覆盖——此时需先运行 npm run build 等命令生成新静态资源，再执行 docker-compose up --build；
- 检查 docker-compose.yml 中是否配置了 volumes 挂载本地目录（如 - ./public:/app/public）。若存在此类挂载，理论上无需重建镜像即可实时生效——但需确认挂载路径与应用实际读取路径一致，且容器内 Web 服务未启用 aggressive 缓存策略；
- 执行 docker-compose down 再 up --build 可彻底清理旧容器与中间镜像，避免残留干扰。
总结：Docker 的核心原则是「镜像不可变」——任何源码或静态资源变更，都必须通过重建镜像来同步。养成 docker-compose up --build 的习惯，是保障本地开发与容器环境一致性的关键实践。
