运行 jdeprscan 前需确认其在 PATH 中，OpenJDK 11+ 自带该工具但默认未加入系统 PATH，尤其 Linux/macOS 下常见；若执行报 “command not found”，可手动创建软链接：sudo ln -s $JAVA_HOME/bin/jdeprscan /usr/local/bin/jdeprscan。
运行 jdeprscan 前要确认它在 PATH 里
OpenJDK 11+ 自带 jdeprscan，但默认不进系统 PATH（尤其 Linux/macOS 的 OpenJDK 官方包或某些发行版如 Amazon Corretto）。执行 jdeprscan -h 报 “command not found” 是最常见卡点。
解决办法是手动链接：
- 查路径：
$JAVA_HOME/bin/jdeprscan是否存在（用ls $JAVA_HOME/bin/jdeprscan验证） - 若存在，加软链：
sudo ln -s $JAVA_HOME/bin/jdeprscan /usr/local/bin/jdeprscan - Windows 用户直接用完整路径，比如：
%JAVA_HOME%\bin\jdeprscan.exe
jdeprscan 只扫 JDK 自带 API，不扫第三方库
它只分析你代码中调用的 java.*、javax.*（JDK 内置部分）和 sun.* 等内部类是否已被弃用或删除——不会检查你用的 Spring、Guava 或自定义工具类里的废弃方法。
所以别指望它报出 org.apache.commons.lang3.StringUtils.isEmpty() 过时这类问题。它的作用边界很明确：
- 能发现：
java.util.Date(String)（已弃用）、sun.misc.BASE64Encoder（已删除） - 不能发现：
com.google.common.collect.ImmutableList.of()是否有新推荐写法 - 对
javax.xml.bind.JAXB这类被移除的模块，jdeprscan不会提示“缺失”，而是静默跳过；要用jdeps --jdk-internals或运行时报错才暴露
扫描 jar 包比扫描 class 目录更实用
直接扫编译产物（jar）更贴近真实部署场景，也避免因源码未全编译导致漏检。命令格式简单：
jdeprscan target/myapp.jar
输出示例：
class com/example/MyService uses deprecated method java/time/LocalDateTime::now()Ljava/time/LocalDateTime; class com/example/Utils uses removed class sun/misc/Unsafe
注意几个关键点：
- 加
--release 8可强制按 Java 8 兼容性检查（适合跨版本构建环境） - 加
--regex '.*Unsafe.*'能过滤聚焦特定内部类 - 它不递归解压嵌套 jar（如 fat-jar 里的依赖），只扫顶层 jar 的 class 文件
- 若输出为空，不代表绝对安全——有些弃用标记在方法签名里没显式声明，
jdeprscan就扫不到
看到 removed 必须处理，deprecated 可暂缓但别忽略
jdeprscan 输出里明确标出 removed 的项（比如 sun.reflect.Reflection、com.sun.image.codec.jpeg），意味着 Java 11 运行时直接抛 NoClassDefFoundError，属于阻断性问题。
而 deprecated 行只是警告，程序仍能跑，但 Oracle 文档已明确不保证后续版本兼容。容易被忽略的陷阱是：
- 某些 IDE（如旧版 IntelliJ）不标红
deprecated的 JDK 方法，开发者毫无感知 - CI 流程里没把
jdeprscan结果当失败条件，导致“能跑就行”的侥幸心理 - 替换成新 API 后，行为可能有细微差异（比如
java.time.format.DateTimeFormatter默认时区逻辑 vsSimpleDateFormat）
真正麻烦的不是工具不会用，而是扫出一堆 deprecated 后，没人跟进替换——拖到 Java 17 或 21，其中一部分就真变 removed 了。
