剛接觸 Ruby 的人看到“數(shù)據(jù)類型”這四個(gè)字很容易走偏——以為它像 Java 那樣先有一套 int、String、Object 的靜態(tài)體系然后給變量貼上類型標(biāo)簽。我跟不少剛轉(zhuǎn)過來的朋友聊過大家第一反應(yīng)都是“那我要不要寫類型聲明”“這個(gè)函數(shù)到底能不能傳 nil”。我的建議是先把腦子里那套靜態(tài)類型的圖景清空再來讀這一篇。Ruby 的“類型”跟你在其他語言里熟悉的“類型”不是同一個(gè)概念。它更像是“這個(gè)對(duì)象是誰創(chuàng)建的、它身上有哪些方法可以調(diào)用”。這篇就是圍繞這個(gè)概念展開的先糾正認(rèn)知再把常用內(nèi)置類型一個(gè)個(gè)拆開看最后用一段實(shí)戰(zhàn)代碼把類型判斷、轉(zhuǎn)換和校驗(yàn)串起來。1. 先建立正確認(rèn)知Ruby 的“類型”到底指的是什么1.1 變量只是標(biāo)簽真正有類型的是對(duì)象在 Ruby 里寫name alice你并沒有聲明“name 是一個(gè)字符串變量”。你只是創(chuàng)建了一個(gè)字符串對(duì)象然后把變量名name指向它。變量本身沒有類型類型只屬于對(duì)象。所以同一個(gè)變量先指向字符串、后來又指向數(shù)組、再指向一個(gè)對(duì)象實(shí)例都是完全合法的。value hello value.class # String value [1, 2, 3] value.class # Array value 42 value.class # Integer這一點(diǎn)和 C/Java 等靜態(tài)類型語言差別非常大。靜態(tài)語言里編譯器靠類型幫你提前攔截一批錯(cuò)誤Ruby 里沒有這層攔截所以類型問題基本都推遲到了運(yùn)行時(shí)才暴露。你問一個(gè)對(duì)象屬于什么類型答案是value.class它返回的是這個(gè)對(duì)象對(duì)應(yīng)的類對(duì)象。類本身也是對(duì)象所以String.class返回 ClassClass.class最后還是 Class。剛?cè)腴T的人容易在這里繞暈其實(shí)可以簡單理解成Ruby 里每個(gè)對(duì)象都記得“我是哪個(gè)類造出來的”但變量不記得。真正需要記住的關(guān)鍵點(diǎn)是對(duì)象的方法是否可用取決于對(duì)象的類是否定義了該方法。你在代碼里寫給value.length只要當(dāng)前指向的對(duì)象是 String 就能跑如果某次運(yùn)行時(shí)它指向了 Array報(bào)錯(cuò)信息就是undefined method length for an instance of Array。這就引出了 Ruby 圈子里常說的“鴨子類型”。1.2 鴨子類型決定了你該怎么思考類型“如果它走起來像鴨子、叫起來像鴨子那它就是鴨子?！边@句話在 Ruby 社區(qū)不是段子是日常寫代碼的方式。很多方法根本不關(guān)心參數(shù)到底是什么類只關(guān)心它能響應(yīng)哪些方法。def print_all(collection) collection.each { |item| puts item } end print_all([1, 2, 3]) # 數(shù)組行 print_all({ a: 1, b: 2 }) # 哈希也行each 會(huì)給出鍵值對(duì)數(shù)組 print_all(1..5) # 范圍也行你不需要去繼承某個(gè)統(tǒng)一的 Collection 接口也不用寫if collection.is_a?(Array)。只要傳入的對(duì)象有each方法這個(gè)函數(shù)就能跑。這種靈活性是 Ruby 效率高的原因之一你不必為每一種容器類型重復(fù)寫邏輯。但硬幣的另一面是方法能不能跑要等到真正調(diào)用時(shí)才知道。如果傳入一個(gè)沒有each的對(duì)象程序在那一瞬間才會(huì)報(bào)錯(cuò)。所以使用鴨子類型時(shí)有兩個(gè)習(xí)慣很重要第一不要寫大量class判斷來“防身”而是用respond_to?來確認(rèn)能力第二團(tuán)隊(duì)協(xié)作時(shí)依賴測試把錯(cuò)誤提前暴露出來。后面第 3 章我會(huì)專門講判斷方法怎么選。基于這個(gè)認(rèn)知我們?cè)偃タ?Ruby 內(nèi)置的各種數(shù)據(jù)類型思路就清楚了它們不是什么抽象的“類型系統(tǒng)”而是一批開箱即用的類各自擁有不同的行為能力和適用場景。2. 內(nèi)置類型拆解每個(gè)核心數(shù)據(jù)結(jié)構(gòu)的脾氣與細(xì)節(jié)2.1 數(shù)字家族Integer、Float、Rational 與 BigDecimalRuby 的數(shù)字類型不像很多語言那樣分int/short/long日常寫代碼基本只接觸Integer和Float。整數(shù)可以是任意大小不會(huì)有溢出這個(gè)概念比如2**1000照樣算得出來這在寫算法題或者處理大數(shù)時(shí)非常省心。浮點(diǎn)數(shù)遵循 IEEE 754 雙精度標(biāo)準(zhǔn)精度限制是繞不開的。0.1 0.2的結(jié)果并不是0.3而是0.30000000000000004。如果你拿它跟錢沾邊就會(huì)出大事。處理金額我一般用整數(shù)“分”來存或者用BigDecimal。require bigdecimal BigDecimal(0.1) BigDecimal(0.2) # 0.3e0此外 Ruby 還內(nèi)置了 Rational有理數(shù)用1r表示例如2r * 3r永遠(yuǎn)得到精確的分?jǐn)?shù)結(jié)果不會(huì)變成浮點(diǎn)。它不是日常必需品但做某些數(shù)學(xué)運(yùn)算時(shí)非常有用。有個(gè)非常經(jīng)典的坑是整數(shù)除法。很多初學(xué)者寫1 / 2期待得到0.5實(shí)際結(jié)果是0因?yàn)閮蓚€(gè)整數(shù)相除結(jié)果仍是整數(shù)。要得到浮點(diǎn)結(jié)果至少把其中一個(gè)變成浮點(diǎn)數(shù)1.0 / 2或者更明確地用1.fdiv(2)。這種規(guī)則不算錯(cuò)但剛轉(zhuǎn)過來的人基本都會(huì)踩一次。下表幫你快速判斷該用哪種數(shù)字類型場景推薦類型原因計(jì)數(shù)器、索引、金額整數(shù)分Integer精確、不溢出常規(guī)科學(xué)計(jì)算、百分比Float計(jì)算快接受精度損失需要精確十進(jìn)制價(jià)格、匯率BigDecimal避免二進(jìn)制浮點(diǎn)誤差數(shù)學(xué)推導(dǎo)、嚴(yán)格有理運(yùn)算Rational保持精確分?jǐn)?shù)2.2 字符串與符號(hào)相近卻性格相反的兩種類型String 是所有人最早接觸的類型它可變、支持拼接、插值和各種文本處理。雙引號(hào)字符串支持#{}插值單引號(hào)字符串幾乎不轉(zhuǎn)義、也不插值寫正則或路徑時(shí)很實(shí)用。name Ruby puts Hello, #{name} # Hello, Ruby puts Hello, #{name} # Hello, #{name}String 的可變性值得注意很多現(xiàn)代語言里的字符串是不可變的Ruby 不是。str !會(huì)原地修改同一個(gè)對(duì)象str str !則會(huì)生成一個(gè)新對(duì)象。大量循環(huán)拼接時(shí)優(yōu)先用或concat避免頻繁創(chuàng)建中間字符串。如果想節(jié)省內(nèi)存還可以在文件開頭寫魔法注釋# frozen_string_literal: true讓字符串字面量默認(rèn)凍結(jié)把“可變”變成“不可變”很多大型項(xiàng)目都這么做能顯著降低字符串分配。Symbol符號(hào)則是另一種存在。它用冒號(hào)開頭:name本質(zhì)是“帶名字的 ID”而且是不可變的。相同內(nèi)容的符號(hào)在程序里通常是同一個(gè)對(duì)象所以比較特別快非常適合做哈希的鍵、枚舉狀態(tài)值等。:name.object_id :name.object_id # true name.object_id name.object_id # false name.to_sym :name # true :name.to_s # name什么時(shí)候用 Symbol、什么時(shí)候用 String我的經(jīng)驗(yàn)是如果這個(gè)值需要參與拼接、修改、展示或者來自用戶輸入就用 String如果只是當(dāng)作標(biāo)識(shí)符、狀態(tài)碼、哈希鍵就用 Symbol。這兩者可以互轉(zhuǎn)但頻繁轉(zhuǎn)換會(huì)浪費(fèi)一點(diǎn)性能建議在數(shù)據(jù)進(jìn)入業(yè)務(wù)邏輯時(shí)就定好形態(tài)后面統(tǒng)一按一種方式處理。2.3 布爾值與 nil只有這兩者是“假”Ruby 的布爾值很簡單true和false注意必須是小寫沒有True/False這種東西。nil表示“什么都沒有”是NilClass的唯一實(shí)例。新手最容易栽的坑是到底哪些值是“假”Ruby 的規(guī)則非常寬松——只有false和nil是假的0、空字符串、空數(shù)組[]、空哈希{}全都是真。這個(gè)習(xí)慣跟 JavaScript、Python 都不同。在 Python 里0和空列表會(huì)走else分支在 Ruby 里它們都會(huì)走if分支。if 0 puts 0 是真的 end if puts 空字符串也是真的 end if [] puts 空數(shù)組還是真的 end如果你剛從別的語言轉(zhuǎn)過來最容易在這里翻車。判斷“數(shù)組是否為空”不要寫if arr它永遠(yuǎn)為真要寫if arr.empty?或者unless arr.empty?。判斷“哈希里有沒有某個(gè)鍵”不要寫if hash[:key]鍵存在但值為 false 時(shí)會(huì)被誤判要用key?或include?。nil 的來源也非常多訪問哈希里不存在的鍵、數(shù)組越界、方法沒有顯式 return、正則匹配不到結(jié)果……習(xí)慣了之后反而覺得方便但新手經(jīng)常被NoMethodError: undefined method xxx for nil:NilClass弄到崩潰。我處理這種情況的通用思路是在數(shù)據(jù)入口處盡早把 nil 轉(zhuǎn)換成有意義的默認(rèn)值或者用安全的訪問方式比如dig、fetch不要讓 nil 深入到業(yè)務(wù)邏輯里到處傳播。2.4 數(shù)組、哈希與范圍容器類型的常用姿勢數(shù)組和哈希是 Ruby 里曝光率最高的兩種容器。數(shù)組用中括號(hào)支持負(fù)數(shù)索引、范圍取值、追加和刪除哈希用大括號(hào)本質(zhì)上是一個(gè)鍵值映射。兩者都有大量迭代方法each、map、select、reject、find、reduce等寫起來非常順手我日常寫循環(huán)的頻率比傳統(tǒng)語言低很多。scores [89, 95, 73, 62] scores.select { |s| s 90 } # 過濾 scores.map { |s| s 5 } # 映射 person { name: alice, age: 30, city: tokyo } person[:name] # alice person[:hobby] # nil person.fetch(:hobby) # 拋 KeyError person.fetch(:hobby, unknown) # 帶默認(rèn)值推薦這里我特別想提一下fetch訪問哈希鍵時(shí)hash[:key]返回 nil 可能導(dǎo)致后續(xù)各種奇怪問題fetch的第二個(gè)參數(shù)能提供默認(rèn)值fetch加 block 還能在鍵不存在時(shí)生成默認(rèn)值。在核心代碼里我基本都用fetch而不是裸訪問。范圍Range也屬于內(nèi)置類型1..5包含 51...5不包含 5。它不只是表示數(shù)字范圍還能在 case 表達(dá)式里做區(qū)間匹配。(1..5).to_a # [1, 2, 3, 4, 5] (1...5).to_a # [1, 2, 3, 4] score 88 case score when 90..100 then 優(yōu)秀 when 60...90 then 合格 else 不合格 endcase/when里用的其實(shí)是Range#這個(gè)細(xì)節(jié)后面講相等比較時(shí)還會(huì)遇到。容器類型本身不難難的是里面的細(xì)節(jié)坑比如默認(rèn)值共享、遍歷時(shí)修改結(jié)構(gòu)、字符串與符號(hào)混用做鍵我會(huì)在第 4 章和第 5 章逐個(gè)展開。3. 類型判斷與轉(zhuǎn)換別把 Ruby 寫成 Java3.1 判斷對(duì)象類型class 比較、is_a? 與 respond_to? 怎么選很多初學(xué)者判斷類型會(huì)這么寫if value.class String # ... end這種寫法能跑但有三個(gè)問題。第一它只判斷了“這個(gè)對(duì)象是不是 String 類的直接實(shí)例”不考慮子類第二.class返回的是一個(gè) Class 對(duì)象拿 Class 對(duì)象跟String比較沒有問題但如果你寫成value.class.to_s String就是又繞又脆弱的寫法第三它強(qiáng)制要求調(diào)用方必須傳入特定類型破壞了鴨子類型的靈活性。更常用的是is_a?和kind_of?這兩個(gè)是同一個(gè)方法的別名會(huì)沿著繼承鏈向上查1.is_a?(Integer) # true 1.is_a?(Numeric) # trueInteger 繼承自 Numeric 1.is_a?(String) # false 1.is_a?(Object) # true所有對(duì)象都是 Object如果只想判斷“是不是某個(gè)類的直接實(shí)例”用instance_of?1.instance_of?(Integer) # true 1.instance_of?(Numeric) # false因?yàn)?1 的直接類是 Integer 不是 Numeric不過在我的實(shí)際代碼里出現(xiàn)最頻繁的不是is_a?而是respond_to?。因?yàn)樗鼏柕牟皇恰澳闶钦l”而是“你會(huì)什么”。判斷類型最終是為了調(diào)用方法那不如直接問方法是否存在。def summarize(source) if source.respond_to?(:to_h) source.to_h elsif source.respond_to?(:each) source.each.to_a else raise ArgumentError, 無法處理的輸入: #{source.inspect} end end這個(gè)例子里傳入哈希、對(duì)象、數(shù)組都能被處理關(guān)鍵是它響應(yīng)什么方法。這不是偷懶而是更貼近 Ruby 的設(shè)計(jì)哲學(xué)。判斷類型的優(yōu)先級(jí)我一般這樣排能用respond_to?就不寫is_a?能用is_a?就不寫class instance_of?只在極少數(shù)“必須精確匹配類”的場景使用。3.2 to_ 系列轉(zhuǎn)換的邊界以及更嚴(yán)格的替代方案Ruby 給每個(gè)對(duì)象都配了一套to_s、to_i、to_f、to_a、to_h之類的方法使用非常普遍但它們的行為有不少反直覺的地方。nil.to_s返回空字符串nil.to_i返回0nil.to_a返回[]。這種寬容特性在拼接數(shù)據(jù)時(shí)很方便但也可能掩蓋真正的問題。比如你期望從外部傳一個(gè)數(shù)字結(jié)果傳來了 nilto_i把它靜默變成 0后續(xù)邏輯看似正常其實(shí)數(shù)據(jù)已經(jīng)錯(cuò)了。String#to_i的解析規(guī)則更值得小心它從左往右解析遇到非法字符就停止如果開頭就不是數(shù)字直接返回 0。123.to_i # 123 12abc.to_i # 12 abc.to_i # 0 .to_i # 0 -42.to_i # -42如果你需要嚴(yán)格校驗(yàn)用Integer(123)、Float(2.5)這種類方法。它們能轉(zhuǎn)換就返回?cái)?shù)值不能轉(zhuǎn)換就拋出異常不會(huì)默默變成 0。Integer(123) # 123 Integer(12abc) # 拋出 ArgumentError Integer(nil) # 拋出 TypeError Float(2.5) # 2.5兩套方案的取舍我總結(jié)為業(yè)務(wù)代碼內(nèi)部盡量少做轉(zhuǎn)換保持?jǐn)?shù)據(jù)形態(tài)一致外部輸入JSON、表單、命令行參數(shù)要嚴(yán)進(jìn)能拋錯(cuò)就拋錯(cuò)不要靜默地“猜”。這能幫你省掉大量排查“為什么數(shù)據(jù)變成了 0/空字符串”的時(shí)間。4. 可變性、凍結(jié)與引用共享類型之外更隱蔽的坑4.1 freeze 和 dup 的區(qū)別凍結(jié)邊界必須搞清楚Ruby 對(duì)象默認(rèn)都是可變的但你可以調(diào)用freeze讓它“凍結(jié)”。凍結(jié)之后再嘗試修改會(huì)拋出FrozenError。s secret.freeze s !! # FrozenError: cant modify frozen String字符串凍結(jié)在常量場景很常見比如配置項(xiàng)、錯(cuò)誤碼、提示語凍結(jié)后一方面防止被意外修改另一方面也便于內(nèi)部共享同一個(gè)對(duì)象減少內(nèi)存占用。數(shù)組、哈希、對(duì)象實(shí)例都可以凍結(jié)。dup和clone都能復(fù)制對(duì)象但對(duì)待凍結(jié)狀態(tài)的態(tài)度不同dup創(chuàng)建的是不凍結(jié)的副本clone會(huì)連同凍結(jié)狀態(tài)一起復(fù)制。a [1, 2, 3].freeze b a.dup b 4 # 沒問題b 是可變的 c a.clone c 4 # FrozenErrorclone 保留了凍結(jié)狀態(tài)還有一個(gè)限制必須認(rèn)清freeze是“淺凍結(jié)”只凍結(jié)了最外層對(duì)象。如果數(shù)組里裝的是字符串?dāng)?shù)組凍結(jié)了里面的字符串仍然可能被修改。arr [a, b].freeze arr[0].upcase! # 不會(huì)報(bào)錯(cuò)字符串本身沒被凍結(jié)想深度凍結(jié)得自己遞歸處理或者使用專門的深拷貝方案。我處理配置對(duì)象時(shí)通常的做法是在入口用deep_dup之類的工具復(fù)制一份再對(duì)整體 freeze內(nèi)部服務(wù)只讀使用。這樣能避免兩層含義混在一起不可變的是對(duì)象本身不是它引用的內(nèi)容。4.2 Hash 默認(rèn)值引用共享以及字符串鍵被內(nèi)部拷貝的細(xì)節(jié)Hash.new(default)看著很貼心實(shí)際上藏著一個(gè)經(jīng)典大坑默認(rèn)值只創(chuàng)建一次所有“缺失鍵”返回的都是同一個(gè)對(duì)象。h Hash.new([]) h[:a] 1 h[:a] # [1] h[:b] # [1]驚不驚喜這個(gè)例子要細(xì)看h[:a] 1并沒有真的給:a賦值它只是取出了默認(rèn)數(shù)組、往數(shù)組里塞了個(gè) 1。因?yàn)槟J(rèn)數(shù)組是同一個(gè)對(duì)象所以:b拿到的也是同一個(gè)數(shù)組。更合理的寫法是給Hash.new傳一個(gè)可以被反復(fù)調(diào)用的 blockh Hash.new { |hash, key| hash[key] [] } h[:a] 1 h[:b] 2 h[:a] # [1] h[:b] # [2]block 形式會(huì)在每次訪問不存在的鍵時(shí)執(zhí)行并且把結(jié)果寫入哈希每個(gè)鍵擁有獨(dú)立的數(shù)組。這是我處理“分組統(tǒng)計(jì)”“緩存累加”等場景時(shí)的首選方案。另一個(gè)和類型有關(guān)的細(xì)節(jié)是字符串鍵的隔離機(jī)制。當(dāng)你用一個(gè)字符串作為哈希鍵時(shí)Ruby 在內(nèi)部會(huì)復(fù)制這個(gè)字符串并凍結(jié)副本避免外部修改鍵時(shí)破壞哈希結(jié)構(gòu)。但正因?yàn)槿绱巳绻惆淹粋€(gè)字符串變量反復(fù)修改后再去查哈希查到的結(jié)果會(huì)很迷惑key name h { key Ruby } key _x h[name] # Ruby鍵是原始副本 h[key] # nilkey 現(xiàn)在是 name_x我早年排查過一個(gè) bug就是有人在外面改了鍵變量導(dǎo)致哈希查不到數(shù)據(jù)。理解了“內(nèi)部拷貝”這個(gè)機(jī)制后你會(huì)自然得出一個(gè)經(jīng)驗(yàn)不要用會(huì)變的字符串對(duì)象當(dāng)長期鍵能用符號(hào)就用符號(hào)。5. 實(shí)戰(zhàn)中容易翻車的類型相關(guān)場景逐一復(fù)盤5.1 、eql?、equal? 三種“相等”別混用Ruby 里至少有三種判斷相等的方式含義完全不同。是常規(guī)相等語義上“值相等”。1 1.0返回 true因?yàn)閿?shù)值比較時(shí)不區(qū)分 Integer 和 Float1 1返回 false因?yàn)樽址蛿?shù)字不相等。大多數(shù)業(yè)務(wù)判斷用就夠了。eql?更嚴(yán)格要求值和類型都相同。所以1.eql?(1.0)返回 false而1.eql?(1)返回 true。哈希判斷兩個(gè)鍵是否相同用的是eql?這就是為什么h[1]和h[1.0]在哈希里是不同鍵。equal?是“同一對(duì)象”判斷相當(dāng)于比較引用是否一致一般不會(huì)用來做業(yè)務(wù)值比較。真正理解這三者的差異后你會(huì)知道為什么1 1.0成立卻不能把1和1.0混作同一個(gè)哈希鍵。1 1.0 # true 1.eql?(1.0) # false [1, 2] [1, 2] # true數(shù)組逐元素比較 [1, 2].eql?([1, 2]) # true a [1, 2] b a a.equal?(b) # true c [1, 2] a.equal?(c) # false另一個(gè)容易被忽略的是操作符。它平時(shí)不怎么用但在case/when里很關(guān)鍵。前文提到的when 90..100就是一個(gè)例子。語義其實(shí)不是“嚴(yán)格相等”而是“case 匹配”。很多初學(xué)者看到就以為和 JavaScript 里一樣這是錯(cuò)的。5.2 浮點(diǎn)數(shù)不能直接用 比較這是類型問題很多人覺得浮點(diǎn)精度問題和“類型”沒關(guān)系其實(shí)關(guān)系很大。Float類型本質(zhì)上是二進(jìn)制浮點(diǎn)數(shù)很多十進(jìn)制小數(shù)在二進(jìn)制里是無限循環(huán)的所以0.1 0.2的結(jié)果不是精確的0.3。直接永遠(yuǎn) false。處理辦法有三種一是用整數(shù)金額用“分”存這是最穩(wěn)的二是用BigDecimal做精確十進(jìn)制三是比較差值在容差范圍內(nèi)。def nearly_equal?(a, b, epsilon 1e-8) (a - b).abs epsilon end nearly_equal?(0.1 0.2, 0.3) # true排序比較浮點(diǎn)數(shù)時(shí)也要小心。不要用返回 nil 的情況比如 Float 和未定義比較的類比較時(shí)可能返回 nil這在sort里會(huì)直接崩潰。數(shù)字相關(guān)字段入口就該界定好類型能轉(zhuǎn)就轉(zhuǎn)不能轉(zhuǎn)就報(bào)錯(cuò)這是成熟的工程選擇。5.3 遍歷過程中修改容器迭代器的隱藏行為在遍歷數(shù)組時(shí)刪除元素是經(jīng)典翻車現(xiàn)場。因?yàn)榈鞯墓ぷ鞣绞绞腔谒饕蛘哂螛?biāo)推進(jìn)的一邊遍歷一邊刪除會(huì)導(dǎo)致元素跳過或者錯(cuò)位。numbers [1, 2, 3, 4] numbers.each_with_index do |n, i| numbers.delete_at(i) if n.even? end p numbers # 結(jié)果不是你想的那個(gè)更安全的方式是使用迭代器自己的過濾方法比如delete_if、select!、reject!或者先復(fù)制一份再遍歷。numbers [1, 2, 3, 4] numbers.delete_if(:even?) p numbers # [1, 3]哈希在遍歷時(shí)修改結(jié)構(gòu)更危險(xiǎn)通常會(huì)直接報(bào)錯(cuò)。我的習(xí)慣是凡是涉及“邊遍歷邊增減”先思考要保留什么結(jié)果然后選擇對(duì)應(yīng)的函數(shù)式方法完成而不是在each里手工增刪。這不僅是在避免類型問題也是讓代碼意圖更明確。5.4 nil 的排查NoMethodError 最常見要從源頭堵住日常報(bào)錯(cuò)里NoMethodError: undefined method xxx for nil:NilClass出現(xiàn)的頻率遠(yuǎn)遠(yuǎn)高于其他類型錯(cuò)誤。核心原因是很多路徑會(huì)返回 nil而你沒有意識(shí)到。舉個(gè)例子config { host: localhost, port: 8080 } config[:database][:host] # NoMethodError因?yàn)?config[:database] 是 nil排查這類問題我有一套固定流程。第一步看報(bào)錯(cuò)棧指向哪一行通常那一行有一個(gè)鏈?zhǔn)秸{(diào)用比如a.b.c.d你要確定斷在哪一環(huán)。第二步用pp或p把中間變量打印出來inspect輸出可能更完整。第三步判斷應(yīng)該在哪個(gè)位置阻斷 nil 傳播。與其在業(yè)務(wù)代碼里到處寫.急救不如在數(shù)據(jù)入口就做好形狀統(tǒng)一。比如訪問嵌套結(jié)構(gòu)用config.dig(:database, :host)某一層不存在時(shí)返回 nil不會(huì)爆。需要默認(rèn)值用config.fetch(:database, {})。如果確認(rèn)必須存在就讓它快速失敗拋異常也比 nil 一路穿透到底、最后在莫名其妙的地方炸掉好。我個(gè)人并不反感 nilRuby 里 nil 是一種合法的“缺失”表達(dá)。真正的問題是它被無意識(shí)地傳播到不該出現(xiàn)的位置。所以設(shè)計(jì)函數(shù)時(shí)我會(huì)明確每個(gè)方法的“空值策略”允許返回 nil 的方法在方法名或注釋里說清楚不允許返回 nil 的方法查不到就拋異常。6. 一個(gè)完整例子多源輸入的類型歸一化處理6.1 場景不確定來源的配置數(shù)據(jù)假設(shè)你寫了一個(gè)內(nèi)部小工具需要讀取一個(gè) JSON 配置文件。文件可能由不同的人手工編寫因此age可能是數(shù)字28也可能是字符串28active可能是布爾值true也可能是字符串truetags可能是數(shù)組也可能被寫成了逗號(hào)分隔的字符串。這種多源輸入如果不做歸一化散落到業(yè)務(wù)代碼里到處都會(huì)出現(xiàn)類型判斷和轉(zhuǎn)換雜亂且容易漏。我的做法是在入口處集中做一次“類型歸一化”把所有輸入映射成業(yè)務(wù)層真正想用的類型讓后續(xù)代碼只跟干凈的數(shù)據(jù)打交道。6.2 實(shí)現(xiàn)集中式轉(zhuǎn)換與嚴(yán)格校驗(yàn)先寫一個(gè)轉(zhuǎn)換模塊核心思路是空值顯式處理、布爾值規(guī)則統(tǒng)一、數(shù)字嚴(yán)格解析、數(shù)組兜底轉(zhuǎn)換。def normalize_boolean(value) case value when true, true, 1, 1 true when false, false, 0, 0, nil, false else raise ArgumentError, 無法識(shí)別的布爾值: #{value.inspect} end end def normalize_integer(value) case value when Integer value when String raise ArgumentError, 數(shù)字格式錯(cuò)誤: #{value.inspect} unless value.match?(/\A-?\d\z/) value.to_i else raise ArgumentError, 數(shù)字格式錯(cuò)誤: #{value.inspect} end end def normalize_field(key, value) case key when name value.to_s.strip when age normalize_integer(value) when active normalize_boolean(value) when level value.is_a?(Numeric) ? value.to_f : Float(value) when tags Array(value).map { |item| item.to_s.strip } else value end end這段代碼里Array(value)是個(gè)非常實(shí)用的小技巧nil會(huì)變成[]已經(jīng)是數(shù)組的保持不變單個(gè)對(duì)象會(huì)變成只含該對(duì)象的一元數(shù)組。它省去了你自己寫一堆if value.is_a?(Array)的判斷。接著接入原始數(shù)據(jù)raw { name Alice , age 28, active true, level 2.5, tags [ruby, dev], remark nil } config {} raw.each_pair do |key, value| config[key.to_sym] normalize_field(key, value) end p config輸出結(jié)果是{ name: Alice, age: 28, active: true, level: 2.5, tags: [ruby, dev], remark: nil }這就是一次完整的歸一化字符串名字被去除兩端空格數(shù)字字符串轉(zhuǎn)成真正的整數(shù)布爾字符串轉(zhuǎn)成布爾值數(shù)組保持不變不帶業(yè)務(wù)規(guī)則的remark原樣保留。這個(gè)集中式方法最大的好處是業(yè)務(wù)層拿到的一定是固定結(jié)構(gòu)的數(shù)據(jù)類型不再變化后續(xù)代碼可以放心假設(shè)config[:age]是整數(shù)。6.3 類型思維總結(jié)邊界嚴(yán)格、內(nèi)部寬松如果給這個(gè)例子提煉一個(gè)原則我會(huì)寫八個(gè)字邊界嚴(yán)格內(nèi)部寬松。外部輸入用什么類型是不可控的你不可能要求每個(gè)寫配置文件的人都懂編程。所以入口處把類型收攏能轉(zhuǎn)就轉(zhuǎn)、不能轉(zhuǎn)就報(bào)錯(cuò)把問題攔在最前面。內(nèi)部數(shù)據(jù)一旦定型就不要反復(fù)轉(zhuǎn)換更不要用一堆if x.class ...去到處防御。這個(gè)案例還說明一個(gè)道理類型問題不一定要靠“類型檢查”解決。通過選擇合適的數(shù)據(jù)結(jié)構(gòu)和轉(zhuǎn)換策略很多本來可能出現(xiàn)的類型不匹配會(huì)在進(jìn)入業(yè)務(wù)邏輯之前就被消解掉。這也呼應(yīng)了文章最開始的觀點(diǎn)——在 Ruby 里你能做出的最好“類型設(shè)計(jì)”就是把對(duì)象的數(shù)據(jù)形態(tài)和職責(zé)在設(shè)計(jì)階段想清楚。7. 一點(diǎn)長年積累的實(shí)戰(zhàn)心得留給剛?cè)腴T的朋友最后聊點(diǎn)我自己的習(xí)慣不灌雞湯都是踩過坑之后留下的。第一不要寫“類型檢查連環(huán)炮”。如果一段代碼里連續(xù)出現(xiàn)if x.is_a?(String) ... elsif x.is_a?(Array)我通常先懷疑方法設(shè)計(jì)出了問題而不是真的需要這么多判斷。Ruby 的鴨子類型已經(jīng)有很強(qiáng)的表達(dá)能力優(yōu)先依賴對(duì)象自身的方法和轉(zhuǎn)換而不是在調(diào)用前反復(fù)盤問“你是誰”。第二外部邊界和內(nèi)部核心要用兩種不同的處理策略。邊界處HTTP 參數(shù)、JSON 文件、命令行輸入可以激進(jìn)一點(diǎn)用Integer()、Float()、fetch這類嚴(yán)格API讓非法數(shù)據(jù)及早暴露。內(nèi)部核心邏輯則盡量保持?jǐn)?shù)據(jù)形態(tài)統(tǒng)一少寫防御性判斷否則代碼會(huì)被大量.和is_a?淹沒反而看不出來真正的問題在哪。第三如果想在團(tuán)隊(duì)協(xié)作中獲得更多“靜態(tài)安全感”Ruby 3 的 RBS 類型簽名、類型推斷工具或者逐步引入一定程度的靜態(tài)檢查都是可行方案。它能幫你把一部分運(yùn)行時(shí)錯(cuò)誤提前到開發(fā)階段發(fā)現(xiàn)。但我的體會(huì)是不要讓工具替代建模。類型簽名是補(bǔ)充核心還是在設(shè)計(jì)階段把數(shù)據(jù)結(jié)構(gòu)、空值策略、可變性邊界想清楚。第四善待 nil。不要把“避免 nil”當(dāng)成目標(biāo)那會(huì)讓代碼寫出無數(shù)句xxx || 反而掩蓋問題。關(guān)鍵是想清楚每個(gè)數(shù)據(jù)可能出現(xiàn)的空值形態(tài)在入口統(tǒng)一處理內(nèi)部就按既定規(guī)則走。只要 unmarshal 進(jìn)來的數(shù)據(jù)是干凈的nil 就只是一種正常狀態(tài)不值得恐懼。如果你讀完這一篇只記住三句話我希望是變量沒有類型、對(duì)象才有優(yōu)先思考對(duì)象能做什么而不只是它是誰數(shù)據(jù)入口做嚴(yán)格的歸一化業(yè)務(wù)內(nèi)部保持寬容和統(tǒng)一。Ruby 的數(shù)據(jù)類型并不難難的是轉(zhuǎn)換思路。希望這些踩過的坑能幫你少走幾步彎路。