结论：GCC报permission denied主因是二进制文件权限异常、路径含空格/特殊字符或系统策略拦截，而非PATH配置错误；需先验证gcc能否独立执行，再检查路径、权限及安全软件拦截。
直接说结论：GCC环境变量配置后报 permission denied，基本不是环境变量本身的问题，而是 GCC 可执行文件（如 gcc.exe 或 g++.exe）所在目录权限异常、路径含空格/特殊字符、或被系统策略拦截——尤其在 Windows（MSYS2/MinGW）或 WSL 中高频出现。
检查 GCC 二进制文件是否真能执行
环境变量配对了，不代表文件可运行。常见陷阱是安装路径含空格（如 C:\Program Files\...），导致 shell 解析失败，报错却显示为 permission denied（而非更明确的 “command not found”）。
- 运行
where gcc（Windows）或which gcc（Linux/macOS/WSL），确认返回路径是否含空格或中文 - 手动进入该路径，尝试双击或命令行直接执行
gcc --version—— 如果失败，说明文件本身不可执行或被拦截 - 若路径含空格，立即重装到无空格短路径（如
C:\mingw64），并更新PATH - 在 MSYS2/UCRT64 环境中，确保你是在对应终端（如 UCRT64 Shell）里调用
gcc，而不是普通 CMD 或 PowerShell —— 否则 DLL 依赖可能缺失，触发权限类假错
Windows 下文件被系统阻止执行
尤其当 GCC 来自第三方下载（非官方 installer），Windows SmartScreen 或杀毒软件可能静默标记其为“不安全”，即使你双击也打不开，命令行调用就报 permission denied。
- 右键
gcc.exe→ 属性 → 检查底部是否有“此文件来自其他计算机”的提示，勾选“解除锁定” - 临时关闭实时防护（如 Windows Defender），再试一次
gcc --version - 用管理员权限打开终端再执行 —— 不是为提权编译，而是绕过某些策略拦截（仅用于验证）
- 若使用 WSL，注意不要在 Windows 文件系统（
/mnt/c/...）里直接调用 Windows 版 GCC；应调用 WSL 自带的gcc，或把源码放~/下
Linux/WSL 中 PATH 指向了错误权限的 GCC
比如你把 GCC 软链接或复制到了 /usr/local/bin/gcc，但没给执行权限，或所有者是 root 而当前用户无权读取该文件。
- 运行
ls -l $(which gcc)，确认输出中有x（如-rwxr-xr-x），且用户有读+执行权限 - 若权限不对，用
sudo chmod +x $(which gcc)补执行位 - 若文件属主是 root 且组不可读，而你不在该组内，用
sudo chown $USER:$(id -gn) $(which gcc)改归属（谨慎操作） - 避免把 GCC 安装到
/root/或/opt/toolchains/这类默认只对 root 可读的路径下
真正卡住的地方往往不是 PATH 写错了，而是 GCC 本体被系统“软性拒绝”——它看起来存在、路径正确、甚至 which 能查到，但操作系统底层策略不让它加载。先验证二进制能否独立运行，再排查路径和权限，比反复改环境变量高效得多。
