PowerShell中直接运行gradlew报错“无法加载文件”是因默认执行策略（Restricted）禁止本地脚本运行；推荐方案为Set-ExecutionPolicy RemoteSigned -Scope CurrentUser，并显式调用.\gradlew.bat或.\gradlew.ps1。
PowerShell里直接运行 gradlew 会报错“无法加载文件”
这是因为 PowerShell 默认禁止执行本地脚本（包括 gradlew.ps1），安全策略会拦截，报错类似：File C:xxxgradlew.ps1 cannot be loaded because running scripts is disabled on this system.
这不是 Gradle 的问题，是 PowerShell 的执行策略限制。解决方式不是关掉所有安全防护，而是精准绕过当前项目目录的限制。
- 推荐做法：在项目根目录下，用
Set-ExecutionPolicy RemoteSigned -Scope CurrentUser临时放宽策略——它只允许你本地写的、微软签名的或你信任的脚本运行，不影响系统全局安全 - 不建议用
Bypass或Unrestricted，风险高，且下次换台机器还得重配 - 执行完这条命令后，再运行
.gradlew.bat（Windows 批处理）比.gradlew.ps1更稳——因为.bat不受 PowerShell 策略限制，且 Gradle Wrapper 默认优先生成它
为什么有时候 .gradlew 没反应或提示“找不到命令”
PowerShell 默认不把当前目录（.）加入命令搜索路径，所以 gradlew（无后缀）不会自动匹配到 gradlew.bat 或 gradlew.ps1。
- 必须显式写上扩展名或路径前缀：
.gradlew.bat或.gradlew.ps1，不能只敲gradlew - 如果项目里只有
gradlew（Linux/macOS 脚本），在 PowerShell 里直接运行会失败——Windows 不识别 shebang，得靠bash ./gradlew（需 WSL）或改用.bat版本 - 检查是否真有
gradlew.bat：新初始化的 Gradle 项目在 Windows 上默认生成它；若缺失，可手动运行gradle wrapper --gradle-version X.Y.Z重新生成
.gradlew.bat 和 .gradlew.ps1 行为差异在哪
两者目标一致，但底层机制不同：前者是 CMD 兼容的批处理，后者是 PowerShell 原生脚本。实际使用中，.bat 更兼容老旧环境，.ps1 对 Unicode 路径和长参数支持稍好。
-
.bat在中文路径、含空格路径下基本没问题；.ps1若未正确转义参数（比如-Pkey="value with space"），容易被截断 -
.ps1启动略快（省去 cmd.exe 中转），但依赖 PowerShell 运行时；某些 CI 环境（如旧版 Azure Pipelines Agent）可能默认没启用 PS 执行策略 - 如果你用的是 Gradle 8.4+，
.ps1已支持-DJVM 参数透传，但.bat对-Dfile.encoding=UTF-8这类仍更稳定
CI/CD 流水线里跑 gradlew 最稳妥的写法
别依赖交互式 PowerShell 配置，流水线脚本要自包含、可复现。
- 统一用
.gradlew.bat，避免执行策略问题，也避开 PowerShell 版本差异（如 PS 5.1 vs 7+） - 加
cmd /c显式调用（cmd /c ".gradlew.bat build"），确保环境变量和工作目录准确继承 - 如果必须用
.ps1，前置加策略绕过语句：Set-ExecutionPolicy RemoteSigned -Scope CurrentUser -Force; .gradlew.ps1 build，但注意-Force会跳过确认提示 - 永远用
.开头——绝对不用gradlew单独写，否则在非交互式 shell 下大概率失败
PowerShell 里跑 Gradle Wrapper，关键不是“怎么让它动起来”，而是理解哪一层在拦你：是策略？是路径解析？还是脚本类型不匹配？多数故障点就卡在这三处，而不是 Gradle 本身。
