Docker WORKDIR作用于本地还是容器？上下文解析及RUN cd替代方案

嘿，这个问题抓得很准，很多刚接触Docker的同学都会在这里踩坑，我给你拆解清楚：

1. WORKDIR的作用范围与上下文 #

WORKDIR完全是作用于容器内部的，它的上下文是最终生成的镜像/容器环境，和你的本地机器、docker build的构建上下文半毛钱关系都没有：

• 它的本质是在构建镜像的过程中，为后续的RUN、CMD、ENTRYPOINT、COPY、ADD等指令设置默认的工作目录，就像你在容器里手动执行cd 目录一样，但这个设置是持久的，后续所有指令都会默认在这个目录下执行。
• 构建上下文是你执行docker build时指定的本地文件集合（比如当前目录.），Docker会把这些文件打包传给构建进程，但WORKDIR和这个打包的文件集合没有直接关联，只是后续如果用COPY/ADD复制文件，会默认放到WORKDIR指定的目录里。

2. 为什么RUN cd && ...的写法不太靠谱？ #

你提到的RUN cd && ...其实有个隐藏的坑：每个RUN指令都是在一个独立的shell进程中执行的。也就是说，你在这个RUN里cd切换了目录，只会影响当前这个进程里的命令，下一个RUN指令又会回到镜像默认的工作目录（比如/），根本达不到持久切换目录的效果。

3. 更合适的替代方案 #

方案一：用WORKDIR全局设置工作目录 #

这是最推荐的写法，清晰又持久。比如你想后续所有指令都在/app目录下执行：

# 切换到/app目录，后续所有指令默认在此执行
WORKDIR /app

# 直接执行npm install，默认在/app下
RUN npm install

# 把构建上下文里的文件复制到/app目录
COPY . .

方案二：单条指令临时切换目录 #

如果只是某一条命令需要在特定目录执行，不想改变全局工作目录，可以用&&把cd和后续命令连起来，确保在同一个shell进程里执行：

# 临时切换到/tmp目录创建文件夹，执行完后不影响全局工作目录
RUN cd /tmp && mkdir -p test && touch test/file.txt

这样写既清晰又能避免进程隔离带来的坑，比单独用RUN cd靠谱多啦～

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