在電商系統里，數據就像流淌的血液 —— 用戶填的手機號、下單的商品數量、支付的金額，每一個數字、每一段文字都得靠譜。要是數據出了錯，輕則訂單下不了，重則錢貨兩空。ZKmall 開源商城作為一個分布式電商系統，每天要處理成百上千的用戶輸入、第三方接口數據和服務間調用，怎么保證這些數據 "干干凈凈" 地流轉？他們用了 Jakarta Validation 這套規范，搭起了一道看不見的數據防線，既省了寫代碼的功夫，又讓系統少出亂子。

Jakarta Validation：讓校驗規則 "貼" 在數據上

以前寫數據校驗，程序員得寫一堆 if-else："用戶名不能為空"、"密碼長度得在 6 到 20 位之間"、"手機號格式不對"…… 這些代碼混在業務邏輯里，看起來就像一鍋大雜燴。后來出了 Jakarta Validation（以前叫 Java EE Validation），這事兒就簡單了 —— 用注解把校驗規則直接 "貼" 在數據上，代碼一下子清爽多了。

這套規范最妙的是解耦。比如用戶注冊時要填用戶名，以前得寫if (username == null || username.trim().isEmpty()) \{ ... \}，現在只要在字段上標個@NotBlank(message = "用戶名不能為空")，校驗邏輯和業務代碼徹底分開。新來的開發者一看注解就知道這個字段有啥要求，不用在一堆代碼里扒邏輯。

復用性也特別好。手機號格式校驗這事兒，用戶注冊、改綁手機、下單填收貨信息時都得用。按以前的做法，可能在三個地方各寫一遍正則判斷，改個規則得改三處。現在把@Pattern(regexp = "^1[3-9]\\\\d\{9\}$")定義在手機號字段上，哪兒用這個字段，哪兒就自動生效，改規則也只改一處。

還有錯誤信息處理，也不用手動攢了。校驗失敗時，系統會自動收集所有問題，比如 "用戶名不能為空"、"手機號格式不對"，直接轉成用戶能看懂的提示。有次運營說用戶反饋報錯信息太亂，技術團隊用這套規范統一了格式，用戶投訴一下子少了一半。

ZKmall 選了 3.0 版本，主要是因為它跟 Spring Boot 3 能無縫銜接，還支持 Java 8 以后的新特性。比如處理 Optional 類型的數據時，注解能自動識別里面的值，不用額外寫代碼判斷是否為空。

注解在手，常見校驗不用愁

Jakarta Validation 帶了一堆現成的注解，像工具箱里的扳手螺絲刀，對付日常校驗綽綽有余。ZKmall 把它們分了四類，用到的時候信手拈來。

基礎約束注解管的是 "有沒有" 的問題。@NotNull說的是這個字段不能是 null，比如訂單里的用戶 ID，沒它根本不知道給誰發貨；@NotBlank專門盯字符串，不光不能是 null，還不能全是空格，像收貨地址填一堆空格肯定不行；@NotEmpty是給集合用的，購物車提交時至少得有一件商品吧？這三個注解組合起來，就能把必填項管得明明白白。

數值約束注解專盯數字。@Positive保證是正數，商品單價總不能是負數；@Min和@Max劃定范圍，比如限購商品每人最多買 100 件；@DecimalMin和@DecimalMax對付高精度的價格計算，避免用 float、double 時出現 "0.01+0.02=0.0300000004" 這種坑。有次財務對賬發現幾分錢的差異，就是因為沒用好這些注解，后來全換成 BigDecimal 加注解校驗，再也沒出過岔子。

字符串約束注解處理文字格式。@Email能自動識別郵箱，哪怕用戶寫成 "USER@EXAMPLE.COM" 也能過，不用自己寫復雜的正則；@Size管長度，密碼太短不安全，太長記不住，設個 6 到 20 位就挺合適；@Pattern最靈活，啥特殊格式都能用正則搞定，比如身份證號、銀行卡號這些有固定規則的。

集合約束注解里，@Valid是個狠角色，能讓校驗 "鉆" 到對象里面去。比如一個訂單里有多個訂單項，給集合標個@Valid，系統就會挨個檢查每個訂單項的商品 ID、數量對不對，不用手動循環校驗。有個新人不知道這個注解，自己寫了個 for 循環遍歷訂單項，結果漏了空指針判斷，上線后出了 bug，后來全換成@Valid，省心多了。

在 Spring Boot 里用這些注解也簡單，Controller 的參數前加個@Validated，系統就會自動觸發校驗。失敗了會拋異常，全局異常處理器接住后，轉成統一的錯誤格式返回給前端，用戶能清楚地看到哪個字段出了問題。

自定義校驗：把業務規則變成 "注解"

現成的注解雖然好用，但電商業務總有特殊要求。比如密碼得同時有字母和數字，促銷活動的結束時間不能比開始時間早，這些規則用內置注解搞不定，就得自己造注解

ZKmall 里有個@PasswordStrength注解，專門管密碼強度。實現這東西分三步：先定義個注解，指定它能標在哪些地方，用哪個類來校驗；然后寫個校驗器，里面放具體的判斷邏輯 —— 長度夠不夠 8 到 20 位，有沒有字母，有沒有數字；最后在密碼字段上標一下這個注解，齊活。

有次安全審計說密碼太簡單，容易被破解，安全團隊提了新要求：得包含大小寫字母、數字和特殊符號。開發們沒改多少代碼，就在校驗器里加了幾行判斷，新規則第二天就上線了，要是換以前改一堆 if-else，沒三天搞不完。

