在这一章节，我们来讨论下 注解的本质，不讨论注解的实现细节。
在讨论之前，我们先给出结论：注解，本质上，是 配置-标记 的一种实现方式，为了取代xml。
注解和xml，分别是 配置-标记 功能的不同实现方式而已。
在注解出来之前，如果我们想实现 配置-标记 的功能，只能将 配置-标记 信息写到xml中。比如：
1.连接数据库，采用什么的驱动、采用什么连接池；
2.需要注册哪些bean，每个bean又依赖哪些其他bean
3.某个类是controller，能使用restful的方式发起请求
这些功能，都需要将相应的配置信息，写到xml文件中。
那既然，已经有了xml，能够实现 配置-标记 功能，为什么后来又引入注解呢？
我们来想一想，如果如果想用xml，来实现 配置-标记 功能，大概步骤如下：
1.指明给谁配置
2.具体配置什么东西（比如，给bean的某个成员变量，指定为其他bean名字，后者其他bean类型）
3.配置时，如果涉及的细节比较多，比较复杂，用xml不太好写，如果使用编程语言，更好表达
4.通用的一些配置，每个项目都需要自己重新写到xml文件中，不能实现复用。
可以看到上面的步骤，用xml来实现，有很多问题
因此，为了解决xml的问题，同时为了能够实现 配置-标记 功能，我们引入了注解。
我们对比xml的4个步骤，我们来看下，注解的优势在哪？
1.注解写在哪个Java类，就是给谁配置的
2.可以给java的成员变量，直接加上注解，就能指定注入容器中的其他bean
3.利用编程语言的强大、且灵活多变，即使再复杂，也能轻松配置。毕竟，编程语言，都能把复杂的业务实现出来，一些配置功能，当然不再话下了。
4.通用的配置，可以写成类似于通用配置类，放到依赖的jar包中，这样就能实现复用了。
可以看到，注解的优势，真的比xml，多太多了。
那注解是完胜xml了吗？啥缺点也没有吗？
其实不是的，注解也有很多缺点：
-
就是太分散了。几十个注解，分散在不同的java类、jar包中，导致出现问题时，不能够快速定位出问题；而xml是集中式配置，所有的配置信息，都写在2-3个配置文件中，能快速定位的，哪个地方配置错了。
-
注解的使用，导致编程风格，变成了隐式，不是明确的显式风格。比如，UserService，需要一个UserDao,注解加了
@Autowired注解，但是程序中，也许有多个UserDao，具体会注入哪个，这里并没有显式指明，程序执行的结果如果有问题，排查原因时，就会有些模糊，不知道看哪一个UserDao实现类的逻辑，可读性也会变差。