如果你在項(xiàng)目里遇到過莫名其妙的多了一個(gè)臨時(shí)對(duì)象編譯器居然不報(bào)錯(cuò)就幫我做了類型轉(zhuǎn)換那十有八九就是隱式轉(zhuǎn)換在搞鬼。C 里explicit關(guān)鍵字就是用來攔住這類自作聰明的行為的。它不算新特性C98 就有但很多人要么只知道構(gòu)造函數(shù)能加要么干脆不重視直到線上出了詭異 bug 才回頭翻文檔。這篇文章我會(huì)從隱式轉(zhuǎn)換的本質(zhì)講起把構(gòu)造函數(shù)的explicit、轉(zhuǎn)換運(yùn)算符的explicit、C20 的explicit(bool)全部串起來結(jié)合真實(shí)踩坑場景說清楚什么時(shí)候必須加、加了之后到底改變了什么、哪些坑是加了也躲不掉的。適合剛?cè)腴T C 不久的新人也適合正被隱式轉(zhuǎn)換折磨的工程實(shí)踐者。1. explicit 到底在解決什么問題1.1 從一次隱式轉(zhuǎn)換翻車現(xiàn)場說起先說一個(gè)我印象很深的排查經(jīng)歷。某跨平臺(tái)系統(tǒng)里有一個(gè)表示配置項(xiàng)的結(jié)構(gòu)體構(gòu)造函數(shù)接收std::string用來解析一段 JSON 字符串struct Config { std::string data; Config(const std::string str) : data(str) {} void load() { /* 解析 data 并填充配置 */ } };某同事在業(yè)務(wù)代碼里寫Config c {\enabled\: true};這行代碼編譯通過了因?yàn)閏onst char*可以隱式轉(zhuǎn)換到std::string而std::string又可以通過非explicit構(gòu)造函數(shù)隱式轉(zhuǎn)換到Config。于是每次都多一次臨時(shí)對(duì)象構(gòu)造如果Config還持有資源伴隨的就是多一次拷貝、多一次釋放。更要命的是如果你寫if (some_string) config some_string;這種代碼編譯器可能在你毫無察覺的情況下構(gòu)造出各種中間對(duì)象拖慢性能不說還會(huì)掩蓋真正的類型設(shè)計(jì)問題。當(dāng)時(shí)我們用內(nèi)存分析工具看到大量臨時(shí)Config對(duì)象的構(gòu)造和析構(gòu)查了大半天才發(fā)現(xiàn)是沒有加explicit導(dǎo)致的。后來把構(gòu)造函數(shù)改成explicit Config(const std::string str)再編譯業(yè)務(wù)代碼那一堆隱式轉(zhuǎn)換點(diǎn)全部報(bào)錯(cuò)逐個(gè)修正臨時(shí)對(duì)象數(shù)量明顯下降。從那以后我對(duì)自己設(shè)計(jì)的任何單參數(shù)構(gòu)造函數(shù)默認(rèn)都會(huì)加explicit除非我有十足把握需要支持隱式轉(zhuǎn)換。1.2 隱式轉(zhuǎn)換的善意與惡意C 允許隱式轉(zhuǎn)換本身是設(shè)計(jì)上的好意。int轉(zhuǎn)double、char*轉(zhuǎn)std::string這些內(nèi)建或庫層面的轉(zhuǎn)換讓代碼寫起來更簡潔。自定義類型也能通過單參數(shù)構(gòu)造函數(shù)或轉(zhuǎn)換運(yùn)算符參與這個(gè)機(jī)制但問題恰恰出在這里隱式轉(zhuǎn)換的觸發(fā)點(diǎn)是隱藏的。你可能只是想傳一個(gè)字符串結(jié)果它經(jīng)過了兩層轉(zhuǎn)換你可能只是想判斷某個(gè)值是否合法結(jié)果它先構(gòu)造成了一個(gè)對(duì)象再參與運(yùn)算。這種隱藏行為在代碼審查、靜態(tài)分析時(shí)都很難一眼發(fā)現(xiàn)運(yùn)行時(shí)才以性能下降或邏輯錯(cuò)誤的形式暴露出來。explicit的作用就是把這些隱式轉(zhuǎn)換關(guān)掉不允許把某個(gè)類型的對(duì)象無聲無息地變成另一個(gè)類型的對(duì)象只能通過顯式構(gòu)造或顯式轉(zhuǎn)型來完成。換句話說它把類型轉(zhuǎn)換的決策權(quán)從編譯器手里奪回來交到開發(fā)者手里。2. 構(gòu)造函數(shù)加 explicit最基礎(chǔ)也最常用2.1 拷貝初始化 vs 直接初始化要理解explicit的邊界必須先分清兩種初始化寫法Widget w1(42); // 直接初始化調(diào)用構(gòu)造函數(shù) Widget w2 42; // 拷貝初始化先構(gòu)造臨時(shí)對(duì)象再拷貝/移動(dòng)到 w2拷貝初始化會(huì)考慮隱式轉(zhuǎn)換序列而直接初始化不會(huì)。explicit構(gòu)造函數(shù)只能用于直接初始化不能用于拷貝初始化。這里的拷貝初始化不僅指這種寫法還包括函數(shù)傳參、返回值、數(shù)組初始化等場景。我見過不少初學(xué)者在.reserve()、push_back()里踩坑想直接塞一個(gè)構(gòu)造參數(shù)結(jié)果v.push_back(42);編譯不過因?yàn)閜ush_back的重載需要隱式轉(zhuǎn)換到Widget而Widget(int)加了explicit。但是注意Widget w2 42在 C17 之后如果是純右值初始化可能發(fā)生復(fù)制消除直接構(gòu)造出w2看起來好像能用explicit構(gòu)造函數(shù)。這里要區(qū)分標(biāo)準(zhǔn)語義和編譯器優(yōu)化。從語言規(guī)則上講拷貝初始化要求存在可行的隱式轉(zhuǎn)換explicit構(gòu)造函數(shù)不參與但復(fù)制消除只是消除了臨時(shí)對(duì)象的實(shí)體化并沒有改變是否允許隱式轉(zhuǎn)換這一規(guī)則。實(shí)際編碼時(shí)不要依賴這種邊緣行為。2.2 什么時(shí)候必須加 explicit只要構(gòu)造函數(shù)是單參數(shù)或者除第一個(gè)參數(shù)外所有參數(shù)都有默認(rèn)值而這個(gè)類型又不需要從實(shí)參類型自然轉(zhuǎn)換過來的語義就該加explicit。舉個(gè)例子一個(gè)表示用戶 ID 的類class UserID { public: explicit UserID(uint64_t raw) : value(raw) {} private: uint64_t value; };如果不加explicit你會(huì)不小心寫出void sendMessage(const UserID uid); sendMessage(10086);這行代碼里10086悄悄變成了UserID看起來還挺方便。問題是UserID和uint64_t在語義上是完全不同的東西一個(gè)是用戶標(biāo)識(shí)符一個(gè)是普通數(shù)字。允許隱式轉(zhuǎn)換意味著任何整數(shù)都能冒充用戶 ID稍微復(fù)雜一點(diǎn)的函數(shù)重載場景里可能選出完全不同的重載分支或者讓本該報(bào)錯(cuò)的地方靜默通過。再比如字符串類、文件路徑類、時(shí)間戳類這些類型內(nèi)部可能就用std::string或某個(gè)數(shù)字存儲(chǔ)但外部語義完全不同。我的經(jīng)驗(yàn)是凡是不希望任意該類型都能直接變成這個(gè)類的場景一律加explicit。這個(gè)原則可以覆蓋 90% 的情況。2.3 explicit 不影響直接初始化在構(gòu)造函數(shù)上加explicit并不是禁止構(gòu)造只是禁止隱式構(gòu)造。你可以繼續(xù)寫著std::make_sharedConfig(str)、Config c(str)、static_castConfig(str)都沒問題。直接初始化仍然是從參數(shù)類型顯式創(chuàng)建對(duì)象的合法途徑。這里有個(gè)容易混淆的細(xì)節(jié)UserID uid UserID(10086);這種寫法是通過函數(shù)式顯式構(gòu)造出一個(gè)臨時(shí)UserID然后拷貝初始化uid。這是合法的因?yàn)閁serID(10086)已經(jīng)是顯式構(gòu)造后面拷貝初始化只是復(fù)制該對(duì)象不再需要隱式轉(zhuǎn)換。同樣的std::string s static_caststd::string(someCharPtr);如果你自定義了一個(gè)MyString也加上了explicit那么只能寫成MyString s(ptr)或MyString s{ptr}不能寫MyString s ptr。3. 轉(zhuǎn)換運(yùn)算符與 explicitC11 的另一個(gè)戰(zhàn)場3.1 普通 operator T() 的隱患構(gòu)造函數(shù)的explicit只是攔住了從其他類型變成這個(gè)類的路徑。反過來這個(gè)類變成其他類型由轉(zhuǎn)換運(yùn)算符控制比如class Score { public: Score(int v) : value(v) {} operator int() const { return value; } private: int value; };有了operator int()Score可以隱式轉(zhuǎn)換成int于是你能寫出Score s(95); int n s; // 隱式轉(zhuǎn)換 if (s 90) {} // s 轉(zhuǎn)成 int 再比較聽起來很方便但你有沒有想過這會(huì)讓Score處處表現(xiàn)得像一個(gè)int萬一Score內(nèi)部不是簡單的數(shù)值而是帶權(quán)重的組合評(píng)分這種隱式轉(zhuǎn)換會(huì)丟掉信息。更危險(xiǎn)的是operator bool()這類轉(zhuǎn)換運(yùn)算符如果被加上會(huì)出現(xiàn)只要對(duì)象非空就能放進(jìn) if的便利背后隱藏的邏輯錯(cuò)誤。我在代碼評(píng)審里見過一個(gè)典型的坑某個(gè)Status類重載了operator bool()用來表示成功或失敗結(jié)果后來加了另一種含義是否正在處理中。同一段代碼里if (status)就被不同維護(hù)者理解成不同意思最后導(dǎo)致狀態(tài)判斷錯(cuò)誤。這種就是隱式轉(zhuǎn)換語義不夠清晰引出的問題。3.2 explicit 轉(zhuǎn)換運(yùn)算符的語義變化C11 開始explicit也能修飾轉(zhuǎn)換運(yùn)算符了。規(guī)則是explicit operator T()仍然允許在按語境轉(zhuǎn)換contextual conversion的場合隱式使用。最典型的按語境轉(zhuǎn)換場景就是if、while、for、、||、!、條件運(yùn)算符以及static_assert等需要布爾表達(dá)式的地方。其他需要真正的隱式轉(zhuǎn)換的地方比如int n score;就不能通過了必須顯式static_castint(score)。所以如果你想讓一個(gè)類型只能出現(xiàn)在條件判斷中但不能隨便變成int或double就聲明explicit operator bool()。既保住安全布爾判斷的便利性又封死其他隱式轉(zhuǎn)換出口。我寫過一個(gè)小型錯(cuò)誤處理工具里面有一個(gè)Result類只提供explicit operator bool()來表示是否成功。這樣if (result)很自然但不會(huì)有人不小心寫出int ok result;。需要拿原始錯(cuò)誤碼時(shí)必須顯式調(diào)用result.errorCode()語義邊界就清晰了。3.3 結(jié)合 if 語句的 safe bool 慣用法在 C11 之前大家為了安全布爾絞盡腦汁比如用成員函數(shù)指針、用私有析構(gòu)等辦法防止operator bool被隱式轉(zhuǎn)換成int再參加算術(shù)運(yùn)算。有了explicit operator bool后這些奇技淫巧全部可以退休。使用時(shí)的注意點(diǎn)顯式布爾轉(zhuǎn)換運(yùn)算符雖然在if (x)里能按語境轉(zhuǎn)換但std::boolalpha x這種需要operator bool的場景會(huì)失敗得手動(dòng)static_castbool(x)。另外類如果同時(shí)有operator bool()和構(gòu)造函數(shù)explicit Class(int)在某些表達(dá)式里可能觸發(fā)重載解析的意外歧義。我在下面第 6 節(jié)會(huì)專門展開排查過程。4. C20 的 explicit(bool)讓條件顯式化4.1 需求來源模板中想根據(jù)類型條件決定是否顯式普通單參數(shù)構(gòu)造函數(shù)你可以直接寫上explicit。但你有沒有遇到過這種情況寫了一個(gè)模板包裝類構(gòu)造函數(shù)形態(tài)固定但希望對(duì)外表現(xiàn)有時(shí)候支持隱式轉(zhuǎn)換有時(shí)候不支持具體取決于模板參數(shù)的類型特征比如實(shí)現(xiàn)一個(gè)WrapperT當(dāng)T是普通可隱式轉(zhuǎn)換類型時(shí)WrapperT也可以隱式構(gòu)造當(dāng)T是一個(gè)強(qiáng)類型比如用戶定義的UserId時(shí)就不允許隱式轉(zhuǎn)換。如果只靠寫死explicit要么全開要么全關(guān)。這時(shí)候explicit(bool)就派上用場了它允許你在編譯期根據(jù)某個(gè)常量表達(dá)式來決定構(gòu)造函數(shù)是否explicit。4.2 編譯期條件 explicit 的寫法與原理C20 里可以這樣寫template typename T class Wrapper { public: explicit(std::is_convertible_vT, int) Wrapper(T value); };explicit(條件)里面填一個(gè)編譯期可求值的bool常量表達(dá)式。如果條件為true構(gòu)造函數(shù)就表現(xiàn)為explicit為false就表現(xiàn)為非explicit。注意explicit后面必須跟括號(hào)圓括號(hào)內(nèi)的表達(dá)式要求是常量表達(dá)式通常是consteval函數(shù)、constexpr變量、類型特征類的靜態(tài)成員等。原理上explicit本就是說明符的一部分它本質(zhì)上是在聲明構(gòu)造函數(shù)不參與隱式轉(zhuǎn)換序列。C20 把它擴(kuò)展成可以接受編譯期參數(shù)的條件說明符編譯時(shí)會(huì)把表達(dá)式算出來再?zèng)Q定是否限制拷貝初始化。這給模板庫作者提供了極大的靈活性。4.3 一個(gè)實(shí)用的包裝類型示例我寫過一個(gè)強(qiáng)類型 ID的模板template typename T, typename Tag class StrongID { public: explicit(!std::is_same_vT, int) StrongID(T val) : value(val) {} T get() const { return value; } private: T value; };如果T本身是int比如using Age StrongIDint, struct AgeTag;那Age a 42;就會(huì)報(bào)錯(cuò)因?yàn)闃?gòu)造是explicit的逼迫你顯式寫Age a(42);。而如果某些內(nèi)部類型確實(shí)需要支持隱式構(gòu)造可以把條件改成std::is_integral_vT等特征按需開放。這個(gè)寫法在涉及類型安全的工程里非常實(shí)用一個(gè)參數(shù)從 JSON 反序列化出來時(shí)你希望強(qiáng)類型 ID 必須顯式構(gòu)造而不是在傳參時(shí)被悄悄轉(zhuǎn)換過去。explicit(bool)讓這個(gè)設(shè)計(jì)在模板層面自動(dòng)實(shí)現(xiàn)。5. 實(shí)操心得與避坑指南5.1 explicit 不是銀彈哪些情況仍然會(huì)導(dǎo)致隱式轉(zhuǎn)換即使把所有構(gòu)造函數(shù)和轉(zhuǎn)換運(yùn)算符都標(biāo)記成explicitC 還是存在其他隱式轉(zhuǎn)換通道。比如算術(shù)提升short到int的整型提升、int到double的浮點(diǎn)提升這些是內(nèi)建規(guī)則explicit攔不住。你定義一個(gè)explicit MyInteger(int)寫了MyInteger m 1024 8;如果這個(gè)表達(dá)式整體是int還是要先算出一個(gè)int才能再顯式構(gòu)造。不過這不屬于自定義類型的隱式轉(zhuǎn)換不在explicit的管轄范圍內(nèi)。另一個(gè)容易忽略的點(diǎn)是bool與指針之間的轉(zhuǎn)換。C 里空指針常量nullptr不能隱式轉(zhuǎn)成int但0可以。如果有一個(gè)explicit Foo(int)和一個(gè)explicit Foo(void*)重載調(diào)用Foo(0)時(shí)會(huì)發(fā)生重載解析可能選擇Foo(int)而Foo(nullptr)則選擇指針版本。這些細(xì)節(jié)如果沒弄清楚排查起來很痛苦。5.2 與移動(dòng)構(gòu)造、初始化列表的交互explicit和移動(dòng)構(gòu)造函數(shù)也經(jīng)常混在一起出問題。編譯器生成移動(dòng)構(gòu)造函數(shù)時(shí)并不會(huì)因?yàn)槟隳硞€(gè)拷貝構(gòu)造函數(shù)是explicit就不生成移動(dòng)操作。但是如果你自己定義了移動(dòng)構(gòu)造但沒有加explicit而它又是單參數(shù)的那么這個(gè)移動(dòng)構(gòu)造本身也可能成為隱式轉(zhuǎn)換的一部分。舉個(gè)例子class BigBuffer { public: explicit BigBuffer(std::vectorint data); BigBuffer(BigBuffer other); // 沒加 explicit };這里BigBuffer的移動(dòng)構(gòu)造函數(shù)沒有加explicit意味著BigBuffer b some_vector;在重載解析時(shí)除了考慮BigBuffer(const std::vectorint)構(gòu)造路徑移動(dòng)構(gòu)造不會(huì)直接參與從std::vectorint到BigBuffer的轉(zhuǎn)換因?yàn)橐苿?dòng)構(gòu)造函數(shù)參數(shù)是BigBuffer源類型不匹配。但如果你有一個(gè)從BigBuffer到BigBuffer的隱式路徑比如operator BigBuffer()情況就復(fù)雜了。所以一個(gè)實(shí)用經(jīng)驗(yàn)是任何單參數(shù)的構(gòu)造函數(shù)包括移動(dòng)構(gòu)造和轉(zhuǎn)換構(gòu)造函數(shù)都應(yīng)該反思一下是否需要有explicit。初始化列表則要小心explicit構(gòu)造函數(shù)不能用于拷貝列表初始化但可以用于直接列表初始化。C 標(biāo)準(zhǔn)規(guī)定Widget w{42};是合法調(diào)用explicit構(gòu)造的而Widget w {42};不合法。這一點(diǎn)挺容易在 IDE 自動(dòng)提示出錯(cuò)時(shí)被誤解。5.3 代碼審查時(shí)怎么檢查該加沒加 explicit我自己做代碼評(píng)審時(shí)會(huì)看每個(gè)單參數(shù)構(gòu)造函數(shù)的語義參數(shù)類型和類自身語義是否同屬一個(gè)抽象層級(jí)比如File(Path)可以把Path當(dāng)參數(shù)但File(std::string)就不該默默接受任意字符串除非File本來就被定義為字符串的薄包裝。是否存在丟失信息的轉(zhuǎn)換比如Fraction(int)不丟信息Fraction(double)就有可能在語義上引入近似這類一般建議explicit。是否會(huì)導(dǎo)致重載集意外變化如果一個(gè)類可以被隱式轉(zhuǎn)換成int那它出現(xiàn)在算術(shù)表達(dá)式里就可能和一堆內(nèi)建類型產(chǎn)生重載糾纏。看到這種情況我通常直接建議把轉(zhuǎn)換運(yùn)算符改成顯式版本。6. 常見問題排查實(shí)錄6.1 為什么 g 沒有報(bào)錯(cuò)有人寫std::optionalint opt 42;能編譯而給optional的構(gòu)造函數(shù)加explicit后就不能編譯了于是困惑optional標(biāo)準(zhǔn)庫是怎么處理的標(biāo)準(zhǔn)庫容器本身設(shè)計(jì)時(shí)就已經(jīng)充分考慮過explicitstd::optionalT有constexpr optional(T)被標(biāo)記為explicit的版本但同時(shí)也提供in_place用于顯式構(gòu)造。所以普通拷貝初始化std::optionalint opt 42;在 C17 中其實(shí)是合法的因?yàn)閟td::optional的轉(zhuǎn)換構(gòu)造函數(shù)不是explicit這需要分情況如果T是intoptionalint的構(gòu)造接受int標(biāo)準(zhǔn)庫把它設(shè)計(jì)為explicit還是非explicit事實(shí)上標(biāo)準(zhǔn)庫對(duì)這個(gè)有專門條款optional(T)是explicit當(dāng)且僅當(dāng)is_convertible_vT, T為假。本質(zhì)上是條件explicit的早期實(shí)踐。所以在你自己的類里如果沒搞清楚為什么有些類型能隱式構(gòu)造、有些不能大概率是標(biāo)準(zhǔn)庫用了類似explicit(bool)的邏輯。排查方法把最小復(fù)現(xiàn)代碼編譯時(shí)加上-fno-elide-constructors再看錯(cuò)誤信息可能暴露構(gòu)造和轉(zhuǎn)換的真實(shí)步驟。6.2 explicit 構(gòu)造函數(shù)能用于 return 語句嗎很多人以為return SomeClass(42);里面有圓括號(hào)是顯式構(gòu)造一定沒問題。但如果函數(shù)返回值類型是SomeClass這條 return 語句確實(shí)合法。不過要小心一種寫法SomeClass make() { return 42; // 如果 SomeClass(int) 是 explicit這里會(huì)報(bào)錯(cuò) }很多編譯器甚至早期版本會(huì)建議你轉(zhuǎn)換為直接初始化但實(shí)際上 C 標(biāo)準(zhǔn)規(guī)定 return 語句中的隱式轉(zhuǎn)換必須可用explicit構(gòu)造函數(shù)不允許在這種情況下使用。所以遇到這類報(bào)錯(cuò)正確改法是return SomeClass(42);。6.3 多參數(shù)構(gòu)造為何很少談 explicitexplicit在多參數(shù)構(gòu)造函數(shù)身上顯得沒那么重要因?yàn)殡[式轉(zhuǎn)換通常只針對(duì)單參數(shù)構(gòu)造而多參數(shù)構(gòu)造你沒法通過一個(gè)表達(dá)式隱式調(diào)用。但 C11 引入了{(lán)}初始化之后情況變了花括號(hào)初始化列表可以在函數(shù)調(diào)用中表達(dá)多個(gè)參數(shù)。比如void f(Point p); f({1, 2});在Point(int, int)非explicit時(shí)能隱式配對(duì)。如果你不想讓這種聚合式隱式構(gòu)造發(fā)生也可以給多參數(shù)構(gòu)造函數(shù)加explicit。不過實(shí)際開發(fā)中這種寫法少見我自己更傾向于用結(jié)構(gòu)體聚合初始化并用靜態(tài)工廠函數(shù)保證語義。6.4 轉(zhuǎn)換運(yùn)算符和構(gòu)造函數(shù)同時(shí)存在時(shí)的重載歧義這是我在實(shí)際項(xiàng)目里排查最久的一類問題。一個(gè)類Value定義了explicit Value(int)同時(shí)還有一個(gè)operator int()看起來一進(jìn)一出很對(duì)稱。結(jié)果寫Value v(42); int x v;時(shí)報(bào)錯(cuò)了查來查去發(fā)現(xiàn)問題出在另一個(gè)操作上Value v(42); bool ok (v 0); // 想讓 v 轉(zhuǎn)成 int 再比較結(jié)果編譯失敗因?yàn)闃?biāo)準(zhǔn)里operator int()如果是顯式的操作符的左操作數(shù)要求轉(zhuǎn)換成int但explicit轉(zhuǎn)換不允許隱式參與。如果同時(shí)存在operator bool()則相關(guān)語境的身份就變得更微妙。這種時(shí)候我會(huì)明確寫if (static_castint(v) 0)絕不指望隱式轉(zhuǎn)換。排查這種問題的技巧先把所有自定義轉(zhuǎn)換函數(shù)全部臨時(shí)改成非explicit如果能編譯過就可以坐實(shí)是顯式轉(zhuǎn)換檢查導(dǎo)致的失敗再把轉(zhuǎn)換函數(shù)一個(gè)個(gè)恢復(fù)定位是哪個(gè)explicit引入的問題。這個(gè)方法在大型模板嵌套場景里很管用。還有一個(gè)更隱蔽的坑當(dāng)類同時(shí)有explicit operator bool()和operator int()后者非顯式在if (v)里其實(shí)是不會(huì)重載到operator int()再轉(zhuǎn)布爾因?yàn)閑xplicit operator bool()正好能被按語境轉(zhuǎn)換選中反而覆蓋了普通轉(zhuǎn)換路徑。所以如果你希望if (v)先轉(zhuǎn)成int再判斷那就別定義explicit operator bool否則拿到的是純 bool 結(jié)果而不是數(shù)值結(jié)果。最后說一個(gè)實(shí)際工作中的體會(huì)explicit這個(gè)關(guān)鍵字我越用越覺得它不是語法糖而是一種表達(dá)類型邊界的手段。每次寫單參數(shù)構(gòu)造時(shí)我會(huì)先問自己一句這個(gè)類型真的應(yīng)該和參數(shù)類型混著用嗎如果答案是否馬上把explicit寫上去。這個(gè)習(xí)慣幫我避開了很多后來才會(huì)變成麻煩的隱式轉(zhuǎn)換問題也讓代碼在長期維護(hù)中少了很多隱藏動(dòng)作。如果你也在重構(gòu)老項(xiàng)目不妨試著把該加explicit的地方加齊編譯報(bào)錯(cuò)的地方挨個(gè)看一遍那些報(bào)錯(cuò)往往能幫你發(fā)現(xiàn)自己之前沒意識(shí)到的隱式轉(zhuǎn)換連接點(diǎn)——處理完之后你能明顯感覺到代碼的行為更加可控了。