每個 Java 開發者都應該知道的 5 個註解

来源:https://www.cnblogs.com/kkdn/archive/2018/03/25/8647345.html
-Advertisement-
Play Games

自 JDK5 推出以來，註解已成為Java生態系統不可缺少的一部分。雖然開發者為Java框架（例如Spring的@Autowired）開發了無數的自定義註解，但編譯器認可的一些註解非常重要。 在本文中，我們將看到5個Java編譯器支持的註解，並瞭解其期望用途。順便，我們將探索其創建背後的基本原理，圍 ...


自 JDK5 推出以來，註解已成為Java生態系統不可缺少的一部分。雖然開發者為Java框架（例如Spring的@Autowired）開發了無數的自定義註解，但編譯器認可的一些註解非常重要。

在本文中，我們將看到5個Java編譯器支持的註解，並瞭解其期望用途。順便，我們將探索其創建背後的基本原理，圍繞其用途的一些特質，以及正確應用的一些例子。雖然其中有些註解比其他註解更為常見，但非初學Java開發人員都應該消化瞭解每個註解。

首先，我們將深入研究Java中最常用的註解之一：@Override。

@Override

覆蓋方法的實現或為抽象方法提供實現的能力是任何面向對象（OO）語言的核心。由於Java是OO語言，具有許多常見的面向對象的抽象機制，所以在非終極超類定義的非最終方法或介面中的任何方法（介面方法不能是最終的）都可以被子類覆蓋。雖然開始時覆蓋方法看起來很簡單，但是如果執行不正確，則可能會引入許多微小的bug。例如，用覆蓋類類型的單個參數覆蓋Object#equals方法就是一種常見的錯誤：

public class Foo {    public boolean equals(Foo foo) {        // Check if the supplied object is equal to this object
    }
}

由於所有類都隱式地從Object類繼承，Foo類的目的是覆蓋Object#equals方法，因此Foo可被測試是否與Java中的任何其他對象相等。雖然我們的意圖是正確的，但我們的實現則並非如此。實際上，我們的實現根本不覆蓋Object#equals方法。相反，我們提供了方法的重載：我們不是替換Object類提供的equals方法的實現，而是提供第二個方法來專門接受Foo對象，而不是Object對象。我們的錯誤可以用簡單實現來舉例說明，該實現對所有的相等檢查都返回true，但當提供的對象被視為Object（Java將執行的操作，例如在Java Collections Framework即JCF中）時，就永遠不會調用它：

public class Foo {    public boolean equals(Foo foo) {        return true;
    }
}
Object foo = new Foo();
Object identicalFoo = new Foo();
System.out.println(foo.equals(identicalFoo));    // false

這是一個非常微妙但常見的錯誤，可以被編譯器捕獲。我們的意圖是覆蓋Object#equals方法，但因為我們指定了一個類型為Foo而不是Object類型的參數，所以我們實際上提供了重載的Object#equals方法，而不是覆蓋它。為了捕獲這種錯誤，我們引入@Override註解，它指示編譯器檢查覆蓋實際有沒有執行。如果沒有執行有效的覆蓋，則會拋出錯誤。因此，我們可以更新Foo類，如下所示：

public class Foo {    @Override
    public boolean equals(Foo foo) {        return true;
}
}

如果我們嘗試編譯這個類，我們現在收到以下錯誤：

$ javac Foo.java
Foo.java:3: error: method does not override or implement a method from a supertype
        @Override
        ^1 error

實質上，我們已經將我們已經覆蓋方法的這一隱含的假設轉變為由編譯器進行的顯性驗證。如果我們的意圖被錯誤地實現，那麼Java編譯器會發出一個錯誤——不允許我們不正確實現的代碼被成功編譯。通常，如果以下任一條件不滿足，則Java編譯器將針對使用@Override註解的方法發出錯誤（引用自Override註解文檔）：

  • 該方法確實會覆蓋或實現在超類中聲明的方法。

  • 該方法的簽名與在Object中聲明的任何公共方法（即equals或hashCode方法）的簽名覆蓋等價（override-equivalent）。

因此，我們也可以使用此註解來確保子類方法實際上也覆蓋超類中的非最終具體方法或抽象方法：

