直接给gradlew加执行权限即可解决，根本原因是Linux/macOS文件权限模型要求脚本必须具备x位才能被execve()系统调用直接执行，而常见诱因包括Windows克隆项目、zip解压丢失权限或CI环境未初始化权限。
直接给 gradlew 加执行权限即可解决，根本原因不是 Gradle 配置或网络问题，而是 Linux 文件权限模型在起作用。
为什么 ./gradlew 会 Permission denied
Linux/macOS 下执行 ./gradlew 时，shell 调用的是内核的 execve() 系统调用，它严格检查两件事：gradlew 文件本身是否有 x（执行）位，以及从根目录到该文件路径上每个中间目录是否都有 x 权限（即“可穿越”）。缺一不可。
- 即使脚本内容完全合法、
gradlew.jar存在、gradle-wrapper.properties配置正确，只要gradlew没有x位，就必然报错 - 常见诱因：从 Windows 克隆项目（Git 默认不保留 Unix 权限）、解压 zip 包、CI 构建机拉取代码后未初始化权限
- 注意：
bash gradlew可能成功——因为那是 bash 自己读文件并解释执行，只依赖r权限，但这绕过了 Wrapper 的设计意图，不能保证 Gradle 版本一致性
怎么快速验证和修复 gradlew 权限
先确认当前状态：
ls -l gradlew
如果输出中没有 x（比如显示 -rw-r--r--），说明权限缺失。修复只需一行：
chmod u+x gradlew
- 用
u+x（仅所有者加执行权）比+x更安全，避免意外开放给组或其他人 - 不需要
sudo，除非你不是文件所有者；若ls -l显示所有者不是你，先运行sudo chown $USER:$USER gradlew - 验证修复：再次
ls -l gradlew，应看到类似-rwxr--r--；然后试跑./gradlew --version，能输出版本即成功
容易被忽略的深层陷阱
权限问题常藏在更隐蔽的地方：
-
gradlew所在目录（通常是项目根目录）若缺少x权限，cd不进去，./gradlew也照样失败——用ls -ld .检查末位是否有x - 在 WSL 或 Docker 挂载的 Windows 盘（如
/mnt/c/...）下，文件系统可能被挂载为noexec，此时chmod +x无效；必须把项目移到 Linux 原生分区（如~/project）再操作 - 脚本第一行是
#!/usr/bin/env bash，如果换行符是 Windows 风格（CRLF），内核会尝试执行bash^M，报错bad interpreter: No such file or directory，看起来像权限问题，实则是编码污染；用dos2unix gradlew或sed -i 's/\r$//' gradlew修复
真正卡住人的往往不是 Gradle 版本或镜像配置，而是这一行 chmod u+x gradlew 没被执行，或者执行了但没意识到目录权限或文件系统限制也在拦路。
