MuleSoft審計挖出4層嵌套SSN

去年一次合規審計，技術團隊在API響應里發現了埋到第4層的社保號碼。遞歸函數一次掃清所有層級，但生產環境的null值讓400個請求直接崩掉。

這事發生在MuleSoft的DataWeave（數據編織）場景里。 org chart API返回的是典型樹狀結構：CEO帶VP，VP帶總監，總監再帶經理。SSN（社保號碼）可能出現在第1層、第3層，或者第6層——深度每家公司都不一樣。

遞歸函數的核心邏輯是類型分發：對象逐字段檢查，數組逐元素遞歸，字符串數字布爾值原樣放行。一個maskPII(payload)調用，理論上能吃掉任意深度。

類型匹配：DataWeave的"安檢門"

函數用match塊做類型判斷。遇到對象就mapObject遍歷鍵值，鍵名是"ssn"走脫敏邏輯，是"email"走郵箱遮蔽，其他鍵遞歸處理。遇到數組就map遍歷每個元素。剩下的基礎類型直接放行。

代碼看起來優雅。CEO的SSN變成***-**-6789，郵箱變成a****@acme.com，嵌套三層的Carol Nguyen同樣處理干凈。

但生產環境教做人。某個經理沒有郵箱字段，API返回了null。match塊把null分發到了Object分支——然后試圖對null執行mapObject。400個響應失敗。

null陷阱：類型系統的"灰色地帶"

DataWeave的match語法有個細節：case obj is Object會匹配任何對象，但null在類型系統里是個孤例。它既不是Object也不是Array，卻可能滑進Object的判斷邏輯，取決于運行時狀態。

修復方案是在match塊最前面加一行：case is Null -> null。顯式攔截null，讓它在觸碰Object處理器之前就被捕獲。

順序很關鍵。如果把null判斷放在Object之后，它永遠執行不到。類型匹配的優先級和書寫順序直接掛鉤，這是DataWeave文檔不會加粗提醒的坑。

作者Shakarbisetty現在的測試清單包括：空對象、空數組、null值、嵌套null、混合類型數組。DataWeave Playground里5分鐘搭好測試環境，這類遞歸bug再也沒漏過。

遞歸模式的隱藏成本

這個案例暴露的是函數式數據處理里的典型張力。遞歸抽象很干凈，但邊界條件得一個一個摳。類型系統幫你擋掉大部分錯誤，null卻像特洛伊木馬——合法存在，行為詭異。

GitHub上的mulesoft-cookbook倉庫收了100個帶MUnit測試的生產級模式。這個maskPII函數是第幾個？作者沒明說，但null處理那行注釋旁邊標了日期——比初始提交晚了三個月。

400次崩潰換一行代碼，這個ROI（投資回報率）怎么算？