Dockerfile构建时mv命令失败 容器内手动执行同命令正常

该报错本质是Dockerfile构建阶段RUN指令的执行上下文，和手动进入容器后的shell执行上下文不一致，最常见的触发场景有两种：

• 路径切换逻辑未跨RUN指令生效
  Dockerfile中每一条RUN指令都会启动独立的shell子进程执行，执行完成后就会销毁子进程，不会保留cd切换的工作目录状态。如果你把路径切换和mv操作拆成了两条RUN（比如单独写RUN cd /opt/app，下一条RUN再写mv命令），执行mv时实际工作目录还是镜像默认的根目录/，你用相对路径写的目标目录在根目录下根本不存在，mv会默认把源文件重命名为你写的目标路径字符串对应的文件，后续操作就会触发"目标不是目录"报错。而手动进入容器时，你是在同一个持续的shell会话里先切换路径再执行mv，路径上下文一致，所以操作可以正常完成。
• shell加载配置差异导致mv行为不一致
  手动进入容器启动的是交互式登录shell，会自动加载/etc/bash.bashrc、~/.bashrc中的别名、环境变量配置，不少定制化基础镜像会给mv、cp这类命令预设别名（比如自动加-t指定目标目录参数）；但Dockerfile的RUN指令启动的是非交互式非登录shell，不会加载上述rc文件中的配置，执行的是原生的/bin/mv命令，参数解析逻辑和你手动执行的带别名的mv完全不同，就会出现命令参数完全一致但执行结果不同的情况。

• 不要拆分cd和后续文件操作到不同RUN指令，同一条RUN内串联路径切换和操作：

RUN cd /your/expected/workdir && \
    mv ./source_resource ./target_directory/

• 优先用WORKDIR指令显式指定工作目录，比RUN cd更稳定可靠：

WORKDIR /your/expected/workdir
RUN mv ./source_resource ./target_directory/

• 写mv命令时在目标路径末尾显式加尾斜杠，强制mv识别目标为目录，彻底消除路径歧义：

# 末尾加/后，mv会直接判定目标是目录，不会出现把目标当文件名重命名的问题
RUN mv /path/to/source_resource /path/to/target_directory/

• 如果是别名导致的行为差异，直接调用mv命令的全路径，绕过别名配置：

RUN /bin/mv /path/to/source_resource /path/to/target_directory/

快速定位方法：在Dockerfile中mv指令的前一行加RUN pwd && ls -l <你mv命令里写的目标路径>，构建时打印出执行mv瞬间的工作目录、目标路径实际状态，和你手动进容器看到的状态对比，就能直接确认上下文差异点。

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