很简单——当您想重写父类中出现的方法时，使用@Override注释来进行正确的重写。如果你没有正确地覆盖它，编译器会警告你。

它允许你(好吧，编译器)在你重写的方法名上使用了错误的拼写。

为了从编译器检查中获益，你应该总是使用Override注释。但是不要忘记Java Compiler 1.5在覆盖接口方法时不允许这个注释。您只能使用它来重写类方法(抽象与否)。

有些ide(如Eclipse)甚至配置了Java 1.6运行时或更高版本，它们保持与Java 1.5的一致性，并且不允许像上面描述的那样使用@override。要避免这种行为，您必须转到:项目属性->Java编译器->勾选“启用项目特定设置”->选择“编译器遵从级别”= 6.0或更高。

我喜欢在每次独立重写方法时使用这个注释，如果基是一个接口或类。

这可以帮助您避免一些典型的错误，例如当您认为您正在重写事件处理程序时，然后您没有看到发生任何事情。假设你想给某个UI组件添加一个事件监听器:

someUIComponent.addMouseListener(new MouseAdapter(){
  public void mouseEntered() {
     ...do something...
  }
});

上面的代码编译并运行，但是如果你将鼠标移动到someUIComponent内部，“do something”代码将提示运行，因为实际上你没有覆盖基本方法mouseEntered(MouseEvent ev)。您只需创建一个新的无参数方法mouseEntered()。如果您使用了@Override注释，那么您将看到一个编译错误，并且没有浪费时间思考为什么事件处理程序没有运行。

It seems that the wisdom here is changing. Today I installed IntelliJ IDEA 9 and noticed that its "missing @Override inspection" now catches not just implemented abstract methods, but implemented interface methods as well. In my employer's code base and in my own projects, I've long had the habit to only use @Override for the former -- implemented abstract methods. However, rethinking the habit, the merit of using the annotations in both cases becomes clear. Despite being more verbose, it does protect against the fragile base class problem (not as grave as C++-related examples) where the interface method name changes, orphaning the would-be implementing method in a derived class.

当然，这种情况多半是夸张的;派生类将不再编译，现在缺少重命名接口方法的实现，今天可能会使用重命名方法重构操作来处理整个代码库。

鉴于IDEA的检查无法配置为忽略已实现的接口方法，今天我将改变我的习惯和我的团队的代码审查标准。

我总是使用标签。它是一个简单的编译时标志，用于捕捉我可能犯的小错误。

它会捕获tostring()而不是tostring()

小事情有助于大项目。

这里有很多好的答案，所以让我提供另一种看待它的方式……

编码时没有多余的东西。输入@override不需要花费任何成本，但是如果您拼写错了方法名或签名稍有错误，节省的成本可能是巨大的。

可以这样想:在你浏览这里并输入这篇文章的时间里，你所花费的时间比你余生输入@override的时间还要多;但是它防止的一个错误可以节省你的时间。

Java尽其所能确保您在编辑/编译时不会犯任何错误，这是一种几乎免费的方法来解决整个类型的错误，这些错误在全面测试之外的任何其他方法都无法预防。

你能在Java中提出一种更好的机制来确保当用户想要重写一个方法时，他实际上做到了吗?

另一个巧妙的效果是，如果您不提供注释，它将在编译时警告您不小心覆盖了父方法——如果您不打算这样做，这可能会很重要。