這些函式的行為會受到 php.ini 中設定的影響。
設定設定的位置。
以下是設定指令的簡短說明。
opcache.enable 布林值啟用操作碼快取。停用時，程式碼不會被最佳化或快取。設定 opcache.enable 無法透過 ini_set() 在執行階段啟用，只能停用。嘗試在腳本中啟用它會產生警告。
opcache.enable_cli 布林值為 PHP 的 CLI 版本啟用操作碼快取。
opcache.memory_consumption 整數OPcache 使用的共享記憶體儲存空間大小，單位為 MB。允許的最小值為 "8"，如果設定的值較小，則會強制使用此值。
opcache.interned_strings_buffer 整數用於儲存內部字串的記憶體量，單位為 MB。在 64 位元架構上，最大值為 32767，在 32 位元架構上，最大值為 4095。
注意： 在 PHP 8.4.0 之前，所有架構的最大值均為 4095 MB。
opcache.max_accelerated_files 整數OPcache 雜湊表中的最大鍵數（以及腳本數）。實際使用的值將是質數集合 { 223, 463, 983, 1979, 3907, 7963, 16229, 32531, 65407, 130987, 262237, 524521, 1048793 } 中大於或等於設定值的第一個數字。最小值為 200。最大值為 1000000。超出此範圍的值將被限制在允許的範圍內。
opcache.max_wasted_percentage 整數如果可用記憶體不足，允許在排程重新啟動之前浪費的記憶體最大百分比。最大允許值為 "50"，如果設定了更大的值，則會強制執行此限制。
opcache.use_cwd 布林值如果啟用，OPcache 會將目前工作目錄附加到腳本鍵值，從而消除具有相同基本名稱的文件之間可能發生的衝突。停用此指令可以提高效能，但可能會破壞現有的應用程式。
opcache.validate_timestamps 布林值如果啟用，OPcache 會每隔 opcache.revalidate_freq 秒檢查更新的腳本。當此指令被停用時，您必須透過 opcache_reset()、opcache_invalidate() 或重新啟動網路伺服器來手動重置 OPcache，才能使檔案系統的變更生效。
注意：如果 opcache.file_update_protection 或 opcache.max_file_size 選項設定為非零值，OPcache 仍然可能在編譯時驗證檔案的時間戳記。
opcache.revalidate_freq 整數檢查腳本時間戳記更新的頻率，以秒為單位。0 將導致 OPcache 在每次請求時檢查更新。
如果 opcache.validate_timestamps 被停用，則會忽略此設定指令。
opcache.revalidate_path 布林值如果停用，將會重複使用使用相同 include_path 的現有快取檔案。因此，如果在 include_path 中的其他位置存在同名檔案，則將找不到該檔案。
opcache.save_comments 布林值如果停用，所有註解將會從操作碼快取中捨棄，以減少最佳化程式碼的大小。停用此設定指令可能會破壞依賴註解解析來進行標註的應用程式和框架，包括 Doctrine、Zend Framework 2 和 PHPUnit。
opcache.fast_shutdown 布林值如果啟用，將使用快速關閉序列，該序列不會釋放每個已配置的區塊，而是依賴 Zend Engine 記憶體管理器來批量釋放整個請求變數集。
此指令已在 PHP 7.2.0 中移除。快速關閉序列的變體已整合到 PHP 中，並將在可能的情況下自動使用。
opcache.enable_file_override 布林值啟用後，在呼叫 file_exists()、is_file() 和 is_readable() 時，將會檢查操作碼快取中是否已快取檔案。這可能會提高檢查 PHP 腳本是否存在和可讀性的應用程式的效能，但如果 opcache.validate_timestamps 被停用，則可能會傳回過時的資料。
opcache.optimization_level 整數一個控制哪些最佳化流程執行的位元遮罩。預設值是應用所有安全的最佳化。更改預設值主要用於除錯/開發最佳化器（另請參閱 opcache.opt_debug_level）。
opcache.inherited_hack 布林值此設定指令會被忽略。
opcache.dups_fix 布林值這個修正程式應該只在需要解決「無法重複宣告類別」錯誤時啟用。
opcache.blacklist_filename 字串OPcache 黑名單檔案的位置。黑名單檔案是一個文字檔，其中包含不應被加速的檔案名稱，每行一個。允許使用萬用字元，也可以提供前綴。以分號開頭的行會被視為註釋而忽略。
一個簡單的黑名單檔案可能如下所示
; Matches a specific file. /var/www/broken.php ; A prefix that matches all files starting with x. /var/www/x ; A wildcard match. /var/www/*-broken.php
opcache.max_file_size 整數將被快取的最大檔案大小，以位元組為單位。如果值為 0，則所有檔案都會被快取。
opcache.consistency_checks 整數如果不為零，OPcache 將每 N 個請求驗證一次快取校驗和，其中 N 是此設定指令的值。這應該只在除錯時啟用，因為它會影響效能。
注意:
自 8.1.18 和 8.2.5 起停用。 已於 PHP 8.3.0 中移除。
opcache.force_restart_timeout 整數如果快取未啟用，則等待排定的重新啟動開始的時間長度，以秒為單位。如果達到逾時，則 OPcache 會假設出現問題，並會終止持有快取鎖定的處理序，以允許重新啟動。
如果 opcache.log_verbosity_level 設定為 2 或更高，則發生這種情況時，錯誤日誌中會記錄警告。
Windows 不支援此指令。
opcache.error_log 字串OPcache 錯誤的錯誤日誌。空字串與 stderr 的處理方式相同，將導致日誌被傳送到標準錯誤輸出（在大多數情況下，這將是 Web 伺服器錯誤日誌）。
opcache.log_verbosity_level 整數日誌詳細程度。預設情況下，僅記錄致命錯誤（級別 0）和錯誤（級別 1）。其他可用級別包括警告（級別 2）、資訊訊息（級別 3）和除錯訊息（級別 4）。
opcache.record_warnings 布林值如果啟用，OPcache 將記錄編譯時警告，並在下一次 include 時重播它們，即使它是從快取中提供的。
opcache.preferred_memory_model 字串OPcache 使用的首選記憶體模型。如果留空，OPcache 將選擇最合適的模型，這在幾乎所有情況下都是正確的行為。
可能的值包括 mmap、shm、posix 和 win32。
opcache.protect_memory 布林值在執行腳本時保護共享記憶體免受意外寫入。這僅適用於內部除錯。
opcache.mmap_base 字串在 Windows 上用於共享記憶體區段的基底位址。所有 PHP 處理程序都必須將共享記憶體映射到相同的位址空間。使用此指令可以修復「無法重新附加到基底位址」的錯誤。
opcache.restrict_api 字串僅允許路徑以指定字串開頭的 PHP 腳本呼叫 OPcache API 函數。預設值 "" 表示沒有限制。
opcache.file_update_protection 字串防止快取小於此秒數的新檔案。它可以防止快取未完全更新的檔案。如果所有檔案更新都是原子性的，則可以將此值設定為 0 來提高效能。這將允許立即快取檔案。
opcache.huge_code_pages 布林值啟用或停用將 PHP 程式碼（文字區段）複製到大型頁面。這應該可以提高效能，但需要適當的作業系統配置。從 PHP 7.0.0 開始在 Linux 上可用，從 PHP 7.4.0 開始在 FreeBSD 上可用。
opcache.lockfile_path 字串用於儲存共享鎖定檔案的絕對路徑（僅限 *nix 系統）
opcache.opt_debug_level 字串產生操作碼傾印，用於除錯不同階段的最佳化。0x10000 將在任何最佳化發生之前輸出編譯器產生的操作碼，而 0x20000 將輸出最佳化後的程式碼。
opcache.file_cache 字串啟用並設定第二級快取目錄。當 SHM 記憶體已滿、伺服器重新啟動或 SHM 重置時，它應該可以提高效能。預設值 "" 會停用基於檔案的快取。
opcache.file_cache_only 布林值啟用或停用共享記憶體中的操作碼快取。
注意:
在 PHP 8.1.0 之前，在檔案快取已填入的情況下停用此指令需要手動清除檔案快取。
opcache.file_cache_consistency_checks 布林值從檔案快取載入腳本時，啟用或停用校驗和驗證。
opcache.file_cache_fallback 布林值對於無法重新附加到共享記憶體的特定處理程序，隱含 opcache.file_cache_only=1（僅限 Windows）。需要明確啟用檔案快取。
停用此設定選項可能會阻止處理程序啟動，因此不建議這樣做。
opcache.validate_permission 布林值根據目前的使用者驗證快取的檔案權限。
opcache.validate_root 布林值防止在 chroot 環境中發生名稱衝突。在所有 chroot 環境中都應啟用此選項，以防止存取 chroot 之外的檔案。
opcache.preload 字串指定一個 PHP 腳本，將在伺服器啟動時編譯和執行，並且可以預先載入其他檔案，方法是使用 include 包含它們，或者使用 opcache_compile_file() 函式。在這些檔案中定義的所有實體（例如函式和類別）在伺服器關閉之前，都可以立即用於處理請求。
注意:
Windows 不支援預載入。
opcache.preload_user 字串允許以指定的系統使用者身分執行預載入。這對於在切換到非特權系統使用者之前以 root 身分啟動的伺服器很有用。基於安全考量，預設情況下不允許以 root 身分預載入，除非此指令明確設定為 root。
opcache.cache_id 字串在 Windows 上，所有在同一個使用者帳戶下執行相同 PHP SAPI（伺服器應用程式介面）且具有相同快取 ID 的處理程序，會共用一個 OPcache 實例。快取 ID 的值可以自由選擇。
對於 IIS，不同的應用程式集區可以透過使用環境變數 APP_POOL_ID 作為 opcache.cache_id 來擁有自己的 OPcache 實例。
opcache.jit 字串|整數對於一般用法，此選項接受四個字串值之一：
disable：完全停用，無法在執行階段啟用。off：停用，但可以在執行階段啟用。tracing/on：使用追蹤 JIT。預設為啟用，建議大多數使用者使用。function：使用函式 JIT。對於進階用法，此選項接受一個 4 位數的整數 CRTO，其中每個數字的意義如下：
C（CPU 特定最佳化旗標）0：停用 CPU 特定最佳化。1：如果 CPU 支援，則啟用 AVX 的使用。R（暫存器分配）0：不執行暫存器分配。1：執行區塊區域暫存器分配。2：執行全域暫存器分配。T（觸發器）0：載入腳本時編譯所有函式。1：首次執行時編譯函式。2：在第一個請求時分析函式，然後編譯最常用的函式。3：動態分析並編譯熱門函式。4：目前未使用。5：使用追蹤 JIT。動態分析並為熱門程式碼區段編譯追蹤。O（最佳化等級）0：無 JIT。1：最小 JIT（呼叫標準 VM 處理程式）。2：內嵌 VM 處理程式。3：使用型別推斷。4：使用呼叫圖。5：最佳化整個腳本。"tracing" 模式對應於 CRTO = 1254，"function" 模式對應於 CRTO = 1205。
opcache.jit_buffer_size 整數預留給已編譯 JIT 程式碼的共享記憶體數量。值為零將停用 JIT。
當使用 整數 時，數值以位元組為單位。也可以使用 此常見問題 中描述的速記符號。opcache.jit_debug 整數指定要啟用哪些 JIT 除錯輸出的位元遮罩。關於可能的值，請參考 » zend_jit.h（搜尋以 ZEND_JIT_DEBUG 開頭的巨集定義）。
opcache.jit_bisect_limit 整數在編譯一定數量的函式後停用 JIT 編譯的除錯選項。這可能有助於二分搜尋 JIT 編譯錯誤的來源。注意：此選項僅在 JIT 觸發器設定為 0（載入腳本時編譯）或 1（首次執行時編譯）時有效，例如 opcache.jit=1215。詳見 opcache.jit 選項。
opcache.jit_prof_threshold 浮點數使用「首次請求時分析」觸發模式時，此閾值決定函式是否被視為熱點。呼叫該函式的次數除以呼叫所有函式的次數必須高於閾值。例如，閾值 0.005 表示佔所有呼叫 0.5% 以上的函式將被 JIT 編譯。
opcache.jit_max_root_traces 整數最大根追蹤數。根追蹤是首先通過程式碼採用一條路徑的執行流程，它是 JIT 編譯的單元。如果達到此限制，JIT 將不會編譯新的程式碼。
opcache.jit_max_side_traces 整數根追蹤可能擁有的最大旁路追蹤數。旁路追蹤是不遵循已編譯根追蹤路徑的另一執行流程。如果達到此限制，屬於同一個根追蹤的旁路追蹤將不會被編譯。
opcache.jit_max_exit_counters 整數旁路追蹤退出計數器的最大數量。這限制了所有根追蹤可能擁有的旁路追蹤總數。
opcache.jit_hot_loop 整數迴圈經過多少次迭代後才被視為熱點。有效值範圍為 [0,255]；對於超出此範圍的任何設定，例如 -1 或 256，將改用預設值。0 將停用 JIT 追蹤和編譯任何迴圈。
opcache.jit_hot_func 整數函式被呼叫多少次後才被視為熱點。有效值範圍為 [0,255]；對於超出此範圍的任何設定，例如 -1 或 256，將改用預設值。0 將停用 JIT 追蹤和編譯任何函式。
opcache.jit_hot_return 整數一個 return 值被視為熱門的返回次數。有效值範圍為 [0,255]；任何超出此範圍的設定，例如 -1 或 256，將會使用預設值。 0 將會停用 JIT 追蹤及編譯任何 return 值。
opcache.jit_hot_side_exit int一個 side exit 被視為熱門的退出次數。有效值範圍為 [0,255]；任何超出此範圍的設定，例如 -1 或 256，將會使用預設值。 0 將會停用 JIT 追蹤及編譯任何 side exit。
opcache.jit_blacklist_root_trace int在將一個 root trace 加入黑名單之前，嘗試編譯它的最大次數。
opcache.jit_blacklist_side_trace int在將一個 side trace 加入黑名單之前，嘗試編譯它的最大次數。
opcache.jit_max_loop_unrolls int在 side trace 中展開迴圈的最大嘗試次數，嘗試到達 root trace 並關閉外層迴圈。
opcache.jit_max_recursive_calls int遞迴呼叫迴圈展開的最大次數。
opcache.jit_max_recursive_returns int遞迴返回迴圈展開的最大次數。
opcache.jit_max_polymorphic_calls int嘗試內嵌多型 (動態或方法) 呼叫的最大次數。超過此限制的呼叫將被視為超多型，並且不會被內嵌。
在 Windows 平台上使用 PHP 並啟用 opcache 時，您可能會遇到偶爾發生的 500 錯誤。這些錯誤似乎完全是隨機出現的。
當這種情況發生時，您的 Windows 事件記錄檔 (Windows 記錄/應用程式) 將會顯示來自 Zend OPcache 的 (可能有多個) 事件 ID 487 的項目。進一步的資訊將會說明以下錯誤訊息：「基底位址標記了無法使用的記憶體區域」。
可以透過在 php.ini 中新增以下內容來解決此問題
opcache.mmap_base = 0x20000000
很遺憾，我不知道值 "0x20000000" 的意義。我只能告訴您，這個值可以解決問題 (經過測試)。如果您嘗試使用 opcache.memory_consumption 配置比可用記憶體更多的記憶體，PHP 將會停止運作，並且没有任何記錄檔可以協助除錯。在建立與正式伺服器相同設定但可用記憶體較少的測試伺服器時，我花了 4 個小時才解決這個問題。php 7.3 的最佳化級別如下
#define ZEND_OPTIMIZER_PASS_1 (1<<0) /* CSE, 字串建構 */
#define ZEND_OPTIMIZER_PASS_2 (1<<1) /* 常數轉換和跳轉 */
#define ZEND_OPTIMIZER_PASS_3 (1<<2) /* ++, +=, 連續跳轉 */
#define ZEND_OPTIMIZER_PASS_4 (1<<3) /* INIT_FCALL_BY_NAME -> DO_FCALL */
#define ZEND_OPTIMIZER_PASS_5 (1<<4) /* 基於 CFG 的優化 */
#define ZEND_OPTIMIZER_PASS_6 (1<<5) /* 基於 DFA 的優化 */
#define ZEND_OPTIMIZER_PASS_7 (1<<6) /* 呼叫圖優化 */
#define ZEND_OPTIMIZER_PASS_8 (1<<7) /* SCCP (常數傳播) */
#define ZEND_OPTIMIZER_PASS_9 (1<<8) /* 暫時變數使用 */
#define ZEND_OPTIMIZER_PASS_10 (1<<9) /* NOP 移除 */
#define ZEND_OPTIMIZER_PASS_11 (1<<10) /* 合併相同的常數 */
#define ZEND_OPTIMIZER_PASS_12 (1<<11) /* 調整已使用的堆疊 */
#define ZEND_OPTIMIZER_PASS_13 (1<<12) /* 移除未使用的變數 */
#define ZEND_OPTIMIZER_PASS_14 (1<<13) /* DCE (無用程式碼刪除) */
#define ZEND_OPTIMIZER_PASS_15 (1<<14) /* (不安全) 收集常數 */
#define ZEND_OPTIMIZER_PASS_16 (1<<15) /* 內聯函數 */
來源：https://lxr.room11.org/xref/php-src%40master/ext/opcache/Optimizer/zend_optimizer.h需要注意的是，根據原始 RFC (https://wiki.php.net/rfc/preload)，`opcache.preload` 會針對底層 PHP 程序的所有執行個體*永久*快取預載的檔案。
這表示，在同一台伺服器上託管多個網站可能會導致一些非預期的行為。
具體範例
- 您有一個 Symfony 3.2 應用程式 (可能是某種類型的端點) 和一個 Symfony 3.4 應用程式 (可能是您的主要應用程式)
- 兩個應用程式都有一個名為 App 的主要類別，位於相同的命名空間中 (這很常見，因為類別名稱在每個專案中都是唯一的)
- 根據先載入哪個應用程式，其中一個會正常運作，因為 `opcache.preload` 沒有基於檔案區分在哪裡使用哪個類別，只是將它們提供給使用者空間。
只要不預載使用者空間類別，或者如果您使用 FPM，則可以透過為每個應用程式定義一個池來避免這種情況。
為了最佳化記憶體消耗，您也可以為所有 Symfony 3.4 應用程式使用一個共同的 FPM 池，並在其中預載整個框架，然後只需不預載使用者空間類別 (這些類別可能仍然會被 opcache 快取，但速度較慢，因為它會在每次請求時檢查檔案是否已更改)。看起來 [opcache.enable] 設定確實*不是* PHP_INI_ALL。
因為在全域層級停用的情況下，在 user.ini 中更改它是無效的。 該設定會忽略 user.ini。儘管 opcache.max_accelerated_files 的值集合包含 1048793，但所述的最大值為 1000000。 如果您選擇大於 1000000 的數字，則該值會設定為其預設值 10000。當 opcache.use_cwd=0 時，從不同目錄使用相對路徑的 include/require 都會解析為同一個 (第一個) 檔案。
範例目錄結構
app1
index.php
lib.php
app2
index.php
lib.php
兩個 index.php
include "lib.php";
app1/lib.php
echo "app1";
app2/lib.php
echo "app2";
兩者都會輸出 "app1"。