簡介一套MATLAB電力系統(tǒng)機組組合優(yōu)化實踐資料面向電力系統(tǒng)調度、運行規(guī)劃研究人員及相關專業(yè)學生重點覆蓋機組啟停決策、最優(yōu)出力分配與多類約束處理。壓縮包共10個文件以Excel結果表格、Visio圖表、MATLAB腳本和Word說明文檔為主整體312KB內容包括熱備用系數(shù)0.05與0.2兩種場景下的機組組合求解結果、直流潮流下節(jié)點導納矩陣及其逆矩陣、核心優(yōu)化程序與基本要求說明圖表和數(shù)據(jù)相互對應便于完整復盤建模與求解流程。已有304人學習下載。借助該包可理解機組組合的數(shù)學建模思路運行MATLAB腳本復現(xiàn)優(yōu)化過程對比不同熱備用水平對機組出力的影響數(shù)據(jù)與代碼銜接完整主程序可直接運行并輸出結果表格適合用于課程設計、畢業(yè)設計或實際調度分析。1. 電力系統(tǒng)機組組合優(yōu)化是什么一份zip包背后的調度難題這份編號為034的zip包里裝的是什么其實不用解壓也能猜到八成——電力系統(tǒng)機組組合優(yōu)化Unit Commitment簡稱UC。它解決的是每個調度員每天都要做兩次的問題未來24小時哪些機組該開、哪些該關、每臺發(fā)多少電才能在滿足負荷和備用要求的前提下把總成本壓到最低。別小看這個“開開關關”寫成混合整數(shù)規(guī)劃后規(guī)模可以從十幾臺機組膨脹到上千臺求解時間從秒級變成小時級。這篇筆記適合三類人電力系統(tǒng)專業(yè)學生想找一份能跑通、能改參數(shù)的學習案例售電公司或園區(qū)微網的運行工程師打算把調度方案從拍腦袋換成優(yōu)化求解剛入優(yōu)化工具、想拿真實業(yè)務練手的算法工程師。我會從建模、代碼、調參一路講到踩坑把這類zip包背后最常用的落地路徑一次說透。2. 機組組合建模與MILP選型從經濟調度到啟停決策2.1 目標函數(shù)里最容易算漏的三項成本機組組合和經濟調度最大的區(qū)別是多了“啟停”這個整數(shù)決策。經濟調度默認機組已經在線上只分配出力UC要把機組開起來、關掉還得決定什么時刻操作。所以目標函數(shù)至少包含三塊燃料成本、啟動成本和停機成本。燃料成本通常用出力的二次函數(shù)擬合工程上為了保持MILP線性結構會做成三段分段線性函數(shù)。啟動成本一般細分為冷啟動、溫啟動、熱啟動三種價格相差很大取決于停機時長。停機成本雖然比啟動成本小但一些大機組關停時要吹掃、要消耗輔助燃料算總賬時漏掉它結果就偏向“頻繁啟?！钡募俦阋朔桨?。很多入門案例只寫燃料成本求解器為了省啟動費就會瘋狂啟停機組最后給出的總成本很低但調度員一看啟動次數(shù)就知道不能執(zhí)行。這也是新手對不上實際成本最常見的原因——目標函數(shù)不完整優(yōu)化出來的方案天然偏門。2.2 五類約束功率平衡、備用、爬坡、最小啟停、初始狀態(tài)UC的標準約束可以歸成五組。第一功率平衡約束每個時段所有在線機組出力之和必須等于負荷這是硬等式。第二備用約束系統(tǒng)要預留旋轉備用一般寫成在線機組最大出力之和大于等于“負荷備用容量”。第三爬坡約束相鄰時段之間出力變化不能超過爬坡率。第四最小運行和最小停機時間約束開機后至少要維持若干小時停機后也要冷卻若干小時不能頻繁啟停。第五初始狀態(tài)約束調度起始時刻之前各機組是開著還是關著、已連續(xù)運行多久停機多久都要作為參數(shù)傳進去。前四類好理解初始狀態(tài)是新手最容易爆雷的地方。比如某臺機組在調度起跑點之前已經連續(xù)運行了20小時最小運行時間是8小時那它在第一個時段完全不用額外限制但如果這臺機組前一天剛停機2小時而最小停機時間是8小時那么從調度開始的前6個小時里它都不能重新開機。如果沒有這些初始信息模型會把第一時段當成“起點”算出違反物理約束的開機計劃。這類錯誤在結果里很難排查因為總成本看著正常拉出來做時序回放才發(fā)現(xiàn)前面的機組狀態(tài)全是錯的。2.3 為什么選MILP啟發(fā)式算法的兩個硬傷很多人問“這類問題用遺傳算法不也行嗎”但電力系統(tǒng)行業(yè)從二十年前就開始轉向MILP到現(xiàn)在商業(yè)求解器和開源CBC、SCIP都能處理幾十萬變量的問題原因有兩點。第一啟發(fā)式算法給不出最優(yōu)性差距跑完一組結果你只知道“還行”不知道離最優(yōu)解差百分之幾MILP求解器明確告訴你gap調度員可以直接拍板“gap 1%以內就用”。第二UC帶大量等式約束和邏輯約束啟發(fā)式算法處理約束只能靠罰函數(shù)罰系數(shù)調起來是玄學一不小心功率平衡就根本不滿足。MILP把約束寫進模型可行域由求解器保證解出來就能直接執(zhí)行。以pulp為例目標函數(shù)寫起來很直觀import pulp as lp # prob是問題對象u[i,t]是0/1開機狀態(tài)p[i,t]是連續(xù)出力 # start[i,t]、shutdown[i,t]分別表示t時段是否發(fā)生啟動和停機 prob lp.lpSum( fuel_cost[i] * p[i, t] start_cost[i] * start[i, t] shutdown_cost[i] * shutdown[i, t] for i in units for t in periods )這段代碼有三個關鍵點需要說明。第一start[i,t]和shutdown[i,t]是二進制變量它們不是獨立自由變量必須通過狀態(tài)轉移約束與u[i,t]關聯(lián)否則求解器會“白嫖”啟動成本——把每個時段都定義成啟動但實際機組狀態(tài)根本沒變化。第二燃料成本系數(shù)這里用的是線性系數(shù)如果原始數(shù)據(jù)是二次曲線要提前做分段線性化。第三shutdown_cost容易漏我見過好幾個模型只有啟動成本沒有停機成本優(yōu)化結果里機組啟停次數(shù)明顯偏高。為什么強調MILP而不是動態(tài)規(guī)劃動態(tài)規(guī)劃做小規(guī)模UC很精確但狀態(tài)爆炸太快機組超過50臺基本沒法用拉格朗日松弛可以解決更大規(guī)模但對偶間隙恢復可行解的代碼復雜度高一般團隊很難短時間搞定。因此從標準做法看MILP是成熟的工業(yè)選擇后續(xù)換商業(yè)求解器也只需改一行參數(shù)。3. 把UC跑起來用python和開源求解器求解最小算例3.1 準備數(shù)據(jù)四臺機組參數(shù)表與負荷曲線討論理論夠了先做一個能跑出結果的最小算例。四臺機組24個時段負荷曲線直接寫在腳本里。機組參數(shù)如下表燃料成本按一次線性近似單位是元/MWh方便計算。機組Pmin (MW)Pmax (MW)爬坡率 (MW/h)最小運行 (h)最小停機 (h)啟動成本 (元)燃料成本 (元/MWh)G110040012042450060G28030010032300075G3502008022180095G4301005011800120為了簡單不單獨列停機成本在啟動成本里按50%折算。負荷曲線用一段Python列表從凌晨低谷的350MW升到晚間高峰的850MW模擬典型的雙峰形狀。3.2 用pulp建模機組組合核心代碼與邏輯說明先定義決策變量u[i,t]表示機組i在t時段是否在線p[i,t]是出力start[i,t]和shutdown[i,t]分別記錄啟動和停機動作。pulp里二進制變量直接指定catBinary。特別注意p[i,t]不能只設上下界還要與u[i,t]耦合機組離線時出力必須為0。import pulp as lp T 24 units { 1: {pmin: 100, pmax: 400, ramp: 120, minup: 4, mindown: 2, sc: 4500, fc: 60}, 2: {pmin: 80, pmax: 300, ramp: 100, minup: 3, mindown: 2, sc: 3000, fc: 75}, 3: {pmin: 50, pmax: 200, ramp: 80, minup: 2, mindown: 2, sc: 1800, fc: 95}, 4: {pmin: 30, pmax: 100, ramp: 50, minup: 1, mindown: 1, sc: 800, fc: 120}, } load [ 350, 340, 330, 350, 400, 500, 650, 750, 780, 790, 780, 730, 700, 680, 670, 690, 730, 760, 800, 850, 820, 700, 520, 380, ] prob lp.LpProblem(UC_Demo, lp.LpMinimize) u {}, p {}, start {}, shutdown {} for i in units: for t in range(T): u[i, t] lp.LpVariable(fu_{i}_{t}, catBinary) p[i, t] lp.LpVariable(fp_{i}_{t}, lowBoundunits[i][pmin], upBoundunits[i][pmax]) start[i, t] lp.LpVariable(fs_{i}_{t}, catBinary) shutdown[i, t] lp.LpVariable(fd_{i}_{t}, catBinary) # 目標函數(shù)燃料成本 啟動成本 0.5*啟動成本作為停機成本近似 prob lp.lpSum( units[i][fc] * p[i, t] 1.5 * units[i][sc] * start[i, t] for i in units for t in range(T) ) # 功率平衡 for t in range(T): prob lp.lpSum(p[i, t] for i in units) load[t] # 啟停與出力耦合離線時出力為0在線時出力在Pmin~Pmax之間 for i in units: for t in range(T): prob p[i, t] units[i][pmax] * u[i, t] prob p[i, t] units[i][pmin] * u[i, t] # 狀態(tài)轉移定義啟動和停機動作 for i in units: for t in range(1, T): prob start[i, t] u[i, t] - u[i, t-1] prob shutdown[i, t] u[i, t-1] - u[i, t] # 最小運行時間一旦啟動至少連續(xù)運行minup個時段 for i in units: mu units[i][minup] for t in range(T - mu 1): prob lp.lpSum(u[i, tt] for tt in range(t, t mu)) mu * start[i, t] # 最小停機時間一旦停機至少連續(xù)停機mindown個時段 for i in units: md units[i][mindown] for t in range(T - md 1): prob lp.lpSum(1 - u[i, tt] for tt in range(t, t md)) md * shutdown[i, t] # 爬坡約束 for i in units: for t in range(1, T): prob p[i, t] - p[i, t-1] units[i][ramp] prob p[i, t-1] - p[i, t] units[i][ramp] status prob.solve(lp.PULP_CBC_CMD(msg1, timeLimit30)) print(求解狀態(tài):, lp.LpStatus[status]) print(總成本:, lp.value(prob.objective))核心邏輯說明三點。一是逆變電器耦合約束p[i,t] pmax * u[i,t]保證停機時機組出力被鎖到0p[i,t] pmin * u[i,t]保證在線機組不能低于技術出力下限。少了這條求解器可能讓一臺離線機組按Pmin出力功率平衡雖然滿足但狀態(tài)和出力自相矛盾。二是最小運行時間的標準寫法累計開機時長必須大于等于minup * start[i,t]這是一個經典的MILP建模技巧。三是啟動和停機動作與狀態(tài)的關系上面的寫法是單側松約束配合目標函數(shù)最小化求解器不會故意多報啟動動作。跑這個算例時如果CBC在30秒內沒達到gap 0通常也能返回一個可行解。四臺機組規(guī)模很小一般幾秒內就能找到最優(yōu)解。3.3 求解參數(shù)設置與結果解讀把timeLimit設成30秒是為了演示參數(shù)入口。真正跑的時候四臺機組即使不用時間限制也很快但等到后面做幾十臺機組時這行參數(shù)就是救命稻草。結果解讀建議額外打印每個時段的機組組合和出力明細for t in range(T): gen {i: lp.value(p[i, t]) for i in units if lp.value(u[i, t]) 0.5} total sum(gen.values()) print(ft{t1:2d} 負荷{load[t]:4.0f} 出力{total:4.0f} f在線{list(gen.keys())})判斷結果好壞先看兩件事第一每個時段出力總和必須等于負荷差值超過0.001就說明模型約束寫錯了第二啟動次數(shù)是否合理比如四臺機組24小時啟動總數(shù)一般在3~8次如果出現(xiàn)十幾二十次就要回頭檢查目標函數(shù)里是否漏了啟動成本。4. 從玩具算例到真調度求解性能與參數(shù)調優(yōu)4.1 MIP gap不是越小越好給求解器留余地很多人在MILP里只會設gapRel0.0001然后等幾個小時。實際調度場景根本沒必要。負荷預測本身有±3%的誤差即使給你一個gap為0.001%的完美解執(zhí)行時也會被預測誤差吃掉。行業(yè)內做日前計劃gap在0.5%到1%就足夠日內滾動計劃可以放寬到2%甚至5%。gapRel參數(shù)本質是“相對最優(yōu)性間隙”公式是(best_bound - best_solution) / best_bound。設置1%不是“允許誤差1%”而是告訴求解器如果當前解距離最優(yōu)界在1%以內立刻停止。這一點新手上手時容易誤讀以為設了1%就等于1%的誤差不可控。事實上求解器給出的解是可行解約束全部滿足只是不保證繼續(xù)改進一定超過1%。如果想看求解器當前最優(yōu)界可以用solver lp.PULP_CBC_CMD(msg0, timeLimit300, options[gapRel 0.005]) prob.solve(solver) # bestBound在pulp中通常存在但某些版本可能取不到 print(目標值:, lp.value(prob.objective))這是對時間和精度的主動取舍。做滾動調度時每輪只有幾分鐘甚至幾十秒窗口與其讓求解器跑到gap0再出結果不如先拿一個1%以內的可行解把因預測更新產生的收益吃回來。4.2 時間限制與MIP start熱啟動實際業(yè)務中UC很少只跑一次。典型做法是每15分鐘滾動一次用最新負荷預測重算未來4小時。如果每次都從零開始求解時間會累加得很可觀。這時候熱啟動warm start也稱MIP start就是最大的免費午餐。熱啟動的本質就是把你認為“可能比較優(yōu)”的機組啟停狀態(tài)事先告訴求解器讓分支定界從一開始就貼著這個解走剪枝效率高很多。在Gurobi里可以這樣傳遞上一輪的最優(yōu)解from gurobipy import Model, GRB m Model(UC) # 這里假設u_vars已經是上一輪求出的0/1矩陣 for i in unit_list: for t in T_list: u_var[i, t].start last_solution[i, t] # start是Gurobi為變量預留的MIP start屬性 m.optimize()上一輪解出來的機組狀態(tài)和這一輪差別通常不大熱啟動能讓求解時間縮短30%~70%。但要注意如果負荷突變特別大比如某臺機組故障導致負荷轉移熱啟動解可能不在可行域內求解器會自動剔除不可行部分繼續(xù)從頭探索。所以熱啟動是“加速器”不是“保證書”。開源求解器CBC也支持MIP start但pulp里傳入的API在不同版本間不一致使用前要先驗證當前版本是否支持如果不支持可以放棄熱啟動改用“上一輪解作為初始值”手動構造可行解但意義不大。因此若項目規(guī)模上千臺機組商業(yè)求解器的熱啟動價值會非常明顯。4.3 大規(guī)模場景的分解與聚合思路機組數(shù)量上千時直接求解MILP的變量數(shù)輕松破百萬時間和內存都受不了。業(yè)界常見做法有三個機組聚合、時間粒度和拉格朗日松弛。機組聚合是把同類型、同容量區(qū)間的機組合并成一臺等效機組。比如某風電場或光伏電站有50臺同型號逆變器聚合成一臺整體參與優(yōu)化再按等比例或邊際成本排序分配出力。對于火電同容量機組也有效。代碼如下def aggregate_units(unit_params, key_fn): groups {} for uid, param in unit_params.items(): key key_fn(param) groups.setdefault(key, []).append(uid) agg {} for key, ids in groups.items(): agg[key] { pmax: sum(unit_params[i][pmax] for i in ids), pmin: sum(unit_params[i][pmin] for i in ids), # 成本系數(shù)按額定容量加權避免簡單平均帶來的偏差 fc: sum(unit_params[i][fc] * unit_params[i][pmax] for i in ids) / sum(unit_params[i][pmax] for i in ids), } return agg注意加權平均的目的是讓聚合后的成本特性盡量接近原群體。如果簡單把燃料成本相加聚合機組成本會虛高優(yōu)化結果會把電量偏向真正的低成本機組。時間粒度分解則是先跑每2小時一個大時段的計劃確定大致啟停方案再把第一個小時到第四個小時細化成15分鐘粒度重優(yōu)化。這樣既保留了可執(zhí)行性又降低了問題規(guī)模。拉格朗日松弛把系統(tǒng)功率平衡約束乘子化逐臺機組獨立求解再更新乘子迭代工程上常用它來生成初始可行解再交給MILP做最終優(yōu)化。5. 踩坑記錄從zip解壓到約束漏加的五個典型問題5.1 zip解壓報invalid zip archive文件沒下完整現(xiàn)象拿到“034電力系統(tǒng)機組組合優(yōu)化.zip”后雙擊解壓直接彈“文件損壞”或“invalid zip archive: could not find eocd”也有人說成“failed to copy spatial iop zip”這類奇奇怪怪的報錯。原因zip文件尾部有一個End of Central Directory記錄Linux解壓工具找不到這條記錄就是典型的“文件沒下完整”。可能是下載中斷、網絡緩存殘留、或者從網盤拿到的分包沒有全部放在同一目錄就急著解壓。解決先核對文件大小跟下載頁標注的字節(jié)數(shù)一致再解壓。第二步用命令行測試unzip -t 034電力系統(tǒng)機組組合優(yōu)化.zip如果輸出里有“End-of-central-directory signature not found”字樣別猶豫重新下載。若文件特別大且下載工具支持斷點續(xù)傳直接續(xù)傳后再次測試如果是分包壓縮務必把分卷文件都放在同一個文件夾否則即使擴展名正確也解不出來。還有一個常見情況普通zip但下載時被瀏覽器改成“下載.zip.zip”文件大小正常卻解不了這時改回原名即可。5.2 zip內中文亂碼編碼不匹配現(xiàn)象解壓后文件名全是亂碼類似“鎶楃伀”或“緗戠粶”這樣的字符。原因zip包在Windows系統(tǒng)壓縮時文件名一般按GBK編碼寫入在Linux或macOS上用默認UTF-8解壓中文名就變成了亂碼。這跟zip包本身無關純粹是編碼不一致。解決Linux環(huán)境用unzip -O GBK重新解壓如果用的壓縮軟件不支持指定編碼可以先用Python把zip里的文件名修正出來再根據(jù)修正后的名字手動解壓到本地。代碼如下import zipfile with zipfile.ZipFile(034電力系統(tǒng)機組組合優(yōu)化.zip) as zf: for info in zf.infolist(): # 先把字節(jié)按cp437解碼再按gbk重新編碼還原中文 safe_name info.filename.encode(cp437).decode(gbk, errorsignore) print(safe_name)這個技巧對含中文的zip非常通用。如果zip本身加了密碼編碼問題反而是小事——沒有密碼只能在腳本里跑字典屬于合規(guī)性以外的話題不做展開。5.3 結果違反功率平衡單位與約束兩處都查現(xiàn)象求解完成后打印各個時段出力之和發(fā)現(xiàn)和負荷差了幾十甚至幾百MW或者某臺機組狀態(tài)顯示為停機但出力卻等于Pmin。原因先從約束排查最常見的是漏寫了p[i,t] pmax * u[i,t]和p[i,t] pmin * u[i,t]停機機組照樣被分配到出力。其次查數(shù)據(jù)單位負荷如果用的是MWh而機組出力是MW一個24小時的時段里差了24倍。解決先加一個結果校驗模塊每次求解完成后自動對賬for t in range(T): gen_sum sum(lp.value(p[i, t]) for i in units) if abs(gen_sum - load[t]) 1e-3: print(f時段{t1}功率不平衡: 負荷{load[t]:.2f} 出力{gen_sum:.2f})這段校驗不是可選項是必選項。尤其是換數(shù)據(jù)源時經常遇到“MW當成MWh”“某機組Pmax寫錯”之類的低級問題有了它對賬翻車概率大大降低。5.4 最小啟停約束導致無解初始狀態(tài)寫錯現(xiàn)象模型報infeasible但把最小運行時間和最小停機時間約束全部注釋掉后立刻有解說明問題就出在這組約束上。原因最小啟停約束是按“調度起點”寫的如果機組在前一天已經運行或停機了若干小時你必須在模型里把這段“歷史狀態(tài)”接過來。我見過一個典型案例某機組最小運行時間8小時初始狀態(tài)寫成了“在線”但實際它只連續(xù)運行了2小時模型要求它前6小時必須保持運行可功率平衡又被其他機組占滿導致無解。根本原因是初始狀態(tài)寫錯或根本沒初始化。解決在建模前把每臺機組的初始運行/停機時間單獨建表并在約束中用分段判斷彌補剩余時長。一個常見寫法是如果機組初始在線時長已超過最小運行時間則首個時段不額外施加minup約束如果還沒達到則讓它在剩余不足的時段里保持在線。最小停機時間同理初始停機時長不足時前幾個時段禁止開機。# init_status: 1在線 0停機 # init_time: 已經連續(xù)運行或停機的小時數(shù) if init_status[i] 1 and init_time[i] units[i][minup]: need units[i][minup] - init_time[i] for t in range(min(need, T)): prob u[i, t] 1這就是前文說的“初始狀態(tài)約束”。很多教程里不寫這層邏輯是因為假設機組已滿足歷史狀態(tài)但真實調度場景里凌晨1點出現(xiàn)無解往往就是這個根因。5.5 求解器報infeasible先做約束松弛現(xiàn)象模型無解求解器只返回“problem infeasible”不告訴你哪條約束沖突排錯全靠猜。原因MILP求解器內部用的是分支定界它發(fā)現(xiàn)可行域為空時會直接停止不會提供一條人話解釋。爬坡約束跨時段耦合一處無解會傳導到后續(xù)所有時段排查特別費勁。解決先用“連續(xù)化診斷”找到沖突范圍。把機組狀態(tài)變量從二進制放松成0到1的連續(xù)變量再求解同一模型。如果連續(xù)模型有解說明是整數(shù)約束和狀態(tài)轉移之間的邏輯沖突如果連續(xù)模型也無解說明線性約束之間就矛盾了。連續(xù)模型求解后查看哪些u[i,t]落在0到1之間這些時段和機組往往就是約束沖突的高發(fā)區(qū)域for i in units: for t in range(T): u[i, t] lp.LpVariable(fu_{i}_{t}, lowBound0, upBound1) # 由Binary改成Continuous只用于診斷 prob.solve() for i in units: for t in range(T): val lp.value(u[i, t]) if 0.01 val 0.99: print(f診斷: 機組{i} 時段{t1} 狀態(tài)值{val:.3f})中間值意味著這個時段的狀態(tài)被兩組約束拉扯重點檢查該機組的爬坡、最小啟停和備用約束。這種“連續(xù)松弛診斷法”在大型模型里比人肉對數(shù)小時管用得多是我現(xiàn)在排查無解的第一動作。6. 進階考慮不確定性與回測驗證的實用技巧6.1 從確定性UC到隨機UC場景法怎么改確定性UC里負荷是單條曲線隨機UC常見做法是場景法構造多個負荷預測場景每個場景設一個概率。狀態(tài)變量u[i,t]是所有場景共用的非預期變量而出力p[i,t,s]允許隨場景變化。目標函數(shù)改為所有場景成本按概率加權。代碼層面的改動很小只需要給p和load加一個場景下標再把功率平衡約束對每個場景分別寫。代價是變量規(guī)模乘以場景數(shù)所以工程上場景常用概率距離方法剪枝到5~20個。6.2 用歷史負荷做回測驗證結果是否可信不管模型寫得多復雜最終要回答“結果能不能用于明天調度”。我的習慣是拿過去30天的歷史負荷做回測每天用前一天的預測負荷跑SCUC再把當天實際負荷代入結果統(tǒng)計功率平衡偏差和爬坡越限次數(shù)。驗證腳本核心就一段def validate(plan_result, actual_load, tolerance10.0): imbalance (actual_load - plan_result[total_gen]).abs() violations (imbalance tolerance).sum() return violations # 返回越限時段數(shù)越少說明方案越穩(wěn)能通過回測的方案才敢排進調度計劃否則模型再精巧也只是紙面好看。這類優(yōu)化項目里我吃過的最大教訓就是“迷信gap和最優(yōu)性”卻忽略了約束本身是否正確。有一版模型把爬坡約束方向寫反求解器跑出完美的0.1% gap拿去現(xiàn)場用才發(fā)現(xiàn)無法執(zhí)行。從那以后任何UC代碼跑完結果我都強制自己先看啟動次數(shù)、單位時段啟停頻繁度再做平衡校驗。如果你手頭正打開這份zip包希望這篇筆記能幫你少走同樣的彎路希望幫到你。本文還有配套的精品資源點擊獲取