更復雜點的跨字段校驗也能搞定。比如促銷活動 DTO 里的startTime和endTime，得保證結束時間在后頭。這種時候，校驗器可以拿到整個對象，對比兩個字段的值。ZKmall 的做法是自定義一個@ValidEndTime注解，校驗器里通過反射拿到startTime，再跟endTime比較，只要endTime不在startTime之后，就報錯。

他們還把常用的自定義校驗打包成了一個模塊，里面有身份證號、銀行卡號、商品編碼這些電商特有的校驗規則。各業務團隊要用的時候，直接引入依賴，標個注解就行，不用重復造輪子。有個做生鮮業務的團隊，要校驗 "配送時間必須在商品保質期內"，就是在這個模塊基礎上擴展的，一周就搞定了。

分組校驗：不同場景，不同規矩

同一個數據在不同場景下，規矩可能不一樣。比如商品 ID，創建商品的時候不能填（系統自動生成），更新的時候必須填；用戶昵稱，注冊時可以不填（用手機號代替），但第一次修改資料時必須填。這種情況，分組校驗就能派上用場。

做法是先定義幾個空接口當 "分組標識"，比如CreateGroup、UpdateGroup，然后在注解里指定這個規則屬于哪個組。創建商品時，id字段標@Null(groups = CreateGroup.class)；更新時，標@NotNull(groups = UpdateGroup.class)。Controller 方法里用@Validated(CreateGroup.class)指定用哪個組的規則，系統就只會按這個組的規則來校驗。

分組還能繼承，比如AdminCreateGroup繼承CreateGroup，這樣管理員創建商品時，既會校驗普通用戶創建時的規則（如商品名稱不能為空），還會額外校驗只有管理員才需要的規則（如審核狀態）。有個運營團隊想搞個 "內部商品"，不需要填那么多字段，技術團隊就新建了個InternalGroup，復用了大部分規則，只改了幾個字段的校驗要求，三天就上線了。

訂單系統里這招用得最多。普通訂單要校驗收貨地址，自提訂單就不用；用優惠券的訂單要校驗優惠券是否有效，不用優惠券的就跳過。以前為每種訂單搞一套 DTO，代碼冗余得不行，現在用分組校驗，一個 DTO 就能應對多種場景，維護起來方便多了。

性能優化：校驗也得 "輕裝上陣"

數據校驗雖然重要，但太耗時也不行。特別是大促的時候，每秒幾萬次請求，每次校驗都慢吞吞的，系統肯定扛不住。ZKmall 琢磨了不少辦法，讓校驗又快又準。

少校驗是最直接的。查詢接口一般只需要校驗頁碼、每頁條數這些簡單參數，不用把整個復雜對象從頭到尾查一遍；內部服務調用時，如果上游已經校驗過了，下游就可以跳過，省點力氣。比如商品服務傳給訂單服務的商品信息，商品服務已經確認過價格、庫存沒問題了，訂單服務就不用再校驗一遍， trust but verify 在這里不太適用，效率更重要。

校驗邏輯要輕。自定義校驗器里千萬別搞復雜操作，像查數據庫、調接口這種事兒，絕對不能放進去。有個開發者圖省事，在校驗器里查了下商品庫存，結果大促時庫存服務一卡，校驗也跟著卡，整個下單流程都慢了。后來把庫存校驗挪到了業務邏輯層，校驗器只負責格式，速度一下子提上來了。

批量處理比逐條校驗快。批量導入商品的時候，要是一條一條校驗，1000 條數據得循環 1000 次，改成一次性把所有數據扔給校驗器，性能能提升一半以上。ZKmall 的商品批量導入功能，就因為改了這個，從每次最多導 500 條，變成能導 2000 條，運營們高興壞了。

還有些小技巧也挺管用。比如@NotBlank已經包含了非 null 的判斷，就別再畫蛇添足加個@NotNull；錯誤消息別用技術術語，用戶看不懂 "Pattern 約束違例"，換成 "手機號格式不對" 就明白多了；校驗和業務邏輯要分清，"數量必須為正數" 是校驗，"庫存不夠" 是業務邏輯，別混在一起。

他們還給所有校驗規則寫了單元測試，特別是自定義的那些。比如測試密碼校驗時，空字符串、純字母、純數字、符合要求的情況都測一遍，上線前跑一遍，心里踏實。有次一個新注解沒測全，漏了對 null 值的處理，結果線上報錯，后來測試覆蓋率提到 100%，這種問題就再也沒出過。

數據校驗：電商系統的 "第一道防線"

用了 Jakarta Validation 之后，ZKmall 的變化挺明顯：手動寫的校驗代碼少了七成，開發者不用再跟 if-else 較勁，能專心琢磨業務；數據相關的線上故障降了一半多，以前總有人因為填錯格式、漏填字段投訴，現在系統提前就攔住了；新功能開發速度快了三成，加個校驗規則只要加個注解，不用改一大片代碼。

隨著系統往微服務方向發展，他們還把校驗規則放進了 API 契約里，服務之間調用的時候，網關會先按契約校驗一遍，省得無效請求跑到服務里去。有次支付服務升級，不小心改了參數格式，網關的校驗立馬報錯，開發們及時回滾，沒影響到用戶。

說到底，電商系統里的數據就像積木，一塊錯了，搭起來的房子可能就塌了。Jakarta Validation 這套規范，就像個細心的質檢員，把不合格的積木早早挑出來，讓整個系統能穩穩當當地跑。對于其他電商項目來說，這套思路也挺值得借鑒 —— 用規范的力量簡化校驗，既省心又靠譜，何樂而不為呢？