public abstract class Foo {    public int doSomething() {        return 1;
    }    public abstract int doSomethingElse();
}public class Bar extends Foo {    @Override
    public int doSomething() {        return 10;
    }    @Override
    public int doSomethingElse() {        return 20;
    }
}
Foo bar = new Bar();
System.out.println(bar.doSomething());         // 10System.out.println(bar.doSomethingElse());     // 20

@Override註解不僅不限於超類中的具體或抽象方法，而且還可用於確保介面的方法也被覆蓋（從JDK 6開始）：

public interface Foo {    public int doSomething();
}public class Bar implements Foo {    @Override
    public int doSomething() {        return 10;
    }
}
Foo bar = new Bar();
System.out.println(bar.doSomething());    // 10

通常，覆蓋非final類方法、抽象超類方法或介面方法的任何方法都可以使用@Override進行註解。有關有效覆蓋的更多信息，請參閱《Overriding and Hiding》文檔 以及《Java Language Specification (JLS)》的第9.6.4.4章節。

@FunctionalInterface

隨著JDK 8中lambda表達式的引入，函數式介面在Java中變得越來越流行。這些特殊類型的介面可以用lambda表達式、方法引用或構造函數引用代替。根據@FunctionalInterface文檔，函數式介面的定義如下：

一個函數式介面只有一個抽象方法。由於預設方法有一個實現，所以它們不是抽象的。

例如，以下介面被視為函數式介面：

public interface Foo {    public int doSomething();
}public interface Bar {    public int doSomething();    public default int doSomethingElse() {        return 1;
    }
}

因此，下麵的每一個都可以用lambda表達式代替，如下所示：

public class FunctionalConsumer {    public void consumeFoo(Foo foo) {
        System.out.println(foo.doSomething());
    }    public void consumeBar(Bar bar) {
        System.out.println(bar.doSomething());
    }
}
FunctionalConsumer consumer = new FunctionalConsumer();
consumer.consumeFoo(() -> 10);    // 10consumer.consumeBar(() -> 20);    // 20

重點要註意的是，抽象類，即使它們只包含一個抽象方法，也不是函數式介面。更多信息，請參閱首席Java語言架構師Brian Goetz編寫的《Allow lambdas to implement abstract classes》。與@Override註解類似，Java編譯器提供了@FunctionalInterface註解以確保介面確實是函數式介面。例如，我們可以將此註解添加到上面創建的介面中：

@FunctionalInterfacepublic interface Foo {    public int doSomething();
}@FunctionalInterfacepublic interface Bar {    public int doSomething();    public default int doSomethingElse() {        return 1;
    }
}

如果我們錯誤地將介面定義為非函數介面並用@FunctionalInterface註解了錯誤的介面，則Java編譯器會發出錯誤。例如，我們可以定義以下帶註解的非函數式介面：

@FunctionalInterfacepublic interface Foo {    public int doSomething();    public int doSomethingElse();
}

如果我們試圖編譯這個介面，則會收到以下錯誤：

$ javac Foo.java
Foo.java:1: error: Unexpected @FunctionalInterface annotation
@FunctionalInterface
^
  Foo is not a functional interface
    multiple non-overriding abstract methods found in interface Foo1 error

使用這個註解，我們可以確保我們不會錯誤地創建原本打算用作函數式介面的非函數式介面。需要註意的是，即使在@FunctionalInterface註解不存在的情況下，介面也可以用作函數式介面（可以替代為lambdas，方法引用和構造函數引用），正如我們前面的示例中所見的那樣。這類似於@Override註解，即一個方法是可以被覆蓋的，即使它不包含@Override註解。在這兩種情況下，註解都是允許編譯器執行期望意圖的可選技術。

有關@FunctionalInterface註解的更多信息，請參閱@FunctionalInterface文檔和《JLS》的第4.6.4.9章節。

@SuppressWarnings

警告是所有編譯器的重要組成部分，為開發人員提供的反饋——可能危險的行為或在未來的編譯器版本中可能會出現的錯誤。例如，在Java中使用泛型類型而沒有其關聯的正式泛型參數（稱為原始類型）會導致警告，就像使用不推薦使用的代碼一樣（請參閱下麵的@Deprecated部分）。雖然這些警告很重要，但它們可能並不總是適用甚至並不總是正確的。例如，可能會有對不安全的類型轉換髮生警告的情況，但是基於使用它的上下文，我們可以保證它是安全的。

