你的Makefile里是不是也有這種情節(jié)同一個(gè)編譯規(guī)則復(fù)制粘貼了十幾遍只改一下模塊名和文件路徑我承認(rèn)我干過而且是在一個(gè)模擬項(xiàng)目的三十多個(gè)子模塊上干的每次新增模塊都要手動(dòng)補(bǔ)規(guī)則、補(bǔ)依賴、補(bǔ)清理清單漏一條就讓你在深夜對(duì)著構(gòu)建日志發(fā)呆。后來真正把GNU Makefile里的eval函數(shù)用起來才找到治本的辦法把規(guī)則寫成模板讓make自己在解析階段批量生成。eval的定位很樸素——它接收一段文本把這段文本當(dāng)作makefile內(nèi)容現(xiàn)場(chǎng)解析配合define、call、foreach就能實(shí)現(xiàn)自動(dòng)生成規(guī)則。這篇文章把從最小例子到生產(chǎn)級(jí)坑點(diǎn)的完整路徑走一遍適合正在維護(hù)多模塊構(gòu)建、已經(jīng)受夠手寫重復(fù)規(guī)則的人。1. 從第30條重復(fù)規(guī)則說起eval到底幫我省了什么1.1 手工規(guī)則膨脹的典型現(xiàn)場(chǎng)我維護(hù)過一個(gè)模擬項(xiàng)目的構(gòu)建腳本結(jié)構(gòu)大概是這樣的十幾個(gè)子模塊每個(gè)模塊都要先編譯成目標(biāo)文件再鏈接成可執(zhí)行程序還要有一堆按模塊區(qū)分的測(cè)試入口。手工寫下去Makefile長(zhǎng)這樣build/alpha.o: src/alpha.c $(CC) $(CFLAGS) -c $ -o $ build/alpha.bin: build/alpha.o $(CC) $(LDFLAGS) $^ -o $ build/beta.o: src/beta.c $(CC) $(CFLAGS) -c $ -o $ build/beta.bin: build/beta.o $(CC) $(LDFLAGS) $^ -o $模塊一多文件就變成規(guī)則海洋。問題不在于多寫了幾行而在于每次改構(gòu)建策略都要同步改幾十處某天我把CFLAGS統(tǒng)一加了一個(gè)-Werror就得保證所有編譯規(guī)則都改到某個(gè)新模塊忘記寫目錄依賴第一次構(gòu)建必掛。最要命的是這類文件沒法review出結(jié)構(gòu)大家只會(huì)逐行看有沒有拼錯(cuò)。復(fù)制粘貼還有一個(gè)隱形成本它讓規(guī)則的一致性變成了一種人工約定。只要有一次只改了A模塊沒改B模塊后續(xù)的構(gòu)建產(chǎn)物就開始悄悄不一致。我后來統(tǒng)計(jì)過手工維護(hù)階段這類漏改導(dǎo)致的構(gòu)建問題占了一半以上。1.2 eval在make里的真正位置簡(jiǎn)單說make在執(zhí)行recipe之前要先花一段時(shí)間把整個(gè)makefile讀進(jìn)來解析變量、規(guī)則、依賴構(gòu)建出一張依賴圖這個(gè)過程叫讀入階段。eval就是在讀入階段生效的——它把一段文本現(xiàn)場(chǎng)變成makefile文本再現(xiàn)場(chǎng)解析。你可以把它理解為在makefile內(nèi)部裝了一個(gè)宏處理器。這跟函數(shù)式編程里的代碼生成代碼很像eval先把模板里的占位符換成真實(shí)值生成一段makefile片段然后這段片段和手寫的規(guī)則沒有任何區(qū)別會(huì)被make當(dāng)成普通規(guī)則加入依賴圖。所以生成的規(guī)則和手寫的規(guī)則是平級(jí)的后續(xù)的依賴解析、并行構(gòu)建、make -n試運(yùn)行全都一視同仁。需要注意這是GNU Make的功能特性。BSD make、nmake這類工具要么沒有對(duì)應(yīng)的eval要么語法完全不同。如果項(xiàng)目明確要求跨多種make工具移植用eval之前要想清楚或者評(píng)估能否接受僅支持GNU Make這個(gè)前提。1.3 什么項(xiàng)目值得上eval兩道判斷題我一般用兩個(gè)問題來判斷這些規(guī)則是不是同構(gòu)的也就是除了名字、路徑、參數(shù)不同結(jié)構(gòu)完全一樣。數(shù)量是不是大到手動(dòng)維護(hù)會(huì)出錯(cuò)一般來說超過五六個(gè)同構(gòu)目標(biāo)就開始值得了。如果目標(biāo)少于五個(gè)而且每個(gè)規(guī)則差異都很大比如有的要調(diào)內(nèi)置工具、有的要跑外部腳本、有的要特殊后處理那強(qiáng)行套eval反而把簡(jiǎn)單問題復(fù)雜化。eval最適合的場(chǎng)景是大量同構(gòu)目標(biāo) 少量差異化參數(shù)這時(shí)候它才能把規(guī)則的重復(fù)度壓到最低讓新增模塊變成一行列表項(xiàng)。團(tuán)隊(duì)對(duì)GNU Make的接受度也要考慮。如果整個(gè)構(gòu)建體系里已經(jīng)大量使用了$(call)、$(foreach)這類函數(shù)式語法那么引入eval幾乎沒有額外學(xué)習(xí)成本。如果團(tuán)隊(duì)還停留在makefile就是寫規(guī)則的認(rèn)知上那這篇文章后面的內(nèi)容反而是最好的入門教材。2. 先跑通再理解define、call與make的兩遍解析2.1 最小可復(fù)現(xiàn)例子先從最簡(jiǎn)單的例子跑通。下面這個(gè)makefile定義了一個(gè)模板生成兩個(gè)目標(biāo)define greeting_rule say_$(1): echo hello, $$ endef $(eval $(call greeting_rule,one)) $(eval $(call greeting_rule,two))這里有個(gè)關(guān)鍵細(xì)節(jié)say_$(1):下面那行recipe縮進(jìn)必須是真實(shí)的Tab字符不是空格。define/endef會(huì)把中間的內(nèi)容原樣保存包括這個(gè)Tabeval解析時(shí)才能認(rèn)出它是recipe。運(yùn)行make say_one你應(yīng)該看到hello, say_one這短短幾行里其實(shí)串起了四個(gè)概念define定義多行變量$(1)是模板參數(shù)占位符$(call ...)把參數(shù)傳入模板$(eval ...)把展開后的文本當(dāng)作makefile內(nèi)容解析。整條鏈路就是模板 - 替換 - 解析。我把這個(gè)例子拆開說是因?yàn)楹芏嗳艘簧蟻砭蛯憦?fù)雜模板結(jié)果編譯報(bào)錯(cuò)也不知道是語法問題還是轉(zhuǎn)義問題。先把最小鏈路跑通再往上加?xùn)|西排查范圍會(huì)小很多。2.2 兩遍解析讀入期與執(zhí)行期理解eval必須理解make處理makefile的兩遍過程。第一遍是讀入期。make逐行讀取makefile解析變量賦值、規(guī)則定義、依賴關(guān)系最終形成一張完整的依賴圖。$(eval ...)調(diào)用就發(fā)生在這一遍它邊生成文本邊解析相當(dāng)于在讀入過程中不斷往依賴圖里追加內(nèi)容。第二遍是執(zhí)行期。make拿到依賴圖之后檢查哪些目標(biāo)過期然后按依賴順序執(zhí)行recipe。注意recipe里的變量不是讀入期就展開的而是延遲到執(zhí)行期、每一條shell命令執(zhí)行前才展開。這就是recipe延遲展開機(jī)制。這兩遍分開的代價(jià)是eval的參數(shù)本身會(huì)被make先展開一次。寫$(eval $(call xxx))的時(shí)候make會(huì)先把$(call xxx)展開成一段makefile文本然后才去解析這段文本。所以模板里凡是想原樣留給執(zhí)行期的變量引用都必須多寫一個(gè)$。這直接引出下面這個(gè)最容易被繞暈的轉(zhuǎn)義問題。2.3 立即展開、延遲展開與那對(duì)$$我見過太多人在eval模板里被$$折磨。其實(shí)規(guī)則就一條eval參數(shù)展開時(shí)$()會(huì)立刻取值$$()經(jīng)過展開后蛻變成$()原樣寫進(jìn)解析結(jié)果為recipe留到執(zhí)行期再展開。在模板里寫eval展開后存入數(shù)據(jù)庫(kù)最終執(zhí)行效果$(CFLAGS)CFLAGS的當(dāng)前值生成時(shí)快照后續(xù)改動(dòng)不影響$$(CFLAGS)文本$(CFLAGS)執(zhí)行recipe時(shí)才取CFLAGS的值$$$執(zhí)行時(shí)自動(dòng)變量目標(biāo)名$空字符串讀入期沒有目標(biāo)上下文直接丟掉最后一行的坑最典型$是自動(dòng)變量只有執(zhí)行recipe時(shí)才有意義。在eval參數(shù)展開階段make根本不在任何規(guī)則上下文里$就是空串。所以模板里的自動(dòng)變量必須寫成$$、$$、$$^。我的經(jīng)驗(yàn)法則是模板里所有希望最終在recipe里展開的東西一律寫成$$開頭寧可多轉(zhuǎn)義不要少轉(zhuǎn)義。3. 實(shí)戰(zhàn)從源文件列表批量生成編譯規(guī)則3.1 foreach call eval三連的完整骨架現(xiàn)在把前面幾塊拼起來做一個(gè)真正能用的編譯規(guī)則生成器。假設(shè)有三個(gè)模塊alpha、beta、gamma每個(gè)模塊有一個(gè)源文件APPS : alpha beta gamma define app_rule build/$(1).o: src/$(1).c | build_dir $$(CC) $$(CFLAGS) -c $$ -o $$ build/$(1).bin: build/$(1).o $$(CC) $$(LDFLAGS) $$^ -o $$ endef $(foreach app,$(APPS),$(eval $(call app_rule,$(app)))) build_dir: mkdir -p build .PHONY: build_dir$(foreach app,$(APPS),...)的語義是遍歷APPS列表每輪把當(dāng)前值賦給變量app并展開循環(huán)體文本。展開體里調(diào)用了$(call app_rule,$(app))于是每個(gè)模塊名都會(huì)被代入模板生成兩到三行規(guī)則文本最后交給$(eval)解析。這么一來APPS列表成了唯一的事實(shí)來源。新增一個(gè)模塊只需要在列表里加一行編譯規(guī)則、鏈接規(guī)則、目錄依賴全部自動(dòng)生成。我把這個(gè)模式叫作三連foreach負(fù)責(zé)遍歷call負(fù)責(zé)傳參eval負(fù)責(zé)落地。| build_dir是order-only前置依賴意思是構(gòu)建前必須先執(zhí)行build_dir的recipe但它的時(shí)間戳變化不觸發(fā)本目標(biāo)重編。目錄這種資源時(shí)間戳每構(gòu)建一次都會(huì)變?nèi)绻麑懗善胀ㄒ蕾嚂?huì)導(dǎo)致所有目標(biāo)每次都被判為過時(shí)那是純粹浪費(fèi)。這個(gè)細(xì)節(jié)別忽略。3.2 把差異化參數(shù)收進(jìn)模板每模塊一套編譯選項(xiàng)同構(gòu)規(guī)則最常見的變體是編譯參數(shù)不一樣。比如alpha要開-O2和宏定義beta要開-g做調(diào)試。手工階段這類差異是靠復(fù)制粘貼不同CFLAGS行實(shí)現(xiàn)的用eval可以把參數(shù)做成每模塊一個(gè)變量模板里按目標(biāo)名拼變量名APPS : alpha beta CFLAGS_alpha : -O2 -DALPHA CFLAGS_beta : -O0 -g -Wall define app_rule obj/$(1).o: src/$(1).c $$(CC) $$(CFLAGS_$(1)) -c $$ -o $$ endef $(foreach app,$(APPS),$(eval $(call app_rule,$(app))))注意$$(CFLAGS_$(1))的處理順序$(call)先把$(1)替換成模塊名比如alpha模板就變成$$(CFLAGS_alpha)eval參數(shù)展開時(shí)$$蛻變成$存進(jìn)數(shù)據(jù)庫(kù)的是$(CFLAGS_alpha)等到執(zhí)行recipe時(shí)才真正去讀CFLAGS_alpha變量的值。所以這個(gè)模板既捕獲了每模塊不同參數(shù)的差異又保持了參數(shù)可以后定義的靈活性——CFLAGS_alpha放在foreach前還是后都不影響最終結(jié)果。這套寫法比每個(gè)模塊復(fù)制一行CFLAGS干凈得多。以后想看某模塊用了什么編譯選項(xiàng)直接看變量定義區(qū)想統(tǒng)一加選項(xiàng)改一處全局的也沒問題。3.3 順手生成目錄規(guī)則、clean入口與all收口eval還有一個(gè)經(jīng)常被忽略的能力它生成的文本里可以包含普通的變量賦值語句。也就是說eval不僅能生成規(guī)則還能在生成的同一次解析中執(zhí)行TARGETS ...這類賦值。利用這一點(diǎn)我們可以讓模板自動(dòng)收集自己生成的目標(biāo)TARGETS : define app_rule bin/$(1): obj/$(1).o $$(CC) $$(LDFLAGS) $$ -o $$ obj/$(1).o: src/$(1).c $$(CC) $$(CFLAGS) -c $$ -o $$ TARGETS bin/$(1) endef $(foreach app,$(APPS),$(eval $(call app_rule,$(app)))) all: $(TARGETS)這里有一個(gè)極其關(guān)鍵的順序問題all: $(TARGETS)這一行必須放在foreach之后。原因在于make在解析all:規(guī)則時(shí)會(huì)立刻展開$(TARGETS)來得到依賴列表除非開了.SECONDEXPANSION。如果all寫在foreach前面那一刻TARGETS還是空的等于定義了all:沒有任何依賴。這跟變量要先用后算是兩回事純粹是解析順序?qū)е碌摹：芏喑鯇W(xué)者在這里卡住以為是eval沒生效其實(shí)是規(guī)則位置錯(cuò)了。clean規(guī)則也可以順手補(bǔ)上。既然所有構(gòu)建產(chǎn)物都集中在build、obj、bin幾個(gè)目錄里清理就很省事clean: rm -rf build obj bin整個(gè)構(gòu)建腳本現(xiàn)在只剩三部分模塊清單、模板定義、foreach生成區(qū)。手工Makefile里那種上百行規(guī)則海洋徹底消失了。4. 讓生成的規(guī)則互相引用元數(shù)據(jù)收集與自動(dòng)變量細(xì)節(jié)4.1 eval不僅能生成規(guī)則還能生成聲明和賦值如果你以為eval只能生成目標(biāo): 依賴這種規(guī)則行那就浪費(fèi)了一半功力。eval生成的文本可以是任何makefile合法內(nèi)容變量賦值、偽目標(biāo)聲明、include指令甚至另一個(gè)$(eval)的調(diào)用文本。比如給每個(gè)模塊生成一個(gè)自檢入口define app_rule .PHONY: run_$(1) run_$(1): bin/$(1) ./bin/$(1) --self-check TARGETS bin/$(1) endef模板里.PHONY: run_$(1)這一行經(jīng)過eval解析后會(huì)變成真實(shí)的偽目標(biāo)聲明跟手寫的.PHONY效果一致。你也可以在模板里給某個(gè)變量做累加把生成規(guī)則和收集規(guī)則信息合在一次eval里完成。這就是元數(shù)據(jù)收集規(guī)則本身進(jìn)了依賴圖規(guī)則的名字也進(jìn)了變量供后續(xù)統(tǒng)一處理?；氐?.1開頭那句包括另一個(gè)eval的調(diào)用文本——技術(shù)上嵌套eval可用但我并不推薦。嵌套會(huì)讓轉(zhuǎn)義層數(shù)指數(shù)級(jí)上升排查問題時(shí)會(huì)極其痛苦。如果你發(fā)現(xiàn)自己需要在一個(gè)模板里再套一層eval先停下來想想是不是可以用兩個(gè)foreach、兩個(gè)模板分階段完成。4.2 自動(dòng)變量轉(zhuǎn)義對(duì)照表與模式規(guī)則取舍前面提過自動(dòng)變量在模板里的轉(zhuǎn)義問題這里給一份完整對(duì)照表方便你寫模板時(shí)直接查自動(dòng)變量含義eval模板里的寫法$目標(biāo)名$$$第一個(gè)前置依賴$$$^所有前置依賴去重$$^$?比目標(biāo)新的前置依賴$$?$*模式規(guī)則中匹配的部分$$*$(D)目標(biāo)所在目錄$$(D)$(F)目標(biāo)文件名部分$$(F)$(D)第一個(gè)前置依賴的目錄$$(D)$(F)第一個(gè)前置依賴的文件名$$(F)這里要提醒一句eval不是萬能的也不是所有規(guī)則都該用eval生成。如果你的目標(biāo)名有嚴(yán)格的字符串規(guī)律比如所有源文件都走obj/%.o: src/%.c直接寫一條模式規(guī)則就夠了一行解決根本不需要模板。eval真正不可替代的場(chǎng)景是目標(biāo)之間是離散的每個(gè)目標(biāo)還帶有獨(dú)立參數(shù)。比如按模塊生成不同名字的二進(jìn)制、按配置生成不同后綴的打包產(chǎn)物這種同構(gòu)但不滿足模式匹配的情況才是eval的主場(chǎng)。4.3 多模塊交叉依賴生成規(guī)則之間如何協(xié)調(diào)實(shí)際項(xiàng)目里模塊之間很少完全獨(dú)立常有A模塊鏈接時(shí)依賴B模塊生成的庫(kù)這種情況。eval生成規(guī)則會(huì)不會(huì)導(dǎo)致依賴順序出問題不會(huì)。讀入期結(jié)束時(shí)make已經(jīng)把所有生成的規(guī)則都收進(jìn)依賴圖了圖的解析發(fā)生在執(zhí)行期。所以在文件里bin模板寫在lib模板前面、還是lib模板寫在bin模板前面對(duì)依賴圖的最終形態(tài)沒有影響。舉例define lib_rule lib/$(1).a: obj/$(1).o $$(AR) rcs $$ $$^ endef define bin_rule bin/$(1): lib/libcore.a $$(CC) $$(LDFLAGS) $$^ -o $$ endef即使bin_rule的foreach寫在lib_rule前面make依然能正確解析出bin/demo依賴lib/libcore.a。真正需要注意的是命名紀(jì)律如果兩個(gè)不同模板生成了同一個(gè)目標(biāo)名make會(huì)報(bào)target given more than once之類錯(cuò)誤。我的習(xí)慣是所有生成目標(biāo)都用$(1)做前綴或子目錄隔離從源頭杜絕目標(biāo)名沖突。5. 我在真實(shí)構(gòu)建里踩過的坑與調(diào)試腳手架5.1 規(guī)則靜默消失展開順序的典型錯(cuò)誤eval最坑的地方在于出錯(cuò)了不一定報(bào)錯(cuò)而是靜默生成空規(guī)則。我踩過最典型的幾個(gè)模板里寫$(CFLAGS)但CFLAGS在foreach之后才定義eval展開時(shí)取到空值生成出來的recipe變成一條沒有編譯參數(shù)的命令編譯卻照樣成功只是產(chǎn)物不對(duì)。修法是模板里統(tǒng)一寫$$(CFLAGS)讓取值延遲到執(zhí)行期。all: $(TARGETS)寫在foreach之前依賴列表展開為空make只輸出Nothing to be done。這個(gè)前面說過位置決定生死。試圖在recipe里調(diào)用$(eval ...)想讓make在每次構(gòu)建時(shí)動(dòng)態(tài)生成新規(guī)則。這是認(rèn)知錯(cuò)誤recipe是執(zhí)行期跑的讀入期早已結(jié)束eval不會(huì)生效。如果你確實(shí)需要每次構(gòu)建時(shí)重新生成規(guī)則正確做法是用$(file ...)把生成的makefile片段寫到磁盤再用include動(dòng)態(tài)包含它。第二條的排查經(jīng)驗(yàn)是遇到目標(biāo)沒生成或命令行為不對(duì)先懷疑展開順序再看轉(zhuǎn)義順序問題的特征是有據(jù)可循比如all放在前面轉(zhuǎn)義問題的特征是生成文本里多了空參數(shù)。5.2 空格縮進(jìn)與missing separator這是eval用戶最容易在復(fù)制代碼時(shí)踩的雷make要求recipe行以Tab開頭這個(gè)要求對(duì)eval生成的文本同樣生效。如果你的編輯器默認(rèn)把Tab轉(zhuǎn)成四個(gè)空格define塊里的recipe行就會(huì)變成空格縮進(jìn)eval解析時(shí)報(bào)錯(cuò)信息通常是missing separator——它不知道這一行該當(dāng)成規(guī)則、變量還是recipe。更隱蔽的情況是模板里有recipe行用了空格縮進(jìn)但前面恰好有一行規(guī)則定義make會(huì)把recipe行解析成游離的雜散文本有時(shí)不報(bào)錯(cuò)只是那條命令永遠(yuǎn)不執(zhí)行。這種不報(bào)錯(cuò)的錯(cuò)最費(fèi)時(shí)間。我的建議是在編輯器里關(guān)掉Tab轉(zhuǎn)空格功能或者在define塊寫完后用sed -n l這種命令檢查一下Tab字符是否真的存在。5.3 $(shell)與$(warning)在eval里的特殊行為eval參數(shù)里如果出現(xiàn)$(shell ...)它會(huì)在每次make解析時(shí)真的執(zhí)行一次shell命令。這意味著有副作用的shell命令寫文件、改系統(tǒng)狀態(tài)放進(jìn)eval里等于每次構(gòu)建都重復(fù)觸發(fā)副作用而且可能因?yàn)椴⑿?、失敗重試等原因產(chǎn)生詭異行為。純查詢類命令讀版本號(hào)、獲取當(dāng)前時(shí)間可以用但也要意識(shí)到它拖慢了讀入階段。比$(shell)更適合調(diào)試eval的是$(warning)和$(info)。這兩個(gè)函數(shù)在展開時(shí)打印消息、返回空字符串用法很直觀。在模板里插一行$(warning now generating rule for $(1))能在foreach循環(huán)時(shí)看到每次調(diào)用的參數(shù)如果放在call之前或之后還能觀察文本生成的位置。我在模板里調(diào)試時(shí)最喜歡的一句是define app_rule $(info [template] target$(1)) ... endef這樣每次$(call)展開模板都會(huì)打印一次當(dāng)前模塊名一眼就能確認(rèn)循環(huán)有沒有跑、參數(shù)傳對(duì)沒有。5.4 調(diào)試腳手架先info打印再eval再make -p最后給一套我屢試不爽的調(diào)試流程。第一步把eval臨時(shí)改成info只看生成的文本不解析# 調(diào)試時(shí)先只打印不解析 $(foreach app,$(APPS),$(info $(call app_rule,$(app)))) # 確認(rèn)文本沒問題再換成 $(foreach app,$(APPS),$(eval $(call app_rule,$(app))))這一步能區(qū)分模板生成錯(cuò)了和規(guī)則解析錯(cuò)了。生成文本如果不對(duì)后面的eval報(bào)什么錯(cuò)都先別管先把模板和轉(zhuǎn)義理順。第二步用make -pR導(dǎo)出make的完整數(shù)據(jù)庫(kù)。-p會(huì)把所有讀入的規(guī)則打印出來-R禁用內(nèi)置規(guī)則減少噪音。在輸出里grep你的目標(biāo)名比如make -pR | grep -A5 build/alpha就能看到eval生成的規(guī)則是否真的進(jìn)了依賴圖依賴寫沒寫對(duì)、recipe是什么全都清清楚楚。第三步make -n做試運(yùn)行只看生成的shell命令不執(zhí)行。這條很關(guān)鍵因?yàn)橐?guī)則進(jìn)沒進(jìn)圖是一回事recipe展開成什么樣子是另一回事。make -n會(huì)讓你直觀地看到$$(CFLAGS)到底展開成了什么如果展開結(jié)果里有空參數(shù)或者$(殘留那基本可以斷定是轉(zhuǎn)義層數(shù)出了問題。還有一點(diǎn)心理準(zhǔn)備eval相關(guān)的報(bào)錯(cuò)信息經(jīng)常指向makefile:0或者一個(gè)不存在的行號(hào)因?yàn)槌鲥e(cuò)的內(nèi)容來自運(yùn)行時(shí)生成的文本make無法回溯到模板的原始位置。所以功能越復(fù)雜的eval模板越要保住命名紀(jì)律和區(qū)域注釋否則半年后你自己也看不懂那段生成代碼。我現(xiàn)在的構(gòu)建腳本里規(guī)則生成區(qū)占了將近一半新增模塊只需要在模塊清單里加一行剩下的事全部交給eval。如果讓我給一個(gè)最重要的習(xí)慣那就是模板文件名統(tǒng)一加前綴清晰標(biāo)識(shí)foreach生成區(qū)集中放在文件底部并配上大段注釋說明這個(gè)區(qū)域只允許改模塊清單和模板不要在這里手寫規(guī)則——這樣團(tuán)隊(duì)里其他人接手時(shí)才不會(huì)把eval生成的東西誤當(dāng)成普通規(guī)則去改。