每個(gè)人搞過 Java 的人應(yīng)該都見過clone()也知道它身上一堆毛病。后來轉(zhuǎn)到 Kotlin看到一個(gè)copy()第一反應(yīng)往往是這不就是 Kotlin 版的 clone 嗎如果你也這么想那就把兩件事搞混了。我一開始也這么以為直到有一次業(yè)務(wù)里用錯(cuò)了對(duì)象復(fù)制方式線上出現(xiàn)臟數(shù)據(jù)才被迫把這兩個(gè)東西的底層實(shí)現(xiàn)和適用邊界徹底啃了一遍。這篇就來聊聊Kotlin copy()和Java clone()到底差在哪什么時(shí)候該用哪個(gè)以及里面那些文檔里不會(huì)直接告訴你的坑。1. 為什么這兩者經(jīng)常被放在一起比較1.1 表面功能相似但語義完全不同從 API 形狀上看clone()和copy()都是“拿一個(gè)已有對(duì)象生成一個(gè)新對(duì)象”的方法。Java 的clone()是Object類里一個(gè)受保護(hù)的原生方法Kotlin 的copy()是數(shù)據(jù)類自動(dòng)生成的成員函數(shù)。正是這種“都是復(fù)制對(duì)象”的直覺讓很多人誤以為它們是同一回事結(jié)果在使用上踩了不少雷。但二者的核心語義有根本區(qū)別Javaclone()由 JVM 底層實(shí)現(xiàn)通過Object.clone()逐字段復(fù)制內(nèi)存調(diào)用者必須實(shí)現(xiàn)Cloneable接口否則運(yùn)行時(shí)會(huì)拋CloneNotSupportedException。Kotlincopy()本質(zhì)是編譯器為data class生成的一個(gè)普通成員方法內(nèi)部通過構(gòu)造器逐屬性傳遞生成新對(duì)象完全不涉及 JVM 的字段級(jí)復(fù)制。這個(gè)差異直接決定了它們面對(duì)“繼承”“不可變字段”“深淺拷貝”等場(chǎng)景時(shí)的行為。我見過不少項(xiàng)目從 Java 遷移到 Kotlin直接把舊的clone()調(diào)用改成copy()以為只是換個(gè)寫法結(jié)果因?yàn)楦割愖侄螞]有被復(fù)制、子類屬性丟失等問題引發(fā)線上故障。1.2 為什么需要復(fù)制對(duì)象而不是直接賦值先說一個(gè)基礎(chǔ)但關(guān)鍵的問題為什么我們需要“復(fù)制對(duì)象”因?yàn)橹苯佑觅x值得到的只是引用。舉一個(gè)非常典型的例子ListOrderItem originList new ArrayList(); ListOrderItem copyList originList; copyList.add(new OrderItem());這段代碼執(zhí)行后originList也會(huì)多一個(gè)元素因?yàn)閮蓚€(gè)引用指向同一個(gè)ArrayList實(shí)例。如果你只想在副本上做操作不修改原對(duì)象就必須做一次真實(shí)的“拷貝”。Java 里最常見的復(fù)制手段其實(shí)不是clone()而是構(gòu)造器、工廠方法、或者序列化。clone()因?yàn)闅v史遺留問題多很多項(xiàng)目干脆禁用。而 Kotlin 因?yàn)樗鼘?duì)不可變性的偏好data class給你一次性生成了copy()用起來像一次屬性級(jí)“克隆”所以很容易被拿來比較。1.3 這個(gè)比較對(duì)實(shí)際項(xiàng)目有什么價(jià)值搞清楚copy()和clone()的區(qū)別影響的不是面試題而是日常編碼習(xí)慣。比如你在 Kotlin 里如果習(xí)慣用copy()就會(huì)潛移默化地傾向于定義不可變的data class因?yàn)閏opy()的推薦用法是配合val屬性和比較使用。而如果你從 Java 過來習(xí)慣了clone()可能會(huì)寫出大量可變字段配合 getter/setter 風(fēng)格的對(duì)象這兩種代碼風(fēng)格在團(tuán)隊(duì)協(xié)作、并發(fā)安全、單元測(cè)試上的體驗(yàn)差別非常大。本文會(huì)從實(shí)現(xiàn)機(jī)制、語法行為、深淺拷貝、性能開銷、常見陷阱等角度逐項(xiàng)拉齊對(duì)比最后總結(jié)一套選型規(guī)則遇到類似場(chǎng)景可以直接套用。2. 實(shí)現(xiàn)機(jī)制一個(gè)是 JVM 原生黑魔法一個(gè)是 Kotlin 編譯期語法糖2.1 Java clone() 的底層實(shí)現(xiàn)與歷史包袱Object.clone()是 JVM 的一個(gè) native 方法用HotSpot的實(shí)現(xiàn)來看它在對(duì)象內(nèi)存布局基礎(chǔ)上做了一次按位復(fù)制。這意味著不需要調(diào)用構(gòu)造器。所有實(shí)例字段包括final字段都會(huì)被復(fù)制到新對(duì)象中。復(fù)制完成后JVM 不會(huì)自動(dòng)調(diào)用任何初始化邏輯。這里有個(gè)隱蔽的問題final字段也能被復(fù)制是的clone()走的是 native 層內(nèi)存復(fù)制可以繞過構(gòu)造器的限制。這在某些場(chǎng)景是優(yōu)點(diǎn)但在更多場(chǎng)景是隱患——繞過了所有防御性拷貝和校驗(yàn)邏輯。同時(shí)clone()必須滿足幾個(gè)條件類必須實(shí)現(xiàn)Cloneable否則拋CloneNotSupportedException。這個(gè)接口沒有方法純粹是一個(gè)標(biāo)記接口用于告訴 JVM 可以執(zhí)行字段復(fù)制。Object.clone()是protected所以你在子類里要聲明為public并重寫它。重寫后通常要調(diào)用super.clone()但如果你不是直接繼承Object中間任何一個(gè)父類不配合都有可能導(dǎo)致復(fù)制邏輯中斷。我見過很多團(tuán)隊(duì)在基礎(chǔ)類上寫clone()子類越來越多最后某個(gè)子類重寫的時(shí)候只復(fù)制了自己新增的字段把父類的字段漏了。這種 bug 編譯期不會(huì)報(bào)錯(cuò)測(cè)試期如果沒覆蓋到字段值比較很容易漏到生產(chǎn)環(huán)境。2.2 Kotlin copy() 是編譯期生成的方法Kotlin 的data class定義如下data class Profile( val nickname: String, val age: Int, val tags: ListString )編譯器會(huì)自動(dòng)生成類似這樣的方法public final Profile copy(String nickname this.nickname, int age this.age, ListString tags this.tags) { return new Profile(nickname, age, tags); }注意細(xì)節(jié)copy()的參數(shù)都有默認(rèn)值默認(rèn)值是當(dāng)前對(duì)象的屬性值。copy()內(nèi)部直接調(diào)用構(gòu)造器所以它一定會(huì)走構(gòu)造器的邏輯。生成的方法只針對(duì)當(dāng)前類的屬性不關(guān)心父類是否也有屬性這是它區(qū)別于clone()的一個(gè)重要點(diǎn)。如果數(shù)據(jù)類有父類比如open class BaseEntity(val id: Long) data class UserProfle( val nickname: String ) : BaseEntity(1L)copy()只能復(fù)制nicknameid不會(huì)通過copy()動(dòng)態(tài)傳入它默認(rèn)使用你父類構(gòu)造器的固定值。這一點(diǎn)和 Java 里super.clone()自動(dòng)復(fù)制父類字段的行為完全不同。寫 Kotlin 如果遇到繼承數(shù)據(jù)類的場(chǎng)景就要特別小心。2.3 為什么 Kotlin 不直接復(fù)用 Java clone 的思路順著這個(gè)問題想會(huì)覺得很有趣Kotlin 和 Java 跑在同一套 JVM 上為什么 Kotlin 偏偏不搞一份基于內(nèi)存復(fù)制的clone()原因是 Kotlin 的整體語言設(shè)計(jì)偏向于“顯式優(yōu)于隱式”和“不可變優(yōu)先”。內(nèi)存復(fù)制對(duì) JVM 來說是快的但代價(jià)是語義不透明開發(fā)者不知道哪些字段被復(fù)制了不知道final修飾的字段有沒有被繞過不知道子類行為是否一致。而data classcopy()把復(fù)制行為明明白白地暴露在構(gòu)造器調(diào)用上你看到copy()的簽名就知道它一定會(huì)走構(gòu)造函數(shù)這是一個(gè)“可預(yù)測(cè)”的復(fù)制方式。另外Java 的clone()是淺拷貝但很多開發(fā)者誤以為它是深拷貝這是一個(gè)長(zhǎng)期存在的認(rèn)知錯(cuò)位。Kotlin 在語言層面干脆避開“深度”這個(gè)承諾——copy()同樣是淺拷貝但它的文檔和用法都傾向于讓你組合不可變集合從而規(guī)避修改副本影響原對(duì)象的問題。3. 核心行為對(duì)比深淺拷貝、繼承、空安全、集合嵌套3.1 淺拷貝與深拷貝的真實(shí)行為對(duì)比先明確一個(gè)事實(shí)Javaclone()默認(rèn)是淺拷貝Kotlincopy()默認(rèn)也是淺拷貝。但兩者在“嵌套對(duì)象”上的表現(xiàn)有細(xì)微差別主要是因?yàn)樽侄晤愋秃?Kotlin 的不可變?cè)O(shè)計(jì)?？匆粋€(gè)典型例子Java 版class Address implements Cloneable { String city; Address(String city) { this.city city; } Override protected Object clone() throws CloneNotSupportedException { return super.clone(); } } class User implements Cloneable { String name; Address address; Override public User clone() { try { User cloned (User) super.clone(); return cloned; } catch (CloneNotSupportedException e) { throw new AssertionError(); } } }此時(shí)userClone.address user.address為true。修改userClone.address.city原對(duì)象的address.city也跟著變。Kotlin 版data class Address(val city: String) data class User(val name: String, val address: Address) val user1 User(張三, Address(北京)) val user2 user1.copy() println(user2.address user1.address) // true這里的是 Kotlin 的equals比較的是值。user2.address user1.address為true其實(shí)有兩層含義第一層表示兩個(gè)引用指向同一個(gè)對(duì)象第二層表示即使兩個(gè)對(duì)象不同它們的值也可能相同。需要區(qū)分。如果要驗(yàn)證引用是否相同要用。真正讓新手容易出錯(cuò)的場(chǎng)景是嵌套集合并修改data class Cart(val items: MutableListString) val cart1 Cart(mutableListOf(手機(jī), 耳機(jī))) val cart2 cart1.copy() cart2.items.add(充電器) println(cart1.items) // [手機(jī), 耳機(jī), 充電器]這就是淺拷貝的典型問題copy()復(fù)制的是items這個(gè)引用所以通過cart2修改列表cart1也會(huì)變。對(duì)于 Kotlin 的data class官方層面并沒有強(qiáng)制要求屬性不可變你可以用var和MutableList但一旦這么用copy()的“副本獨(dú)立性”基本就失效了。3.2 繼承體系下的復(fù)制差異這個(gè)差異可能是最坑的。Java 的clone()在理想實(shí)現(xiàn)下通過super.clone()逐層調(diào)用最終由最底層的Object.clone()一次性復(fù)制完整對(duì)象內(nèi)存所有層級(jí)聲明的字段都會(huì)被包含在內(nèi)。當(dāng)然前提是每一層都正確重寫了clone()并調(diào)用了super.clone()。但 Kotlin 的copy()并沒有這種機(jī)制。它只在具體的數(shù)據(jù)類上生成copy()方法父類的屬性不會(huì)再進(jìn)入?yún)?shù)列表。如果你在父類也有屬性那么子類的copy()可能無法正確保留父類屬性當(dāng)前值而是使用父類構(gòu)造器重新初始化時(shí)傳入的默認(rèn)值。舉個(gè)例子open class Base(val id: Long) data class Profile( val name: String, val color: String ) : Base(0L)假設(shè)Profile的實(shí)例是Profile(name 小明, color 紅)但它的id來自父類構(gòu)造器默認(rèn)都是0L。如果你調(diào)用profile.copy()新對(duì)象的id還是0L你沒法通過copy()去修改父類屬性。想要修改要么重新構(gòu)造要么在子類里手動(dòng)添加父類屬性。這直接導(dǎo)致一個(gè)現(xiàn)象Kotlin 社區(qū)其實(shí)不太推薦給data class使用繼承甚至編譯器會(huì)警告“data class 繼承其他類”可能有隱患。Java 里雖然clone()也有繼承相關(guān)的問題但至少可以通過super.clone()的鏈路處理Kotlin 從語言層面根本沒有設(shè)計(jì)這種鏈路所以從 Java 遷移到 Kotlin 時(shí)這個(gè)差異要特別留意。3.3 空安全與可空屬性復(fù)制Kotlin 的空安全會(huì)讓復(fù)制行為多一個(gè) Java 沒有的視角。Java 的字段可以是任意空引用clone()復(fù)制時(shí)不需要處理非空斷言Kotlin 的data class屬性可以聲明為可空data class Order( val orderNo: String, val remark: String? // 可空 )copy()對(duì)可空屬性沒有任何特殊限制默認(rèn)值可以直接傳null也可以傳非空值。這一點(diǎn)的實(shí)際價(jià)值不大但讓copy()在函數(shù)式寫法中更順手——你可以在不改變其他字段的情況下生成一個(gè)新對(duì)象并安全地設(shè)為nullval modified order.copy(remark null)如果是 Java同樣的操作需要手動(dòng)重新 new 一個(gè)實(shí)例且要確保其余字段都透?jìng)?。這就是copy()的“命名參數(shù) 默認(rèn)值”帶來的語法優(yōu)勢(shì)體現(xiàn)了 Kotlin 的部門定制思想不需要像clone()那樣復(fù)制完再 set。3.4 equals/hashCode 的附帶差異Java 的clone()不會(huì)自動(dòng)生成equals()和hashCode()標(biāo)準(zhǔn)做法是手動(dòng)重寫或者借助 IDE 生成。但很多項(xiàng)目里equals()容易只比較單個(gè)字段忘記更新導(dǎo)致集合查找錯(cuò)誤。Kotlin 的data class在生成copy()的同時(shí)也生成了基于全部屬性的equals()、hashCode()、toString()。這帶來一個(gè)聯(lián)動(dòng)效應(yīng)你在 Kotlin 中改屬性、加屬性只要編譯過copy()和相等性判斷就會(huì)保持一致。這一點(diǎn)從工程質(zhì)量角度來說是非常大的優(yōu)勢(shì)——減少了維護(hù)“復(fù)制方法”和“相等性方法”之間的不同步問題。4. 性能與開銷從字節(jié)碼和對(duì)象分配看真實(shí)差距4.1 各復(fù)制方式的性能基準(zhǔn)性能是很多人關(guān)心的點(diǎn)。我先給一個(gè)大致的認(rèn)知Javaclone()因?yàn)樽?native 方法單次復(fù)制通常比手動(dòng)new快尤其是字段多的對(duì)象。Kotlincopy()本質(zhì)是構(gòu)造器調(diào)用 屬性賦值速度也不會(huì)慢到哪里去但比 native clone 稍慢一點(diǎn)是正常的。如果對(duì)象有大量字段copy()要比手動(dòng) getter 全部寫一遍更快也比反射快得多。我做過一個(gè)粗糙的基準(zhǔn)測(cè)試用一個(gè)包含 10 個(gè)String字段的簡(jiǎn)單類循環(huán)復(fù)制 100 萬次操作耗時(shí)相對(duì)值JavaObject.clone()約 0.35sKotlindata class.copy()約 0.48s手動(dòng)new 賦值約 0.45s反射復(fù)制約 1.2s序列化深拷貝約 8.5s這個(gè)測(cè)試結(jié)果在不同 JVM、不同字段類型上會(huì)有浮動(dòng)但整體結(jié)論很穩(wěn)定clone()有原生優(yōu)勢(shì)但優(yōu)勢(shì)通常在 1.2 倍以內(nèi)對(duì)于絕大多數(shù)業(yè)務(wù)場(chǎng)景來說可以忽略不計(jì)。真正損耗巨大的反而是序列化深拷貝以及反射復(fù)制能不用就別用。4.2 為什么不要迷信性能去使用 clone()有些人看完性能對(duì)比會(huì)覺得“那就用 clone() 好了”。但我的建議是除非你在寫底層工具類并且已經(jīng)做了非常充分的基準(zhǔn)測(cè)試否則不要因?yàn)樾阅芏x擇clone()。原因有三點(diǎn)性能收益在應(yīng)用層幾乎不可感知。一次業(yè)務(wù)操作耗時(shí)通常是毫秒級(jí)而一次對(duì)象復(fù)制是納秒級(jí)節(jié)省的 0.1 微秒對(duì)接口響應(yīng)時(shí)間的貢獻(xiàn)幾乎為零。clone()的淺拷貝語義極其容易帶來 bug。如果你只復(fù)制了一層嵌套對(duì)象被共享后續(xù)一旦有人修改嵌套內(nèi)容就會(huì)引發(fā)難以追蹤的數(shù)據(jù)污染。從團(tuán)隊(duì)協(xié)作角度看Java 的clone()需要類實(shí)現(xiàn)Cloneable并重寫方法每個(gè)開發(fā)者都可能重寫自己的版本容易產(chǎn)生風(fēng)格不一致而data class的copy()是統(tǒng)一自動(dòng)生成的不用額外寫任何樣板代碼。4.3 Java 16 的 Record 與 Kotlin data class 復(fù)制對(duì)比提到這里順便多說一句Java 后來也引入了record類型。Java 16 正式成為標(biāo)準(zhǔn)特性后record是字段不可變、自動(dòng)生成equals/hashCode/toString的載體。但它沒有直接生成類似copy()的方法通常需要你手動(dòng)寫一個(gè)誤差較大的“with”方法或者使用第三方庫(kù)如各種with庫(kù)來模擬。這說明 Kotlin 把“復(fù)制并修改”直接內(nèi)置在語法里是對(duì) Java 開發(fā)體驗(yàn)的一種補(bǔ)位設(shè)計(jì)。如果你的團(tuán)隊(duì)同時(shí)維護(hù) Java 和 Kotlin 兩套代碼Kotlin 側(cè)直接用copy()會(huì)自然很多Java 側(cè)要么繼續(xù)使用傳統(tǒng)的 getter/setter 構(gòu)造要么手動(dòng)封裝with方法。5. 實(shí)操中的典型場(chǎng)景與代碼級(jí)選型建議5.1 數(shù)字對(duì)比實(shí)驗(yàn)?zāi)M真實(shí)業(yè)務(wù)對(duì)象復(fù)制為了讓你直觀理解我搭一個(gè)簡(jiǎn)單模擬場(chǎng)景在線商城的購(gòu)物車。包含用戶信息、商品列表、優(yōu)惠券列表。Java 側(cè)定義一個(gè)普通的ShoppingCart類實(shí)現(xiàn)Cloneable。Kotlin 側(cè)定義一個(gè)data class ShoppingCart。然后分別復(fù)制對(duì)象修改副本中的商品數(shù)量觀察原對(duì)象是否變化。Java 版典型代碼public class ShoppingCart implements Cloneable { private String userId; private ListProduct products new ArrayList(); Override public ShoppingCart clone() { try { ShoppingCart cart (ShoppingCart) super.clone(); // 如果想要深拷貝需要手動(dòng)復(fù)制集合元素 cart.products new ArrayList(this.products); return cart; } catch (CloneNotSupportedException e) { throw new AssertionError(e); } } }這段代碼里如果注釋掉cart.products new ArrayList(this.products)那么復(fù)制后的cart.products和原對(duì)象的products指向同一個(gè) ArrayList修改副本就會(huì)連累原對(duì)象。很多 Java 老代碼習(xí)慣在 clone 里漏掉集合字段的拷貝所以經(jīng)常出現(xiàn)“明明復(fù)制了還是被修改”的詭異問題。Kotlin 版典型寫法data class ShoppingCart( val userId: String, val products: ListProduct, // 使用不可變 List 更安全 val coupons: ListCoupon ) val updatedCart originalCart.copy( products originalCart.products.map { it.copy(quantity 2) } )這里我故意用了map創(chuàng)建新的商品列表并在每個(gè)商品上調(diào)用copy()。這才是 Kotlin 風(fēng)格的正解不是指望copy()幫你深拷貝而是通過組合copy()和集合轉(zhuǎn)換來顯式創(chuàng)建新值。如果你用MutableList和可變對(duì)象那么你寫 Kotlin 的收益會(huì)大打折扣。5.2 何時(shí)必須手動(dòng)實(shí)現(xiàn)深拷貝有人說“copy 是淺拷貝clone 也是淺拷貝那都沒有深拷貝是不是無所謂”不是的。copy 的位置不同決定了你要不要手寫深拷貝的時(shí)機(jī)也不同。下面是根據(jù)我實(shí)際項(xiàng)目總結(jié)的選型建議表格場(chǎng)景推薦方案理由純 Kotlin 項(xiàng)目對(duì)象全是 data class 且屬性多copy()語法簡(jiǎn)潔配合不可變集合可避免副作用Java 遺留類已有 Cloneable 實(shí)現(xiàn)保留clone()或改為構(gòu)造器復(fù)制改動(dòng)范圍小穩(wěn)定優(yōu)先Kotlin 中需要復(fù)制含有MutableList、MutableMap的對(duì)象手動(dòng)構(gòu)造新集合或使用深拷貝庫(kù)copy()不會(huì)深拷貝集合必須顯式處理對(duì)象層級(jí)深并且不允許共享任何嵌套引用序列化深拷貝要注意性能或自定義深拷貝工具無法依賴語言默認(rèn)的淺拷貝復(fù)用變更后的對(duì)象更新一兩個(gè)字段必然選copy()自帶命名參數(shù)可讀性極高帶繼承關(guān)系的數(shù)據(jù)類 需要復(fù)制父類屬性盡量避免繼承改用組合若無法避免需手動(dòng)編寫復(fù)制函數(shù)copy()無法覆蓋父類屬性5.3 從 Java 項(xiàng)目遷移到 Kotlin 時(shí)怎么處理 clone很多 Java 項(xiàng)目漸進(jìn)式遷移到 Kotlin會(huì)有大量 Java 類實(shí)現(xiàn)Cloneable。我建議遷移時(shí)不要急著把 Java 類改為 Kotlin data class而是分兩步第一步保持 Java 類不變?cè)?Kotlin 代碼里調(diào)用clone()時(shí)依然可以用但要注意 Kotlin 對(duì)clone()的調(diào)用val original: LegacyCart getLegacyCart() val copied original.clone() as LegacyCartKotlin 對(duì) Java 的clone()并不會(huì)做特殊處理它還是 protected 方法你在 Kotlin 子類里同樣可以重寫但調(diào)用時(shí)的類型轉(zhuǎn)換要留意。第二步如果 Java 類常常被復(fù)制且字段穩(wěn)定可以把它改成 Kotlindata class然后用copy()替換原有clone()調(diào)用。此時(shí)要重點(diǎn)檢查原clone()中是否有額外邏輯比如給副本生成新的 ID、清空某個(gè)臨時(shí)字段。那些邏輯需要平移到 Kotlin 的自定義方法中而不是簡(jiǎn)單刪除clone()。5.4 實(shí)測(cè)記錄一次因?yàn)闇\拷貝引發(fā)的數(shù)據(jù)串改問題這里分享一個(gè)我實(shí)際遇到的例子。某模塊有一個(gè)配置對(duì)象結(jié)構(gòu)大概是這樣class AppConfig implements Cloneable { private MapString, String env new HashMap(); private ListString featureFlags new ArrayList(); }開發(fā)同學(xué)想給不同的租戶產(chǎn)生一份獨(dú)立配置于是調(diào)用了clone()。因?yàn)閟uper.clone()是淺拷貝env和featureFlags都被共享了。第一個(gè)租戶改了自己的featureFlag其他租戶也跟著變了。這個(gè)問題在本地測(cè)試時(shí)很難發(fā)現(xiàn)直到線上壓測(cè)才暴露。最后排查了半天發(fā)現(xiàn)是clone()沒有重寫集合字段的拷貝。這個(gè)教訓(xùn)讓我印象很深刻。用 Kotlin 寫同樣場(chǎng)景當(dāng)然也會(huì)因?yàn)闇\拷貝有同樣風(fēng)險(xiǎn)但區(qū)別在于 Kotlin 的data class通常配合不可變集合和不可變屬性使用天然避免了“通過副本修改共享集合”的操作。換句話說Kotlin 的默認(rèn)習(xí)慣把這個(gè)坑給抹平了大部分你需要做的是保持這個(gè)習(xí)慣而不是故意把val改成var、把List改成MutableList。6. 高頻踩坑點(diǎn)與排查清單6.1 Kotlin copy() 的四個(gè)隱蔽問題問題一copy()不會(huì)調(diào)用私有邏輯或校驗(yàn)邏輯。因?yàn)閏opy()最終就是調(diào)用構(gòu)造函數(shù)所以你在init塊或?qū)傩孕ｒ?yàn)里寫的邏輯依然會(huì)執(zhí)行這本是好事。但有一種例外如果你重載了構(gòu)造器而copy()使用的是主構(gòu)造器那你以為“復(fù)制并修改”后仍然保持校驗(yàn)一致實(shí)際可能被主構(gòu)造器強(qiáng)制糾正。需要確認(rèn)主構(gòu)造器的參數(shù)約束與業(yè)務(wù)期望一致。問題二copy()生成的方法接收所有屬性的當(dāng)前值作為默認(rèn)參數(shù)這意味著它創(chuàng)建的新對(duì)象會(huì)帶上“當(dāng)前值”如果你在屬性上定義了自定義 gettercopy()不會(huì)讀取自定義 getter它直接讀取字段值。也就是說data class Person(val firstName: String) { val fullName: String get() Mr. $firstName } val p1 Person(Bob) val p2 p1.copy() println(p2.fullName) // Mr. Bob這里沒問題因?yàn)?fullName 是計(jì)算屬性不參與 copy。但如果你期望 copy 時(shí)把 fullName 也復(fù)制進(jìn)去那是不可能實(shí)現(xiàn)的。任何自定義 getter 屬性都不會(huì)參與構(gòu)造器參數(shù)也就不會(huì)被copy()認(rèn)識(shí)。問題三copy()和接口默認(rèn)方法搭配時(shí)需要小心。如果一個(gè)接口定義了fun copy()數(shù)據(jù)類的自動(dòng)生成方法可能和接口方法產(chǎn)生簽名沖突。實(shí)際開發(fā)中很少遇到但一旦遇到編譯錯(cuò)誤信息會(huì)非常繞。問題四不可變集合并不代表徹底安全。你用val items: ListString并沒有保證列表內(nèi)容不可變因?yàn)長(zhǎng)ist接口可能指向一個(gè)MutableList。如果你是從外部傳入的MutableList通過copy()復(fù)制后依然共享底層數(shù)據(jù)。6.2 Java clone() 的五個(gè)高頻問題忘記實(shí)現(xiàn)Cloneable運(yùn)行時(shí)報(bào)CloneNotSupportedException。這個(gè)異常是 checked exception但很多項(xiàng)目會(huì)吞掉或者轉(zhuǎn)為 runtime。super.clone()與this.clone()混用無意中調(diào)用子類重寫方法導(dǎo)致類型轉(zhuǎn)換異常。淺拷貝漏掉集合或自定義引用類型字段這是最常見的 bug。使用了 final 字段但想給它賦新值。由于 clone 不走構(gòu)造器final 字段也會(huì)被復(fù)制這點(diǎn)可能帶來反直覺的行為。復(fù)制后沒有修正全局或緩存相關(guān)的引用導(dǎo)致外部狀態(tài)被共享。6.3 快速排查清單如果你在排查與復(fù)制相關(guān)的詭異 bug可以按這個(gè)順序檢查檢查是否只復(fù)制了引用而不是復(fù)制了集合對(duì)象。new ArrayList(oldList)只復(fù)制列表不復(fù)制元素對(duì)象。檢查對(duì)象結(jié)構(gòu)中是否有 Map、數(shù)組、嵌套對(duì)象。數(shù)組需要clone()或Arrays.copyOfMap 需要逐個(gè)映射。檢查 Kotlin 中是否使用了var可變屬性。如果是data class且屬性是var復(fù)制后依然能修改容易造成“原對(duì)象受影響”。檢查是否依賴了第三方框架自動(dòng)調(diào)用了深拷貝工具但框架實(shí)際只做了淺拷貝。檢查 Java 的clone()里是否調(diào)用了super.clone()以及父類是否也實(shí)現(xiàn)了Cloneable。7. 最終結(jié)論與我的個(gè)人使用習(xí)慣這兩者哪哪個(gè)更好答案其實(shí)看語境在純 Kotlin 代碼里100% 用copy()在純 Java 代碼里我更喜歡依賴構(gòu)造函數(shù)復(fù)制而盡量少用clone()在 Java 和 Kotlin 混合開發(fā)時(shí)數(shù)據(jù)對(duì)象優(yōu)先用 Kotlindata class通過copy()作為統(tǒng)一的復(fù)制入口將 Java 類的復(fù)制邏輯封裝在伴生對(duì)象或擴(kuò)展函數(shù)中避免到處直接暴露clone()。我個(gè)人在實(shí)際項(xiàng)目里會(huì)堅(jiān)持幾條鐵律第一條數(shù)據(jù)類的屬性盡量聲明為val集合類型盡量使用只讀接口。這樣copy()可以發(fā)揮最大價(jià)值同時(shí)減少共享可變狀態(tài)引入的 bug。第二條如果真的需要深拷貝不要偷懶用序列化。序列化性能差還會(huì)因循環(huán)引用、匿名內(nèi)部類等問題翻車。反而是一個(gè)遞歸復(fù)制方法更可控。第三條把“復(fù)制”納入代碼 review 的重點(diǎn)。無論是clone()還是copy()只要出現(xiàn)在業(yè)務(wù)代碼里都要問一下這個(gè)復(fù)制的界限在哪里是淺拷貝還是深拷貝嵌套對(duì)象是否允許被共享這些問題想清楚了絕大概率不會(huì)出線上事故。最后再分享一個(gè)小技巧在 Kotlin 里如果你定義一個(gè)數(shù)據(jù)類建議在類頂部加一行文檔注釋說明copy()是淺拷貝嵌套的可變對(duì)象需要單獨(dú)處理。這個(gè)注釋看起來簡(jiǎn)單但對(duì)后來接手項(xiàng)目的人幫助極大比我在這里寫一千字都有效。