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