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

每当一个方法覆盖了另一个方法，或者一个方法在接口中实现了签名。

@Override注释确保您确实重写了某些内容。如果没有注释，可能会出现拼写错误或参数类型和数字不同的情况。

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

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

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

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

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

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

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

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

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

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

小事情有助于大项目。