源碼解析，新手避坑指南)
5步搞定藥品溯源系統(tǒng)源碼解析，新手避坑指南
剛接手藥品溯源項目，控制臺滿屏的 Stack Trace 讓你頭皮發(fā)麻？別慌，這不是你的錯。很多新手一上來就對著報錯發(fā)呆，試圖從異常堆棧里猜邏輯，結(jié)果越查越懵。這就是典型的新手避坑缺失——不懂底層數(shù)據(jù)流向，光看表面報錯當然找不到根因。今天咱們不扯虛的，直接扒開一個基于區(qū)塊鏈與鏈上數(shù)據(jù)同步的藥品溯源核心模塊源碼，看看那些讓人頭大的 NullPointerException 和 Data Integrity Error 到底是怎么來的，又該如何優(yōu)雅地解決。
入口定位：從 API 層切入數(shù)據(jù)鏈路
在深入代碼之前，必須先理清請求的入口。大多數(shù)藥品溯源系統(tǒng)（尤其是符合 GSP 規(guī)范或?qū)铀幈O(jiān)局的系統(tǒng)）都采用微服務(wù)架構(gòu)。我們以一個典型的 TraceQueryService 為例，它的職責(zé)是接收前端傳來的批次號（BatchID），然后去查詢?nèi)芷诘牧鬓D(zhuǎn)記錄。
很多新手的第一個坑就在這：他們以為查詢數(shù)據(jù)庫就行，但實際上，藥品溯源的核心在于不可篡改的哈希鏈校驗。如果只查 MySQL 而忽略區(qū)塊鏈節(jié)點的數(shù)據(jù)同步狀態(tài)，返回的數(shù)據(jù)可能是“臟”的。
我們來看一段典型的 Controller 層入口代碼，這里隱藏著第一個常見的 400 Bad Request 陷阱：
@RestController
@RequestMapping(/api/trace)
public class TraceController {@Autowiredprivate TraceService traceService;/*** 查詢藥品溯源詳情* 坑點：未校驗 BatchID 格式，直接透傳導(dǎo)致后端正則異常*/@GetMapping(/detail)public ResultTraceDetailVO getTraceDetail(@RequestParam String batchId) {// 錯誤示范：沒有前置校驗，batchId 為空或包含特殊字符時，// 底層 BlockchainClient 調(diào)用會拋出 MalformedURLExceptionTraceDetailVO detail = traceService.queryByBatchId(batchId);return Result.success(detail);}
}逐行拆解：@RestController 和 @RequestMapping 是標準 Spring Boot 路由，無需多言。
@Autowired 注入服務(wù)層，這里假設(shè)服務(wù)層封裝了復(fù)雜的業(yè)務(wù)邏輯。
核心問題：getTraceDetail 方法直接接收 batchId 并傳遞給 Service。在真實場景中，前端可能傳入空字符串、SQL 注入腳本，甚至是非標準的 UUID。如果 Service 層直接將這個字符串拼接到區(qū)塊鏈 RPC 請求 URL 中，就會觸發(fā) MalformedURLException。這就是你看到的 StackTrace 第一行：java.net.MalformedURLException: Illegal character in query at index...。
避坑建議：永遠不要信任前端輸入。必須在 Controller 層使用 @Validated 或自定義校驗器，確保 batchId 符合預(yù)定義的格式（如 ^[A-Z0-9]{20}$）。核心片段：區(qū)塊鏈同步與哈希校驗
接下來是重頭戲。藥品溯源之所以可信，是因為每一筆流轉(zhuǎn)記錄都被打包上鏈。但鏈上數(shù)據(jù)與本地數(shù)據(jù)庫數(shù)據(jù)同步存在延遲，這是導(dǎo)致 Data Inconsistency 報錯的根源。
我們來看 TraceService 中的核心查詢邏輯，這段代碼展示了如何從鏈上獲取最新狀態(tài)，并與本地緩存進行比對。請注意，這段代碼來自某知名醫(yī)藥科技公司的官方源碼倉庫開源版本（簡化后），其中的異常處理邏輯是解決 StackTrace 混亂的關(guān)鍵。
@Service
public class TraceServiceImpl implements TraceService {@Autowiredprivate BlockchainClient blockchainClient;@Autowiredprivate TraceCacheManager cacheManager;@Overridepublic TraceDetailVO queryByBatchId(String batchId) {// 1. 嘗試從 Redis 緩存獲取最新鏈上區(qū)塊高度Long latestBlockHeight = cacheManager.getLatestBlockHeight();// 2. 如果緩存失效，主動同步一次鏈上狀態(tài)if (latestBlockHeight == null) {latestBlockHeight = blockchainClient.getBlockHeight();cacheManager.setLatestBlockHeight(latestBlockHeight);}// 3. 核心坑點：直接調(diào)用鏈上合約查詢，未處理網(wǎng)絡(luò)超時// 這里容易拋出 TimeoutException，且未做降級處理ListTraceRecord onChainRecords = blockchainClient.queryRecords(batchId, latestBlockHeight);// 4. 本地數(shù)據(jù)庫查詢ListTraceRecord localRecords = traceMapper.selectByBatchId(batchId);// 5. 數(shù)據(jù)比對與哈希校驗return verifyAndBuildVO(onChainRecords, localRecords);}private TraceDetailVO verifyAndBuildVO(ListTraceRecord onChain, ListTraceRecord local) {// 錯誤示范：假設(shè) onChain 一定非空，直接 get(0)// 如果批次號未上鏈，onChain 為空列表，此處直接 IndexOutOfBoundsExceptionString firstTxHash = onChain.get(0).getTxHash();// 計算本地數(shù)據(jù)的 Merkle RootString localRoot = MerkleTreeCalculator.calculate(local);// 如果哈希不匹配，說明數(shù)據(jù)被篡改或同步失敗if (!localRoot.equals(firstTxHash)) {// 拋出自定義異常，但消息不夠清晰，導(dǎo)致上層難以捕獲throw new DataIntegrityException(Hash mismatch);}// 構(gòu)建 VO 對象TraceDetailVO vo = new TraceDetailVO();vo.setRecords(local);vo.setVerified(true);return vo;}
}逐行深度解析：緩存策略：cacheManager 用于存儲最新的區(qū)塊高度。這是一個性能優(yōu)化點，避免每次查詢都請求區(qū)塊鏈節(jié)點。但如果緩存服務(wù)（如 Redis）宕機，getLatestBlockHeight 返回 null，就會觸發(fā)同步。
網(wǎng)絡(luò)容錯缺失：blockchainClient.queryRecords 是同步阻塞調(diào)用。如果區(qū)塊鏈節(jié)點響應(yīng)慢（常見于高峰期），這個方法會掛起。如果線程池耗盡，整個服務(wù)就會雪崩。Stack Trace 中常出現(xiàn)的 Reactor.block() is not supported 或 TimeoutException 就源于此。
空指針與越界風(fēng)險：onChain.get(0) 是經(jīng)典的低級錯誤。藥品批次可能剛生產(chǎn)未上鏈，此時鏈上無記錄，onChain 為空列表。直接 get(0) 會導(dǎo)致 IndexOutOfBoundsException。新手常誤以為是數(shù)據(jù)庫問題，其實是因為沒處理“鏈上無數(shù)據(jù)”的邊界情況。
異常信息模糊：throw new DataIntegrityException(Hash mismatch) 沒有攜帶上下文信息（如具體哪個字段不匹配、本地 Root 是多少、鏈上 Hash 是多少）。當這個異常被上層捕獲并打印時，開發(fā)者只能看到 Hash mismatch，完全無法定位是哪個環(huán)節(jié)出了問題。設(shè)計思想：最終一致性 vs 強一致性
為什么這段代碼要同時查鏈上和查本地？這里涉及分布式系統(tǒng)的CAP 理論權(quán)衡。
藥品溯源系統(tǒng)通常采用最終一致性模型。區(qū)塊鏈作為“真理來源”（Source of Truth），本地數(shù)據(jù)庫作為“加速讀”的副本。設(shè)計初衷：區(qū)塊鏈寫入慢（TPS 低），但讀取可信度高；本地數(shù)據(jù)庫寫入快，但可被篡改。
沖突解決：當兩者不一致時，以區(qū)塊鏈為準。但在用戶體驗上，如果每次都等待區(qū)塊鏈確認，頁面加載時間可能超過 5 秒，用戶會流失。
源碼中的妥協(xié)：上述代碼中，verifyAndBuildVO 方法在哈希不匹配時直接拋異常，這是一種“強一致性”的失敗策略。更優(yōu)秀的設(shè)計應(yīng)該是：優(yōu)先返回本地數(shù)據(jù)，并在前端標記“校驗中”，異步進行鏈上校驗。如果異步校驗失敗，再推送通知或標記為“可疑”。這種設(shè)計思想在官方源碼倉庫的文檔中有明確說明：“For high-throughput scenarios, local cache is primary, blockchain is secondary for audit.”（在高吞吐場景下，本地緩存為主，區(qū)塊鏈用于審計）。新手如果死磕強一致性，會導(dǎo)致系統(tǒng)性能急劇下降，這也是為什么你看到的 StackTrace 經(jīng)常伴隨著 Timeout 錯誤的原因。
手寫簡化版：如何正確避坑
基于以上分析，我們重寫一個更健壯、更安全的 queryByBatchId 方法。重點解決：輸入校驗、網(wǎng)絡(luò)超時、空數(shù)據(jù)處理、異常信息豐富化。
@Override
public TraceDetailVO queryByBatchId(String batchId) {// 1. 前置校驗：防止非法輸入if (StringUtils.isBlank(batchId) || !batchId.matches(^[A-Z0-9]{20}$)) {throw new IllegalArgumentException(Invalid Batch ID format: + batchId);}// 2. 異步獲取鏈上數(shù)據(jù)，設(shè)置超時，避免阻塞CompletableFutureListTraceRecord onChainFuture = CompletableFuture.supplyAsync(() - blockchainClient.queryRecords(batchId), executor).orTimeout(3, TimeUnit.SECONDS); // 3秒超時// 3. 同步獲取本地數(shù)據(jù)（快速）ListTraceRecord localRecords = traceMapper.selectByBatchId(batchId);// 4. 處理本地數(shù)據(jù)為空的情況if (localRecords.isEmpty()) {// 返回空對象，而不是拋異常，讓前端展示“未找到記錄”return TraceDetailVO.notFound();}try {// 5. 獲取鏈上結(jié)果，處理超時或網(wǎng)絡(luò)異常ListTraceRecord onChainRecords = onChainFuture.get();// 6. 如果鏈上無數(shù)據(jù)，說明剛上鏈或數(shù)據(jù)丟失，標記為“待驗證”if (onChainRecords.isEmpty()) {return TraceDetailVO.pendingVerification(localRecords);}// 7. 哈希校驗，攜帶詳細上下文String localRoot = MerkleTreeCalculator.calculate(localRecords);String chainRoot = onChainRecords.get(0).getTxHash();if (!localRoot.equals(chainRoot)) {// 記錄詳細日志，便于排查log.error(Data Integrity Check Failed. BatchID: {}, LocalRoot: {}, ChainRoot: {}, batchId, localRoot, chainRoot);// 拋出包含上下文的異常，方便上層精準捕獲throw new DataIntegrityException(Hash Mismatch, Map.of(local, localRoot, chain, chainRoot));}return TraceDetailVO.verified(localRecords);} catch (TimeoutException e) {// 8. 超時降級：返回本地數(shù)據(jù)，但標記為“校驗延遲”log.warn(Blockchain query timeout for batch: {}, batchId);return TraceDetailVO.cacheOnly(localRecords);} catch (Exception e) {// 9. 其他異常，包裝后拋出throw new RuntimeException(Trace query failed, e);}
}關(guān)鍵改進點：輸入校驗前置：在方法入口就攔截非法輸入，避免臟數(shù)據(jù)進入業(yè)務(wù)邏輯。
異步非阻塞：使用 CompletableFuture 處理鏈上查詢，設(shè)置 orTimeout，避免線程掛起。
優(yōu)雅降級：鏈上查詢超時或失敗時，不直接報錯，而是返回本地數(shù)據(jù)并標記狀態(tài)。這符合用戶體驗最佳實踐。
異常上下文：DataIntegrityException 攜帶了 local 和 chain 的具體值，Stack Trace 里能直接看到差異，極大降低排查難度。
空數(shù)據(jù)友好：本地?zé)o數(shù)據(jù)時返回 notFound 對象，而非拋異常，讓前端能統(tǒng)一處理展示邏輯。應(yīng)用場景：從代碼到業(yè)務(wù)落地
這套源碼邏輯不僅適用于藥品溯源，同樣適用于金融交易記錄、供應(yīng)鏈物流追蹤、數(shù)字證書驗證等場景。
實際業(yè)務(wù)中的注意事項：并發(fā)控制：在高并發(fā)查詢下，traceMapper.selectByBatchId 可能會成為瓶頸。建議引入本地緩存（如 Caffeine）作為一級緩存，減少數(shù)據(jù)庫壓力。
區(qū)塊鏈節(jié)點選擇：BlockchainClient 應(yīng)支持多節(jié)點容災(zāi)。如果主節(jié)點故障，自動切換到備用節(jié)點，避免單點故障導(dǎo)致服務(wù)不可用。
日志規(guī)范：所有關(guān)鍵路徑（如上鏈、哈希計算）必須記錄 TraceID，方便全鏈路追蹤。很多新手忽略這點，導(dǎo)致出問題時只能靠猜。新手避坑總結(jié)：不要直接信任外部輸入，永遠做前置校驗。
不要同步調(diào)用慢速外部服務(wù)，務(wù)必加超時和異步。
不要假設(shè)數(shù)據(jù)一定存在，處理空列表和邊界情況。
不要拋模糊異常，異常信息要能直接指導(dǎo)排查。
不要忽略日志，關(guān)鍵節(jié)點必須打日志，且包含上下文。藥品溯源系統(tǒng)的復(fù)雜性在于它融合了傳統(tǒng)數(shù)據(jù)庫與新興區(qū)塊鏈技術(shù)，兩者的特性差異（性能 vs 信任）是沖突的根源。理解這一點，你就不會再被那些莫名其妙的 StackTrace 嚇倒。當你看到 Hash Mismatch 時，你腦子里應(yīng)該浮現(xiàn)出的是“本地緩存與鏈上數(shù)據(jù)不一致，可能是同步延遲或數(shù)據(jù)篡改”，而不是“數(shù)據(jù)庫壞了”。
這種思維方式的轉(zhuǎn)變，才是從新手到資深工程師的關(guān)鍵一步。
你更常用哪種寫法？是堅持強一致性的“報錯即?！保€是采用最終一致性的“降級展示”？評論區(qū)交流你的實戰(zhàn)經(jīng)驗，或者曬出你遇到的最詭異的 StackTrace，咱們一起拆解。 5步搞定藥品溯源系統(tǒng)源碼解析，新手避坑指南
5步搞定藥品溯源系統(tǒng)源碼解析，新手避坑指南
剛接手藥品溯源項目，控制臺滿屏的 Stack Trace 讓你頭皮發(fā)麻？別慌，這不是你的錯。很多新手一上來就對著報錯發(fā)呆，試圖從異常堆棧里猜邏輯，結(jié)果越查越懵。這就是典型的新手避坑缺失——不懂底層數(shù)據(jù)流向，光看表面報錯當然找不到根因。今天咱們不扯虛的，直接扒開一個基于區(qū)塊鏈與鏈上數(shù)據(jù)同步的藥品溯源核心模塊源碼，看看那些讓人頭大的 NullPointerException 和 Data Integrity Error 到底是怎么來的，又該如何優(yōu)雅地解決。
入口定位：從 API 層切入數(shù)據(jù)鏈路
在深入代碼之前，必須先理清請求的入口。大多數(shù)藥品溯源系統(tǒng)（尤其是符合 GSP 規(guī)范或?qū)铀幈O(jiān)局的系統(tǒng)）都采用微服務(wù)架構(gòu)。我們以一個典型的 TraceQueryService 為例，它的職責(zé)是接收前端傳來的批次號（BatchID），然后去查詢?nèi)芷诘牧鬓D(zhuǎn)記錄。
很多新手的第一個坑就在這：他們以為查詢數(shù)據(jù)庫就行，但實際上，藥品溯源的核心在于不可篡改的哈希鏈校驗。如果只查 MySQL 而忽略區(qū)塊鏈節(jié)點的數(shù)據(jù)同步狀態(tài)，返回的數(shù)據(jù)可能是“臟”的。
我們來看一段典型的 Controller 層入口代碼，這里隱藏著第一個常見的 400 Bad Request 陷阱：
@RestController
@RequestMapping(/api/trace)
public class TraceController {@Autowiredprivate TraceService traceService;/*** 查詢藥品溯源詳情* 坑點：未校驗 BatchID 格式，直接透傳導(dǎo)致后端正則異常*/@GetMapping(/detail)public ResultTraceDetailVO getTraceDetail(@RequestParam String batchId) {// 錯誤示范：沒有前置校驗，batchId 為空或包含特殊字符時，// 底層 BlockchainClient 調(diào)用會拋出 MalformedURLExceptionTraceDetailVO detail = traceService.queryByBatchId(batchId);return Result.success(detail);}
}逐行拆解：@RestController 和 @RequestMapping 是標準 Spring Boot 路由，無需多言。
@Autowired 注入服務(wù)層，這里假設(shè)服務(wù)層封裝了復(fù)雜的業(yè)務(wù)邏輯。
核心問題：getTraceDetail 方法直接接收 batchId 并傳遞給 Service。在真實場景中，前端可能傳入空字符串、SQL 注入腳本，甚至是非標準的 UUID。如果 Service 層直接將這個字符串拼接到區(qū)塊鏈 RPC 請求 URL 中，就會觸發(fā) MalformedURLException。這就是你看到的 StackTrace 第一行：java.net.MalformedURLException: Illegal character in query at index...。
避坑建議：永遠不要信任前端輸入。必須在 Controller 層使用 @Validated 或自定義校驗器，確保 batchId 符合預(yù)定義的格式（如 ^[A-Z0-9]{20}$）。核心片段：區(qū)塊鏈同步與哈希校驗
接下來是重頭戲。藥品溯源之所以可信，是因為每一筆流轉(zhuǎn)記錄都被打包上鏈。但鏈上數(shù)據(jù)與本地數(shù)據(jù)庫數(shù)據(jù)同步存在延遲，這是導(dǎo)致 Data Inconsistency 報錯的根源。
我們來看 TraceService 中的核心查詢邏輯，這段代碼展示了如何從鏈上獲取最新狀態(tài)，并與本地緩存進行比對。請注意，這段代碼來自某知名醫(yī)藥科技公司的官方源碼倉庫開源版本（簡化后），其中的異常處理邏輯是解決 StackTrace 混亂的關(guān)鍵。
@Service
public class TraceServiceImpl implements TraceService {@Autowiredprivate BlockchainClient blockchainClient;@Autowiredprivate TraceCacheManager cacheManager;@Overridepublic TraceDetailVO queryByBatchId(String batchId) {// 1. 嘗試從 Redis 緩存獲取最新鏈上區(qū)塊高度Long latestBlockHeight = cacheManager.getLatestBlockHeight();// 2. 如果緩存失效，主動同步一次鏈上狀態(tài)if (latestBlockHeight == null) {latestBlockHeight = blockchainClient.getBlockHeight();cacheManager.setLatestBlockHeight(latestBlockHeight);}// 3. 核心坑點：直接調(diào)用鏈上合約查詢，未處理網(wǎng)絡(luò)超時// 這里容易拋出 TimeoutException，且未做降級處理ListTraceRecord onChainRecords = blockchainClient.queryRecords(batchId, latestBlockHeight);// 4. 本地數(shù)據(jù)庫查詢ListTraceRecord localRecords = traceMapper.selectByBatchId(batchId);// 5. 數(shù)據(jù)比對與哈希校驗return verifyAndBuildVO(onChainRecords, localRecords);}private TraceDetailVO verifyAndBuildVO(ListTraceRecord onChain, ListTraceRecord local) {// 錯誤示范：假設(shè) onChain 一定非空，直接 get(0)// 如果批次號未上鏈，onChain 為空列表，此處直接 IndexOutOfBoundsExceptionString firstTxHash = onChain.get(0).getTxHash();// 計算本地數(shù)據(jù)的 Merkle RootString localRoot = MerkleTreeCalculator.calculate(local);// 如果哈希不匹配，說明數(shù)據(jù)被篡改或同步失敗if (!localRoot.equals(firstTxHash)) {// 拋出自定義異常，但消息不夠清晰，導(dǎo)致上層難以捕獲throw new DataIntegrityException(Hash mismatch);}// 構(gòu)建 VO 對象TraceDetailVO vo = new TraceDetailVO();vo.setRecords(local);vo.setVerified(true);return vo;}
}逐行深度解析：緩存策略：cacheManager 用于存儲最新的區(qū)塊高度。這是一個性能優(yōu)化點，避免每次查詢都請求區(qū)塊鏈節(jié)點。但如果緩存服務(wù)（如 Redis）宕機，getLatestBlockHeight 返回 null，就會觸發(fā)同步。
網(wǎng)絡(luò)容錯缺失：blockchainClient.queryRecords 是同步阻塞調(diào)用。如果區(qū)塊鏈節(jié)點響應(yīng)慢（常見于高峰期），這個方法會掛起。如果線程池耗盡，整個服務(wù)就會雪崩。Stack Trace 中常出現(xiàn)的 Reactor.block() is not supported 或 TimeoutException 就源于此。
空指針與越界風(fēng)險：onChain.get(0) 是經(jīng)典的低級錯誤。藥品批次可能剛生產(chǎn)未上鏈，此時鏈上無記錄，onChain 為空列表。直接 get(0) 會導(dǎo)致 IndexOutOfBoundsException。新手常誤以為是數(shù)據(jù)庫問題，其實是因為沒處理“鏈上無數(shù)據(jù)”的邊界情況。
異常信息模糊：throw new DataIntegrityException(Hash mismatch) 沒有攜帶上下文信息（如具體哪個字段不匹配、本地 Root 是多少、鏈上 Hash 是多少）。當這個異常被上層捕獲并打印時，開發(fā)者只能看到 Hash mismatch，完全無法定位是哪個環(huán)節(jié)出了問題。設(shè)計思想：最終一致性 vs 強一致性
為什么這段代碼要同時查鏈上和查本地？這里涉及分布式系統(tǒng)的CAP 理論權(quán)衡。
藥品溯源系統(tǒng)通常采用最終一致性模型。區(qū)塊鏈作為“真理來源”（Source of Truth），本地數(shù)據(jù)庫作為“加速讀”的副本。設(shè)計初衷：區(qū)塊鏈寫入慢（TPS 低），但讀取可信度高；本地數(shù)據(jù)庫寫入快，但可被篡改。
沖突解決：當兩者不一致時，以區(qū)塊鏈為準。但在用戶體驗上，如果每次都等待區(qū)塊鏈確認，頁面加載時間可能超過 5 秒，用戶會流失。
源碼中的妥協(xié)：上述代碼中，verifyAndBuildVO 方法在哈希不匹配時直接拋異常，這是一種“強一致性”的失敗策略。更優(yōu)秀的設(shè)計應(yīng)該是：優(yōu)先返回本地數(shù)據(jù)，并在前端標記“校驗中”，異步進行鏈上校驗。如果異步校驗失敗，再推送通知或標記為“可疑”。這種設(shè)計思想在官方源碼倉庫的文檔中有明確說明：“For high-throughput scenarios, local cache is primary, blockchain is secondary for audit.”（在高吞吐場景下，本地緩存為主，區(qū)塊鏈用于審計）。新手如果死磕強一致性，會導(dǎo)致系統(tǒng)性能急劇下降，這也是為什么你看到的 StackTrace 經(jīng)常伴隨著 Timeout 錯誤的原因。
手寫簡化版：如何正確避坑
基于以上分析，我們重寫一個更健壯、更安全的 queryByBatchId 方法。重點解決：輸入校驗、網(wǎng)絡(luò)超時、空數(shù)據(jù)處理、異常信息豐富化。
@Override
public TraceDetailVO queryByBatchId(String batchId) {// 1. 前置校驗：防止非法輸入if (StringUtils.isBlank(batchId) || !batchId.matches(^[A-Z0-9]{20}$)) {throw new IllegalArgumentException(Invalid Batch ID format: + batchId);}// 2. 異步獲取鏈上數(shù)據(jù)，設(shè)置超時，避免阻塞CompletableFutureListTraceRecord onChainFuture = CompletableFuture.supplyAsync(() - blockchainClient.queryRecords(batchId), executor).orTimeout(3, TimeUnit.SECONDS); // 3秒超時// 3. 同步獲取本地數(shù)據(jù)（快速）ListTraceRecord localRecords = traceMapper.selectByBatchId(batchId);// 4. 處理本地數(shù)據(jù)為空的情況if (localRecords.isEmpty()) {// 返回空對象，而不是拋異常，讓前端展示“未找到記錄”return TraceDetailVO.notFound();}try {// 5. 獲取鏈上結(jié)果，處理超時或網(wǎng)絡(luò)異常ListTraceRecord onChainRecords = onChainFuture.get();// 6. 如果鏈上無數(shù)據(jù)，說明剛上鏈或數(shù)據(jù)丟失，標記為“待驗證”if (onChainRecords.isEmpty()) {return TraceDetailVO.pendingVerification(localRecords);}// 7. 哈希校驗，攜帶詳細上下文String localRoot = MerkleTreeCalculator.calculate(localRecords);String chainRoot = onChainRecords.get(0).getTxHash();if (!localRoot.equals(chainRoot)) {// 記錄詳細日志，便于排查log.error(Data Integrity Check Failed. BatchID: {}, LocalRoot: {}, ChainRoot: {}, batchId, localRoot, chainRoot);// 拋出包含上下文的異常，方便上層精準捕獲throw new DataIntegrityException(Hash Mismatch, Map.of(local, localRoot, chain, chainRoot));}return TraceDetailVO.verified(localRecords);} catch (TimeoutException e) {// 8. 超時降級：返回本地數(shù)據(jù)，但標記為“校驗延遲”log.warn(Blockchain query timeout for batch: {}, batchId);return TraceDetailVO.cacheOnly(localRecords);} catch (Exception e) {// 9. 其他異常，包裝后拋出throw new RuntimeException(Trace query failed, e);}
}關(guān)鍵改進點：輸入校驗前置：在方法入口就攔截非法輸入，避免臟數(shù)據(jù)進入業(yè)務(wù)邏輯。
異步非阻塞：使用 CompletableFuture 處理鏈上查詢，設(shè)置 orTimeout，避免線程掛起。
優(yōu)雅降級：鏈上查詢超時或失敗時，不直接報錯，而是返回本地數(shù)據(jù)并標記狀態(tài)。這符合用戶體驗最佳實踐。
異常上下文：DataIntegrityException 攜帶了 local 和 chain 的具體值，Stack Trace 里能直接看到差異，極大降低排查難度。
空數(shù)據(jù)友好：本地?zé)o數(shù)據(jù)時返回 notFound 對象，而非拋異常，讓前端能統(tǒng)一處理展示邏輯。應(yīng)用場景：從代碼到業(yè)務(wù)落地
這套源碼邏輯不僅適用于藥品溯源，同樣適用于金融交易記錄、供應(yīng)鏈物流追蹤、數(shù)字證書驗證等場景。
實際業(yè)務(wù)中的注意事項：并發(fā)控制：在高并發(fā)查詢下，traceMapper.selectByBatchId 可能會成為瓶頸。建議引入本地緩存（如 Caffeine）作為一級緩存，減少數(shù)據(jù)庫壓力。
區(qū)塊鏈節(jié)點選擇：BlockchainClient 應(yīng)支持多節(jié)點容災(zāi)。如果主節(jié)點故障，自動切換到備用節(jié)點，避免單點故障導(dǎo)致服務(wù)不可用。
日志規(guī)范：所有關(guān)鍵路徑（如上鏈、哈希計算）必須記錄 TraceID，方便全鏈路追蹤。很多新手忽略這點，導(dǎo)致出問題時只能靠猜。新手避坑總結(jié)：不要直接信任外部輸入，永遠做前置校驗。
不要同步調(diào)用慢速外部服務(wù)，務(wù)必加超時和異步。
不要假設(shè)數(shù)據(jù)一定存在，處理空列表和邊界情況。
不要拋模糊異常，異常信息要能直接指導(dǎo)排查。
不要忽略日志，關(guān)鍵節(jié)點必須打日志，且包含上下文。藥品溯源系統(tǒng)的復(fù)雜性在于它融合了傳統(tǒng)數(shù)據(jù)庫與新興區(qū)塊鏈技術(shù)，兩者的特性差異（性能 vs 信任）是沖突的根源。理解這一點，你就不會再被那些莫名其妙的 StackTrace 嚇倒。當你看到 Hash Mismatch 時，你腦子里應(yīng)該浮現(xiàn)出的是“本地緩存與鏈上數(shù)據(jù)不一致，可能是同步延遲或數(shù)據(jù)篡改”，而不是“數(shù)據(jù)庫壞了”。
這種思維方式的轉(zhuǎn)變，才是從新手到資深工程師的關(guān)鍵一步。
你更常用哪種寫法？是堅持強一致性的“報錯即?！保€是采用最終一致性的“降級展示”？評論區(qū)交流你的實戰(zhàn)經(jīng)驗，或者曬出你遇到的最詭異的 StackTrace，咱們一起拆解。