jenv比手动改JAVA_HOME更可靠，因其通过shell函数动态注入版本，避免多项目间JDK串用；而手动配置易导致java/javac/Maven/IDE版本不一致。
为什么 jenv 比手动改 JAVA_HOME 更可靠
手动改 JAVA_HOME 和 PATH 看似简单，但项目一多就容易串版本：Maven 编译用的是 JDK 17，IDE 却在跑 JDK 11，java -version 和 javac -version 还可能不一致。这是因为不同工具读取 Java 的方式不同——java 走 PATH，javac 可能依赖 JAVA_HOME，而 Maven、Gradle、IDEA 又各有自己的 JDK 配置入口。jenv 不改全局环境变量，而是通过 shell 函数动态注入，让每个终端会话、每个子进程都拿到一致的 java/javac 版本。
实操建议：
立即学习“Java免费学习笔记（深入）”；
-
jenv必须在 shell 启动时加载（如写入~/.zshrc或~/.bash_profile），否则新开终端不生效 - 不要把
JAVA_HOME写死在 shell 配置里，jenv会自动管理它；如果已有残留配置，启动时会报Warning: JAVA_HOME is set - Mac 用户注意：
brew install jenv安装后默认不启用插件，需手动运行jenv enable-plugin export才能支持export类命令
安装多个 JDK 后，jenv add 怎么找对路径
常见错误是直接用 /usr/libexec/java_home -v 17 的输出路径去 jenv add，结果报错 No valid java directory found。因为 jenv add 要求路径指向 JDK 根目录（含 bin/java、lib/rt.jar 等），而 java_home 返回的常是 Contents/Home 的上层（比如 /Library/Java/JavaVirtualMachines/jdk-17.jdk），实际 JDK 根目录其实是它里面的 Contents/Home。
实操建议：
立即学习“Java免费学习笔记（深入）”；
- Mac 上推荐用
/usr/libexec/java_home -v 17查路径，然后补上/Contents/Home——例如输出是/Library/Java/JavaVirtualMachines/jdk-17.jdk，则真实路径是/Library/Java/JavaVirtualMachines/jdk-17.jdk/Contents/Home - Linux / Windows WSL 下，JDK 通常解压即用，路径就是解压后的目录（如
~/jdk-11.0.21），确认里面有bin/java就行 - 运行
jenv add <path>后，用jenv versions检查是否显示带星号的默认版本；没星号说明添加失败，大概率是路径不对或权限不足
jenv local 和 jenv global 切换失效的典型原因
执行 jenv local 11 后，java -version 还是显示 17，最常见原因是当前目录下存在 .java-version 文件但被 Git 忽略或误删了——jenv local 实际就是往当前目录写这个文件；另一个原因是 shell 没重新加载 jenv 初始化脚本，导致 jenv 命令本身不可用。
当用户要求为 Java 代码添加注释、修改注释、审查注释、整理注释格式，或要求按照代码注释规范处理 Java 文件时，使用本技能。本技能用于统一生成和维护 Java 类注释模板、按 Git 对比 release 判断版本号、补充每行代码上方中文块注释、调整注释空行规则，并保持 Java 文件 UTF-8 无 BOM 编码。典型触发场景包括：补充类注释、更新 @version、检查 @author 来源、整理行尾注释、把注释放到代码上一行、检查注释是否符合规范、构建前检查 Java 注释风格。
实操建议：
立即学习“Java免费学习笔记（深入）”；
-
jenv local 11会在当前目录生成.java-version，内容就是11；可手动检查该文件是否存在、内容是否正确 - 切换后立刻执行
source ~/.zshrc（或对应 shell 配置），确保jenv的 shell 函数已载入；否则jenv命令可能报错或静默失败 -
jenv global设的是 fallback 版本，只在没.java-version且没jenv shell时生效；别指望它覆盖项目级设置 - IDE（如 IntelliJ）不会读
jenv设置，需单独在Project Structure → SDKs里指定，否则编译和运行仍可能用错 JDK
Gradle/Maven 项目里，jenv 对 sourceCompatibility 无效怎么办
jenv 只控制 java 和 javac 命令的版本，不影响构建工具内部的编译目标。比如 jenv local 17 后 javac -version 是 17，但 Gradle 的 sourceCompatibility = JavaVersion.VERSION_11 仍会用 JDK 17 的 javac 去编译成 Java 11 字节码——这不算错，但容易让人误以为“没切成功”。真正出问题的是当项目用了 JDK 17 特有 API（如 Stream.toList()），却设 sourceCompatibility = 11，编译会失败。
实操建议：
立即学习“Java免费学习笔记（深入）”；
- 先确认
jenv version输出是否与预期一致，再查gradle --version显示的 JVM 路径是否匹配——Gradle 默认复用当前 shell 的java - Maven 项目若用
maven-compiler-plugin，必须显式配置<source>和<target>，不能只靠jenv - Gradle 中
java.toolchain.languageVersion才真正绑定 JDK 版本，比sourceCompatibility更底层；设成JavaLanguageVersion.of(17)才会强制用 JDK 17 的javac
最容易被忽略的是：同一台机器上多个终端窗口互不影响，一个窗口 jenv local 11，另一个还是 global 设置；关掉终端再开，local 设置就丢了——它只作用于当前 shell 会话和它的子进程。
