对于我来说，@Override确保我有正确的方法签名。如果我放入注释，而方法拼写不正确，那么编译器会报错，让我知道有什么地方出错了。

@Override在接口上实际上是有帮助的，因为如果你改变了接口，你会得到警告。

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

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

小事情有助于大项目。

最好将它用于打算重写的每个方法，以及Java 6+，用于打算作为接口实现的每个方法。

首先，它会在编译时捕获像“hashcode()”而不是“hashcode()”这样的拼写错误。当真正的原因是您的代码从未被调用时，调试为什么您的方法的结果似乎与您的代码不匹配可能会令人困惑。

同样，如果一个超类改变了一个方法签名，旧签名的重写就会被“孤立”，留下令人困惑的死代码。@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的检查无法配置为忽略已实现的接口方法，今天我将改变我的习惯和我的团队的代码审查标准。

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

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

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