PHP 成員變量訪問性能深度解析：四種模式的 Opcode 對比

在 PHP 代碼優化中，成員變量的訪問方式往往被忽視，實際上不同的定義與調用方式在底層 Opcode 層面有顯著差異。本文通過四個典型代碼片段，結合 VLD 擴展輸出的 Opcode 及 Zend VM 實現，深入剖析性能排序背後的原理。

四種測試場景

1. 公有屬性 + 直接賦值 + 直接讀取（Foo）
2. 公有屬性 + 構造函數賦值 + 直接讀取（Foo2）
3. 受保護屬性 + 構造函數賦值 + 普通方法獲取（Foo3）
4. 受保護屬性 + 構造函數賦值 + 魔術方法 __get 獲取（Foo4）

性能排序結果：1 > 2 > 4 > 3

即：直接訪問公有屬性最快，魔術方法 __get 次之，自定義 Getter 方法最慢。

Opcode 逐項拆解

場景 1：直接賦值、直接讀取

ZEND_FETCH_CLASS 'Foo'
NEW
DO_FCALL_BY_NAME (構造函數，無參)
ASSIGN
ZEND_ASSIGN_OBJ  !0, 'id'   ; 直接對象屬性寫入
ZEND_OP_DATA   10
FETCH_OBJ_R    $9, !0, 'id' ; 直接對象屬性讀取
ECHO           $9

最精簡：無參構造、無函數調用開銷，屬性操作直擊 zend_std_write_property / zend_std_read_property。

場景 2：構造函數傳參賦值

ZEND_FETCH_CLASS 'Foo2'
NEW
SEND_VAL 10                 ; 參數壓棧
DO_FCALL_BY_NAME 1          ; 調用 __construct($id)
ASSIGN
FETCH_OBJ_R $14, !1, 'id'   ; 直接讀取
ECHO $14

比場景 1 多了 SEND_VAL 與帶參數的 DO_FCALL_BY_NAME。參數處理（zend_parse_parameters、變量複製/引用計數）在高頻調用下開銷可觀。

場景 3：自定義 Getter 方法

ZEND_FETCH_CLASS 'Foo3'
NEW
SEND_VAL 10
DO_FCALL_BY_NAME 1          ; __construct
ASSIGN
ZEND_INIT_METHOD_CALL !2, 'getId' ; 初始化方法調用
DO_FCALL_BY_NAME 0 $20      ; 執行 getId()
ECHO $20

引入 ZEND_INIT_METHOD_CALL + DO_FCALL_BY_NAME 兩條指令，意味著完整的用戶空間函數調用棧幀創建、執行、銷毀，開銷遠大於屬性直接讀取。

場景 4：魔術方法 __get

ZEND_FETCH_CLASS 'Foo4'
NEW
SEND_VAL 10
DO_FCALL_BY_NAME 1
ASSIGN
FETCH_OBJ_R $25, !3, 'id'   ; 觸發內部魔術方法調用
ECHO $25

Opcode 看似與場景 1 相同（FETCH_OBJ_R），但關鍵差異在 C 層：zend_std_read_property 發現屬性不存在（protected 不可外部訪問），轉而檢測並調用內部 __get。內部函數調用無需用戶空間棧幀切換，效率高於場景 3。

核心結論與優化建議

1. 優先使用內置函數/機制：內核實現（如 __get、陣列訪問）比用戶自定義方法快。
2. 謹慎使用 OOP 封裝：每個方法調用、對象創建都伴隨記憶體分配與棧幀開銷。性能敏感場景可考慮 public 屬性或數組替代。
3. 減少魔術方法：除非必要（如代理、懶加載），否則避免 __get/__set/__call 等，框架大量使用魔術方法是性能瓶頸來源之一。
4. 參數傳遞優化：多參數函數考慮打包為陣列/對象傳入，減少 SEND_VAL 開銷。
5. 語法結構 > 函數 > 對象：能用語言結構（如 isset、empty）不用函數；能用內置函數（如 array_map）不用自寫循環；能用函數不用對象封裝。

「過早優化是萬惡之源」，但在高併發、高頻調用的核心路徑上，理解底層機制並做出正確選擇，往往能帶來數倍的吞吐量提升。