193 - Python 觀念理解 on 嗡嗡的隨手筆記

【Python 觀念理解 #3】mutation、mutability、copy 三件事，拆開想就不會亂 (shallow copy / deep copy)

Fri, 24 Jul 2026 22:00:00 +0800

前言

上一篇【Python 觀念理解 #2】pass by object reference 寫完之後，
我以為我懂了。結果實際寫 code 時還是會慌：

這個型別能不能改？（mutability）

這次呼叫會不會動到原資料？（mutation，原地改動這個「動作」）

我要不要先複製一份？（copy）

一緊張就開始亂猜，三個問題揉成一團 XD。

後來發現問題出在：這根本是三個獨立的問題，各有各的答案，
混著想才會覺得玄。這篇就把它們拆成三層，一層一層講。

第一層：傳參數的規則只有一條，而且它不改任何東西

先把上一篇的結論搬過來當地基：

呼叫端跟函式內的變數名字，是貼在同一個物件上的兩張便利貼。

def func(data):
    ...

a = [1, 2, 3]
func(a)   # 此刻 data 跟 a 貼在同一個 list 上

重點是：這條規則本身不會導致任何東西被改。
貼便利貼這個動作是無害的，資料會不會變，要看後面兩層。

所以「傳進函式」不是危險動作，它只是把「共用同一個物件」這件事準備好而已。

第二層：mutability 只是「門票」

型別決定了你能不能對物件做原地改動，僅此而已。
list 有門票、tuple 沒有：

lst = ["a", "b", "c"]
lst[0] = "X"          # OK，list 可以原地改
print(lst)

tup = ("a", "b", "c")
tup[0] = "X"          # 直接報錯

結果：

['X', 'b', 'c']
Traceback (most recent call last):
  File "demo.py", line 6, in <module>
    tup[0] = "X"
TypeError: 'tuple' object does not support item assignment

注意「門票」這個詞的意思：mutable 只代表可以被改，
不代表它會被改。會不會真的被改、誰看得到，那是第三層的事。

邊界情況：tuple 裡面裝 list

這是我覺得最能檢驗有沒有真懂的例子。
tuple 本身鎖死，但它格子裡裝的 list 還是能改：

t = ([1, 2], "hello")

t[0] = [9, 9]         # 不行，動到 tuple 的格子

結果：

TypeError: 'tuple' object does not support item assignment

t = ([1, 2], "hello")

t[0].append(3)        # 可以！動的是格子裡那個 list
print(t)

結果：

([1, 2, 3], 'hello')

tuple 鎖的是「每個格子貼著哪個物件」，不是那些物件的內容。
所以 tuple 只是 shallow immutable（外殼不可變），
裡面裝了 mutable 的東西，該能改還是能改。

第三層：會不會被外面看到，只看動詞打在哪

這層的判斷準則跟上一篇完全同一條：

看這行 code 的動詞，是打在「物件本身」還是「變數名字」上。

而且要強調：這跟它是不是函式參數完全無關，在最外層一樣成立：

a = [1, 2, 3]
b = a

b.append(4)   # 動詞打在物件上：a 看得到
print(a)

b = [0]       # 動詞打在名字上：只是換便利貼，a 不受影響
print(a)

結果：

[1, 2, 3, 4]
[1, 2, 3, 4]

沒有任何函式出場，行為一模一樣。
所以不用背「函式裡改參數會怎樣」的特例，根本沒有特例，就這一條規則。

Copy 是完全獨立的第三件事，而且要自己動手

前面三層講完，你會發現一件事：Python 從頭到尾都沒有幫你複製任何東西。
賦值不複製、傳參數不複製，預設就是大家共用同一個物件。

想要一份獨立的資料？要自己主動觸發，而且這裡有一個經典的坑。

Shallow copy：只複製最外層

「lst.copy()」或「lst[:]」都是 shallow copy，
它只建立新的外殼，內層還是共用參考：

grid = [[1, 2], [3, 4]]
shallow = grid[:]          # 或 grid.copy()

shallow[0][0] = 99         # 改「內層」：慘，grid 也跟著變
print(grid)

shallow[1] = [7, 8]        # 改「外層」：安全，grid 不受影響
print(grid)

