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

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

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

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

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

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

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

我尽可能多地使用它来识别方法何时被覆盖。如果你看看Scala编程语言，它们也有一个override关键字。我发现它很有用。

最佳实践是始终使用它(或让IDE为您填充它们)

@Override有用性是检测父类中没有向下报告的变化。 如果没有@Override，你可以改变方法签名而忘记改变它的覆盖，使用@Override，编译器将为你捕获它。

有这样的安全网总是好的。

接口实现上的@Override是不一致的，因为在java中没有“覆盖接口”这样的事情。

@Override on interface implementation is useless since in practise it catches no bugs that the compilation wouldn't catch anyway. There is only one, far fetched scenario where override on implementers actually does something: If you implement an interface, and the interface REMOVES methods, you will be notified on compile time that you should remove the unused implementations. Notice that if the new version of the interface has NEW or CHANGED methods you'll obviously get a compile error anyways as you're not implementing the new stuff.

在1.6中不应该允许接口实现@Override，而不幸的是，eclipse选择自动插入注释作为默认行为，我们得到了大量杂乱的源文件。在阅读1.6代码时，您无法从@Override注释中看出一个方法实际上覆盖了超类中的一个方法，还是仅仅实现了一个接口。

在重写超类中的方法时使用@Override是可以的。

它所做的另一件事是，当读取代码时，它会更明显地改变父类的行为。这有助于调试。

此外，在Joshua Block的著作《Effective Java》(第二版)中，第36项详细介绍了注释的好处。