出现 bad interpreter 错误，95% 是因脚本首行 shebang 指向的解释器在容器中不存在，或脚本含 Windows 换行符（\r\n），导致 Linux 将 /bin/sh\r 误作路径查找而报错。
直接说结论：出现 bad interpreter 错误，95% 是因为脚本第一行的 #!/bin/sh（或类似）指向的解释器在容器里根本不存在，或者脚本本身是 Windows 换行符（\r\n）导致 Linux 解释器读到 \r 当作路径一部分——最终报错类似 /bin/sh^M: bad interpreter。
为什么容器里执行脚本会报 /bin/sh^M: bad interpreter
这是最典型的换行符问题。你在 Windows 上用记事本、VS Code（未设 LF）、Git Bash 默认配置编辑过脚本，保存时用了 \r\n，而 Linux 容器只认 \n。解释器尝试执行 /bin/sh^M（^M 就是 \r），自然找不到这个“带回车的解释器路径”。
- 现象：脚本明明有
#!/bin/sh，但运行时报/bin/sh^M: bad interpreter或No such file or directory - 验证方式：进容器执行
cat -A your-script.sh，如果看到行尾有^M，就是它了 - 修复方法：在宿主机用
dos2unix your-script.sh，或 VS Code 切换右下角换行符为LF后重存 - 构建时预防：在
.dockerignore里加*.sh没用；真正有效的是 Git 配置git config --global core.autocrlf input（Linux/macOS 用户）或false（Windows 用户需手动控制）
ENTRYPOINT/CMD 脚本找不到 /bin/bash 怎么办
很多脚本写 #!/bin/bash，但基础镜像（如 alpine、scratch、甚至部分 slim Debian 镜像）压根没装 bash，只有 sh。Docker 启动时调用 exec 去找 /bin/bash，失败就报 bad interpreter 或更直白的 executable file not found in $PATH。
- 检查镜像是否含 bash：运行容器后执行
which bash或ls /bin/bash - 安全做法：脚本首行统一用
#!/bin/sh，避免依赖 bash 特性；必须用 bash 时，在Dockerfile显式安装：RUN apk add --no-cache bash（Alpine）或RUN apt-get update && apt-get install -y bash（Debian） - 注意 ENTRYPOINT 写法：如果写成
ENTRYPOINT ["./entrypoint.sh"]（exec 形式），它会绕过 shell 解析，直接调用解释器——这时#!/bin/sh必须存在且可执行；如果写成ENTRYPOINT ["sh", "./entrypoint.sh"]，就强制走sh，不依赖脚本首行
脚本权限被忽略导致 exec 失败
Docker 构建时如果不显式 chmod +x，即使本地有执行权，COPY 进镜像后也可能丢失 x 位。启动时 Docker 尝试 exec 一个不可执行文件，报错可能表现为 bad interpreter（尤其当系统试图用默认解释器去“猜”怎么跑它时）。
- 现象：脚本存在、换行符正确、解释器也存在，但运行仍失败，
docker logs空或只报permission denied - 验证：进容器执行
ls -l entrypoint.sh，确认有-rwxr-xr-x中的x - 修复：在
Dockerfile中COPY后立刻加RUN chmod +x /path/to/entrypoint.sh - 替代方案：用
ENTRYPOINT ["sh", "-c", "sh /path/to/entrypoint.sh"]绕过权限检查（不推荐用于生产，仅调试）
真正容易被忽略的是：错误信息里的 ^M 和 not found 看似无关，但根源往往都在构建前的编辑环境和镜像选型上。别急着改 Dockerfile，先确认脚本在宿主机上用 sh -n 能语法校验通过，再用 file your-script.sh 看编码和换行符类型——这两步比重打镜像快十倍。