結果：

[[99, 2], [3, 4]]
[[99, 2], [3, 4]]

為什麼？因為 shallow copy 做的新外殼裡，
每個格子還是貼在原本的內層 list 上。
改內層等於改到共用的物件；換掉外層的格子才是動到新外殼自己。

Deep copy：連內層一起複製

真的要一份完全獨立的資料，兩個選擇：

import copy

grid = [[1, 2], [3, 4]]

deep1 = copy.deepcopy(grid)          # 萬用，巢狀多深都處理
deep2 = [row[:] for row in grid]     # 二維 list 的手工版，刷題常見

deep1[0][0] = 99
deep2[0][0] = 77
print(grid)

結果：

[[1, 2], [3, 4]]

原資料毫髮無傷。代價當然是複製的時間跟空間，所以才說 copy 要「主動觸發」，
Python 不會自作主張幫你付這個成本。

實戰收斂：預設直接 mutate，不能動再說

講完三層，實際寫演算法時我自己的原則很簡單：

預設直接 mutate 原始資料，除非題目明講不能動 input。

像 flood-fill 這類演算法，直接把走過的格子改掉當記號，
省空間又省事，大部分情況這樣就對了。

真的不能動 input 時，兩個選項：

手動 shallow-copy 每一列：「[row[:] for row in grid]」，拿一份可以亂改的副本
開一個獨立的 visited set 或 array：完全不碰原始資料，把「狀態」跟「資料」分開放

第二種通常是比較受青睞的做法：意圖清楚（一看就知道在記狀態）、
也不用擔心 copy 深度夠不夠的問題。

小測驗：真的懂了嗎？

最後留一題，把這篇的東西全部串起來。
先自己推推看呼叫端最後印出什麼，再往下對答案：

def f(lst):
    lst.append(1)     # 動作一：mutate
    lst = [0]         # 動作二：rebind
    lst.append(2)     # 動作三：mutate（但動的是誰？）

a = [9]
f(a)
print(a)

想好了嗎？（真的先想，用便利貼推一次 XD）

答案是：

[9, 1]

逐行對一次：

動作一（mutate）：此時「lst」跟「a」貼在同一個物件上，append 打在物件本身，所以外面看得到，物件變成「[9, 1]」
動作二（rebind）：把「lst」這張便利貼撕下來，貼到新物件「[0]」上。原物件不受影響，「a」還貼在上面
動作三（mutate）：又是 mutate 沒錯，但此刻「lst」貼的是新物件，動到的是「[0]」，跟「a」再也沒有關係

三個動作、每一行都用「動詞打在哪」判斷一次，答案就出來了。
推對的話，恭喜，這三件事在你腦中應該已經是分開的三格抽屜了；
推錯也沒關係，回去把出錯的那一層再看一次就好（我自己也是錯過好幾次才內化的 XD）。

小結

傳參數只是貼便利貼，這個動作本身不改任何東西
mutability 是型別給的門票：能不能改是一回事，改不改是另一回事（tuple 只鎖外殼）
會不會被外面看到，只看動詞打在「物件」還是「名字」上，跟是不是參數無關
copy 永遠要自己動手，而且 shallow copy 只複製外殼，內層還是共用

一樣，我盡力、但也不能保證完全都理解正確，
有寫錯的地方很歡迎幫忙糾正！

Reference

【Python 觀念理解 #2】C++ 與 Python 的參數傳遞差異，Python 有 call by reference 或 value 的問題嗎？(Python = pass by object reference)

Fri, 24 Jul 2026 21:30:00 +0800

前言

我最早是先接觸 C++ 的，當年學的時候因為考試的關係，
被「call by value？call by reference？」這組題目狠狠教育過 XD。

於是帶著這段交戰記憶踏入 Python 的世界後，
我天天都在想這些 C++ 世界的問題：
「這裡是傳值還是傳參考？」「這樣寫外面會不會被改到？」
結果越想越混亂。

後來才想通：Python 根本沒有這個二分法，
硬要套 C++ 的心智模型，只會把自己搞混。
這篇就是為了幫我解除這個混亂而生的：
一次整理「該換掉的舊模型」跟「該裝上的新模型」。

