兩個符號如何改變Go的內存游戲規則

Alice把鑰匙遞給你時，她本可以復印整棟房子的內容——昂貴、笨重，且你的改動不會影響原物。但她選擇寫下一個地址。這個選擇，正是Go指針的核心隱喻。

每個Go開發者都會遇到&和*。它們初看晦澀，有時甚至在同一行緊挨著出現。但一旦你理解它們在硬件層面的真實含義，這些符號就會變成直覺。

內存不是抽象概念，是字節數組

你的RAM在硬件層面是一個巨大的連續字節數組。每個字節有唯一的數字索引——這就是內存地址。64位系統上，地址是64位整數，理論尋址空間達2^64字節（約18艾字節）。實際中，操作系統和硬件會限制映射到物理芯片的空間。

聲明var age int = 42時，運行時并非創造抽象的"變量"。它在這個字節數組中挑選位置，寫入42的二進制表示（64位系統上int占8字節），并將名字age與這個地址關聯。名字只存在于源碼和調試符號中；運行時只有地址和字節。

CPU通過內存總線與RAM通信。讀取：CPU把地址放到總線上，RAM返回該位置的字節。寫入：CPU把地址和值放到總線上，RAM存儲。這只需納秒——很快，但比讀CPU寄存器或緩存慢得多。

&取地址，*解引用：一場門牌號與鑰匙的配合

回到Alice的房子。&是"寫下地址"的動作——它取一個值的內存地址，返回一個指針。*是"用鑰匙開門"——它接收一個指針，讓你訪問或修改那個地址存儲的實際數據。

這種區分在函數傳參時變得關鍵。Go默認按值傳遞：函數拿到的是數據的副本。如果數據是大型結構體，復制成本高昂。更糟的是，函數內的修改影響不了原值。

指針打破這個限制。傳遞指針時，你復制的只是一張"地址紙條"——8字節，與數據大小無關。函數通過*解引用，直接操作原內存位置的值。副作用？這正是設計意圖。

硬件真相：為什么指針關乎性能

CPU緩存層級（L1/L2/L3）比主內存快10-100倍。指針本身很小，容易留在緩存中。但解引用后的數據訪問可能觸發緩存未命中，需要到主內存取數。

更隱蔽的是指針的間接性帶來的優化障礙。編譯器難以追蹤指針指向的數據流，某些激進的優化（如寄存器分配、指令重排）被迫保守。密集指針結構比連續數組更難被CPU預取機制預測。

Go的垃圾回收器同樣受指針布局影響。指針越多，GC需要掃描的引用關系越復雜。這是map和slice內部設計的考量之一——它們在必要時才暴露指針語義，平衡靈活性與GC壓力。

權衡的藝術：何時該用，何時該躲

小數據（int、bool、小結構體）直接傳值，復制成本低于指針解引用的間接開銷。大數據結構或需要函數修改原值時，指針合理。

但指針引入的生命周期問題常被低估。返回局部變量的指針？Go的逃逸分析會把它移到堆上，觸發GC負擔。這是go build -gcflags="-m"能告訴你的故事——哪些變量"逃逸"到堆，為什么。

并發場景下，指針是共享內存的通道，也是數據競爭的源頭。sync.Mutex保護的應是它旁邊的數據，但指針讓這份保護可以跨越函數邊界，責任邊界隨之模糊。

&和*不是語法糖，是Go與硬件內存模型的直接對話。理解它們，意味著理解你的變量住在RAM的哪個字節、CPU如何找到它、復制與共享的代價幾何。

下次寫函數簽名時，停一秒：這個參數該傳值還是傳指針？這個選擇背后，是納秒級的延遲、堆分配的觸發與否、以及未來維護者能否一眼看出數據流向。Go的簡潔性不幫你做這個決定——它把權力和責任同時交到你手上。