根本原因是构建上下文与宿主机路径映射不一致，需确认当前目录含目标文件、检查.dockerignore、禁用缓存重试。
在 Docker Desktop（macOS/Windows）上构建时 COPY 报 “no such file or directory”，根本原因不是 Docker Desktop 本身有问题，而是构建上下文（build context）与宿主机路径映射不一致导致的——尤其在 Windows WSL2 后端或 macOS 虚拟机文件系统桥接场景下，路径解析极易出错。
确认 build context 是否包含目标文件
Docker Desktop 的构建过程完全依赖你执行 docker build 时指定的上下文目录（即命令末尾的 . 或具体路径），它不会自动穿透父目录或读取 IDE 工作区根目录外的文件。
- 运行
ls -la（macOS/Linux）或dir（Windows CMD）检查当前终端所在目录是否真有你要COPY的文件，比如COPY nginx.conf /etc/nginx/conf.d/前，先确认当前目录下存在nginx.conf - 若文件在子目录（如
./config/nginx.conf），COPY指令必须写成COPY config/nginx.conf /etc/nginx/conf.d/，不能只写nginx.conf - Windows 用户特别注意：Docker Desktop 默认仅共享
C:\Users（或设置中指定的其他驱动器），若 Dockerfile 在D:\project下且未在 Docker Desktop 设置中启用 D: 盘共享，docker build -f D:\project\Dockerfile .会静默失败——此时应切换到C:\Users\you\project下操作，或补全共享设置
Windows 路径大小写与反斜杠陷阱
Windows 文件系统默认不区分大小写，但 Linux 容器内严格区分；同时 COPY 指令只接受正斜杠 /，反斜杠 \ 会被当作普通字符处理，导致路径错位。
- 错误写法：
COPY .\src\main.js /app/→ 构建时实际尝试找名为.\src\main.js的文件（带点和反斜杠的字面量） - 正确写法：
COPY src/main.js /app/（全部小写、用正斜杠、路径相对于上下文） - 若源文件名含大写字母（如
Src/），而你在指令里写成src/，在 Windows 上可能“碰巧”成功，但在 Linux 构建节点或 CI 环境必然失败——务必统一为真实大小写
Docker Desktop 的 .dockerignore 干扰
.dockerignore 文件作用于构建上下文压缩阶段，在文件打包传入构建引擎前就过滤掉匹配项。一旦被忽略，COPY 就永远找不到它，且不会报错提示“被 ignore”——这是最隐蔽的坑。
- 检查项目根目录是否存在
.dockerignore，并确认其中没有误写**/*.conf、config/或!.env这类通配规则（!开头的例外规则在 Docker Desktop 中支持不稳定，建议避免） - 临时重命名
.dockerignore为.dockerignore.bak，再运行docker build --no-cache .，看问题是否消失 - 常见误伤项：
node_modules/通常合理，但若你COPY package.json && RUN npm install后又想COPY node_modules/，就会因.dockerignore里这行而失败
验证 COPY 是否真生效的快速方法
不要只信构建日志里的 “COPYing x files”，得进镜像看实际内容——因为缓存可能让旧层残留，掩盖新 COPY 的失败。
- 构建时加
--no-cache --progress=plain，观察最后一行是否出现类似failed to compute cache key: "src/main.js" not found的明确提示 - 构建成功后立即运行：
docker run --rm -it，确认目标路径下是否有对应文件ls -la /app/ - 若仍不确定上下文是否传对，可在 Dockerfile 开头加一行：
RUN find / -name "main.js" 2>/dev/null || echo "main.js not found anywhere"，强制暴露查找结果
真正卡住人的从来不是 COPY 语法本身，而是你认为“这个文件就在那里”的假设，和 Docker Desktop 实际拿到的构建上下文之间的偏差。每次遇到“找不到”，先 ls 当前目录、查 .dockerignore、关缓存重试——三步下来，90% 的问题当场定位。
