1. 凌晨?jī)牲c(diǎn)半我被一條999999999999999驚醒半夜兩點(diǎn)四十七分告警電話打過來的時(shí)候我正睡得不深。監(jiān)控平臺(tái)顯示支付回調(diào)接口的成功率從99.98%一路掉到92.7%失敗請(qǐng)求不報(bào)超時(shí)、不報(bào)空指針而是齊刷刷地卡在一個(gè)奇怪的地方order_no 999999999999999。剛開始我以為是日志框架把變量打丟了或者同事調(diào)試時(shí)隨手打印了一堆9。等我把這條訂單號(hào)拿去生產(chǎn)庫(kù)一查后背直接發(fā)涼——它真的在表里而且不止一條。更詭異的不是這條數(shù)據(jù)本身而是它引發(fā)的連鎖反應(yīng)。這張訂單表有三千多萬行正常情況下按主鍵查一條數(shù)據(jù)毫秒級(jí)返回?？上掠螌?duì)賬系統(tǒng)拿到order_no999999999999999之后把它判成了異常單據(jù)需要人工復(fù)核然后走了一條幾乎沒人維護(hù)的審批分支。一個(gè)晚上下來消息隊(duì)列里積壓了十幾萬條待復(fù)核消息消費(fèi)組不斷重試重試又不斷失敗最后把下游幾個(gè)核心服務(wù)的線程池全部拖滿。那會(huì)兒我腦子里只有一個(gè)念頭這串9到底是誰寫進(jìn)來的。事后復(fù)盤我發(fā)現(xiàn)這串?dāng)?shù)字的來歷一點(diǎn)都不玄乎甚至有點(diǎn)諷刺——它是被人當(dāng)成邊界值寫進(jìn)去的。很多人覺得999999999999999只是測(cè)試環(huán)境隨手敲的占位符不可能跑到生產(chǎn)環(huán)境。但現(xiàn)實(shí)是它不單能跑進(jìn)來還能順著一條條鏈路把訂單、對(duì)賬、支付、短信全禍害一遍。這篇就專門聊聊一長(zhǎng)串9在真實(shí)系統(tǒng)里是怎么混進(jìn)來的、會(huì)造成哪些讓你意想不到的后果以及我在排查和修復(fù)過程中總結(jié)出來的方法和教訓(xùn)。2. 這串9的真實(shí)身份從測(cè)試腳本到生產(chǎn)庫(kù)的幾種常見來路2.1 測(cè)試環(huán)境里偷工減料的造數(shù)習(xí)慣先說最常見的來路——測(cè)試環(huán)境造數(shù)。自動(dòng)化腳本跑接口經(jīng)常需要構(gòu)造一個(gè)非空且看起來像訂單號(hào)的字段。很多測(cè)試同學(xué)圖省事直接寫order_no 9 * 15或者干脆在參數(shù)文件里填999999999999999。這種數(shù)據(jù)在測(cè)試環(huán)境里跑一千遍都不會(huì)出問題因?yàn)闇y(cè)試環(huán)境的校驗(yàn)邏輯和生產(chǎn)是一樣的都是只要不是空、只要是數(shù)字就放行。問題出在數(shù)據(jù)同步和腳本復(fù)用上。不少公司為了調(diào)試方便會(huì)把測(cè)試庫(kù)的數(shù)據(jù)定期同步到預(yù)發(fā)環(huán)境或者讓測(cè)試腳本直接連看起來像測(cè)試環(huán)境的庫(kù)。一旦這串9被同步過去它就不再是測(cè)試數(shù)據(jù)而是生產(chǎn)數(shù)據(jù)了。我見過最離譜的一次是同事把造數(shù)腳本里的庫(kù)連接配置從測(cè)試庫(kù)改成了生產(chǎn)庫(kù)因?yàn)樗敝?yàn)證一個(gè)接口忘了改回來。一條999999999999999的訂單就這樣誕生了。2.2 接口文檔里的示例值被直接復(fù)制第二種來路比測(cè)試數(shù)據(jù)更隱蔽也更常見——接口文檔。很多外部對(duì)接文檔里為了演示最大值或者無限制的場(chǎng)景會(huì)拿999999999999999當(dāng)示例值。寫文檔的人本意是告訴下游這個(gè)字段允許很大的數(shù)可對(duì)接的研發(fā)往往沒看字段說明直接復(fù)制示例值就當(dāng)真實(shí)入?yún)⒂昧?。我之前排查過一次故障上游調(diào)用我們系統(tǒng)時(shí)傳的客戶號(hào)全是999999999999999。追了半天發(fā)現(xiàn)上游開發(fā)是從對(duì)接文檔的請(qǐng)求示例里復(fù)制的。文檔里寫的注釋是客戶號(hào)最長(zhǎng)15位數(shù)字示例值為999999999999999他理解成了這個(gè)接口的客戶號(hào)就該傳這個(gè)值。從那以后我在評(píng)審接口文檔時(shí)都會(huì)加一條要求示例值必須用一個(gè)明顯不真實(shí)但業(yè)務(wù)上合法的假數(shù)據(jù)比如210000198801010011而不是一長(zhǎng)串整齊的9。2.3 兜底邏輯里隱晦的默認(rèn)值第三種來路是代碼層面的坑而且是最難查的一種兜底邏輯把異常值寫成了默認(rèn)值。很多團(tuán)隊(duì)在實(shí)現(xiàn)RPC調(diào)用時(shí)喜歡給返回值一個(gè)兜底比如超時(shí)或異常時(shí)返回-1或0。但有些系統(tǒng)不走尋常路為了跟正常的負(fù)數(shù)或0區(qū)分開用了999999999999999來表示調(diào)用失敗。這個(gè)設(shè)計(jì)在單系統(tǒng)里跑沒什么問題問題出在跨團(tuán)隊(duì)協(xié)作。下游系統(tǒng)只看到這個(gè)字段返回了一個(gè)巨大但合法的數(shù)字壓根不知道它其實(shí)是失敗的暗號(hào)。于是下游把它當(dāng)成真實(shí)客戶號(hào)去查庫(kù)、去關(guān)聯(lián)、去入賬一條鏈路上的每個(gè)系統(tǒng)都在按規(guī)矩辦事合在一起就變成了災(zāi)難。這類默認(rèn)值往往藏在框架代碼或者公共SDK里排查起來非常費(fèi)勁因?yàn)樗鼪]有任何日志提示表面上一切都正常。2.4 用戶輸入與導(dǎo)入文件的漏網(wǎng)之魚最后一種來路是用戶自己輸入的或者從Excel導(dǎo)入的。別覺得用戶不會(huì)輸一長(zhǎng)串9你會(huì)發(fā)現(xiàn)總有人為了測(cè)試你的校驗(yàn)邏輯故意輸入最大位數(shù)的9也總有人從別處復(fù)制一段數(shù)據(jù)里面剛好帶著一串占位用的9。前端如果只控制了輸入框的長(zhǎng)度沒控制內(nèi)容和業(yè)務(wù)語義后端的正則如果只寫了^\d$那15個(gè)9就是完全合法的數(shù)字串。Excel導(dǎo)入的情況更經(jīng)典。用戶在表格里填了999999999999999Excel顯示成科學(xué)計(jì)數(shù)法導(dǎo)入程序如果解析時(shí)沒處理好可能拿到的是999999999999999也可能是被截?cái)嗟?9999999999999。不管是哪種它都堂而皇之地進(jìn)了庫(kù)。我后來在導(dǎo)入程序里加了一條硬規(guī)則凡是手機(jī)號(hào)、身份證號(hào)、訂單號(hào)這類有明確格式的字段除了要校驗(yàn)數(shù)字格式還必須校驗(yàn)位數(shù)和業(yè)務(wù)前綴。來路典型特征為什么能混過校驗(yàn)測(cè)試造數(shù)腳本里硬編碼一串9只校驗(yàn)非空不校驗(yàn)真實(shí)性文檔示例和下游對(duì)接文檔中的示例一致開發(fā)復(fù)制示例值未讀注釋兜底默認(rèn)值公共SDK/框架代碼中返回對(duì)下游來說值合法但語義異常用戶輸入/導(dǎo)入Excel科學(xué)計(jì)數(shù)法或手輸正則只判斷是否為數(shù)字不判斷位數(shù)這四種來路沒有一種是靠高深黑客技術(shù)進(jìn)來的全是普通工程習(xí)慣埋下的雷。3. 一串9如何讓整個(gè)業(yè)務(wù)鏈路集體翻車3.1 精度與類型15位9的臨界點(diǎn)效應(yīng)在討論危害之前先糾正一個(gè)常見誤解999999999999999本身恰好是15位而JavaScript的Number.MAX_SAFE_INTEGER是9007199254740991所以這串9在JS里其實(shí)能被精確表示單看這一個(gè)數(shù)并不會(huì)因?yàn)榫葐栴}直接爆掉。但問題恰恰出在恰好這兩個(gè)字上。你永遠(yuǎn)無法保證生產(chǎn)環(huán)境里出現(xiàn)的都是干凈的15位9。系統(tǒng)里可能同時(shí)存在16個(gè)9、17個(gè)9甚至在某個(gè)極端情況下一個(gè)字段被填成了Long.MAX_VALUE。JS超過9007199254740991之后整數(shù)精度就開始不可靠了而Java的Integer.parseInt在遇到2147483647以上的數(shù)字時(shí)直接拋異常。我見過一個(gè)真實(shí)案例上游把訂單號(hào)用Long傳給前端前端用JS的Number去接收然后作為參數(shù)回傳后端再轉(zhuǎn)成String一頓操作下來原本19位的訂單號(hào)已經(jīng)面目全非。像999999999999999這種整齊劃一的數(shù)字往往就是這條精度鏈路上第一個(gè)被反復(fù)測(cè)試、反復(fù)拷貝的探路石。3.2 數(shù)據(jù)庫(kù)里的隱式轉(zhuǎn)換與偽熱點(diǎn)數(shù)據(jù)庫(kù)側(cè)的問題同樣不容忽視。如果表里的訂單號(hào)字段是varchar而查詢代碼里寫的是where order_no 999999999999999MySQL會(huì)把字符串列隱式轉(zhuǎn)換成數(shù)值再比較。一旦列里存在非數(shù)字的值轉(zhuǎn)換規(guī)則會(huì)變得非常詭異更重要的是這種比較方式會(huì)直接讓該字段的索引失效。一個(gè)本該走索引的查詢突然變成全表掃描量大的時(shí)候?qū)?shù)據(jù)庫(kù)來說就是一場(chǎng)災(zāi)難。還有一種情況是字段本身被定義成了bigint999999999999999存進(jìn)去沒任何報(bào)錯(cuò)但它會(huì)成為一個(gè)偽熱點(diǎn)。所有異常數(shù)據(jù)、所有兜底路徑都指向同一個(gè)巨大數(shù)值數(shù)據(jù)庫(kù)里這一行的訪問頻率遠(yuǎn)高于其他正常數(shù)據(jù)行鎖競(jìng)爭(zhēng)、緩存失效、排序錯(cuò)亂接踵而來。我們當(dāng)時(shí)那個(gè)事故里對(duì)賬系統(tǒng)正好用這個(gè)訂單號(hào)做分組統(tǒng)計(jì)結(jié)果所有異常記錄擠在同一組里報(bào)表直接被撐爆。3.3 業(yè)務(wù)狀態(tài)機(jī)異常值被當(dāng)成真單據(jù)相比技術(shù)和數(shù)據(jù)庫(kù)層面的問題更讓人頭疼的是業(yè)務(wù)語義被污染。真實(shí)業(yè)務(wù)系統(tǒng)里訂單號(hào)、用戶ID、流水號(hào)都是有業(yè)務(wù)含義的比如帶時(shí)間、帶機(jī)房、帶校驗(yàn)位。而999999999999999不具備任何業(yè)務(wù)含義但它一旦進(jìn)入系統(tǒng)就會(huì)像一個(gè)身份不明但證件齊全的人走到哪都能通過基礎(chǔ)校驗(yàn)然后在業(yè)務(wù)狀態(tài)機(jī)里亂串。我復(fù)盤那次事故時(shí)發(fā)現(xiàn)真正的轉(zhuǎn)折點(diǎn)是定時(shí)任務(wù)。任務(wù)設(shè)計(jì)者為了避免重復(fù)處理用處理時(shí)間大于某閾值來判斷是否該執(zhí)行。碰巧有任務(wù)為了做時(shí)間判斷會(huì)從單據(jù)號(hào)里截取一段當(dāng)作時(shí)間戳來用而999...這段截出來的數(shù)字遠(yuǎn)大于真實(shí)時(shí)間任務(wù)邏輯認(rèn)為這條記錄還沒到處理時(shí)間于是一遍又一遍地跳過。其他正常數(shù)據(jù)排隊(duì)等著處理這串9永遠(yuǎn)插在前面擋路積壓就從這里開始。這種問題寫代碼時(shí)根本想不到但一旦發(fā)生了排查方向會(huì)非常隱蔽。3.4 安全視角可預(yù)測(cè)的數(shù)字等于半開的后門最后聊一個(gè)容易被忽視的角度——安全。唯一標(biāo)識(shí)符的核心要求是不可預(yù)測(cè)性。如果系統(tǒng)里真實(shí)存在999999999999999這種整齊劃一的標(biāo)識(shí)相當(dāng)于告訴攻擊者這個(gè)系統(tǒng)的ID生成邏輯毫無隨機(jī)性甚至可能是固定值、順序值。配合一個(gè)沒做越權(quán)校驗(yàn)的查詢接口攻擊者不需要猜只需要把參數(shù)改成999999999999999就能訪問到這條特殊數(shù)據(jù)萬一它恰好是管理員賬號(hào)或內(nèi)部單據(jù)問題就大了。即便沒有這么嚴(yán)重一串連續(xù)9也會(huì)污染統(tǒng)計(jì)口徑和風(fēng)控模型。風(fēng)控系統(tǒng)會(huì)學(xué)習(xí)正常用戶的行為分布一個(gè)突然出現(xiàn)的極端值會(huì)把平均值拉偏后續(xù)所有的異常檢測(cè)閾值都跟著失真。所以我說它是個(gè)半開的后門不是說它能直接拿權(quán)限而是它在層層系統(tǒng)里制造了一個(gè)又一個(gè)特例每個(gè)特例都是一次風(fēng)險(xiǎn)敞口。4. 面對(duì)滿屏9該怎么查、怎么修、以后怎么防4.1 從日志到數(shù)據(jù)源的完整排查鏈路如果你也遇到了類似情況先別急著刪數(shù)據(jù)更別急著改代碼。我的排查順序是這樣的從告警和日志里拿到發(fā)生異常的requestId和traceId把一條完整的調(diào)用鏈拉出來。定位第一個(gè)出現(xiàn)999999999999999的服務(wù)節(jié)點(diǎn)看它是作為入?yún)⑦M(jìn)來的還是作為返回值生成的。如果是入?yún)⑼嫌握掖_認(rèn)是誰傳的如果是返回值檢查代碼里的兜底邏輯和默認(rèn)值定義。拿到數(shù)據(jù)后去生產(chǎn)庫(kù)做一次影響面掃描統(tǒng)計(jì)這個(gè)值在哪些表、哪些字段里出現(xiàn)過關(guān)聯(lián)了多少業(yè)務(wù)記錄。翻時(shí)間線確認(rèn)第一批臟數(shù)據(jù)是哪個(gè)時(shí)間點(diǎn)出現(xiàn)的跟發(fā)布單、數(shù)據(jù)同步任務(wù)、腳本執(zhí)行記錄做比對(duì)基本就能鎖定來源。這套鏈路看起來簡(jiǎn)單但真正執(zhí)行時(shí)最容易被卡住的是第二步。很多團(tuán)隊(duì)沒有全鏈路追蹤日志里只有零散的片段根本不知道這串9是哪個(gè)服務(wù)塞進(jìn)來的。所以平時(shí)把traceId打全、把關(guān)鍵入?yún)⒋蛉⒉皇强捎锌蔁o的要求真出事故時(shí)它就是救命的線索。4.2 修復(fù)三步走摘除、補(bǔ)償、固化定位到來源之后修復(fù)動(dòng)作我建議分三步走不要一上來就UPDATE。第一步是摘除把臟數(shù)據(jù)從正常業(yè)務(wù)流程里摘出去?？梢韵韧ㄟ^配置中心下發(fā)一個(gè)黑名單讓對(duì)賬、統(tǒng)計(jì)、定時(shí)任務(wù)在遇到999999999999999時(shí)直接跳過先恢復(fù)核心鏈路。第二步是補(bǔ)償確認(rèn)這些臟數(shù)據(jù)是否有對(duì)應(yīng)的真實(shí)業(yè)務(wù)。如果是測(cè)試數(shù)據(jù)按公司數(shù)據(jù)規(guī)范做歸檔或清理如果是兜底值誤入需要追溯這段時(shí)間內(nèi)受影響的下游單據(jù)逐一核對(duì)是否需要補(bǔ)單。第三步是固化把這次踩坑變成代碼和配置層面的約束。比如在配置中心增加一個(gè)保留值名單凡是在名單里的值任何接口都不允許作為業(yè)務(wù)單據(jù)入庫(kù)。這一步里最容易犯的錯(cuò)是直接DELETE。生產(chǎn)庫(kù)里的數(shù)據(jù)哪怕看起來是垃圾也可能已經(jīng)被別的系統(tǒng)引用、歸檔甚至報(bào)送了。你先刪掉后面對(duì)賬對(duì)不上神仙也救不了。所以優(yōu)先摘除補(bǔ)償最后才考慮清理。4.3 源頭治理從參數(shù)校驗(yàn)到環(huán)境隔離修復(fù)只能救急真正的解決方案在源頭。我在事后總結(jié)時(shí)把源頭治理拆成了四個(gè)層面參數(shù)校驗(yàn)層前后端都要做后端尤其要校驗(yàn)業(yè)務(wù)語義不能只判斷isNotEmpty和isNumeric。訂單號(hào)要有前綴、手機(jī)號(hào)要有號(hào)段、金額要有上下限把像不像真的納入校驗(yàn)規(guī)則。環(huán)境隔離層測(cè)試環(huán)境、預(yù)發(fā)環(huán)境、生產(chǎn)環(huán)境的數(shù)據(jù)通道必須物理隔離。造數(shù)腳本、數(shù)據(jù)同步任務(wù)、Mock平臺(tái)在連接生產(chǎn)庫(kù)之前要做強(qiáng)制確認(rèn)更理想的是通過統(tǒng)一的造數(shù)平臺(tái)生成看起來真實(shí)的測(cè)試數(shù)據(jù)從根上消滅硬編碼的一串9。契約測(cè)試層對(duì)外接口的文檔示例值要小心設(shè)計(jì)最好加一些業(yè)務(wù)上合法但不真實(shí)的樣例并在契約測(cè)試?yán)锛由戏欠ㄖ涤美乐瓜掠伟咽纠诞?dāng)真實(shí)值用。數(shù)據(jù)庫(kù)約束層對(duì)于關(guān)鍵業(yè)務(wù)字段能加CHECK約束就加能建唯一索引就建即使數(shù)據(jù)庫(kù)層擋不住所有臟數(shù)據(jù)也能在出現(xiàn)問題時(shí)更快報(bào)警。我為什么強(qiáng)調(diào)業(yè)務(wù)語義校驗(yàn)因?yàn)榇蠖鄶?shù)只做正則校驗(yàn)的系統(tǒng)就是被^\d$之類的寬松規(guī)則坑的。一串15位9在正則眼里是完美的數(shù)字但它在現(xiàn)實(shí)世界里不具備任何可解釋性。給字段定義合法形態(tài)比定義非法字符更有效。4.4 監(jiān)控告警里最容易被忽略的一條最后說監(jiān)控。很多團(tuán)隊(duì)的監(jiān)控體系很完善接口成功率、RT、錯(cuò)誤碼、JVM內(nèi)存、數(shù)據(jù)庫(kù)慢查詢?nèi)加?。但?99999999999999這種問題這些指標(biāo)幾乎都發(fā)現(xiàn)不了因?yàn)榻涌谑浅晒Φ腞T是正常的錯(cuò)誤碼也是200。唯一暴露問題的是業(yè)務(wù)側(cè)的對(duì)賬失敗率等這個(gè)指標(biāo)飆起來往往已經(jīng)造成了不小的影響。我建議在核心表上增加一種數(shù)據(jù)分布異常監(jiān)控。具體做法對(duì)訂單號(hào)、用戶ID這類高基數(shù)業(yè)務(wù)字段周期性統(tǒng)計(jì)其重復(fù)次數(shù)、最大最小值、是否出現(xiàn)連續(xù)相同數(shù)字的號(hào)碼。一旦發(fā)現(xiàn)某個(gè)值在短時(shí)間內(nèi)重復(fù)率異常上升或者出現(xiàn)了一個(gè)遠(yuǎn)超正常范圍的極端大數(shù)立刻告警。這比事后翻日志高效得多。我們團(tuán)隊(duì)后來用了一個(gè)簡(jiǎn)單的定時(shí)任務(wù)每天掃描主表里字段長(zhǎng)度超過正常范圍或等于保留值名單的記錄跑了大半年抓到了好幾起類似的事故苗頭。5. 換個(gè)角度看999邊界值設(shè)計(jì)里被低估的極限數(shù)字5.1 為什么999...是所有測(cè)試用例里最有價(jià)值的一組聊完了事故和修復(fù)我想把視角拉高一點(diǎn)。999999999999999在質(zhì)量保障和測(cè)試設(shè)計(jì)里其實(shí)是一個(gè)非常經(jīng)典的邊界值樣本。很多人做邊界值分析時(shí)只會(huì)測(cè)最小值和最大值比如金額的0和999999.99卻忽略了一個(gè)維度業(yè)務(wù)語義的邊界。一段數(shù)字從15位漲到16位、17位、19位每一擋都對(duì)應(yīng)不同的類型邊界2147483647是Java Integer的上限9007199254740991是JS的安全整數(shù)上限9223372036854775807是Java Long的上限。999999999999999在Long里合法、在JS里也精確但它已經(jīng)站在了所有精度邊界和業(yè)務(wù)語義邊界的交叉點(diǎn)上。如果你在測(cè)試用例里填過這些數(shù)你其實(shí)是在幫整個(gè)系統(tǒng)做一次數(shù)字邊界體檢。我在給團(tuán)隊(duì)做測(cè)試設(shè)計(jì)培訓(xùn)時(shí)專門列過一個(gè)極端數(shù)字矩陣0、-1、2147483647、2147483648、9007199254740991、9007199254740992、9223372036854775807、999999999999999。每一組都代表一類語言或數(shù)據(jù)庫(kù)的邊界。把這些用例跑一遍很多類型轉(zhuǎn)換、精度丟失、隱式轉(zhuǎn)換的問題都能提前暴露出來。5.2 團(tuán)隊(duì)數(shù)字紀(jì)律把魔法數(shù)字關(guān)進(jìn)籠子經(jīng)歷過兩次類似事故后我在團(tuán)隊(duì)里立了幾條數(shù)字紀(jì)律現(xiàn)在分享出來大家可以參考代碼里禁止硬編碼超過6位且全部相同的數(shù)字作為默認(rèn)值或配置項(xiàng)排查時(shí)必須在配置中心統(tǒng)一管理。一切造數(shù)操作必須走造數(shù)平臺(tái)平臺(tái)生成的測(cè)試數(shù)據(jù)要帶明顯的測(cè)試標(biāo)識(shí)比如以特定前綴開頭防止混入生產(chǎn)。業(yè)務(wù)字段的業(yè)務(wù)語義校驗(yàn)不能省略尤其是ID類、號(hào)碼類、金額類字段位數(shù)、前綴、校驗(yàn)位都要逐步補(bǔ)上。CodeReview時(shí)重點(diǎn)關(guān)注異常返回值和兜底邏輯看到Long.MAX_VALUE或者99999...這類寫法時(shí)一定要追問下游知道這個(gè)值代表什么嗎這些紀(jì)律看起來都是小事但它們確實(shí)能擋住大部分 一長(zhǎng)串9 事故。特別是第一條我把它寫進(jìn)了團(tuán)隊(duì)的靜態(tài)檢查規(guī)則里用正則去掃代碼發(fā)現(xiàn)連續(xù)9以上的硬編碼數(shù)字就報(bào)警從一開始就不讓這類魔法數(shù)字溜進(jìn)代碼庫(kù)。那次凌晨事故之后我把999999999999999這串?dāng)?shù)字設(shè)成了手機(jī)里一個(gè)特殊的備忘不是為了紀(jì)念什么而是每次看到它都會(huì)想起真正危險(xiǎn)的從來不是那串?dāng)?shù)字本身而是寫了它卻不告訴別人它是什么意思的人以及對(duì)著它熟視無睹的校驗(yàn)和監(jiān)控。現(xiàn)在團(tuán)隊(duì)里再有人拿一長(zhǎng)串9當(dāng)占位符他會(huì)被全組人追著改掉因?yàn)槲覀兌贾浪皇菬o所謂的數(shù)據(jù)它是所有隱形坑的集合。