HTTP/2 的限流機制全部長成同一個樣子一個計數(shù)器加一個上限。并發(fā)流數(shù)由SETTINGS_MAX_CONCURRENT_STREAMS限制頭部占用由SETTINGS_MAX_HEADER_LIST_SIZE一類的設(shè)置限制連接級緩沖由流控窗口限制。這套東西的設(shè)計前提是計數(shù)器計的那個東西就是你想限制的那個資源。從 2023 年的 Rapid Reset 到 2026 年的一批記錄被反復(fù)利用的正是這個前提的裂縫。而裂縫不止一種形狀計數(shù)單位可能與資源的單位不同按編碼字節(jié)計而占用在解碼之后才發(fā)生計數(shù)器可能因某個協(xié)議事件遞減而資源的生命周期由協(xié)議之外的因素決定計數(shù)器可能只守一個字段而分配發(fā)生在它旁邊的另一個字段。這三種形狀各自有明確的記錄。把它們分開看比把它們合成“HTTP/2 DoS”更有用因為三種形狀對應(yīng)的修法不同。并發(fā)流上限計的是狀態(tài)不是工作量先從最基礎(chǔ)的那個計數(shù)器看起。RFC 9113 §5.1.2 規(guī)定了哪些流會占用并發(fā)額度Streams that are in the “open” state or in either of the “half-closed” states count toward the maximum number of streams that an endpoint is permitted to open. Streams in any of these three states count toward the limit advertised in the SETTINGS_MAX_CONCURRENT_STREAMS setting. Streams in either of the “reserved” states do not count toward the stream limit.三個狀態(tài)open、half-closed (local)、half-closed (remote)。closed不在這個列表里。規(guī)范的措辭很確定這是“哪些狀態(tài)計數(shù)”的完整清單沒有留余地。也就是說一條已經(jīng)關(guān)閉的流不占用并發(fā)額度無論它觸發(fā)的工作是否還在跑。這個規(guī)定的合理性在于它的視角SETTINGS_MAX_CONCURRENT_STREAMS的本意是限制對端同時打開多少條流這是一個協(xié)議狀態(tài)層面的事情。誰在什么時候打開流是協(xié)議能觀測到的而“這條流引發(fā)的后端處理是否結(jié)束”協(xié)議看不見。而攻擊面就落在這個不可見的地方。2023 年的 Rapid Reset 做的是客戶端快速打開流、發(fā)出請求頭、然后立刻發(fā)RST_STREAM取消。從協(xié)議的角度每條流從 open 走到 closed耗時極短因此并發(fā)額度幾乎不被占用而服務(wù)端在收到請求頭之后就已經(jīng)把請求轉(zhuǎn)給了后端取消通知到達(dá)后端需要時間后端的工作已經(jīng)在做了。攻擊者用極小的協(xié)議資源換到了極大的后端工作量。NVD 對 CVE-2023-44487 的描述用的是request cancellation can reset many streams quickly——“快速重置很多流”。這句描述的落點是計數(shù)器的行為重置使流快速離開計數(shù)狀態(tài)而不是攻擊者的手段。CVE-2023-44487 的 CVE 記錄本身很薄沒有標(biāo)題、metrics 為空、受影響產(chǎn)品是占位值它的實質(zhì)內(nèi)容在那份 144 條的廠商引用清單里。要引用它的 CVSS 必須去 NVD不能引 CVE 記錄。第一次錯配計數(shù)單位是編碼字節(jié)資源占用在解碼之后第二種形狀與 HPACK 有關(guān)而它是三種里最“結(jié)構(gòu)性”的一種。HPACK 是 HTTP/2 的頭部壓縮格式它的設(shè)計目標(biāo)之一是讓重復(fù)的頭部只傳一次靜態(tài)表與動態(tài)表把常見的字段名與值預(yù)先編碼成索引后續(xù)只傳索引號。一個字節(jié)的線上數(shù)據(jù)因此可以展開成很長的頭部值。SETTINGS_MAX_HEADER_LIST_SIZE這個設(shè)置的作用是限制頭部列表的大小但它的字面含意是編碼后的字節(jié)數(shù)還是解碼后的字節(jié)數(shù)各個實現(xiàn)的理解不一致。Envoy 記錄里的 CVE-2026-47774CVSS 3.1 7.5分類為 CWE-405 與 CWE-770把這一點寫成了兩處并存的錯配cookie header bytes are not fully accounted for during request header size validation以及HPACK header block limits … are enforced on encoded bytes without a corresponding limit on total decoded header size第一處是“某個字段沒被計入”下文會作為第三種形狀單獨講第二處正是這里要說的限制施加在編碼字節(jié)上而內(nèi)存占用發(fā)生在解碼之后。一個精心構(gòu)造的頭部塊可以在很小的編碼長度里展開出很大的解碼結(jié)果因為 HPACK 的動態(tài)表允許重復(fù)引用。同樣的形狀在 h2o 的 CVE-2026-54340 里有更明確的表述。那份記錄的摘要寫的是h2o has HTTP/2 state amplification細(xì)節(jié)里說明放大的方式是把 HPACK 解壓與停滯的流結(jié)合起來并給出結(jié)論需要額外的限制來約束解碼后的頭部狀態(tài)。把這兩處放在一起這條錯配的定義就清楚了限制器測量的是“傳輸量”被保護(hù)的資源是“解碼后的駐留量”。兩者在正常情況下近似成正比所以按前者限制后者看起來夠用而 HPACK 的設(shè)計目的就是打破這個正比關(guān)系讓重復(fù)的內(nèi)容傳得更小。壓縮比越高這兩者的偏離越大而壓縮比正是攻擊者可以選的東西。Go 在 2026 年的兩條記錄也落在這個形狀附近。GO-2026-6603說的是請求尾部的處理可以繞過Server.MaxHeaderValueCount與MaxHeaderBytes兩個上限GO-2026-6611說的是大量小的 SETTINGS 幀攜帶SETTINGS_INITIAL_WINDOW_SIZE會讓 CPU 消耗遠(yuǎn)超一個幀應(yīng)有的量。后者的錯配方向稍有不同一個 SETTINGS 幀在計數(shù)上是一而按 RFC 9113 §6.9.2 的規(guī)定它要求端點按差值調(diào)整所有流的窗口也就是說一幀的工作量是 O(流數(shù))而計數(shù)器把它記成了 1。這里的計數(shù)單位是“幀”被保護(hù)的資源是“由這一幀觸發(fā)的計算量”而規(guī)范本身要求了這個乘數(shù)。第二次錯配計數(shù)器因協(xié)議事件遞減資源的生命周期由后端決定第三種形狀是 2025 年的新東西也是“MadeYouReset”這個名字的由來。它的機制建立在第一次錯配的同一塊基礎(chǔ)上但觸發(fā)方向相反。Rapid Reset 里是客戶端發(fā)RST_STREAM而 CVE-2025-8671分類 CWE-404 的做法是讓服務(wù)端發(fā)RST_STREAM客戶端通過畸形幀或流控錯誤去引發(fā)服務(wù)端主動重置。這個區(qū)別不是修辭而是這一整類問題的分界線?？匆幌?CERT/CC 那份公告的原文Streams reset by the server are considered closed, even though backend processing continues… when a stream is reset, the protocol considers it no longer active and no longer accounts for it within this counter.服務(wù)端自己發(fā)出的重置同樣會讓流從計數(shù)里消失。于是出現(xiàn)一個局面服務(wù)端在壓力下主動重置流以保護(hù)自己而主動重置這個動作恰好釋放了并發(fā)額度讓攻擊者可以再開新流重置成了攻擊的推進(jìn)器而不是它的剎車。這里有一處措辭需要小心因為兩份來源不一致。CERT 公告的概述部分把觸發(fā)歸于客戶端“rapidly triggering the server to reset them”而同一份公告里講SETTINGS_MAX_CONCURRENT_STREAMS的段落寫的是 “when a stream is reset by the attacker”。字面上像是指攻擊者發(fā)了重置。CVE-2025-8671 的記錄給出了澄清式的表述客戶端觸發(fā)、服務(wù)端發(fā)出的重置。這個區(qū)分是整個機制的關(guān)鍵如果攻擊者自己發(fā)重置那不過是 2023 年的做法正因為重置由服務(wù)端發(fā)出才說明“服務(wù)端主動保護(hù)自己”這個動作本身可以被變成攻擊的一部分。同一份 CVE 記錄還帶著一句自我聲明This CVE will be updated as affected product details are released.也就是說它的受影響產(chǎn)品清單是一個會變的快照引用時必須注明觀測日期不能當(dāng)作穩(wěn)定事實。記錄里還有一個廠商名寫成H20幾乎可以確定是 h2o 的筆誤引用時照抄會傳遞錯誤改寫又等于修正他人記錄這一處只能繞開。RFC 9113 其實給了這一類的對策而且寫得很清楚?！?.1 在講關(guān)閉狀態(tài)的流時給了一條操作建議Endpoints SHOULD NOT use timers for this purpose.“這個目的”指的是判斷對端是否還在處理。規(guī)范的建議是不要靠計時器去猜而是用 SETTINGS 或 PING 的確認(rèn)作為同步點——§6.5.3 定義了這套確認(rèn)機制收到 SETTINGS 的對端必須立即回一個帶 ACK 的 SETTINGS而發(fā)方在收到 ACK 之后才能確信自己發(fā)的那組值已經(jīng)生效。規(guī)范把這條寫成了SHOULD NOT而實現(xiàn)里靠計時器判斷“對端是否還活著”是常見做法。這里存在一個可以單獨檢查的點如果某個實現(xiàn)用超時來判斷流是否真的結(jié)束那么它對“服務(wù)端主動重置”這類事件的資源記賬就會偏松如果它用 SETTINGS/PING 的確認(rèn)那么記賬與真實狀態(tài)之間的窗口會窄得多。這條判據(jù)可以直接讀代碼得到答案不需要構(gòu)造流量。Tomcat 在這一族里有一處修復(fù)把后果說得最具體CVE-2025-48989 的記錄里這個問題的表現(xiàn)是The denial of service typically manifested as an OutOfMemoryError堆內(nèi)存耗盡。也就是說“流關(guān)閉了但工作還在”這個錯配最終落在的是內(nèi)存上而不是 CPU 上。這一條與前面講的形狀合在一起說明了同一個計數(shù)器可以同時被多種資源繞過。在進(jìn)入第三種錯配之前先看一處確實管用的計量因為它提供了一個對照。RFC 9113 第 8.1.1 節(jié)規(guī)定一個請求或響應(yīng)在什么情況下算畸形if the value of a content-length header field does not equal the sum of the DATA frame payload lengths這條規(guī)則的做法與前面兩種都不同它不是在給某個量設(shè)上限而是要求兩個獨立的計量互相對賬。聲明了一個長度實際收到的 DATA 幀載荷之和必須與之相等。任何一側(cè)記賬出錯都會被這個等式發(fā)現(xiàn)因為它不依賴哪個計數(shù)是對的只要求兩者一致。把這條與前面兩種錯配放在一起可以看到一個區(qū)分。前兩種錯配的共同點是只有一個計量限制器在計被保護(hù)的資源沒有自己的獨立計量所以限制器算錯了沒有東西能發(fā)現(xiàn)。而這里這種互相對賬的做法天然免疫單側(cè)記賬錯誤。這也是為什么這一族問題的修法常常是再加一個獨立的限制而不是把現(xiàn)有閾值調(diào)準(zhǔn)加獨立限制的效果是讓兩個計量互相約束與這條對賬規(guī)則是同一個思路。第三次錯配計數(shù)器守一個字段分配發(fā)生在旁邊第三種形狀是三種里最“日?！钡囊环N也是最容易在代碼審查里發(fā)現(xiàn)的一種。它的模式是限制器檢查某個字段而實際分配發(fā)生在相鄰的另一個字段上。字段之間在語義上相關(guān)在代碼里也可能是相鄰的兩行但限制器只覆蓋了其中之一。Envoy 記錄的第一處錯配就是這一個cookie header bytes are not fully accounted for during request header size validation。頭部大小校驗在算總長度時沒有把 cookie 的字節(jié)完全算進(jìn)去而 cookie 恰恰是最容易膨脹的頭部字段之一它由服務(wù)端自己下發(fā)攻擊者只要多訪問幾次讓它們累積起來即可。Go 的GO-2026-6603是同一形狀的另一個實例請求尾部trailer的處理可以繞過兩個頭部相關(guān)的上限。尾部的語義是“跟在正文后面的頭部字段”與頭部在語法上同源因此共享限制器看起來自然但限制器實現(xiàn)時盯的是頭部那一側(cè)尾部那一側(cè)成了出口。同一形狀還有一個更細(xì)的變體落在流量控制這個機制上GO-2026-6612記錄了它refund connection-level flow control twice for the same data … bypass the configured connection-level flow control limit同一次數(shù)據(jù)被退還了兩次額度于是連接級流控窗口這個計數(shù)器不再反映真實緩沖量。這條記錄同時給了一個有用的對照它明確指出即使連接級窗口被繞過“總緩沖數(shù)據(jù)仍受并發(fā)流上限與流級流控限制”。這句話的價值在于它點出了剩余邊界的位置一個計數(shù)器被繞過之后真正管住資源的是另一個計數(shù)器而那個計數(shù)器是否也屬于前兩種錯配之一是可以逐個檢查的。把三處放在一起這一形狀的共性就清楚了限制器與分配點在代碼里的位置相關(guān)而不是在語義上重合。檢查頭部大小的代碼與分配 cookie 內(nèi)存的代碼可能在同一段里限制 trailer 的代碼與分配Request.Trailermap 的代碼可能相鄰。誰都沒寫錯只是限制器的覆蓋范圍與分配的覆蓋范圍是兩個不同的集合。三種形狀為什么修法不同現(xiàn)在把它們分開因為分開之后才看得出“為什么同一條修復(fù)不能覆蓋另一條”。第一種編碼 vs 解碼的修法是改變計量的時機。只要限制器測量的還是線上字節(jié)壓縮比就會成為攻擊者可以調(diào)節(jié)的杠桿。Envoy 與 h2o 的記錄都指向同一個方向給解碼后的狀態(tài)加一個獨立的限制。這不是把閾值調(diào)小調(diào)小只能改變放大倍數(shù)的可容忍范圍改不了“計量對象不對”這件事。第二種事件 vs 生命周期的修法是把記賬的依據(jù)從協(xié)議事件換成后端的實際狀態(tài)。而這個方向有一個根本困難協(xié)議層看不到后端的處理是否結(jié)束。所以可行的做法不是“記準(zhǔn)”而是別讓計數(shù)器的釋放成為攻擊者可用的資源——RFC 9113 §5.1 那條“不要用計時器”的建議正是這個意思用確認(rèn)點代替猜測讓協(xié)議的同步點與真實的處理邊界盡可能貼近。而只要后端處理與協(xié)議狀態(tài)之間沒有強制的同步機制這個窗口就消不掉只能收窄。第三種守一個字段分配在隔壁的修法最直接把覆蓋范圍對齊。它是三種里唯一可以靠“補一處檢查”解決的因為限制器與分配點在同一個實現(xiàn)里兩者都能被讀到。它的問題也不是設(shè)計上的而是實現(xiàn)上的檢查與分配由不同的代碼路徑完成時兩者的字段集合很容易長歪。這里有一處很具體的困難限制器的計量單位往往在設(shè)置項的名字里看不出來。SETTINGS_MAX_HEADER_LIST_SIZE里的 “SIZE”指的是什么RFC 9113 給它的定義是“對端愿意接受的頭部列表的最大尺寸”而這個“尺寸”按 §6.5.2 的說明是未壓縮的大小規(guī)范的意圖是解碼后的量。但實現(xiàn)里這個設(shè)置常常被拿去和一個按編碼字節(jié)計的內(nèi)部緩沖區(qū)比較因為那個緩沖區(qū)是實現(xiàn)的代碼里真實存在的東西而“解碼后的量”要等解碼完成才知道。于是規(guī)范定義的語義與實現(xiàn)里的現(xiàn)成量之間有一處缺口而填這個缺口的方式是各實現(xiàn)自己選的。這也解釋了為什么第一種錯配在這批記錄里出現(xiàn)得最頻繁它不是某個實現(xiàn)寫錯了而是“按現(xiàn)成的量記賬”這個做法在壓縮存在時就不成立。要發(fā)現(xiàn)它需要問一個不在配置項名字里的問題這個限制是在解碼之前生效還是之后生效。三種形狀里前兩種的根在協(xié)議設(shè)計的邊界協(xié)議能觀測什么、觀測不到什么第三種在實現(xiàn)的覆蓋范圍。這個區(qū)分決定了一個部署能自查到什么程度第三種讀自己的代碼就能發(fā)現(xiàn)第二種要對著規(guī)范的同步機制檢查有沒有用計時器、有沒有用確認(rèn)點第一種需要判斷自己的限制器到底在給什么計量而這個問題往往要讀依賴庫的配置語義才能回答因為“限制的是編碼字節(jié)還是解碼字節(jié)”在設(shè)置項的名字里通?？床怀鰜怼Ｒ惶幮枰Ａ舻牟灰恢伦詈蟀巡牧侠锏膸滋幟苡浵聛硪驗樗鼈儠绊懸?。Tomcat 有一份記錄 CVE-2026-78437 在廠商頁上的等級是Low而 NVD 給它 7.3 HIGH?？淳唧w內(nèi)容廠商把它描述為“一個用戶的請求可能讓另一個用戶的請求失敗”分類是 CWE-459未完成的清理它是跨請求隔離問題不是資源放大問題。把這一條算進(jìn)“HTTP/2 限流”這一族是不對的。nginx 的 CVE-2026-95101 也有歸類問題。它在兩份 CVSS 里的影響評級都是I:LOW, A:NONE分類是 CWE-172編碼處理不一致實質(zhì)是 HTTP/3 的請求體注入。它不屬于放大類。而這處記錄的正文在 F5 的登錄頁之后不可讀只引用可讀的等價來源因此這里不對其細(xì)節(jié)做描述。Tomcat 在這一族里還有另一份記錄 CVE-2026-68763它的形態(tài)是第三種錯配的一個變體記錄寫的是An allocation leak in the HTTP/2 backlog tracking when a stream was reset在流被重置時為積壓跟蹤分配的對象泄漏了。這里計數(shù)與分配都沒有算錯出問題的是“流被重置”這個事件觸發(fā)了一條清理路徑而那條路徑漏掉了這個對象。前兩種錯配是“賬記錯了”這一種是“東西沒還”但它同樣落在同一個交匯點上重置這個協(xié)議事件被當(dāng)成了資源生命周期的終點而實際上有一個分配對象沒有被這個事件覆蓋。還有一處是規(guī)范內(nèi)部的RFC 9113 §5.1 說收到關(guān)閉狀態(tài)流上的幀應(yīng)當(dāng)“最小處理然后丟棄”而 §6.1 說在 open 或 half-closed 之外的流上收到 DATA 幀要報STREAM_CLOSED流錯誤。同一個幀、兩處不同的處置建議。這一處張力是本文從兩段原文對照讀出的規(guī)范沒有把它標(biāo)成一個問題但它說明“關(guān)閉”這個狀態(tài)上的行為在規(guī)范里本身就不是完全單義的而實現(xiàn)要在其中選一種。操作層面還有一處困難這一族問題很難有統(tǒng)一的版本排查方式。同一條錯配形狀在不同實現(xiàn)里的修復(fù)版本互不相關(guān)而且修復(fù)往往落在各自的內(nèi)部計數(shù)器上不會出現(xiàn)在對外接口的變化里。CVE-2025-8671 的記錄自己聲明受影響清單會隨產(chǎn)品細(xì)節(jié)的發(fā)布而更新這等于承認(rèn)它給不出一個穩(wěn)定范圍而 CVE-2023-44487 的 CVE 記錄里受影響產(chǎn)品是占位值任何范圍都得回到廠商公告。實際可行的做法是按形狀去查而不是按 CVE 去查把自己的實現(xiàn)按那三種錯配順序過一遍看每一處限制器計的是什么然后對照該實現(xiàn)對應(yīng)版本的發(fā)布說明。按 CVE 查的前提是有人已經(jīng)把你的實現(xiàn)對應(yīng)到某條記錄上而這一族的記錄在這一點上恰恰是最不可靠的部分。Rapid Reset 與 MadeYouReset 都沒有對應(yīng)的 IETF RFC。后者在 CVE 記錄的引用清單里有一份個人的 Internet-Draft關(guān)于 HTTP/2 流限制但它從未成為 RFC這意味著這一族問題上沒有一份規(guī)范文本可以當(dāng)作判據(jù)能用的只有 RFC 9113 里那幾條關(guān)于狀態(tài)與同步的建議。有一件事對三種形狀都成立這些機制的失效方式都不是“某個實現(xiàn)寫錯了”。Rapid Reset 與 MadeYouReset 利用的是規(guī)范對“流何時算結(jié)束”的定義HPACK 的放大利用的是壓縮本身的設(shè)計目標(biāo)Envoy 與 h2o 的頭部分配利用的是“編碼字節(jié)與解碼字節(jié)不必成比例”這一語言事實Go 的 SETTINGS 放大利用的是規(guī)范要求“一幀調(diào)整所有窗口”這條 MUST。四處都是規(guī)范或設(shè)計原本就允許的可能性而不是實現(xiàn)偏離了規(guī)范。 這個區(qū)分決定了后面三種形狀的分析方式——要找的不是誰違反了規(guī)定而是規(guī)定本身在哪里留下了記賬與資源之間的缺口。三種形狀為什么會在同一族里同時出現(xiàn)這三種錯配不是三個獨立的缺陷類別它們在同一個協(xié)議族里集中出現(xiàn)有共同原因。共同原因是 HTTP/2 的限流機制全部建立在“用協(xié)議可見的量去約束協(xié)議不可見的資源”這個做法上。協(xié)議能觀測到的是幀、流的狀態(tài)遷移、線上的字節(jié)而真正被消耗的是內(nèi)存、CPU、后端連接。這兩組量之間沒有恒定的換算關(guān)系壓縮比讓字節(jié)與內(nèi)存脫鉤后端處理時間讓狀態(tài)遷移與工作量脫鉤實現(xiàn)的分配結(jié)構(gòu)讓字段與內(nèi)存脫鉤。三個脫鉤點各自產(chǎn)生一種錯配形狀。這個解釋也說明為什么修法是“加獨立限制”而不是“調(diào)準(zhǔn)閾值”閾值調(diào)準(zhǔn)只在一個換算比下成立而三個脫鉤點都是攻擊者可以調(diào)節(jié)的。Envoy 與 h2o 分別給解碼后的頭部狀態(tài)加了獨立限制道理在這里獨立的限制等于在不可見的資源側(cè)也放一個計量讓兩個計量互相約束。反過來看這也解釋了 §8.1.1 那條對賬規(guī)則為什么是有效的它同時擁有兩個計量。這一族里所有真正管住的限制都是兩個計量互相約束的形式所有被繞過的限制都是單個計量加一個閾值。這個區(qū)分可以當(dāng)成一個通用判據(jù)用。一個可以直接用的檢查順序三種形狀給了一個可以照著走的檢查順序。先查第三種因為成本最低把自己的頭部大小校驗、尾部分配、cookie 處理、流控額度退還這幾處的字段集合列出來比對限制器的覆蓋面與分配的覆蓋面是否一致。這一步只需要讀自己的代碼。再查第二種因為它決定了第一種的后果有多大找出所有“用超時判斷對端狀態(tài)”的地方看能不能換成 SETTINGS 或 PING 的確認(rèn)。規(guī)范在 §5.1 與 §6.5.3 里已經(jīng)把這兩條路徑的區(qū)別寫清楚了。最后查第一種因為它最依賴對依賴庫的理解把每一個“頭部大小”類的限制項找出來確認(rèn)它計的是編碼字節(jié)還是解碼字節(jié)如果答案是前者那么它約束的不是內(nèi)存。Envoy 與 h2o 的記錄都指向同一個結(jié)論解碼后的頭部狀態(tài)需要一個自己的上限而不是靠編碼字節(jié)的上限去近似。具體到每一處可以問的問題是這樣。第三種這個限制器校驗的字段集合與它后面那次分配的字段集合是不是同一個如果不是差的那幾個字段由誰負(fù)責(zé)。第二種這里的超時是為了判斷什么如果是判斷對端是否還在處理那 RFC 9113 §5.1 已經(jīng)給了替代做法用 SETTINGS 或 PING 的確認(rèn)作為同步點讓協(xié)議的同步時刻盡量貼近真實的處理邊界。第一種這個限制項設(shè)的是編碼字節(jié)還是解碼字節(jié)如果設(shè)置項的名字里看不出來就去讀實現(xiàn)里它被拿去比較的那個變量是什么單位。三處問完會得到一張清單上面寫著哪些限制器在給自己計的名哪些在給被保護(hù)的資源計量。這張清單本身比任何一個閾值都更有用因為它指出了哪些限制的失效不是“調(diào)大調(diào)小”的問題。這三個順序不是按危害排的而是按能否在本項目內(nèi)查清排的。第三種完全在自己的代碼里第二種要對著規(guī)范核對第一種要讀別人的實現(xiàn)或者把自己的閾值按最壞壓縮比重新推一遍。