执行 docker exec 时出现 executable file not found in $PATH，通常表示Docker准备在容器内启动的新进程找不到指定可执行文件。这里检查的是容器文件系统和exec进程环境，不是宿主机是否安装了同名命令。
先判断程序根本没装、路径没进入PATH，还是把一整段Shell表达式当成了可执行文件。 这三类原因的修复方式完全不同。
先确认容器和错误原文
Docker官方说明，docker exec 只能在容器主进程仍在运行时启动新命令。先确认容器状态、使用的镜像和原始启动命令：
docker inspect -f '{{.State.Status}} {{.Config.Image}} {{json .Config.Cmd}}' app
docker ps -a --filter name=app容器处于paused状态时会得到专门的暂停错误；主进程已经退出时，也不能把exec当成修复入口。若容器在运行，保留完整报错中的命令名和路径，不要只记录最后一句。
0 查找的是app容器里的curl，宿主机上的 1 与它无关。 先把执行环境边界弄清楚，才能避免在错误的系统里安装软件。
检查镜像里是否真的有这个命令
若容器带有Shell，可在容器内查看PATH并查询命令：
docker exec app sh -c 'printf "%s\n" "$PATH"; command -v curl || true'
docker exec app sh -c 'ls -l /usr/bin/curl /usr/local/bin/curl 2>/dev/null || true'Alpine、distroless、scratch或经过多阶段构建的精简镜像，可能没有bash、curl、ps甚至sh。此时 docker exec app sh 自身也会失败，不能据此判断容器损坏。可以检查镜像Dockerfile、构建记录或使用与生产镜像对应的调试变体。
如果应用程序文件应由镜像构建产生，再检查容器文件系统与镜像声明：
docker inspect -f '{{json .Config.Env}}' app
docker inspect -f '{{json .Config.Entrypoint}} {{json .Config.Cmd}}' app
docker diff app不要把进入运行中容器后临时安装软件当成长期修复。 容器重建后改动会丢失，应回到Dockerfile增加依赖并重新构建。
命令链必须交给Shell解析
Docker官方文档明确要求exec后的命令本身必须是可执行文件。下面把整段带 && 的字符串作为一个文件名，因此不会工作：
docker exec app "echo ready && env"容器确实包含Shell时，应显式调用Shell：
docker exec app sh -c 'echo ready && env'重定向、管道、变量展开、通配符和 && 都是Shell语法，不由Docker CLI自行解释。若镜像没有Shell，应直接执行单个二进制文件及其参数，或使用专门的调试容器。
不要为了让命令链运行而假定所有镜像都有 0 ；很多生产镜像只有 1 ，有些连sh也没有。
核对PATH、用户和工作目录
程序存在但不在PATH时，先用绝对路径验证：
docker exec app /usr/local/bin/mytool --version
docker exec app envDocker exec进程默认继承容器创建时配置的环境，也可用 -e 为本次exec覆盖变量。若确需补充PATH，应只对诊断命令临时设置，并把长期配置写回镜像或编排文件：
docker exec -e PATH=/usr/local/bin:/usr/bin:/bin app mytool --version还要核对执行用户和工作目录。-u 可指定用户，-w 可指定目录，但它们不能让不存在的文件凭空出现：
docker exec -u 1000:1000 -w /app app ./mytool --version文件存在但没有执行权限时通常会报permission denied，而不是file not found。 不要用 --privileged 处理PATH或缺包问题，它扩大权限，却没有修复镜像内容。
把修复写回镜像和部署流程
确认依赖缺失后，在Dockerfile对应阶段安装或复制程序，并保证最终阶段包含它。多阶段构建尤其要检查文件是否只留在builder阶段，以及动态链接器和依赖库是否一并存在。
FROM alpine:3.22
RUN apk add --no-cache curl
WORKDIR /app
COPY mytool /usr/local/bin/mytool重新构建并以明确标签发布，然后重建容器。docker restart 只重启原容器，不会自动切换到新镜像。需要复制相同Docker版本做无损测试时，可在 萤光云 建立临时主机；跨地区拉取和验证镜像时，也可使用 LightNode 部署测试节点。
生产重建前应确认数据写入持久卷，并保留当前镜像摘要或标签作为回退依据。 不要删除旧容器和卷后才发现新镜像仍缺少依赖。
修复后的验收标准
先确认运行容器对应的镜像ID，再执行最小化版本或帮助命令：
docker inspect -f '{{.Image}} {{.Config.Image}}' app
docker exec app /usr/local/bin/mytool --version
printf 'exit=%s\n' "$?"随后用与真实运行用户、工作目录和环境变量一致的方式执行目标操作，并检查应用日志。若使用Shell命令链，还要分别验证Shell是否存在以及每个子命令的退出码。
验收通过应同时满足容器处于running、目标文件在最终镜像中、PATH或绝对路径正确、指定用户有执行权限，并且容器重建后问题不会复现。 只在当前容器里手工修好不算完成。
FAQ
为什么 0 失败，但应用仍正常？
应用镜像可能只包含自身二进制，根本没有bash。可尝试镜像实际提供的sh，或使用官方支持的调试方式。
宿主机安装curl后，容器里为什么还是找不到？
容器使用独立文件系统。应在镜像构建阶段安装curl，或使用外部诊断容器，不会自动继承宿主机软件。
可以在生产容器中临时安装命令吗？
仅适合经过授权的短时诊断，而且改动不可持续。正式修复应写入Dockerfile并通过构建、扫描和发布流程交付。
温馨提示
精简镜像没有常用工具往往是设计结果。先通过镜像元数据、绝对路径和调试容器取证，再决定是否增加依赖；不要为了方便exec而无边界地扩大生产镜像和容器权限。