為了忽略某些上下文中的特定警告，JDK 5中引入了@SuppressWarnings註解。此註解接受一個或多個字元串參數——描述要忽略的警告名稱。雖然這些警告的名稱通常在編譯器實現之間有所不同，但有3種警告在Java語言中是標準化的（因此在所有Java編譯器實現中都很常見）：

  • unchecked：表示類型轉換未經檢查的警告（編譯器無法保證類型轉換是安全的），導致發生的可能原因有訪問原始類型的成員（參見《JLS》4.8章節）、窄參考轉換或不安全的向下轉換（參見《JLS》5.1.6章節）、未經檢查的類型轉換（參見《JLS》5.1.9章節）、使用帶有可變參數的泛型參數（參見《JLS》8.4.1章節和下麵的@SafeVarargs部分）、使用無效的協變返回類型（參見《JLS》8.4.8.3章節）、不確定的參數評估（參見《JLS》15.12.4.2章節），未經檢查的方法引用類型的轉換（參見《JLS》15.13.2章節）、或未經檢查的lambda類型的對話（參見《JLS》15.27.3章節）。

  • deprecation：表示使用了已棄用的方法、類、類型等的警告（參見《JLS》9.6.4.6章節和下麵的@Deprecated部分）。

  • removal：表示使用了最終廢棄的方法、類、類型等的警告（參見《JLS》9.6.4.6章節和下麵的@Deprecated部分）。

為了忽略特定的警告，可以將@SuppressedWarning註解與抑制警告（以字元串數組的形式提供）的一個或多個名字添加到發生警告的上下文中：

public class Foo {    public void doSomething(@SuppressWarnings("rawtypes") List myList) {        // Do something with myList
    }
}

@SuppressWarnings註解可用於以下任何一種情況：

  • 類型

  • 域

  • 方法

  • 參數

  • 構造函數

  • 局部變數

  • 模塊

一般來說，@SuppressWarnings註解應該應用於最直接的警告範圍。例如，如果方法中的局部變數應忽略警告，則應將@SuppressWarnings註解應用於局部變數，而不是包含局部變數的方法或類：

public class Foo {    public void doSomething() {        @SuppressWarnings("rawtypes")
        List myList = new ArrayList();        // Do something with myList
    }
}

@SafeVarargs

可變參數在Java中是一種很有用的技術手段，但在與泛型參數一起使用時，它們也可能會導致一些嚴重的問題。由於泛型在Java中是非特定的，所以具有泛型類型的變數的實際（實現）類型不能在運行時被斷定。由於無法做出此判斷，因此變數可能會存儲非其實際類型的引用到類型，如以下代碼片段所示（摘自《Java Generics FAQs》）：

List ln = new ArrayList<Number>();
ln.add(1);
List<String> ls = ln;                 // unchecked warning String s = ls.get(0);                 // ClassCastException

在將ln分配給ls後，堆中存在變數ls，該變數具有List<String>的類型，但存儲引用到實際為List<Number>類型的值。這個無效的引用被稱為堆污染。由於直到運行時才能確定此錯誤，因此它會在編譯時顯示為警告，併在運行時出現ClassCastException。當泛型參數與可變參數組合時，可能會加劇此問題：

public class Foo {    public <T> void doSomething(T... args) {        // ...
    }
}

在這種情況下，Java編譯器會在調用站點內部創建一個數組來存儲可變數量的參數，但是T的類型並未實現，因此在運行時會丟失。實質上，到doSomething的參數實際上是Object[]類型。如果依賴T的運行時類型，那麼這會導致嚴重的問題，如下麵的代碼片段所示：

public class Foo {
    public <T> void doSomething(T... args) {        Object[] objects = args;        String string = (String) objects[0];
    }
}
Foo foo = new Foo();
foo.<Number>doSomething(1, 2);

如果執行此代碼片段，那麼將導致ClassCastException，因為在調用站點傳遞的第一個Number參數不能轉換為String（類似於獨立堆污染示例中拋出的ClassCastException）。通常，可能會出現以下情況：編譯器沒有足夠的信息來正確確定通用可變參數的確切類型，這會導致堆污染，這種污染可以通過允許內部可變參數數組從方法中轉義來傳播，如下麵摘自《Effective Java》第3版 pp.147的例子：

public static <T> T[] toArray(T... args) {    return args;
}

