脚本在Linux容器中无法执行的根本原因是缺少执行权限（x位），需在Dockerfile中用RUN chmod +x显式赋权，并确保换行符为LF、shebang正确、ENTRYPOINT/CMD写法合规，且依赖命令已安装。
脚本文件权限不对，容器里根本没法执行
Linux 容器里运行 Shell 脚本前，chmod +x 是硬性前提。Windows 下编辑的脚本默认没可执行位，哪怕 ls -l 看着路径对、内容也正常，./init.sh 仍会报 Permission denied 或直接提示 No such file or directory（后者常因 shebang 行换行符不兼容导致）。
实操建议：
- 构建镜像时用
RUN chmod +x /usr/local/bin/init.sh显式赋权，别依赖 COPY 自动继承 - 若脚本在 Windows 上编写，保存为 Unix 换行符（LF），避免 CRLF 导致
#!/bin/sh^M解析失败 - 进容器后手动验证：
ls -l /usr/local/bin/init.sh确认有x位；file /usr/local/bin/init.sh看是否显示with CRLF line terminators
ENTRYPOINT/CMD 写法错误，脚本压根没被调用
Docker 启动时不会自动扫描并执行目录下所有 .sh 文件。必须通过 ENTRYPOINT 或 CMD 明确指定，且写法决定是否走 shell 解析层——这直接影响环境变量展开、管道、重定向等行为。
常见错误现象：
-
CMD ["/usr/local/bin/init.sh"]：exec 模式，不经过 shell，$PATH不生效，echo $HOME不展开 -
CMD /usr/local/bin/init.sh（无方括号）：shell 模式，能展开变量，但无法接收docker run后的参数 -
ENTRYPOINT ["sh", "-c", "/usr/local/bin/init.sh"]：混合写法，容易漏掉$@导致传参丢失
推荐写法（兼顾可维护与信号传递）：
ENTRYPOINT ["/usr/local/bin/init.sh"] CMD ["app"]
这样 init.sh 总是执行，app 作为默认参数传入，脚本末尾用 exec "$@" 启动主进程。
脚本依赖的命令或环境在基础镜像里不存在
很多脚本默认假设系统有 curl、jq、netstat 或特定版本的 bash，但 Alpine 镜像默认只有 ash，Debian slim 版也精简掉了大量工具。结果脚本一运行就卡在 command not found，连错误日志都打不出来。
使用场景判断：
- Alpine 基础镜像 → 改用
apk add --no-cache curl jq安装依赖，别用apt-get - 脚本含
[[ ]]或source→ 确保用#!/bin/bash开头，并在镜像中安装bash - 需要等待数据库 → 别直接用
nc -z，Alpine 里得装busybox-extras或改用timeout 5 sh -c 'until nc -z db 5432; do sleep 1; done'
Windows 主机挂载脚本，路径/换行/权限全乱套
在 Windows 上用 -v C:\scripts\init.sh:/init.sh 挂载脚本，问题成堆：反斜杠路径解析失败、CRLF 换行符、NTFS 权限不映射到 WSL2 文件系统，最终表现是容器内 /init.sh 看似存在，但 bash: /init.sh: No such file or directory。
根本原因不是脚本写错了，而是挂载机制把 Windows 文件“原样”塞进 Linux 环境，而两者对文件元数据的理解完全不同。
可靠做法：
- 放弃 Windows 直接挂载脚本，改用
COPY构建进镜像（适合稳定脚本） - 若需热更新，把脚本放在 WSL2 发行版的 Linux 路径下（如
/home/user/scripts/），再用-v /home/user/scripts:/scripts挂载 - 临时调试时，在容器内用
printf '%s\n' '#!/bin/sh' 'echo hello' | tee /tmp/test.sh && chmod +x /tmp/test.sh && /tmp/test.sh快速验证执行链路
最易被忽略的一点：WSL2 的 ext4.vhdx 文件系统本身可能损坏，导致挂载后文件内容错乱或不可读——此时 wsl --shutdown 再重启 WSL 往往比修脚本更有效。
