PHP 腳本執行超時設置全解析：set_time_limit、max_execution_time 與最佳實踐

PHP 腳本執行超時設置全解析：set_time_limit、max_execution_time 與最佳實踐

PHP 腳本執行超時是開發中常見問題：導入大數據、生成報表、視頻轉碼、爬蟲任務等長時間運行場景，若不正確配置超時，會導致進程被強制終止、數據不一致、用戶體驗差。本文系統梳理 PHP 超時機制、配置層級、動態調整與生產環境最佳實踐。

一、PHP 超時機制原理

• 計時範圍：僅計算 PHP 解釋器執行 CPU 時間，不包含：資料庫查詢等待、網路請求等待、sleep()、流操作阻塞、系統調用等待
• 觸發動作：超時拋出 E_ERROR（致命錯誤），腳本立即終止，無法被 try-catch 捕獲
• 測量模式：Linux 使用 SIGPROF 信號，Windows 使用多媒體計時器

二、三層配置優先級

三、核心函數詳解

<?php
// 1. set_time_limit(秒數)
// 特性：每次調用都會「重置」計時器
// 0 = 無限制（慎用！僅 CLI 或受控任務）
set_time_limit(300); // 當前腳本允許 300 秒 CPU 時間

// 2. ini_set('max_execution_time', 秒數)
// 效果等同 set_time_limit，但不重置計時器（僅修改限制值）
ini_set('max_execution_time', '300');

// 3. CLI 模式下默認無限制（max_execution_time = 0）
// Web 模式下默認 30 秒

// 4. 獲取當前設置
echo ini_get('max_execution_time'); // 返回字符串
echo get_cfg_var('max_execution_time'); // 返回 php.ini 原始值

四、常見誤區與避坑指南

五、長任務的架構級解決方案

1. 異步隊列（推薦）：
   Web 請求 → 寫入 Redis/RabbitMQ/數據庫隊列 → 即時返回 → Worker 進程消費（CLI 模式無超時限制）
2. 分批處理 + 斷點續傳：
   大循環改為分頁處理，每批執行 < 10 秒，記錄游標，前端輪詢或 WebSocket 推送進度
3. 流式輸出：
   ob_implicit_flush() + set_time_limit(0)（僅 CLI），邊執行邊輸出進度，避免瀏覽器/代理超時
4. 外部進程調用：
   exec('php long_task.php > /dev/null 2>&1 &') 後台運行，主進程即時返回

六、生產環境配置建議

; php.ini 基礎配置
max_execution_time = 30          ; Web 默認 30 秒
max_input_time = 60              ; 輸入解析時間
memory_limit = 256M              ; 內存限制

; Nginx + PHP-FPM (www.conf)
request_terminate_timeout = 35s  ; FPM 進程硬性終止，略大於 PHP 設置
; Nginx 配置
fastcgi_read_timeout 35s;        ; Nginx 等待 FastCGI 響應

; 專項長任務入口（如 /admin/import）
; 僅在該控制器動作中動態調整
set_time_limit(300);
ini_set('memory_limit', '512M');

七、監控與告警

• 記錄慢請求：slowlog (FPM) + request_slowlog_timeout = 10s
• 監控指標：max_execution_time 觸發次數、FPM 進程數、CPU 使用率
• 業務級超時：在代碼關鍵節點記錄微秒時間，超過業務閾值主動拋出異常、記錄日誌、發送告警

總結：Web 環境堅持 30-60 秒基礎超時，長任務走異步隊列（CLI 無限制）。動態調整 set_time_limit 僅作為過渡方案，架構層面應將耗時操作從請求-響應循環中剝離，這才是高併發、高可用 PHP 系統的正確姿勢。