在某些情況下，我們知道方法實際上是類型安全的，不會造成堆污染。如果可以在保證的情況下做出這個決定，那麼我們可以使用@SafeVarargs註解來註解該方法，從而抑制與可能的堆污染相關的警告。但是，這引出了一個問題：什麼時候通用可變參數方法會被認為是類型安全的？Josh Bloch在《Effective Java》第3版第147頁的基礎上提供了一個完善的解決方案——基於方法與內部創建的用於存儲其可變參數的數組的交互：

如果方法沒有存儲任何東西到數組（這會覆蓋參數）且不允許對數組的引用進行轉義（這會使得不受信任的代碼可以訪問數組），那麼它是安全的。換句話說，如果可變參數數組僅用於從調用者向方法傳遞可變數量的參數——畢竟，這是可變參數的目的——那麼該方法是安全的。

因此，如果我們創建了以下方法（來自pp.149同上），那麼我們可以用@SafeVarags註解來合理地註解我們的方法：

@SafeVarargsstatic <T> List<T> flatten(List<? extends T>... lists) {    List<T> result = new ArrayList<>();    for (List<? extends T> list : lists) {
        result.addAll(list);
    }    return result;
}

有關@SafeVarargs註解的更多信息，請參閱@SafeVarargs文檔，《JLS》9.6.4.7章節以及《Effective Java》第3版中的Item32。

@Deprecated

在開發代碼時，有時候代碼會變得過時和不應該再被使用。在這些情況下，通常會有個替補的更適合手頭的任務，且雖然現存的對過時代碼的調用可能會保留，但是所有新的調用都應該使用替換方法。這個過時的代碼被稱為不推薦使用的代碼。在某些緊急情況下，不建議使用的代碼可能會被刪除，應該在未來的框架或庫版本從其代碼庫中刪除棄用的代碼之前立即轉換為替換代碼。

為了支持不推薦使用的代碼的文檔，Java包含@Deprecated註解，它會將一些構造函數、域、局部變數、方法、軟體包、模塊、參數或類型標記為已棄用。如果棄用的元素（構造函數，域，局部變數等）被使用了，則編譯器發出警告。例如，我們可以創建一個棄用的類並按如下所示使用它：

@Deprecatedpublic class Foo {}
Foo foo = new Foo();

如果我們編譯此代碼（在命名為Main.java的文件中），我們會收到以下警告：

$ javac Main.javaNote: Main.java uses or overrides a deprecated API.Note: Recompile with -Xlint:deprecation for details.

