1.錯誤碼規范

之前版本中是沒有關于「錯誤碼」的整體說明的，而這個版本增加了很大的篇幅，來把這個前后端配合的重要環節「錯誤碼」部分，做了詳細的規范和說明，可謂非常的香，具體規范如下：

• 【強制】錯誤碼的制定原則：快速溯源、簡單易記、溝通標準化。
• 【強制】錯誤碼不體現版本號和錯誤等級信息。
• 【強制】全部正常，但不得不填充錯誤碼時返回五個零：00000。
• 【強制】錯誤碼為字符串類型，共 5 位，分成兩個部分：錯誤產生來源 + 四位數字編號。

說明：錯誤產生來源分為 A/B/C：

• A：表示錯誤來源于用戶，比如參數錯誤，用戶安裝版本過低，用戶支付超時等問題；
• B：表示錯誤來源于當前系統，往往是業務邏輯出錯，或程序健壯性差等問題；
• C：表示錯誤來源于第三方服務，比如 CDN 服務出錯，消息投遞超時等問題；四位數字編號從 0001 到 9999，大類之間的步長間距預留 100，詳情可見《Java開發手冊》正文。

2.擴充了日期處理方案

一個寫死為 365 天的年份天數，在閏年里讓大家嘗盡了悲傷痛楚，比如，緩存有效期 = 3652460*60 秒，結果提前一天所有緩存同時失效，高并發訪問時數據庫就跪了。

【強制】不要在程序中寫死一年為 365 天，避免在公歷閏年時出現日期轉換錯誤或程序邏輯錯誤。

正例：

// 獲取今年的天數
int daysOfThisYear = LocalDate.now().lengthOfYear();
// 獲取指定某年的天數
LocalDate.of(2011, 1, 1).lengthOfYear();

反例：

// 第一種情況：在閏年 366 天時，出現數組越界異常
int[] dayArray = new int[365];
// 第二種情況：一年有效期的會員制，今年 1 月 26 日注冊，硬編碼 365 返回的卻是 1 月 25 日
Calendar calendar = Calendar.getInstance();
calendar.set(2020, 1, 26);
calendar.add(Calendar.DATE, 365);

3.表別名規范

【強制】對于數據庫中表記錄的查詢和變更，只要涉及多個表，都需 表名）進行限定。說明：對多表進行查詢記錄、更新記錄、刪除記錄時，如果對操作列沒有限定表的別名（或表名），并且 操作列在多個表中存在時，就會拋異常。正例：select t1.name from table_first as t1 , table_second as t2 where t1.id=t2.id;

反例：在某業務中，由于多表關聯查詢語句沒有加表的別名（或表名）的限制，正常運行兩年后，最近在 某個表中增加一個同名字段，在預發布環境做數據庫變更后，線上查詢語句出現出 1052 異常：Column 'name' in field list is ambiguous。

【推薦】SQL 語句中表的別名前加 as，并且以 t1、t2、t3、...的順序依次命名。說明：

• 別名可以是表的簡稱，或者是根據表出現的順序，以 t1、t2、t3 的方式命名。
• 別名前加 as 使別名更容易識別。正例：select t1.name from table_first as t1, table_second as t2 where t1.id=t2.id;

4.三目運算符規范

原來在三目運算符中：

condition ? 表達式1 : 表達式2

表達式 1 和 2 在涉及算術計算或數據類型轉換時，會觸發自動拆箱。拆箱操作本來沒有問題，但是當其中的操作數為 null 值時，一個大大的 NPE（NullPointerException）就砸到了我滴臉上，如下代碼所示：

Integer a = 1;
Integer b = 2;
Integer c = null;
Boolean flag = false;
Integer result = (flag ?  a * b  :  c);

注意：a*b 的結果是 int 類型，那么 c 會強制拆箱成 int 類型，拋出 NPE 異常。

【強制】三目運算符 condition? 表達式 1 : 表達式 2 中，高度注意表達式 1 和 2 在類型對齊時，可能拋出因自動拆箱導致的 NPE 異常。

說明：以下兩種場景會觸發類型對齊的拆箱操作：

• 表達式 1 或表達式 2 的值只要有一個是原始類型。
• 表達式 1 或表達式 2 的值的類型不一致，會強制拆箱升級成表示范圍更大的那個類型。