std::ranges 這個(gè)名字我在 C20 標(biāo)準(zhǔn)發(fā)布之前就開始關(guān)注了。說實(shí)話最早我并沒有當(dāng)回事無非是把begin()/end()這對迭代器包裝成一個(gè)“范圍”再丟給算法看起來就是一層語法糖。直到一次項(xiàng)目重構(gòu)我面對一段三層嵌套循環(huán)加兩個(gè)中間 vector 的舊代碼用 ranges 改寫后邏輯突然變得清清楚楚中間容器的生命周期糾纏也順手消失了我才意識到這套東西比“少打幾個(gè)字符”要深刻得多。這篇文章不打算把標(biāo)準(zhǔn)文檔抄一遍而是從實(shí)際寫業(yè)務(wù)代碼的角度把std::ranges最常用、也最容易出錯(cuò)的幾個(gè)操作拆開講透。適合已經(jīng)掌握 STL 基礎(chǔ)、但還沒系統(tǒng)用過 ranges 的開發(fā)者也適合正在評估要不要把舊代碼遷到 ranges 的團(tuán)隊(duì)?？赐昴銜?huì)理解為什么視圖是惰性的、管道順序?yàn)槭裁磿?huì)影響結(jié)果、哪些坑是看文檔看不出來的。1. 從迭代器對到范圍對象std::ranges 到底解決了什么1.1 一個(gè)三行改寫的具體案例先看一段很常見的舊式寫法。假設(shè)有一組學(xué)生成績要先篩出及格項(xiàng)再把每一項(xiàng)翻倍#include vector #include algorithm #include iterator std::vectorint scores{80, 55, 92, 63, 77, 100, 41}; std::vectorint passed; std::copy_if(scores.begin(), scores.end(), std::back_inserter(passed), [](int n) { return n 60; }); std::vectorint doubled; std::transform(passed.begin(), passed.end(), std::back_inserter(doubled), [](int n) { return n * 2; });這里有兩個(gè)中間容器passed和doubled每個(gè)算法調(diào)用都要寫一對迭代器。代碼本身沒什么錯(cuò)但讀起來注意力會(huì)被分散你要先看算法名再看迭代器參數(shù)最后才明白數(shù)據(jù)是怎么流動(dòng)的。而且迭代器對很容易寫反兩個(gè)容器首尾交錯(cuò)也不是編譯期一定會(huì)暴露的錯(cuò)誤。用std::ranges重寫數(shù)據(jù)流是順著管道往下走的auto pipeline scores | std::views::filter([](int n) { return n 60; }) | std::views::transform([](int n) { return n * 2; }); for (int value : pipeline) { // 直接遍歷最終結(jié)果 }pipeline不是一個(gè)裝滿數(shù)據(jù)的容器它是一條“取數(shù)規(guī)則”。每次循環(huán)取出下一個(gè)值時(shí)才會(huì)臨時(shí)計(jì)算一次先判斷是否及格及格了就翻倍然后交給你。整個(gè)過程沒有分配任何一個(gè)中間 vector。如果你確實(shí)需要把結(jié)果收集成 vectorC20 下可以這樣做std::vectorint result; std::ranges::copy(pipeline, std::back_inserter(result));C23 以后更省事直接用std::ranges::toauto result scores | std::views::filter([](int n) { return n 60; }) | std::views::transform([](int n) { return n * 2; }) | std::ranges::tostd::vectorint();這個(gè)改動(dòng)帶給我的直觀感受是處理步驟一多舊寫法每多一層就要新建一個(gè)容器并且新容器里的數(shù)據(jù)是“舊狀態(tài)”的副本如果源數(shù)據(jù)在中間被修改臨時(shí)結(jié)果不會(huì)自動(dòng)同步。而視圖鏈?zhǔn)窃磾?shù)據(jù)的實(shí)時(shí)投影你改源數(shù)據(jù)視圖讀到的就是新值。1.2 sentinel 和范圍抽象不是語法糖的三個(gè)理由如果 ranges 只是把 begin/end 打包那確實(shí)不值得專門學(xué)習(xí)。真正讓它區(qū)別于“迭代器對”的是標(biāo)準(zhǔn)里引入的 sentinel 概念。傳統(tǒng) STL 算法要求兩個(gè)迭代器類型完全一致sort(begin, end)begin和end都是vectorint::iterator。但很多范圍的“終點(diǎn)”并不需要一個(gè)真實(shí)迭代器。例如 C 風(fēng)格數(shù)組的終點(diǎn)是一個(gè)“不知道何時(shí)結(jié)束”的特殊標(biāo)記輸入流視圖的終點(diǎn)是“讀到 EOF 再說”某些自定義范圍只需要一個(gè)計(jì)數(shù)條件。std::ranges里的end()返回的不一定是迭代器可能是 sentinel只要它支持與迭代器比較相等即可。這意味著什么看一個(gè)標(biāo)準(zhǔn)算法的新用法int arr[] {4, 2, 5, 1, 3}; std::ranges::sort(arr); // 直接排序整個(gè)數(shù)組老寫法你得寫std::sort(arr, arr 5)手動(dòng)把數(shù)組首地址和尾地址算出來。ranges 版本不需要因?yàn)閟td::ranges::sort接受的是“整個(gè)范圍對象”而數(shù)組天然是一個(gè) range。再比如std::views::counted它用“起始迭代器 元素個(gè)數(shù)”描述一個(gè)范圍終點(diǎn)類型和起點(diǎn)類型完全不同int arr[] {1, 2, 3, 4, 5}; for (int value : std::views::counted(arr, 3)) { // 依次得到 1, 2, 3 }這種“異構(gòu)的起點(diǎn)和終點(diǎn)”在傳統(tǒng)算法模板里幾乎是不可想象的。范圍抽象統(tǒng)一了它們所有std::ranges算法都能直接處理不需要你把范圍手動(dòng)轉(zhuǎn)換成同類型迭代器對。還有一點(diǎn)容易被低估把 range 直接傳給算法后模板約束能更早發(fā)現(xiàn)錯(cuò)誤。你傳入一個(gè)不是隨機(jī)訪問范圍的對象去排序編譯錯(cuò)誤的是“該算法要求 random_access_range”而不是報(bào)一堆深埋在一千行實(shí)例化模板里的內(nèi)部類型錯(cuò)誤。對維護(hù)者來說這種提示友好得多。2. 視圖、適配器與惰性求值管道符背后的執(zhí)行模型2.1 view 是“延遲裝配的流水線”很多初學(xué)者把scores | filter(...) | transform(...)理解成“先算出一個(gè)過濾后的臨時(shí)容器再算出另一個(gè)臨時(shí)容器”。這是最大的誤解。視圖鏈不會(huì)產(chǎn)生任何中間容器甚至不會(huì)立刻執(zhí)行任何計(jì)算。我在解釋惰性求值時(shí)喜歡用一個(gè)帶計(jì)數(shù) lambda 的例子?？聪旅孢@段代碼transform里的函數(shù)到底會(huì)被調(diào)用多少次#include ranges #include iostream int calls 0; auto pipeline std::views::iota(0, 10) | std::views::transform([calls](int n) { calls; return n * n; }) | std::views::take(3); for (int x : pipeline) { std::cout x ; } std::cout calls calls \n;你可能以為源序列有 10 個(gè)元素所以transform至少會(huì)被調(diào)用 10 次。實(shí)際上calls的值是 3因?yàn)閠ake(3)只需要消費(fèi)前 3 個(gè)結(jié)果就停了。iota(0, 10)雖然理論上能產(chǎn)出 0 到 9但視圖鏈?zhǔn)恰鞍葱枥　钡难h(huán)體要一個(gè)值流水線才處理一個(gè)值處理完 3 個(gè)就結(jié)束后面 7 個(gè)根本不碰。這個(gè)特性的價(jià)值在于計(jì)算成本與消費(fèi)量成正比。如果今天取的是前 3 個(gè)明天改成前 100 個(gè)源代碼不用變運(yùn)行開銷自動(dòng)跟著縮放。另一個(gè)實(shí)際好處是視圖鏈可以操作“無限序列”。std::views::iota(1)表示從 1 開始一直遞增的整數(shù)值沒有終點(diǎn)。你沒辦法把無限序列塞進(jìn) vector但你可以先用take(5)截?cái)嗨傧M(fèi)auto first_five std::views::iota(1) | std::views::take(5); for (int x : first_five) { std::cout x ; // 輸出 1 2 3 4 5 }我第一次理解這個(gè)用法時(shí)才真正意識到“范圍”和“容器”是兩種東西容器負(fù)責(zé)擁有數(shù)據(jù)范圍負(fù)責(zé)描述“如何取數(shù)據(jù)”。視圖是后者它可以沒有邊界也正因?yàn)闆]有邊界才衍生出無窮的組合空間。2.2 管道順序會(huì)影響語義不只是影響性能管道順序這件事很多人一開始都不當(dāng)回事。filter和transform換一下位置有時(shí)結(jié)果一樣有時(shí)完全不一樣。原因很簡單視圖鏈?zhǔn)菑淖蟮接乙来沃鹪靥幚淼拿總€(gè)操作符都只處理前面操作符“放行”的元素。std::vectorint data{1, 2, 3, 4, 5, 6}; auto a data | std::views::filter([](int n) { return n % 2 0; }) | std::views::take(3); auto b data | std::views::take(3) | std::views::filter([](int n) { return n % 2 0; });a的語義是“在整個(gè)序列里找前 3 個(gè)偶數(shù)”結(jié)果是 2、4、6b的語義是“先取序列前 3 個(gè)元素再在這 3 個(gè)里篩偶數(shù)”結(jié)果是 2總共就一個(gè)偶數(shù)。如果把take換成transform順序的影響更隱蔽auto c data | std::views::filter(ok) | std::views::transform(expensive);transform里的expensive只對通過ok的元素執(zhí)行。反過來寫auto d data | std::views::transform(expensive) | std::views::filter(ok);expensive會(huì)對所有元素執(zhí)行一遍再讓filter挑選。這個(gè)差異在純代碼閱讀時(shí)看不出來但運(yùn)行耗時(shí)差別可能很大。所以我在寫管道時(shí)有一個(gè)習(xí)慣把“篩選”盡量放在前面把“昂貴計(jì)算”盡量放在后面讓后者只處理真正需要的元素。3. 組合視圖的邊界能力iota、take/drop、split 與無限序列3.1 views::iota不用手寫循環(huán)變量生成連續(xù)整數(shù)很多人第一時(shí)間想到for (int i 0; i n; i)。在 ranges 語境下views::iota可以把“數(shù)值序列”作為一個(gè)值傳遞、組合for (int i : std::views::iota(0, 5)) { // i 0, 1, 2, 3, 4半開區(qū)間不包含 5 } auto indices std::views::iota(0, static_castint(data.size())); for (int idx : indices) { // idx 0, 1, 2, ..., data.size()-1 }iota(0, 5)是有限序列iota(0)是無限序列。無限序列在搭配take、transform時(shí)非常有價(jià)值。例如需要生成“前 20 個(gè) 3 的倍數(shù)”auto multiples std::views::iota(1) | std::views::transform([](int n) { return n * 3; }) | std::views::take(20);iota的另一個(gè)實(shí)用場景是給元素生成序號。比如有一個(gè)名單names想輸出“序號-姓名”可以用zipC23或者直接疊加iota和transformfor (int i : std::views::iota(0, static_castint(names.size()))) { std::cout (i 1) : names[i] \n; }不過要提醒一句iota生成無限序列時(shí)那只是“迭代時(shí)按規(guī)則產(chǎn)出值”不代表范圍本身適合塞進(jìn)所有算法。不要把無限視圖直接傳給std::ranges::size或期望它能被完整遍歷。必須先用take之類適配器截?cái)嗖拍軅鹘o那些需要具體元素?cái)?shù)量的操作。3.2 輸入流視圖與 split處理逐行數(shù)據(jù)不再需要中間緩存std::views::istream是我最早喜歡上 ranges 的一個(gè)特性。它能把輸入流變成按元素讀取的視圖逐詞、逐行消費(fèi)數(shù)據(jù)天然具備惰性。假設(shè)有一個(gè)字符串流每行一個(gè)姓名#include sstream std::istringstream input(alice\nbob\ncarol\ndave); auto names std::views::istreamstd::string(input) | std::views::take(2); for (const auto name : names) { // 只會(huì)讀到 alice、bob }istream_view每次迭代時(shí)才從流里讀取一次讀到take(2)滿足后就不再消費(fèi)后面的內(nèi)容。這個(gè)行為的工程意義很大如果輸入來自一個(gè)大文件傳統(tǒng)做法往往先加載全部內(nèi)容到 vector 再處理這里可以邊讀邊處理內(nèi)存占用與文件大小無關(guān)。但要注意istream_view是單向輸入范圍只能順序遍歷一次不能反復(fù)begin()也不能隨機(jī)訪問。這是輸入流的天然限制不是 ranges 的缺陷寫代碼時(shí)要心里有數(shù)。split視圖也是高頻用法。處理 CSV 或分號分隔的字符串相當(dāng)方便std::string csv apple,banana,cherry; for (auto part : csv | std::views::split(,)) { std::string_view word(part.begin(), part.end()); // word 依次是 apple、banana、cherry }這里有個(gè)初學(xué)者容易懵的細(xì)節(jié)split產(chǎn)出的每個(gè)part不是一個(gè)string_view而是一個(gè)子范圍subrange。在 C20 下你要自己用part.begin()和part.end()構(gòu)造string_viewC23 可以直接用std::string_view(part)構(gòu)造。如果直接拿part當(dāng)字符串用編譯器會(huì)報(bào)類型錯(cuò)誤這不是代碼質(zhì)量問題而是 API 設(shè)計(jì)就是這樣。4. 生命周期懸垂、復(fù)制限制與 borrowed ranges最該警惕的坑4.1 視圖不擁有數(shù)據(jù)別在返回時(shí)引用局部容器這是我見過最嚴(yán)重、也最難排查的 ranges 問題視圖本身不持有數(shù)據(jù)它只持有“如何從底層數(shù)據(jù)取數(shù)”的規(guī)則。如果底層數(shù)據(jù)銷毀了視圖就成了懸垂引用?？催@段代碼auto bad_view() { std::vectorint data{1, 2, 3, 4, 5, 6}; return data | std::views::filter([](int n) { return n % 2 0; }); } auto evens bad_view(); for (int n : evens) { // 未定義行為data 已經(jīng)銷毀 }函數(shù)bad_view返回一個(gè)filter_view里面保存的是對局部 vectordata的引用。函數(shù)返回時(shí)data被銷毀返回的視圖變成懸垂?fàn)顟B(tài)。最麻煩的是編譯器通常不會(huì)報(bào)錯(cuò)因?yàn)槟銢]有語法錯(cuò)誤只是運(yùn)行時(shí)行為不可控——可能偶爾正?？赡鼙罎⒖赡墚a(chǎn)生臟數(shù)據(jù)。為什么我不能直接把data | std::views::filter(...)的臨時(shí)結(jié)果“復(fù)制”出來因?yàn)?view 的拷貝是淺拷貝拷貝的是規(guī)則不是數(shù)據(jù)。數(shù)據(jù)到底歸誰管完全由你自己負(fù)責(zé)。正確的設(shè)計(jì)有這么幾種:數(shù)據(jù)由調(diào)用方持有函數(shù)通過參數(shù)接收數(shù)據(jù)只返回視圖auto get_evens(std::spanint data) { return data | std::views::filter([](int n) { return n % 2 0; }); }因?yàn)閟td::span是借用范圍它只引用調(diào)用方已有的數(shù)組函數(shù)返回的視圖生命周期與調(diào)用方持有的數(shù)據(jù)一致安全。如果函數(shù)需要獨(dú)立返回?cái)?shù)據(jù)就直接返回容器把視圖物化std::vectorint get_evens_as_container(const std::vectorint data) { auto view data | std::views::filter([](int n) { return n % 2 0; }); return {view.begin(), view.end()}; // C20 下可以這樣收集 }這里要做一個(gè)清晰的判斷如果返回容器有拷貝/移動(dòng)開銷那就用借用參數(shù)如果調(diào)用方更方便擁有新數(shù)據(jù)就物化成容器。不要在“返回引用局部數(shù)據(jù)的視圖”這條路上走。4.2 謂詞和函數(shù)對象捕獲的生命周期數(shù)據(jù)生命周期之外謂詞的生命周期也容易被忽略。當(dāng)視圖在函數(shù)結(jié)束時(shí)被返回而謂詞捕獲了函數(shù)的局部狀態(tài)就會(huì)產(chǎn)生第二類懸垂auto get_above(const std::vectorint data, int threshold) { return data | std::views::filter([threshold](int n) { return n threshold; }); }threshold是函數(shù)形參按值傳入。lambda 用threshold捕獲了形參的引用。函數(shù)返回后形參變量銷毀lambda 里的引用懸垂。正確寫法是把threshold按值捕獲auto get_above(const std::vectorint data, int threshold) { return data | std::views::filter([threshold](int n) { return n threshold; }); }這個(gè)坑的隱蔽程度更高因?yàn)樗簧婕叭萜髦簧婕耙粋€(gè) int 變量。表面上看“閾值”始終是那個(gè)值但因?yàn)樗蔷植可芷谝坏┓祷啬憔筒冗M(jìn)了未定義行為區(qū)域。我現(xiàn)在的習(xí)慣是凡是返回視圖的函數(shù)謂詞一律按值捕獲必要狀態(tài)或者用shared_ptr管理共享狀態(tài)絕不在 lambda 里隱式引用棧上變量。4.3 filter_view 為何不可復(fù)制、split_view 的狀態(tài)性以及 borrowed range 規(guī)則接觸 ranges 一段時(shí)間后你會(huì)遇到一個(gè)讓人困惑的報(bào)錯(cuò)想復(fù)制一個(gè)filter_view編譯器說拷貝構(gòu)造被刪除。auto v1 data | std::views::filter(pred); auto v2 v1; // C20 下不合法原因在標(biāo)準(zhǔn)實(shí)現(xiàn)里filter_view為了在常數(shù)時(shí)間內(nèi)返回begin()需要緩存“起始迭代器”。這份緩存是視圖的內(nèi)部狀態(tài)而視圖本身又不是共享所有權(quán)結(jié)構(gòu)所以標(biāo)準(zhǔn)直接禁用了拷貝構(gòu)造成員。split_view也有類似的狀態(tài)性問題。這個(gè)限制提醒我視圖不是普通值對象不要試圖把它當(dāng)快照到處傳。如果你需要一個(gè)可以反復(fù)使用、可以拷貝的“過濾結(jié)果”請物化成 vectorstd::vectorint snapshot ...; // 直接拷貝數(shù)據(jù) auto v1 snapshot | std::views::filter(pred); auto v2 snapshot | std::views::filter(pred); // 基于同一份數(shù)據(jù)生成兩個(gè)視圖再看 borrowed range 規(guī)則。range分為“借用范圍”和“非借用范圍”view、span、subrange是借用的表示它們不擁有數(shù)據(jù)vector、string、array不是借用的數(shù)據(jù)歸自己管。標(biāo)準(zhǔn)因此規(guī)定右值容器不能直接作為視圖鏈的輸入因?yàn)榕R時(shí)容器產(chǎn)生的視圖在表達(dá)式結(jié)束后必然懸垂。auto v std::vectorint{1, 2, 3} | std::views::transform(...); // 按標(biāo)準(zhǔn)這是不合適的臨時(shí) vector 是右值非借用范圍主流實(shí)現(xiàn)會(huì)拒絕這個(gè)組合而不是默默產(chǎn)生懸垂視圖。如果你在網(wǎng)上看到用臨時(shí)容器拼接視圖的示例要么是舊編譯器寬松行為要么是在 C23 里有其他容器機(jī)制支持落地生產(chǎn)代碼時(shí)一定不要照抄。我自己在這個(gè)問題上栽過一次跟頭早期版本編譯器放行了臨時(shí)容器管道上線后偶發(fā)崩潰排查了很久才發(fā)現(xiàn)是視圖引用了臨時(shí)容器的已釋放內(nèi)存。5. 性能、調(diào)試與視圖鏈的工程化落地5.1 編譯時(shí)間、運(yùn)行性能和調(diào)試體驗(yàn)的真實(shí)權(quán)衡ranges 不是銀彈它有自己的成本。先說編譯期ranges頭文件是出了名的模板重災(zāi)區(qū)。一個(gè)項(xiàng)目如果大量使用視圖組合編譯時(shí)間會(huì)比手寫循環(huán)明顯增加。我經(jīng)歷過一個(gè)中等規(guī)模模塊引入 ranges 后該模塊的編譯時(shí)間從 20 秒左右漲到 25 秒尚可接受但大型庫全量使用時(shí)要做好心理準(zhǔn)備。運(yùn)行期性能則通常不用擔(dān)心。在-O2下視圖鏈的filter、transform等適配器大多能內(nèi)聯(lián)成普通循環(huán)不會(huì)產(chǎn)生額外分配。換句話說ranges 的抽象在編譯器優(yōu)化后常常接近于手寫循環(huán)。這也意味著如果你手寫循環(huán)已經(jīng)復(fù)雜到看不清數(shù)據(jù)流用 ranges 重構(gòu)后性能不會(huì)變差可讀性卻會(huì)大幅提升。最讓我覺得需要適應(yīng)的是調(diào)試體驗(yàn)。視圖的類型非常長比如ranges::filter_viewranges::ref_viewstd::vectorint, lambda層層嵌套斷點(diǎn)步進(jìn)時(shí)你會(huì)看到一堆模板類型。這時(shí)候不要硬看。我常用的手段是在關(guān)鍵位置物化成具體容器確認(rèn)邏輯正確后再把物化點(diǎn)移回邊界// C23 下臨時(shí)快速物化 auto debug_view data | std::views::transform(...) | std::ranges::tostd::vectorint(); // C20 下等價(jià)寫法 std::vectorint debug_view; std::ranges::copy(data | std::views::transform(...), std::back_inserter(debug_view));物化不是性能妥協(xié)而是“調(diào)試期觀察口”。確認(rèn)管道行為無誤再移除物化點(diǎn)交給生產(chǎn)代碼。5.2 投影和 ranges 算法另一個(gè)被低估的生產(chǎn)力點(diǎn)很多人只關(guān)注視圖和管道忽視了std::ranges算法自帶的投影projection能力。投影可以讓你在排序、查找、計(jì)數(shù)時(shí)直接把謂詞作用在字段上少寫大量 lambda?？匆粋€(gè)最典型的場景。按年齡排序一組人struct Person { std::string name; int age; }; std::vectorPerson people { ... }; // 傳統(tǒng)寫法 std::sort(people.begin(), people.end(), [](const Person a, const Person b) { return a.age b.age; }); // ranges 寫法 std::ranges::sort(people, std::less{}, Person::age);第二個(gè)參數(shù)是比較器第三個(gè)參數(shù)是投影。Person::age表示“排序時(shí)只看 age 字段”。std::less{}作用于投影后的值自然比較大小。再比如找年齡最大的auto oldest std::ranges::max_element(people, {}, Person::age);統(tǒng)計(jì)成年人數(shù)int adult_count std::ranges::count_if( people, [](int age) { return age 18; }, Person::age);注意這里的謂詞接收的是投影后的字段值不是整個(gè)Person。這個(gè)設(shè)計(jì)讓代碼意圖非常直白我要的是年齡大于等于 18 的人數(shù)。配合min_element、find、partition等算法投影能刪掉大量“取出字段再比較”的樣板代碼。5.3 遷移策略先小管道后大組合時(shí)刻盯住生命周期如果你的項(xiàng)目還沒有引入 ranges我不建議一次性把所有循環(huán)改寫成視圖鏈。遷移路徑應(yīng)該像是“先在空地上搭個(gè)小棚子再?zèng)Q定要不要蓋大樓”。第一步在新代碼里嘗試單層適配器。比如某個(gè)地方需要把 vector 里的每個(gè)元素翻倍再輸出原來手寫循環(huán)的地方先改成std::views::transform。這個(gè)改動(dòng)風(fēng)險(xiǎn)低、收益直觀。第二步當(dāng)團(tuán)隊(duì)適應(yīng)了單層適配器再引入多層管道但只在“表達(dá)式內(nèi)部”完成組合并立刻物化。不要在類成員變量里保存引用容器的視圖不要在回調(diào)之間傳遞長生命周期視圖。把視圖當(dāng)作一次性的數(shù)據(jù)處理管道用完即走。第三步把函數(shù)的邊界設(shè)計(jì)清楚函數(shù)只接受span或引用參數(shù)返回物化容器這樣生命周期問題被牢牢限制在函數(shù)內(nèi)部。等這套規(guī)則成為團(tuán)隊(duì)共識后再放開那些確實(shí)需要返回借用范圍的場景并且在代碼注釋里顯式寫明“調(diào)用方必須保證數(shù)據(jù)生命周期長于視圖”。我自己的經(jīng)驗(yàn)是把生命周期規(guī)則前置想清楚比后續(xù)排查懸垂引用痛快得多。那些在函數(shù)返回視圖的代碼里掙扎的半天最后十有八九都是局部容器或局部捕獲狀態(tài)造成的。先定好規(guī)則ranges 就能變成非常可靠的工程工具。