其實很多年前我寫過一篇【Python 觀念理解 #1】記憶體位置與 function 關係之研究，
當時是用「id()」實測記憶體位置的角度切入。
這篇算是多年後的補完：把當年觀察到的現象，收斂成一個好用的心智模型。

C++ 的世界觀：變數「就是」一塊記憶體

先看 C++ 為什麼需要 call by value / call by reference 這個二分法：

void byValue(int x)  { x = 100; }   // 拷貝一份，外面不動
void byRef(int& x)   { x = 100; }   // 拿到本尊，外面跟著變

在 C++ 裡，一個變數名字背後就是一塊實際的記憶體。
所以傳參數時只有一個問題要問：

傳過去的是「這塊記憶體的拷貝」，還是「這塊記憶體本人」？

答對這題，行為就全部確定了。這套模型在 C++ 裡非常好用，
好用到我帶著它去寫 Python（然後就出事了）。

Python 的世界觀：變數是貼在物件上的便利貼

Python 的變數不是一塊記憶體，它比較像一張便利貼（label）。

a = [1, 2, 3]
b = a

第一行其實做了兩件事：先在某個地方造出 list 物件「[1, 2, 3]」，
然後把一張寫著「a」的便利貼貼上去。

第二行沒有複製任何東西，只是又拿了一張寫著「b」的便利貼，
貼在同一個物件上。

a = [1, 2, 3]
b = a
b.append(4)
print(a)

結果：

[1, 2, 3, 4]

兩張便利貼、同一個物件，所以誰動了物件，另一張便利貼看過去當然也是動過的樣子。
注意這段完全沒有函式出場，這是 Python 賦值本身的行為，不是參數傳遞的特例。

函式呼叫＝多貼一張便利貼

理解了便利貼，函式呼叫就沒有新東西了：

def func(lst):
    ...

a = [1, 2, 3]
func(a)

呼叫「func(a)」的瞬間，就只是把一張寫著「lst」的新便利貼，
貼到「a」指著的那個物件上。就這樣，沒有拷貝、也沒有 C++ 那種「別名本尊」的魔法。

這個行為的正式名稱叫 pass by object reference（也有人叫 pass by assignment），
因為它跟一般的賦值「lst = a」做的事一模一樣。

所以「Python 是 call by value 還是 call by reference？」這題的正確答案是：
都不是，問題本身就問錯了。它傳的既不是物件的拷貝，也不是變數的別名。

mutate vs rebind：出事的分界線在這

那為什麼有時候函式裡改東西，外面看得到，有時候看不到？
關鍵不在參數怎麼傳，在你對便利貼做了哪種動作：

def mutate(lst):
    lst.append(99)    # 動到「物件本身」

def rebind(lst):
    lst = [99]        # 只是把 lst 這張便利貼撕下來，貼到新物件上

a = [1, 2, 3]
mutate(a)
print("after mutate:", a)

b = [1, 2, 3]
rebind(b)
print("after rebind:", b)

結果：

after mutate: [1, 2, 3, 99]
after rebind: [1, 2, 3]

mutate 那邊應該沒懸念：「lst.append(99)」是對物件本身動手，
而「a」也貼在同一個物件上，所以外面看得到。

重點是 rebind 為什麼「沒改到」。
我第一次看的時候卡的點是：b 在傳入的當下，lst 不就已經是 b 的替身了嗎？

這正是 C++ reference 留下的最後一個坑。
lst 確實是替身，但它是「物件」的替身，不是「b」的替身：

C++ 的「byRef(int& x)」：x 綁定的是「b 這個變數本身（那塊記憶體格子）」，x 就是 b 的別名，對 x 賦值＝對 b 寫入
Python 的「rebind(b)」：傳進去的不是「b 這個名字」，是「b 當下指著的那個物件」。函式從頭到尾拿不到「b」，它只拿到物件

你以為的（C++ reference 帶來的模型）：   實際上的（Python）：

  lst ──→ b ──→ [1, 2, 3]               b ──→ [1, 2, 3] ←── lst
  （lst 是 b 的替身）                    （兩張獨立便利貼，互不認識）

