@Deprecated是Java标记API过时的注解，调用被其标注的元素时编译器和IDE会发出警告，提示迁移至替代方案，但不阻断编译运行。

弃用方法不加 @Deprecated 不会直接引发构建警告——真正触发警告的，是**调用了已被标注为 @Deprecated 的方法或类**。如果你看到构建警告，说明项目中某处代码正在使用一个已被明确标记为废弃的 API，而这个标记正是通过 @Deprecated 实现的。

构建警告从哪来？

Java 编译器（如 javac）和主流 IDE（IntelliJ、Eclipse）在编译时会扫描所有被 @Deprecated 注解修饰的元素。一旦发现代码中调用了这些元素，就会发出警告，例如：

• warning: [deprecation] oldMethod() in MyClass has been deprecated
• Maven 构建时显示 [WARNING] Some methods are deprecated

这个机制不是靠“检测是否缺少 @Deprecated”，而是靠“检测是否使用了带 @Deprecated 的东西”。所以，没加 @Deprecated 的旧方法本身不会报警；但只要它被别人加了 @Deprecated 并发布到你依赖的库中，你的调用就会立刻亮黄灯。

为什么必须用 @Deprecated 标记？

不标记就等于没声明“过时”状态，其他开发者无法感知风险。而加上 @Deprecated 后，能自动触发三重提醒：

• 编译器输出警告，阻断无意识误用
• IDE 在编辑器里给方法名加删除线，视觉强提示
• Javadoc 中配合 @deprecated 文档，说明替代方案（比如 “请改用 newMethod()”）

常见误解澄清

• “我写的旧方法没标 @Deprecated，为什么还报错？” —— 很可能你调用的是第三方库（如 Spring、Apache Commons）里已标注废弃的 API，不是你自己的代码问题
• “加了 @Deprecated 就不能用了？” —— 不是。它仍可编译运行，只是提醒你：该方法未来可能被删，现在就该换
• “用 @SuppressWarnings("deprecation") 能关掉警告？” —— 可以，但这是掩耳盗铃。警告消失不代表风险消失，反而容易错过迁移时机

怎么快速定位和修复？

构建日志里的警告通常带完整类名和行号。按提示打开对应文件，找到那行调用，然后：

• 查该方法所在类的 Javadoc 或源码，看是否有推荐替代项（常写在 @deprecated 注释里）
• 升级所用的依赖版本（比如把 Guava 从 v20 升到 v32），新版本通常已移除废弃调用
• 若暂时无法替换，至少在调用处补上注释，写明原因和计划修复时间