通常，每當使用@Deprecated註解的元素時，都會引發警告，除了用於以下五種情況：

  • 聲明本身就被聲明為是棄用的（即遞歸調用）。

  • 聲明被註解禁止棄用警告（即@SuppressWarnings(“deprecation”）註解，如上所述，應用於使用棄用元素的上下文。

  • 使用和聲明都在同一個最外面的類中（即，如果類調用其本身的棄用方法）。

  • 用在import聲明中，該聲明導入通常不贊成使用的類型或構件（即，在將已棄用的類導入另一個類時）。

  • exports或opens指令內。

正如前面所說的，在某些情況下，當不推薦使用的元素將被刪除，則調用代碼應立即刪除不推薦使用的元素（稱為terminally deprecated code）。在這種情況下，可以使用forRemoval參數提供的@Deprecated註解，如下所示：

@Deprecated(forRemoval = true)public class Foo {}

使用此最終棄用代碼會導致一系列更嚴格的警告：

$ javac Main.java
Main.java:7: warning: [removal] Foo in com.foo has been deprecated and marked for removal
                Foo foo = new Foo();
                ^
Main.java:7: warning: [removal] Foo in com.foo has been deprecated and marked for removal
                Foo foo = new Foo();
                              ^2 warnings

除了標準@Deprcated註解所描述的相同異常之外，總是會發出最終棄用的警告。我們還可以通過為註解提供since變數來添加文檔到@Deprecated註解中：

@Deprecated(since = "1.0.5", forRemoval = true)public class Foo {}

可以使用@deprecated JavaDoc元素（註意小寫字母d）進一步文檔化已棄用的元素，如以下代碼片段所示：

/**
 * Some test class.
 * 
 * @deprecated Replaced by {@link com.foo.NewerFoo}.
 * 
 * @author Justin Albano
 */@Deprecated(since = "1.0.5", forRemoval = true)public class Foo {}

JavaDoc工具將生成以下文檔：

 

有關@Deprecated註解的更多信息，請參閱@Deprecated文檔和《JLS》9.6.4.6章節。

結尾

自JDK 5引入註解以來，註解一直是Java不可缺少的一部分。雖然有些註解比其他註解更受歡迎，但本文中介紹的這5種註解是新手級別以上的開發人員都應該理解和掌握的：@Override，@FunctionalInterface，@SuppressWarnings，@SafeVarargs，和@Deprecated。雖然每種方法都有其獨特的用途，但所有這些註解使得Java應用程式更具可讀性，並允許編譯器對我們的代碼執行一些其他隱含的假設。隨著Java語言的不斷發展，這些經過實踐驗證的註解可能服務多年，幫助確保更多的應用程式按開發人員的意圖行事。

 


您的分享是我們最大的動力!

-Advertisement-
Play Games
更多相關文章
  • webmagic 基本的方法
    WebMagic的結構分為Downloader、PageProcessor、Scheduler、Pipeline四大組件，並由Spider將它們彼此組織起來。這四大組件對應爬蟲生命周期中的下載、處理、管理和持久化等功能 PageProcessor 需要自己寫 Scheduler 除非項目有一些特殊的 ...
  • TCP 詳解
    電腦網路中比較中要的無非就是 TCP/IP 協議棧，以及應用層的 HTTP 和 HTTPS 。 前幾天一直炒的的比較火的就是 HTTP/2.0 了，但是其實 HTTP/2.0 早在2015年的時候就已經出來了，並且這個版本是基於 Google 公司的 SPDY 協議發佈的，其實說白了就是用的 SP ...
  • Java併發系列[9]----ConcurrentHashMap源碼分析
    我們知道哈希表是一種非常高效的數據結構，設計優良的哈希函數可以使其上的增刪改查操作達到O(1)級別。Java為我們提供了一個現成的哈希結構，那就是HashMap類，在前面的文章中我曾經介紹過HashMap類，知道它的所有方法都未進行同步，因此在多線程環境中是不安全的。為此，Java為我們提供了另外一 ...
  • 白話python3、c語言和javascript的hello world表述（開篇版）
    有一句段子流傳很久。 我精通各種語言的hello world !。 因為比如python3、c語言和javascript與學習網路安全關係非常大，所以說，對這幾門語言的關註比較多。 但是，在kali上學習的時候有一些東西非常值得註意，否則非常的耽誤時間，因為在這上面白白浪費了幾個小時的代價，所以說， ...
  • 18.C++-[ ]操作符使用 、函數對象與普通函數區別(詳解)
    在上章17.C++-string字元串類(詳解)學習了string類,發現可以通過[ ]重載操作符來訪問每個字元。 比如: 接下來,我們來自己寫個[ ]重載操作符,來模擬string類 運行列印: 函數對象 函數對象是指該對象具備函數的行為 函數對象,是通過()調用操作符聲明得到的,然後便能通過函數 ...
  • thinkphp5 taglib自定義標簽教程
    學著寫了一下，終於搞定了，順便分享一下！taglib是tp框架自定義標簽功能，如果你用過cms，肯定見過類似： 或者： 這樣的操作，這對於開發工作是挺方便的，所以覺得有必要看下tp的taglib，教程如下：1 、在common（我是在common，你自己看，反正是用命名空間載入）里新建目錄tagli ...
  • CDN的作用與基本過程
    簡介 CDN，Content Distribute Network，可以直譯成內容分髮網絡，CDN解決的是如何將數據快速可靠從源站傳遞到用戶的問題。用戶獲取數據時，不需要直接從源站獲取，通過CDN對於數據的分發，用戶可以從一個較優的伺服器獲取數據，從而達到快速訪問，並減少源站負載壓力的目的。 動機 ...
  • python中強大優雅的列表推導表達式
    推導表達式其實就是簡化一些迴圈判斷操作等 生成一個數字1-10的列表，可以有多少種方法？ 現在看下推導表達式 有些人，可能會說，直接range( 1, 11 )就好了，多此一舉，如果我們要篩選出奇數? 當然，range依然能夠做到： 那，如果要得到偶數，需要遍歷每一項，判斷 他等價於如下的推導表達式 ...
一周排行
    -Advertisement-
    Play Games
  • 移動開發（一）：使用.NET MAUI開發第一個安卓APP
    移動開發（一）：使用.NET MAUI開發第一個安卓APP 對於工作多年的C#程式員來說，近來想嘗試開發一款安卓APP，考慮了很久最終選擇使用.NET MAUI這個微軟官方的框架來嘗試體驗開發安卓APP，畢竟是使用Visual Studio開發工具，使用起來也比較的順手，結合微軟官方的教程進行了安卓 ...
  • wpf ToggleButton選中效果和一個登錄界面
    前言 QuestPDF 是一個開源 .NET 庫，用於生成 PDF 文檔。使用了C# Fluent API方式可簡化開發、減少錯誤並提高工作效率。利用它可以輕鬆生成 PDF 報告、發票、導出文件等。 項目介紹 QuestPDF 是一個革命性的開源 .NET 庫，它徹底改變了我們生成 PDF 文檔的方 ...
  • 彈幕樹洞項目功能新增篇
    項目地址 項目後端地址： https://github.com/ZyPLJ/ZYTteeHole 項目前端頁面地址： ZyPLJ/TreeHoleVue (github.com) https://github.com/ZyPLJ/TreeHoleVue 目前項目測試訪問地址： http://tree ...
  • 第27篇 sqlserver2022詳細安裝步驟
    話不多說，直接開乾 一.下載 1.官方鏈接下載： https://www.microsoft.com/zh-cn/sql-server/sql-server-downloads 2.在下載目錄中找到下麵這個小的安裝包 SQL2022-SSEI-Dev.exe，運行開始下載SQL server； 二. ...
  • .NET 開源高性能 MQTT 類庫
    前言 隨著物聯網（IoT）技術的迅猛發展，MQTT（消息隊列遙測傳輸）協議憑藉其輕量級和高效性，已成為眾多物聯網應用的首選通信標準。 MQTTnet 作為一個高性能的 .NET 開源庫，為 .NET 平臺上的 MQTT 客戶端與伺服器開發提供了強大的支持。 本文將全面介紹 MQTTnet 的核心功能 ...
  • Serilog文檔翻譯系列（六） - 可用的接收器、增強器、格式化輸出
    Serilog支持多種接收器用於日誌存儲，增強器用於添加屬性，LogContext管理動態屬性，支持多種輸出格式包括純文本、JSON及ExpressionTemplate。還提供了自定義格式化選項，適用於不同需求。 ...
  • 警惕 Visual Studio 屬性求值副作用導致邏輯不符合預期
    目錄簡介獲取 HTML 文檔解析 HTML 文檔測試參考文章 簡介 動態內容網站使用 JavaScript 腳本動態檢索和渲染數據，爬取信息時需要模擬瀏覽器行為，否則獲取到的源碼基本是空的。 本文使用的爬取步驟如下： 使用 Selenium 獲取渲染後的 HTML 文檔 使用 HtmlAgility ...
  • [使用目前最新版]HybridCLR6.9.0+YooAsset2.2.4實現純C# Unity熱更新方案 (一)
    1.前言 什麼是熱更新 游戲或者軟體更新時，無需重新下載客戶端進行安裝，而是在應用程式啟動的情況下，在內部進行資源或者代碼更新 Unity目前常用熱更新解決方案 HybridCLR，Xlua，ILRuntime等 Unity目前常用資源管理解決方案 AssetBundles，Addressable， ...
  • 在 ASP.NET Core Web API 中使用操作篩選器統一處理通用操作
    本文章主要是在C# ASP.NET Core Web API框架實現向手機發送驗證碼簡訊功能。這裡我選擇是一個互億無線簡訊驗證碼平臺，其實像阿裡雲，騰訊雲上面也可以。 首先我們先去 互億無線 https://www.ihuyi.com/api/sms.html 去註冊一個賬號 註冊完成賬號後，它會送 ...
  • 第28篇 如何.net中實現高效可靠數據同步api
    通過以下方式可以高效，並保證數據同步的可靠性 1.API設計 使用RESTful設計，確保API端點明確，並使用適當的HTTP方法（如POST用於創建，PUT用於更新）。 設計清晰的請求和響應模型，以確保客戶端能夠理解預期格式。 2.數據驗證 在伺服器端進行嚴格的數據驗證，確保接收到的數據符合預期格 ...
所有分類