gradlew脚本跨平台但需区分使用方式：linux/macos用./gradlew，windows用gradlew.bat；两者均调用同一gradle-wrapper.jar，但启动逻辑、路径处理和环境变量解析不同，配置文件gradle-wrapper.properties本身跨平台。
不能直接共用，但项目级 Wrapper 配置本身是跨平台的——关键在于脚本和路径处理方式不同，不是“能不能用”，而是“怎么用才不报错”。
gradlew 和 gradlew.bat 是两个独立脚本，各自只在对应系统生效
Linux/macOS 下执行 ./gradlew，Windows 下必须用 gradlew.bat（或 gradlew 命令在 PowerShell/CMD 中会被自动识别为批处理）。两者底层都调用 gradle-wrapper.jar，但启动方式、环境变量解析、路径分隔符处理逻辑完全不同。
-
gradlew（Shell 脚本）依赖/bin/sh，硬编码使用/作路径分隔符，Windows 的 CMD 无法原生执行 -
gradlew.bat使用 Windows 批处理语法，比如%~dp0获取当前目录，set设置变量，Linux 的 bash 会直接报语法错误 - Git 仓库中通常同时保留这两个文件，IDE（如 Android Studio）会根据当前 OS 自动选对脚本，但命令行手动运行时必须区分
gradle-wrapper.properties 中的 distributionUrl 是跨平台的，但路径相关配置容易踩坑
distributionUrl 指向的是远程 ZIP 包地址，协议、域名、路径写法在 Windows/Linux 下完全一致，这部分可放心共用。真正出问题的是本地缓存路径和项目内硬编码路径。
-
distributionBase默认是GRADLE_USER_HOME（即~/.gradle或C:UsersXXX.gradle），这个值本身跨平台，但如果你手动改成PROJECT_DIR并写死./gradle/dists，在 Windows 上可能因路径斜杠被误解析为转义字符而失败 - 如果在
build.gradle里用file("keys/my.jks")这类相对路径，Linux 用/、Windows 用都能被 Groovy 正确处理；但若写成"keys\my.jks"，在 Linux 下会变成keysmy.jks（反斜杠不转义），导致找不到文件 - 签名配置、NDK 路径、keystore 文件引用等，凡涉及
storeFile、ndk.dir等字段，必须用正斜杠/或File.separator，不能硬写\
CI/CD 流水线中要显式指定执行脚本，不能靠“自动发现”
GitHub Actions、GitLab CI、Jenkins 等环境默认不识别 gradlew 的可执行位（尤其在 Windows runner 上），也不会自动 fallback 到 gradlew.bat。你得明确告诉它用哪个。
- Linux runner：用
chmod +x ./gradlew && ./gradlew build - Windows runner：必须用
./gradlew.bat build，否则报Command not found或Invalid or corrupt jarfile - GitHub Actions 中
runs-on: ubuntu-latest和runs-on: windows-latest是完全隔离的执行环境，缓存的~/.gradle/wrapper不共享，每次都会按gradle-wrapper.properties重新下载对应版本
最常被忽略的一点：团队成员从 Windows 拉下代码后，在 Git Bash 里直接敲 gradlew build 看似能跑，其实走的是 gradlew.bat 的模拟层，一旦涉及 JVM 参数（如 -Dfile.encoding=UTF-8）或自定义环境变量，行为就可能和原生 CMD 或 Linux shell 不一致——这种隐性差异比构建失败更难排查。
