从没想过这个，但是…看来你是对的，注释继承设施没有问题(至少我没有看到它的问题)。

关于你用“验证器”注释的例子-你可以利用“元注释”方法。例如，您将特定的元注释应用到整个注释接口。

关于为什么它不是这样设计的，你可以在JSR 175设计常见问题中找到答案，它说:

为什么不支持注释子类型(一种注释类型扩展另一种注释类型)? 它使注释类型复杂化 系统，并使它更多 “特定工具”很难写。 .．. “特定工具”-用于查询的程序 已知的注释类型为任意 外部程序。存根生成器, 例如，就属于这一类。 这些程序读起来是带注释的 类，而无需将它们加载到 虚拟机，但将加载 注解的接口。

所以，是的，我想，原因就是KISS。无论如何，这个问题(以及许多其他问题)似乎正在作为JSR 308的一部分进行研究，您甚至可以找到由Mathias Ricken开发的具有此功能的替代编译器。

我可能晚了三年才回答这个问题，但我发现它很有趣，因为我发现自己也处于同样的境地。以下是我的看法。您可以将注释作为枚举来查看。它们只提供单向的信息——要么使用，要么失去。

我有一个情况，我想在一个web应用程序中模拟GET, POST, PUT和DELETE。我非常希望有一个“超级”注释，叫做“HTTP_METHOD”。后来我才明白，这无关紧要。好吧，我不得不在HTML表单中使用一个隐藏字段来标识DELETE和PUT(因为POST和GET无论如何都是可用的)。

在服务器端，我寻找一个名为“_method”的隐藏请求参数。如果值是PUT或DELETE，那么它将覆盖相关的HTTP请求方法。话虽如此，我是否需要扩展注释来完成工作并不重要。所有的注释看起来都是一样的，但是它们在服务器端得到了不同的处理。

因此，在您的情况下，不要急于扩展注释。把它们当作“标记”。它们“代表”一些信息，而不一定“操纵”一些信息。

Java注释支持的设计者做了许多不利于Java社区的“简化”。

没有注释子类型会使许多复杂的注释变得不必要地丑陋。注释中不能简单地有一个属性，该属性只能包含以下三种内容之一。一个需要有三个独立的属性，这使开发人员感到困惑，并且需要运行时验证以确保只使用三个属性中的一个。 每个站点只能有一个给定类型的注释。这导致了完全不必要的集合注释模式。@Validation和@Validations， @Image和@Images等等。

第二个问题已经在Java 8中得到了解决，但为时已晚。许多框架都是基于Java 5中可能实现的功能编写的，现在这些API的缺陷将会存在很长一段时间。

和我有同样的问题。不，你不能。我确实“自律”自己在注释中写属性，以尊重一些标准，所以当你得到注释时，你可以通过它的属性“嗅”出它是什么类型的注释。

从没想过这个，但是…看来你是对的，注释继承设施没有问题(至少我没有看到它的问题)。

关于你用“验证器”注释的例子-你可以利用“元注释”方法。例如，您将特定的元注释应用到整个注释接口。