1. 拿到仿真數(shù)據(jù)之后先別急著畫圖每個做過5G網(wǎng)絡(luò)仿真的人應該都有這種體驗NS-3或MATLAB里跑完一輪仿真生成一堆.txt、.sca、.csv文件加起來可能幾百MB甚至幾個GB興沖沖打開數(shù)據(jù)結(jié)果盯著屏幕不知道從哪看起。這個系列做到第8篇前面已經(jīng)覆蓋了無線網(wǎng)絡(luò)仿真的場景搭建、參數(shù)配置、流量模型和模擬器選型現(xiàn)在終于進入大家最關(guān)心的環(huán)節(jié)——5G網(wǎng)絡(luò)仿真結(jié)果分析。我的習慣是拿到任何一輪仿真結(jié)果先做三件事確認數(shù)據(jù)完整性、按指標分層、建立分析起點。這一步不做好后面畫出來的圖要么意義不明要么根本沒法解釋更別提拿去寫報告、做決策了。先說數(shù)據(jù)完整性。很多朋友跑完仿真第一件事就是看吞吐量平均值但如果這時候日志里還報了一堆“Packet drop due to queue overflow”“CRC error rate abnormally high”之類的警告那結(jié)果可信度就要打折扣。我個人的經(jīng)驗是先看仿真日志尾部有沒有正常結(jié)束標志再看丟包事件的時間分布最后才去看統(tǒng)計數(shù)據(jù)。丟包如果集中在某一個時間段大概率是場景里某個節(jié)點故障或者干擾源異常這時候算出來的平均值其實是被污染的。接下來按指標分層。5G網(wǎng)絡(luò)仿真涉及的數(shù)據(jù)指標非常多我把它們歸納成以下三層鏈路層指標RSRP、RSRQ、SINR、CQI、MCS、BLER這些反映的是空口質(zhì)量系統(tǒng)層指標吞吐量、時延、丟包率、抖動、切換成功率、接入成功率這些是最終用戶能感知到的因果層指標調(diào)度器行為、緩存占用率、RB利用率、HARQ重傳率、ARQ狀態(tài)這些用來解釋為什么系統(tǒng)層指標是這個樣子。很多做分析的人卡住是因為一上來就看系統(tǒng)層指標跑到一半發(fā)現(xiàn)結(jié)果不合理才回頭查鏈路層結(jié)果還得從頭重跑仿真。正確做法是先建立這樣一個三層分析框架從鏈路層看到系統(tǒng)層再從系統(tǒng)層倒推鏈路層形成閉環(huán)。我拿自己一個典型的仿真場景舉例。當時搭的是城區(qū)宏站密集組網(wǎng)三扇區(qū)基站間距300米20MHz帶寬30個子載波間隔幀結(jié)構(gòu)用TDD模式上下行配比3:1。仿真跑完平均SINR大概19dB平均吞吐量下行能到42Mbps這個數(shù)字單獨看沒啥感覺但如果把它拆到三層去分析就可以判斷出吞吐量還有多少提升空間、瓶頸在哪里、下一步應該調(diào)參數(shù)還是調(diào)場景。所以在動筆寫分析或者畫圖之前先在表里把這三層指標列出來一份規(guī)劃清晰的分析骨架就出來了。后面你每一步都填內(nèi)容而不是東看一個西看一個效率會高很多。2. 吞吐量與時延兩張圖看清基站調(diào)度邏輯系統(tǒng)層的吞吐量和時延是最核心的KPI也是結(jié)果分析里繞不開的開胃菜。但我在前面說過這兩項指標不能只看平均它們必須結(jié)合分布、累積曲線和調(diào)度器共同分析否則容易得出片面的結(jié)論。2.1 平均吞吐量背后的三種統(tǒng)計口徑很多人習慣直接看平均吞吐量但在5G網(wǎng)絡(luò)的仿真結(jié)果里平均吞吐量其實有至少三種統(tǒng)計口徑混著用會出問題第一種是全網(wǎng)平均用戶吞吐量也就是整個仿真時間內(nèi)所有UE的吞吐量求平均。這個指標最容易算但它的參考價值其實有限——它混合了中心用戶和邊緣用戶的性能通常會把結(jié)果拉到中間值左右掩蓋真實差距。第二種是小區(qū)平均吞吐量按每一個gNB的小區(qū)粒度去統(tǒng)計。這個指標更能反映小區(qū)間的負載均衡情況。如果一個小區(qū)的吞吐量明顯低于其他小區(qū)通常說明它的覆蓋范圍內(nèi)用戶分布太密或者干擾協(xié)調(diào)參數(shù)沒調(diào)好。第三種是邊緣用戶吞吐量5%位吞吐量也就是把所有UE的吞吐量排序取第5百分位的值。這個指標在很多實際網(wǎng)絡(luò)優(yōu)化里比平均值重要得多因為它代表的是一般用戶能感知到的最差體驗。URLLC場景、車聯(lián)網(wǎng)場景里邊緣吞吐量直接決定業(yè)務(wù)能不能跑起來。我個人的建議是仿真分析報告里至少要同時看小區(qū)平均值和邊緣極值兩個都列出表格對比否則你沒法判斷高平均值到底是所有用戶都很好還是一部分用戶拉高了整體平均。具體到我自己跑過的一個案例一個室內(nèi)場景60個UE均勻分布在兩個樓層每個樓層一個gNB20MHz帶寬使用TDD配比下行滿負載。最終統(tǒng)計出來全網(wǎng)平均用戶吞吐量是36Mbps但從小區(qū)粒度看gNB1覆蓋的樓層UDP業(yè)務(wù)多峰值壓力大邊緣用戶吞吐量只有8MbpsgNB2覆蓋的樓層大部分時間空閑邊緣用戶吞吐量能到22Mbps。如果只看全網(wǎng)平均值你會覺得一切正常但邊緣用戶的差距說明兩個小區(qū)間的業(yè)務(wù)均衡策略還需要調(diào)整。2.2 時延分布比時延平均值更值得關(guān)注時延同理。5G網(wǎng)絡(luò)仿真的時延數(shù)據(jù)通常被分成兩類接入時延Control Plane Delay和數(shù)據(jù)傳輸時延User Plane Delay。前者包含隨機接入過程、RRC連接建立、承載建立等一整套信令交互的耗時后者則是數(shù)據(jù)包從應用層發(fā)出到接收端應用層收到的時間差。兩者完全不是一回事但很多分析報告里會直接統(tǒng)稱時延導致結(jié)論毫無說服力。我的經(jīng)驗是至少需要畫兩種情況下的時延累計分布函數(shù)CDF曲線用戶面時延CDF用來觀察傳輸時延的整體分布尤其是高時延尾部控制面時延CDF用來觀察接入、切換、重建等關(guān)鍵流程的信令開銷。舉個例子有一次我們做面向智能制造場景的仿真目標控制面時延要求小于100ms。第一次跑完統(tǒng)計平均控制面時延居然只有45ms當時我覺得很滿意。但畫CDF曲線之后發(fā)現(xiàn)曲線尾部的第99百分位時延到了320ms——這意味著極端情況下某些用戶要等300多毫秒才能完成接入。在工業(yè)控制場景里這個極值比平均值要命得多。后來排查發(fā)現(xiàn)問題出在調(diào)度器在接入壓力大的時候把隨機接入前導碼沖突處理得過于激進部分用戶的PRACH嘗試次數(shù)達到上限觸發(fā)了回退機制。所以說時延分析如果有條件一定要把CDF畫出來再看光看平均值做判斷很容易漏掉重要問題。2.3 吞吐量上不去先看MCS分布再看RB利用率很多朋友問過我明明信道條件不錯SINR也有20多dB為什么吞吐量就是上不去這種情況十有八九不是信道問題而是調(diào)度器和鏈路自適應LA的配合出了問題。鏈路自適應的核心參數(shù)是MCSModulation and Coding Scheme。5G里MCS等級從0到28高MCS意味著高階調(diào)制和更高編碼效率但要求信道質(zhì)量足夠好。仿真里最常見的問題是CQI上報周期太長或者上報的MCS落后于實際信道變化導致基站始終用偏保守的MCS調(diào)度那吞吐量自然就趴在地上。我建議拿到仿真結(jié)果后做一件事統(tǒng)計MCS的使用分布畫直方圖。如果看到大量UE的MCS集中在較低檔位比如5到10而且此時SINR明明很高那就大概率是鏈路自適應參數(shù)沒調(diào)好或者CQI上報延遲過大。反過來如果MCS集中在25以上但吞吐量依然不高那就要看RB利用率了。RB利用率反映的是頻譜有沒有被用滿。如果某個小區(qū)RB利用率只有60%左右但UE還在排隊等著調(diào)度說明調(diào)度器可能配置了過大的上下行資源預留或者周期性業(yè)務(wù)觸發(fā)的調(diào)度請求沒有被及時處理。表現(xiàn)出的現(xiàn)象就是信道很好、MCS也很高、但吞吐量上不去一查RB利用率問題一目了然。我有一份實際跑過的仿真數(shù)據(jù)可以說明這個問題。當時一個8K視頻流業(yè)務(wù)場景帶寬100MHz子載波間隔30kHz基站調(diào)度周期1ms但CSI上報周期被設(shè)置成了80ms。結(jié)果SINR均值21dBMCS平均在22理論峰值吞吐量應該接近200Mbps實際平均只有68Mbps。分析之后發(fā)現(xiàn)MCS分布雖然不低但RB利用率只有52%——因為基站拿不到足夠新的CSI大量RB在MCS通道給的是Proactive調(diào)度但實際數(shù)據(jù)包沒有跟上。把CSI周期改成20ms之后同樣場景下平均吞吐量提到了125Mbps。所以說看到吞吐量指標異常思路是這樣的先看MCS分布判斷鏈路自適應是否正常再看RB利用率判斷資源是否被有效填滿最后回看丟包調(diào)度隊列判斷是否存在擁塞。這三步走完吞吐量問題基本能有結(jié)論。3. 仿真結(jié)果必須可信三個方向驗證模型真實性分析結(jié)果的時候如果只沉浸在自己的仿真結(jié)果是正確的假設(shè)里特別容易被表面數(shù)據(jù)騙過去。5G網(wǎng)絡(luò)仿真的結(jié)果要真正可用于決策必須通過可信性驗證。這部分我一般從三個方向做3.1 重傳率與HARQ行為檢驗任何無線通信系統(tǒng)都會存在誤碼和丟包HARQ機制的目的正是為了糾錯和恢復。仿真結(jié)果里如果重傳率是0反而是可疑的——它要么說明信道建模過于理想要么說明數(shù)據(jù)包太小、BER模型沒生效。正常的5G仿真里BLER應該在一定范圍內(nèi)波動通?？刂圃?0%以內(nèi)或者根據(jù)業(yè)務(wù)需求調(diào)整目標值。如果觀察到大規(guī)模重傳具體表現(xiàn)為HARQ傳輸次數(shù)分布里第3次、第4次傳輸占比顯著上升需要立刻排查是干擾源過強、還是MCS選擇過于激進、或者信道衰落模型設(shè)置得過于嚴苛。有個值得注意的細節(jié)HARQ重傳率不能只看整體平均要看按MCS等級拆分的條件重傳率。實際場景中往往高MCS檔位的UE重傳率不高低MCS檔位的UE重傳率異常升高說明邊緣干擾或者功率控制有問題。如果反過來是高MCS檔位的重傳率更高那就是鏈路自適應優(yōu)化過度、MCS選擇盲目偏高。3.2 切換事件與小區(qū)邊緣效應5G網(wǎng)絡(luò)仿真里面移動性場景切換事件是驗證系統(tǒng)級行為是否合理的試金石。具體做法是把仿真里的切換事件日志拎出來按發(fā)生時刻、源小區(qū)、目標小區(qū)去排時間線和UE的運動軌跡對照看。如果切換發(fā)生在UE接近小區(qū)邊界的位置那說明切換邏輯是合理的如果切換點偏離了理論邊界很遠或者切換頻繁在乒乓狀態(tài)發(fā)生那要懷疑切換參數(shù)比如A3事件偏移量、TTT時長是否配置得太敏感。這里有個仿真新手常踩的坑在SINR分布圖上小區(qū)邊緣的SINR遠低于中心區(qū)域這個本身是符合預期的。但如果邊緣區(qū)域的RSRP已經(jīng)低到-120dBm以下且SINR出現(xiàn)了斷崖式下跌而不是漸變那大概率是場景里的干擾協(xié)調(diào)沒有生效或者天線方向圖設(shè)置掛了導致中心區(qū)域的波束能量被錯誤映射這不屬于正常網(wǎng)絡(luò)行為而是模型配置的問題。切換事件驗證還有一個用處它能反過來檢驗用戶在場景中的移動模型是否正確。如果明明設(shè)定的是步行場景結(jié)果切換事件頻繁到像每小時跑60公里那移動模型大概率出了問題。3.3 RSRP、RSRQ、SINR三者的一致性檢查這三個指標理論上應該是聯(lián)動的RSRP反映參考信號接收功率RSRQ反映參考信號接收質(zhì)量考慮了干擾和噪聲SINR是信號與干擾加噪聲的比率。在仿真結(jié)果里如果RSRP很高但SINR很低說明干擾功率很大如果RSRP和SINR都高但RSRQ突然掉了那說明帶外噪聲或者鄰頻干擾模型被打開了。我常用的做法是把這三個指標畫在同一組坐標里觀察它們之間的數(shù)學關(guān)系是否自洽。比如從RSRP和SINR推算干擾加噪聲的功率再去和鄰區(qū)RSRP對比如果推算結(jié)果遠大于鄰區(qū)RSRP之和說明場景里可能存在非建模干擾源。這時候要回頭檢查是不是有節(jié)點的發(fā)射功率沒關(guān)或者天線極化方向設(shè)置不當這類錯誤在復雜多小區(qū)場景里經(jīng)常出現(xiàn)。在驗證完成后才建議開始做數(shù)據(jù)歸并和可視化。否則你花了一晚上畫出的精美圖表可能基于的是一份跑得漏洞百出的仿真數(shù)據(jù)那和拿錯了體檢報告去開藥沒什么區(qū)別。4. 仿真結(jié)果里最常踩的四個坑這一部分的內(nèi)容來自實際踩過的坑。無線網(wǎng)絡(luò)仿真里結(jié)果分析階段有四個高頻問題幾乎每個項目都會遇到。把它們單列出來希望能幫后來者省掉重復排查的時間。4.1 仿真時間太短導致統(tǒng)計不收斂仿真結(jié)果的統(tǒng)計置信度取決于數(shù)據(jù)包樣本量和仿真時長。5G網(wǎng)絡(luò)仿真里一個常見的錯誤是仿真時間只跑了不到2秒?？鋸垎岵豢鋸?。很多初學用NS-3跑仿真的朋友把ApplicationStartTime設(shè)為1秒SimulationTime設(shè)為2秒實際有效統(tǒng)計時間就只有1秒左右。在這個時間內(nèi)UE可能才完成小區(qū)搜索和隨機接入還沒來得及穩(wěn)定傳輸數(shù)據(jù)仿真就結(jié)束了。你拿這些數(shù)據(jù)算平均吞吐量結(jié)果會嚴重偏低因為大量時間被控制面的初始化過程占用了。我的經(jīng)驗是仿真開始前先讓網(wǎng)絡(luò)完成初始化RRC建立、承載配置、初始測量報告至少預留0.5到1秒的settle時間正式業(yè)務(wù)數(shù)據(jù)的統(tǒng)計時間不要短于10秒建議在20秒以上。如果場景里有切換最好覆蓋2-3次完整切換的移動過程。否則統(tǒng)計出來的KPI在時間維度上不具有代表性。具體數(shù)字可以這樣推導一個20MHz帶寬、最大吞吐量約100Mbps的小區(qū)在20秒仿真里理論上能傳輸250MB數(shù)據(jù)。如果有效統(tǒng)計時間只有1秒傳輸量就只有12.5MB在緩存管理和調(diào)度上根本無法反映穩(wěn)態(tài)行為隊列積壓、時延抖動這些現(xiàn)象根本來不及出現(xiàn)。4.2 調(diào)度器參數(shù)和信道模型之間的隱性矛盾這是一個隱蔽的問題。很多仿真器特別是基于離散事件模擬的調(diào)度器的決策依賴信道質(zhì)量反饋而信道模型本身又有時間相關(guān)性比如多普勒效應、快衰落。當調(diào)度器參數(shù)里的反饋周期和信道相干時間嚴重不匹配時仿真結(jié)果會出現(xiàn)一種很別扭的現(xiàn)象鏈路層SINR看著正常但系統(tǒng)層時延和重傳率就是偏高。舉例來說一個20km/h的移動用戶在3.5GHz頻段多普勒頻移大約65Hz信道相干時間大約是15ms。如果CSI上報周期被設(shè)置成40ms那么基站在調(diào)度時使用的信道信息實際上已經(jīng)過期了兩輪衰落周期MCS的選擇偏差就會擴大。這時即使有外環(huán)鏈路自適應去補償HARQ重傳率依然會偏高。這類問題在結(jié)果分析里不容易一眼看出來因為光看SINR和CQI分布都正常。要做的是把信道變化速率和反饋周期這兩個時間常數(shù)放在一起對比如果它們之間的數(shù)量級關(guān)系不合理那就是配置層面的矛盾必須修改參數(shù)后重跑。4.3 多小區(qū)干擾模型沒打開這個坑在UE數(shù)量少、小區(qū)規(guī)模不大的仿真里影響不明顯一放到密集城區(qū)、多小區(qū)同時開啟業(yè)務(wù)就會讓結(jié)果完全失真。默認情況下某些仿真工具在用戶面數(shù)據(jù)流量低的時候會產(chǎn)生一種偽空閑的干擾狀態(tài)鄰區(qū)基站此時沒有業(yè)務(wù)既不上報互干擾也不會產(chǎn)生實際干擾功率于是中心UE的SINR變得異常好。等到流量一上來所有基站同時發(fā)射干擾突然全部出現(xiàn)SINR斷崖式下跌。這在真實網(wǎng)絡(luò)中對應的是負載相關(guān)干擾但在仿真里如果干擾模型是簡化模型或者門控模型只有在RLC Buffer非空時才計算干擾那結(jié)果里的SINR變化就不是連續(xù)的而是一個臺階式的跳變。解決思路是查看仿真器的物理層干擾模型確認是每個TTI實時計算所有小區(qū)干擾還是按條件觸發(fā)。如果是后者務(wù)必讓鄰居小區(qū)也配置背景業(yè)務(wù)數(shù)據(jù)避免出現(xiàn)干擾空窗期。否則你分析得出結(jié)論該場景下SINR良好其實只對無負載情況成立一旦考慮真實負載結(jié)論就站不住腳。4.4 啟動階段的瞬態(tài)數(shù)據(jù)污染平均時延還有一個細節(jié)仿真剛開始時空口緩沖區(qū)、接入響應、上行調(diào)度授權(quán)建立都需要時間。在這段時間內(nèi)數(shù)據(jù)包經(jīng)歷的時延往往高于穩(wěn)態(tài)值。如果統(tǒng)計窗口包含了這個啟動階段平均時延會被明顯拉高尤其是URLLC這類對時延極其敏感的業(yè)務(wù)偏差可能大到從1ms級別變成5ms級別。我處理的辦法是在仿真腳本里明確設(shè)置統(tǒng)計的冷啟動窗口。比如仿真總時長30秒但只統(tǒng)計從第5秒到第28秒的數(shù)據(jù)。前5秒就算熱身階段不做統(tǒng)計。這樣平均時延反映的是網(wǎng)絡(luò)穩(wěn)態(tài)行為而不是初始化開銷。再進一步我會單獨統(tǒng)計首包接入時延和穩(wěn)態(tài)時延兩個指標前者用于分析控制面流程后者用于分析用戶面?zhèn)鬏?。兩者混在一起談只會讓論文和項目報告里的結(jié)論都變得無法解釋。5. 把仿真結(jié)果組織成能說服人的結(jié)論做到這里數(shù)據(jù)已經(jīng)分析完畢坑也排掉了。最后一步是把結(jié)論呈現(xiàn)出來讓其他人——可能是導師、技術(shù)評審、或者項目決策者——能快速看懂你證明了什么。這一步的技術(shù)含量不亞于前面的仿真工作。5.1 結(jié)論呈現(xiàn)的三個層級我的習慣是每個結(jié)論都按一張圖、三句話、一個建議的形式組織。一張圖這張圖必須體現(xiàn)最核心的指標對比比如邊緣用戶吞吐量CDF曲線、時延分布直方圖、SINR熱力圖挑最有代表性的一張即可。不要同時丟出十張圖看起來覆蓋全面實際上沒有重點。三句話第一句說明現(xiàn)象該場景下平均吞吐量為XXMbps邊緣用戶吞吐量為XXMbps第二句說明原因主要受限于XX小區(qū)邊緣干擾/MCS偏低/調(diào)度限制第三句說明影響這意味著該場景在XX業(yè)務(wù)模式下無法滿足XX需求。一個建議提出基于該結(jié)論的下一步行動比如應優(yōu)化CSI上報周期后重跑或者該場景不適合URLLC業(yè)務(wù)建議調(diào)整幀結(jié)構(gòu)為FDD模式。這樣做的好處是每個結(jié)論都有從現(xiàn)象到原因再到行動的完整鏈路而不是孤立地堆數(shù)據(jù)。5.2 用場景反推結(jié)論是否合理最后一步是反向驗證。我會問自己如果這個結(jié)論放到現(xiàn)實網(wǎng)絡(luò)里物理上是否講得通舉例來說如果你仿真出的邊緣用戶SINR是25dB、同時邊緣用戶吞吐量是120Mbps你要質(zhì)疑在300米站間距的宏站場景里邊緣用戶SINR怎么可能有25dB這個結(jié)論從物理上就不太可能成立說明要么仿真場景太稀疏要么干擾模型沒配對。反之如果你仿真出的控制面時延是15ms也要追問隨機接入一次大約需要7-9個PRACH周期一個周期20ms起步如果仿真里還包含競爭沖突那么15ms的接入時延明顯偏低除非你配置了免授權(quán)接入或者非競爭接入否則這個結(jié)論也要打問號。這種物理直覺反推的能力需要積累真實網(wǎng)絡(luò)數(shù)據(jù)和多次仿真經(jīng)驗才能形成。我個人建議在做結(jié)論定性之前至少對照一遍3GPP標準里的典型時延和吞吐量范圍。5G eMBB場景下IMT-2020給出的典型用戶體驗下行速率是100Mbps級別邊緣也要到10Mbps以上URLLC場景要求用戶面時延1ms級別控制面時延20ms級別Release 15標準里還有更多細分值。如果你的仿真結(jié)果偏離這些典型值幾個數(shù)量級就不要硬解釋回到參數(shù)配置找原因。5.3 報告寫作上的幾個小節(jié)關(guān)于報告寫作這個很多人不重視、實際上很影響印象分的環(huán)節(jié)我也說幾句。第一每個指標都要寫明統(tǒng)計口徑。平均吞吐量是每UE平均還是小區(qū)聚合平均時延是用戶面還是控制面統(tǒng)計區(qū)間是從T1到T2這些必須在圖表標題或者表注里寫清楚否則讀者只能靠猜。第二對照組必須有。很多項目報告只放本方案的結(jié)果沒有基線對照組評審根本不知道這些數(shù)字算好還是差。我的習慣是至少跑三組純空載基線、標準3GPP參數(shù)對照組、優(yōu)化參數(shù)組。三組對比著分析優(yōu)化的增量一目了然。第三不要只報告仿真結(jié)束時的結(jié)果。5G網(wǎng)絡(luò)是一個動態(tài)系統(tǒng)時延和吞吐量隨時間變化是有意義的。在報告里放一張橫軸為仿真時間、縱軸為吞吐量的曲線能直觀體現(xiàn)網(wǎng)絡(luò)是否啟動正常、是否收斂、中間是否出現(xiàn)異常抖動。第四軟件和參數(shù)版本一定要記錄。NS-3的某個版本和另一個版本對物理層模型的處理細節(jié)可能有差異MATLAB的5G Toolbox不同release的API也有變動。把版本號、隨機種子、仿真場景配置都記錄在附錄里一方面方便復現(xiàn)另一方面也是對自己結(jié)果負責。做結(jié)果分析不是把仿真日志打開、按幾個按鈕導出折線圖就算完了。它本質(zhì)上是在仿真搭建、參數(shù)配置、物理模型的基礎(chǔ)上做一次完整的科研驗證而驗證的核心不在工具在于你對系統(tǒng)的理解有多深。我這些經(jīng)驗是從一次次結(jié)果不合理、反復查參數(shù)、最后發(fā)現(xiàn)是配置細節(jié)出問題的過程中積累起來的希望這篇內(nèi)容能幫你少走幾段彎路。這個系列后面我還會碰移動性管理、多天線波束賦形仿真、以及與邊緣計算結(jié)合的聯(lián)合仿真——每一個都有完全不同的結(jié)果分析思路。到時候遇到了坑再回來更新分享。