应检查并正确配置path环境变量，确保其中包含%java_home%\bin路径，因为javac.exe位于jdk的bin目录下，系统需通过path才能定位该命令。

javac 命令报“不是内部或外部命令”怎么办

说明：这不是 Java 没装好，而是 JAVA_HOME 或 PATH 配置漏了关键一环——javac 在 %JAVA_HOME%\bin 下，但该路径没加进系统 PATH。

实操建议：

Java Maven Common

Java Maven 项目审查工作流的通用输入处理。当 Java Maven 项目以 ZIP压缩包或 GitLab 仓库 URL 形式提供且需要...时使用。

下载

• 确认 JAVA_HOME 指向 JDK 根目录（如 C:\Program Files\Java\jdk-17.0.2），不是 JRE 目录
• PATH 中必须包含 %JAVA_HOME%\bin，不能只写 %JAVA_HOME%
• Windows 上修改后需重启终端（CMD/PowerShell）或运行 refreshenv（若装了 Chocolatey）
• Linux/macOS 修改 ~/.bashrc 或 ~/.zshrc 后，要执行 source ~/.zshrc

验证 javac 是否真可用，别只看 java -version

说明：java -version 成功只代表 JRE 运行时可用，javac 是独立工具，可能缺失或版本不匹配（比如误装了 JRE 而非 JDK）。

实操建议：

• 在终端直接运行 javac -version，预期输出类似 javac 17.0.2
• 进一步验证编译能力：新建 Hello.java，内容为 public class Hello { public static void main(String[] args) { System.out.println("OK"); } }，然后执行 javac Hello.java → 应生成 Hello.class，再运行 java Hello 输出 OK
• 若 javac -version 报错但 java -version 正常，基本可断定环境变量指向的是 JRE 而非 JDK

JDK 多版本共存时 javac 总调用错版本

说明：多个 JDK 安装后，PATH 顺序、JAVA_HOME 设置、IDE 内置 JDK 配置三者可能不一致，导致终端用的 javac 和 IDE 编译器不是同一个。

实操建议：

• 查当前生效的 javac 路径：Windows 执行 where javac，macOS/Linux 执行 which javac
• 对比输出路径是否与 %JAVA_HOME%\bin（或 $JAVA_HOME/bin）一致；不一致说明 PATH 里有更靠前的 JDK bin 目录
• IntelliJ/Eclipse 的 Project SDK 和 Project language level 不影响终端 javac，但会影响编译行为，务必保持三者（终端、IDE、构建工具如 Maven 的 toolchain）目标 JDK 版本对齐

Mac M1/M2 上 javac 提示 “已损坏” 或 “无法打开”

说明：Apple Gatekeeper 对未签名的 JDK 二进制文件（尤其是早期 Azul/Zulu ARM64 版本）会拦截，表现为 javac 执行无响应或弹窗报错。

实操建议：

• 检查 JDK 来源：优先使用官网下载的 Oracle JDK 或 Adoptium（Eclipse Temurin）ARM64 版本，避免第三方打包版
• 若已安装却报“已损坏”，终端执行 xattr -d com.apple.quarantine $(which javac) 清除隔离属性（仅限可信 JDK）
• 确认 javac 文件权限：运行 ls -l $(which javac)，应有可执行权限（-rwxr-xr-x）；若无，补上 chmod +x $(which javac)

真正卡住人的往往不是配置步骤，而是“以为配好了”——比如 java -version 通过就不再验证 javac，或者 PATH 里混进了旧 JDK 的 bin 路径却没意识到它优先级更高。

Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南