lst 跟 b 之間沒有任何連結，它們只是剛好貼在同一個物件上。
帶著這個認知，把「lst = [99]」的動作一步步慢放：

呼叫「rebind(b)」的瞬間：物件「[1, 2, 3]」身上貼著兩張獨立的便利貼，「b」跟「lst」
執行「lst = [99]」這行：Python 先造出一個全新的物件「[99]」，再把「lst」這張便利貼撕下來、改貼到新物件上
函式結束：「lst」這張便利貼作廢，「[99]」沒人貼著，之後就被回收了
而「b」從頭到尾都貼在「[1, 2, 3]」上，它當然什麼事都沒有

呼叫 rebind(b) 時：            執行 lst = [99] 之後：

  b ──┐                          b ──→ [1, 2, 3]   ← 從頭到尾沒人碰過它
      ├─→ [1, 2, 3]
lst ──┘                        lst ──→ [99]        ← 全新物件，函式結束就被丟掉

換句話說，「lst = [99]」這行改的不是資料，是「lst 這個名字指向誰」。
更底層一點講：「b」住在呼叫端的登記簿（namespace）、「lst」住在函式自己的登記簿，
是兩本不同的本子；這行只改寫了函式那本登記簿的其中一行，呼叫端的登記簿碰都沒碰到。
Python 也沒有任何語法能把「呼叫端的名字」交給函式（這正是 C++ 的「&」在做的事，而 Python 刻意不提供）。

最後給一個自我檢驗法：「rebind(b)」在傳入當下做的事，跟你手寫「lst = b」一模一樣
（pass by assignment 這個名字就是這樣來的）。
你應該不會期待「lst = b」之後再「lst = [99]」會改到 b，
函式參數也是同理。

補一個容易踩的坑：「+=」

照上面的分類，「lst += [4]」有等號、動詞看起來打在名字上，
應該算 rebind（外面看不到）對吧？

錯，它是 mutate。直接看實驗：

def plus_equal(lst):
    lst += [4]          # 你以為它等於下面那行，其實不是

def plus_then_assign(lst):
    lst = lst + [4]     # 這才是真的 rebind

a = [1, 2, 3]
plus_equal(a)
print("after lst += [4]:      ", a)

b = [1, 2, 3]
plus_then_assign(b)
print("after lst = lst + [4]: ", b)

結果：

after lst += [4]:       [1, 2, 3, 4]
after lst = lst + [4]:  [1, 2, 3]

兩行長得幾乎一樣，行為卻完全相反。原因是 Python 對「+=」有特殊處理：

「lst = lst + [4]」：先造一個新的 list（原本的加上 [4]），再把「lst」便利貼搬過去。原物件沒被動過，外面看不到
「lst += [4]」：list 有定義原地版本的加法（效果同「lst.extend([4])」），所以它直接把 [4] 塞進原物件，沒有造新物件、便利貼也沒搬家。外面看得到

「+=」對 list 來說是 mutate，不是 rebind。
它是「動詞打在哪」這條準則唯一需要特別背的例外：
有等號、長得像換便利貼，實際上卻是對物件本身動手。

一句可操作的判斷準則

收斂成一句話：

看這行 code 的動詞，是打在「物件本身」還是「變數名字」上。
打在物件上（append、pop、「lst[0] = x」）：所有貼著它的便利貼都看得到。
打在名字上（「lst = …」）：只是換貼紙，其他便利貼完全不受影響。

而且這條準則跟「這是不是函式參數」無關，
在函式內、函式外、巢狀結構裡通通成立。
只要盯著動詞看，就不用再猜「這次是 by value 還是 by reference」了。

小結

C++ 的模型是「變數 = 一塊記憶體」，所以才有拷貝 vs 本尊的二分法
Python 的模型是「變數 = 貼在物件上的便利貼」，函式呼叫只是多貼一張
出不出事看動詞：mutate（動物件）外面看得到，rebind（換貼紙）外面看不到

我自己換上這個模型之後，寫題目時就不太會再慌了。
不過我盡力、但也不能保證完全都理解正確，
有寫錯的地方很歡迎幫忙糾正！

下一篇打算來拆另一團更容易混在一起的東西：
mutation、mutability、copy 這三件事（光看名字就很像 XD）。