我每次都用。它提供了更多的信息，当我在一年后重新访问代码时，我可以快速弄清楚发生了什么，而我已经忘记了我第一次想的是什么。

使用@Override注释可以在编译时防止常见的编程错误。它会抛出一个编译错误，如果你在一个方法上有注释，而你实际上没有重写超类方法。

最常见的情况是，当您更改基类中的一个方法以拥有一个不同的参数列表时，这是有用的。子类中用于覆盖超类方法的方法将不再这样做，因为方法签名已更改。这有时会导致奇怪和意外的行为，特别是在处理复杂的继承结构时。@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注释，那么您将看到一个编译错误，并且没有浪费时间思考为什么事件处理程序没有运行。

接口实现上的@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是可以的。

我到处都用它。 关于标记方法的工作，我让Eclipse替我做，所以不需要额外的工作。

我对持续重构非常虔诚....所以，我会利用每一件小事让它进行得更顺利。

在实现接口方法时使用@Override完全没有意义。在这种情况下使用它没有任何好处——编译器已经发现了你的错误，所以这只是不必要的混乱。