註解的本質就是一個繼承了 Annotation 介面的介面。有關這一點，你可以去反編譯任意一個註解類，你會得到結果的。

一個註解準確意義上來說，只不過是一種特殊的註釋而已，如果沒有解析它的程式碼，它可能連註釋都不如。

而解析一個類或者方法的註解往往有兩種形式，一種是編譯期直接的掃描，一種是執行期反射。反射的事情我們待會說，而編譯器的掃描指的是編譯器在對 java 程式碼編譯位元組碼的過程中會檢測到某個類或者方法被一些註解修飾，這時它就會對於這些註解進行某些處理。

典型的就是註解 @Override，一旦編譯器檢測到某個方法被修飾了 @Override 註解，編譯器就會檢查當前方法的方法簽名是否真正重寫了父類的某個方法，也就是比較父類中是否具有一個同樣的方法簽名。

這一種情況只適用於那些編譯器已經熟知的註解類，比如 JDK 內建的幾個註解，而你自定義的註解，編譯器是不知道你這個註解的作用的，當然也不知道該如何處理，往往只是會根據該註解的作用範圍來選擇是否編譯進位元組碼檔案，僅此而已。

至於算不算侵入式程式設計，看怎麼比。

如果說算，是因為加註解，則需要依賴註解的型別，並且註解也會編譯到class中。

如果說不算，是因為註解可以和框架主體分離，依賴註解不代表依賴框架。而且從邏輯上講，註解屬於元資料，不影響執行(如果不反射也不自行解析位元組碼，jvm不會管註解)。

不知道題主的觀點怎麼來的，註解和侵入風馬牛不相及，註解和注入倒是會有一些聯絡。

說下註解，很多語言都有這玩意，但是名字和解釋五花八門。有的叫註解（如java），也有叫特徵或特性（如c#）。可能是翻譯時存在詞不達意的情況，影響理解。

註解的本意是，給型別或者成員附加一些額外的資料。請注意這些資料是附加的，跟型別或成員並沒有什麼直接關係。 可以理解為型別資訊元資料的一部分。

常見的例子是，將某個型別或者方法新增已廢棄（Obsolete）的註解，開發環境遇到這樣的註解時，就可以提示使用者不要繼續使用了。

舉個簡單直白的例子，註解的作用類似於打標籤。如題主會把他認識的妹子打上標籤，如漂亮、性感、多金等，一想到漂亮妹子時，題主立即在心裡把所有認識的妹子過一遍，看看誰符合漂亮的標籤。

在使用框架時，經常會發現註解滿天飛的情況，這是因為主流的框架普遍使用註解驅動，細化一點是反射+註解。 反射用於動態的訪問，如動態載入、建立、訪問型別元資料等，而註解則用於判斷是否符合約定或滿足條件等。

算是侵入式的，這也是我們用mybatis時推薦使用xml的原因之一，侵入的程度區別是依賴的註解是標準的JSR註解還是自定義的註解，標準JSR註解的通用性更強，也意味著侵入更低。特別提一下swagger的註解，直接導致原始碼亂糟糟，我們基本不推薦使用。

Java註解不是程式碼侵入，只是在原始檔中嵌入“附加”資訊，不改變原程式的執行。獲取註解資訊時透過反射機制讀取。

一，Java註解用途

Java從5.0開始支援註解，Spring框架也從2.5開始捨棄xml配置，使用註解。

Java Annotation註解也叫元資料，不改變程式的執行，在編譯、載入、執行時被讀取，可以被很多工具使用，比如程式碼掃描工具、開發工具和部署工具等。

Java註解用途廣泛，熟練使用它們有助於提高程式碼質量和開發效率，也是工程師水平高低的一個反映。

二，Java註解保留策略

宣告註解時，指定不同的保留策略RetentionPolicy，比如@Override在編譯時就被丟棄了，@Bean註解一直保留到執行時。

三，Java註解分類

Java註解很多，應用於多種功能場景，可以宣告在package包、類、方法、成員變數、區域性變數、形參等前面，用來對這些元素進行說明和註釋。我們在實際開發工作中，會經常使用到一些註解，比如@Override, @Test，還有一些Spring註解，比如@Service, @Autowired, @SpringBootApplication

四，如何讀取註解？

Package、Class、Constructor、Method、Field都實現了介面AnnotatedElement，該介面位於反射包java.lang.reflect中，呼叫功能函式獲取註解資訊：

比如宣告一個HelloAnnotation註解，建立一個HelloClass類，然後增加註解。程式碼執行讀取註解資訊時，呼叫Class實現的AnnotatedElement反射介面函式，示例程式碼如下：

侵入應該是指透過繼承實現框架裡的程式碼，改變原有功能或實現功能，前提是有部分程式碼必須依靠別人的程式碼和框架，耦合較大，程式碼不能單獨使用。非傾入就是完全沒動過改變框架或程式碼裡的功能，自己原創或對結果加強。要較好的通用型。註解通用性很強，可以說是非侵入的，但其實註解和侵入沒半毛錢關係，光註解不能實現任何功能，也不能配合其他框架，怎麼侵入。

算，也不算

如果說算，是因為加註解，則需要依賴註解的型別，並且註解也會編譯到class中。如果說不算，是因為註解可以和框架主體分離，依賴註解不代表依賴框架。而且從邏輯上講，註解屬於元資料，不影響執行(如果不反射也不自行解析位元組碼，jvm不會管註解)

關於spring註解

spring3.0 以前的註解會有入侵，但入侵不是因為註解而是對註解的業務處理對整個系統的耦合。在 spring 5.0 以上可以放心大膽的使用,

先搞清楚侵入性的概念當你的程式碼引入了一個元件,導致其它程式碼或者設計,要做相應的更改以適應新元件.這樣的情況我們就認為這個新元件具有侵入性。

顯然，如果設計的程式碼對原有程式碼邏輯有程式碼侵入的話，是一個糟糕的設計方式。什麼是侵入性？個人認為就是一旦你這段新增的程式碼出現異常對原本的程式碼會有極大影響，那你這段程式碼侵入性就太明顯了。

而註解對程式碼是否有侵入性呢？

要知道註解是從老版jdk就有的一個語法特性，目前廣泛運用在各大框架中介軟體的開發中，比如我們最常用的spring框架，程式設計時service和autoware等註解幾乎是必用的。如果說註解式程式設計對程式碼有過度侵入性，我想甲骨文公司也不會去創造註解這種東西。顯然，註解本身並不會對程式碼造成侵入，反而他的設計是為了解耦合，透過代理等方式將需要引入的元件新增到原邏輯中。

但是註解一定不會侵入嗎？

答案是否定的，註解本身其實不用糾結會不會侵入，而是對註解使用過程中的開發者，是否會寫出侵入性極強的程式碼。用註解完全可以寫出侵入式的程式碼，比如在寫spring的aop時，後置處理的程式碼有bug，那必然會導致原邏輯不能正常進行，這就是一種侵入，而且還影響很大。

宇文哥習慣性總結:註解是一件利器，用的好程式碼可以低耦合，用的不好，就會造成侵入性極強，沒有最好的技術只有更好的編碼者。

是，也不是如果說是，是因為加註解，則需要依賴註解的型別，並且註解也會編譯到class中。如果說不是，是因為註解可以和框架主體分離，依賴註解不代表依賴框架。而且從邏輯上講，註解屬於元資料，不影響執行(如果不反射也不自行解析位元組碼，jvm不會管註解)