算，也不算
如果说算，是因为加注解，则需要依赖注解的类型，并且注解也会编译到class中。如果说不算，是因为注解可以和框架主体分离，依赖注解不代表依赖框架。而且从逻辑上讲，注解属于元数据，不影响执行(如果不反射也不自行解析字节码，jvm不会管注解)
关于spring注解
spring3.0以前的注解会有入侵，但入侵不是因为注解而是对注解的业务处理对整个系统的耦合。在spring5.0以上可以放心大胆的使用，
是，也不是如果说是，是因为加注解，则需要依赖注解的类型，并且注解也会编译到class中。如果说不是，是因为注解可以和框架主体分离，依赖注解不代表依赖框架。而且从逻辑上讲，注解属于元数据，不影响执行(如果不反射也不自行解析字节码，jvm不会管注解)
应该算是侵入，因为注解依赖于编译，所以无法再没有编译环境中修改一些元信息。算是低耦合高内聚的一种折中。
侵入应该是指通过继承实现框架里的代码，改变原有功能或实现功能，前提是有部分代码必须依靠别人的代码和框架，耦合较大，代码不能单独使用。非倾入就是完全没动过改变框架或代码里的功能，自己原创或对结果加强。要较好的通用型。注解通用性很强，可以说是非侵入的，但其实注解和侵入没半毛钱关系，光注解不能实现任何功能，也不能配合其他框架，怎么侵入。
注解的本质就是一个继承了Annotation接口的接口。有关这一点，你可以去反编译任意一个注解类，你会得到结果的。
一个注解准确意义上来说，只不过是一种特殊的注释而已，如果没有解析它的代码，它可能连注释都不如。
而解析一个类或者方法的注解往往有两种形式，一种是编译期直接的扫描，一种是运行期反射。反射的事情我们待会说，而编译器的扫描指的是编译器在对java代码编译字节码的过程中会检测到某个类或者方法被一些注解修饰，这时它就会对于这些注解进行某些处理。
典型的就是注解@Override，一旦编译器检测到某个方法被修饰了@Override注解，编译器就会检查当前方法的方法签名是否真正重写了父类的某个方法，也就是比较父类中是否具有一个同样的方法签名。
这一种情况只适用于那些编译器已经熟知的注解类，比如JDK内置的几个注解，而你自定义的注解，编译器是不知道你这个注解的作用的，当然也不知道该如何处理，往往只是会根据该注解的作用范围来选择是否编译进字节码文件，仅此而已。
至于算不算侵入式编程，看怎么比。
如果说算，是因为加注解，则需要依赖注解的类型，并且注解也会编译到class中。
如果说不算，是因为注解可以和框架主体分离，依赖注解不代表依赖框架。而且从逻辑上讲，注解属于元数据，不影响执行(如果不反射也不自行解析字节码，jvm不会管注解)。
算是侵入式的，这也是我们用mybatis时推荐使用xml的原因之一，侵入的程度区别是依赖的注解是标准的JSR注解还是自定义的注解，标准JSR注解的通用性更强，也意味着侵入更低。特别提一下swagger的注解，直接导致源码乱糟糟，我们基本不推荐使用。
不知道题主的观点怎么来的，注解和侵入风马牛不相及，注解和注入倒是会有一些联系。
说下注解，很多语言都有这玩意，但是名字和解释五花八门。有的叫注解（如java），也有叫特征或特性（如c#）。可能是翻译时存在词不达意的情况，影响理解。
注解的本意是，给类型或者成员附加一些额外的数据。请注意这些数据是附加的，跟类型或成员并没有什么直接关系。可以理解为类型信息元数据的一部分。
常见的例子是，将某个类型或者方法添加已废弃（Obsolete）的注解，开发环境遇到这样的注解时，就可以提示用户不要继续使用了。
举个简单直白的例子，注解的作用类似于打标签。如题主会把他认识的妹子打上标签，如漂亮、性感、多金等，一想到漂亮妹子时，题主立即在心里把所有认识的妹子过一遍，看看谁符合漂亮的标签。
在使用框架时，经常会发现注解满天飞的情况，这是因为主流的框架普遍使用注解驱动，细化一点是反射+注解。反射用于动态的访问，如动态加载、创建、访问类型元数据等，而注解则用于判断是否符合约定或满足条件等。
谢邀，作为一个Java软件工程师对这个问题有自己的见解。
先搞清楚侵入性的概念
当你的代码引入了一个组件，导致其它代码或者设计，要做相应的更改以适应新组件.这样的情况我们就认为这个新组件具有侵入性。显然，如果设计的代码对原有代码逻辑有代码侵入的话，是一个糟糕的设计方式。什么是侵入性？个人认为就是一旦你这段添加的代码出现异常对原本的代码会有极大影响，那你这段代码侵入性就太明显了。
而注解对代码是否有侵入性呢？
要知道注解是从老版jdk就有的一个语法特性，目前广泛运用在各大框架中间件的开发中，比如我们最常用的spring框架，编程时service和autoware等注解几乎是必用的。如果说注解式编程对代码有过度侵入性，我想甲骨文公司也不会去创造注解这种东西。显然，注解本身并不会对代码造成侵入，反而他的设计是为了解耦合，通过代理等方式将需要引入的组件添加到原逻辑中。
但是注解一定不会侵入吗？
答案是否定的，注解本身其实不用纠结会不会侵入，而是对注解使用过程中的开发者，是否会写出侵入性极强的代码。用注解完全可以写出侵入式的代码，比如在写spring的aop时，后置处理的代码有bug，那必然会导致原逻辑不能正常进行，这就是一种侵入，而且还影响很大。
宇文哥习惯性总结:注解是一件利器，用的好代码可以低耦合，用的不好，就会造成侵入性极强，没有最好的技术只有更好的编码者。
关注@极客宇文氏一名热心有料的Java软件工程师。一个非常好的问题。我是工作多年的Web应用架构师，来回答一下这个问题。欢迎关注我，了解更多IT专业知识。
Java注解不是代码侵入，只是在源文件中嵌入“附加”信息，不改变原程序的运行。获取注解信息时通过反射机制读取。
一，Java注解用途
Java从5.0开始支持注解，Spring框架也从2.5开始舍弃xml配置，使用注解。
JavaAnnotation注解也叫元数据，不改变程序的运行，在编译、加载、运行时被读取，可以被很多工具使用，比如代码扫描工具、开发工具和部署工具等。
Java注解用途广泛，熟练使用它们有助于提高代码质量和开发效率，也是工程师水平高低的一个反映。
二，Java注解保留策略
声明注解时，指定不同的保留策略RetentionPolicy，比如@Override在编译时就被丢弃了，@Bean注解一直保留到运行时。
三，Java注解分类
Java注解很多，应用于多种功能场景，可以声明在package包、类、方法、成员变量、局部变量、形参等前面，用来对这些元素进行说明和注释。我们在实际开发工作中，会经常使用到一些注解，比如@Override，@Test，还有一些Spring注解，比如@Service，@Autowired，@SpringBootApplication
Java+SpringBoot开发时，用到的注解按照来源可以分类为：Java内置注解、Spring注解、Web注解、自定义注解，等等。
四，如何读取注解？
Package、Class、Constructor、Method、Field都实现了接口AnnotatedElent，该接口位于反射包java.lang.reflect中，调用功能函数获取注解信息：
比如声明一个HelloAnnotation注解，创建一个HelloClass类，然后增加注解。代码运行读取注解信息时，调用Class实现的AnnotatedElent反射接口函数，示例代码如下：