问题根源 #

你遇到的错误核心是不同Linux发行版中mv命令的行为差异，再加上当前Dockerfile的逻辑冲突——我来拆解清楚：

• 你之前用的node:8.8镜像基于Debian/Ubuntu，自带的是GNU mv工具：当移动一个目录到已存在的同名目录时，它会默认把源目录的内容合并到目标目录，不会报错。
• 现在用的node:9-alpine镜像基于Alpine Linux，用的是BusyBox版mv：它遵循POSIX标准，默认不允许将非空目录移动到已存在的同名目录下，直接抛出Directory not empty错误。

回到你的Dockerfile逻辑：

1. 你在/tmp/node下执行yarn install生成了非空的node_modules目录
2. 执行ADD . /app/后，/app目录已经包含了你的项目文件（哪怕你的本地项目目录里只有空的node_modules文件夹，都会触发冲突）
3. 当你运行mv /tmp/node/* ./时，通配符会匹配/tmp/node/node_modules，尝试移动到/app/node_modules，此时BusyBox mv检测到目标目录已存在，直接报错。

修复方案 #

方案1：先删除冲突目录再移动（适配当前结构）

直接在mv前移除/app里的node_modules，彻底避免冲突：

RUN rm -rf /app/node_modules && mv /tmp/node/* ./

这个方法简单直接，不需要调整现有Dockerfile的整体结构。

方案2：优化Dockerfile结构（更推荐）

其实你没必要在/tmp/node里单独处理依赖，标准的Node.js Dockerfile写法可以直接利用Docker缓存，同时完全避免目录移动的问题：

FROM node:9-alpine
WORKDIR /app

# 先复制依赖文件，这一步会被缓存，只要package.json/yarn.lock不变就不会重新安装
COPY package.json yarn.lock ./
RUN yarn install --frozen-lockfile --ignore-platform --ignore-engines --quiet

# 再复制整个项目文件，只有代码修改时这一步才会重新执行
COPY . ./

EXPOSE 1337
CMD ["yarn", "start"]

这种写法既保留了依赖缓存的优势，又简化了镜像构建逻辑，是更简洁可靠的方式。

方案3：使用BusyBox mv的强制覆盖参数

BusyBox的mv支持-f参数强制覆盖，但要注意：它会直接替换目标目录（而非合并），如果你的/app/node_modules里有需要保留的内容，这个方法不适用：

RUN mv -f /tmp/node/* ./

补充说明 #

你第一个Dockerfile能正常运行，就是因为node:8.8基于Debian，GNU mv默认允许合并同名目录，所以即使/usr/src/app里有node_modules，也会自动合并内容而不报错。而Alpine的轻量特性决定了它使用更严格的POSIX工具，才出现了行为差异。

内容的提问来源于stack exchange，提问作者k0pernikus