這篇文章給大家分享的內容是淺析php錯誤處理，自動加載，棧堆內存以及運行模式，有著一定的參考價值，有需要的朋友可以參考一下
Php錯誤處理
##Php錯誤等級:
E_ERROR 致命錯誤,會終止腳本執行.值為1
E_WARNING 警告錯誤,給予提示,不會終止執行值為2
E_PARSE 編譯時的語法解析錯誤,解析錯誤僅由分析器產生。值為4
E_NOTICE 執行階段通知錯誤,表示腳本可能會遇到錯誤的情況值為8
E_CORE_ERROR 在PHP初始化啟動過程中發生的致命錯誤。這個錯誤類似 E_ERROR，但是是由PHP引擎核心產生的。值為16
E_CORE_WARNING PHP初始化啟動過程中發生的警告 (非致命錯誤) 。類似 E_WARNING，但是是PHP引擎核心產生的。值為32
E_COMPILE_ERROR 致命編譯時錯誤。類似E_ERROR, 但是是由Zend腳本引擎產生的。值為64
E_COMPILE_WARNING 編譯時警告 (非致命錯誤)。類似 E_WARNING，但是是由Zend腳本引擎產生的。值為128
E_USER_ERROR 使用者產生的錯誤訊息。類似 E_ERROR, 但是是由使用者自己在程式碼中使用PHP函數 trigger_error()來產生的。值為256
E_USER_WARNING 使用者產生的警告訊息。類似 E_WARNING, 但是是由使用者自己在程式碼中使用PHP函數 trigger_error()來產生的。值為512
E_USER_NOTICE 使用者產生的通知訊息。類似 E_NOTICE, 但是是由使用者自己在程式碼中使用PHP函數 trigger_error()來產生的。值為1024
E_STRICT 啟用 PHP 對程式碼的修改建議，以確保程式碼具有最佳的互通性和向前相容性。值為2048
E_RECOVERABLE_ERROR可被捕捉的致命錯誤。它表示發生了一個可能非常危險的錯誤，但還沒有導致PHP引擎處於不穩定的狀態。如果該錯誤沒有被使用者自訂句柄捕獲 (參見 set_error_handler())，將成為一個 E_ERROR 從而腳本會終止運行。值為4096
E_DEPRECATED 執行階段通知。啟用後將會對在未來版本中可能無法正常運作的程式碼給予警告。值為8192
E_USER_DEPRECATED用戶產少的警告訊息。類似 E_DEPRECATED, 但是是由使用者自己在程式碼中使用PHP函數 trigger_error()來產生的。值為16384
E_ALL 表示E_STRICT除外的所有錯誤和警告訊息。值為30719
使用位元運算子組合顯示或屏蔽的錯誤(二進位權限判斷)
Php有關於錯誤的配置
error_reporting 設定錯誤報告的等級,等級設定可看上面
其預設值為E_ALL & ~E_NOTICE,表示顯示除了E_NOTICE以及E_STRICT的所有錯誤
# E_STRICT錯誤等級不包含在E_ALL裡,必須自己明確啟用該等級才能出現
#在php以外使用錯誤等級常數是沒有意義的,可以用十進制數字代替,比如2147483647 包含了所有的錯誤
display_errors 是否將錯誤輸出到屏幕上
#雖然可以使用ini_set重新設定,但是當php發生致命錯誤時,是無法設定的
display_startup_errors #是否顯示啟動時的錯誤
log_errors 是否將腳本的錯誤訊息記錄到log
log_errors_max_len #
設定 log_errors 的最大位元組數. 在 error_log 會加入有關錯誤來源的資訊。預設值為1024，如果設定為0表示不限長度。此長度設定對記錄的錯誤，顯示的錯誤，以及 $php_errormsg都會有限製作用。
ignore_repeated_errors
#不記錄重複的錯誤訊息,
ignore_repeated_source
忽略重複訊息時，也忽略訊息的來源。當該設定開啟時，重複訊息將不會記錄它是由不同的檔案還是不同的原始程式碼行產生的。
report_memleaks
#如果這個參數設定為Off，則記憶體外洩資訊不會顯示(在stdout 或日誌中)。 This report will be send to stderr on Posix platforms. On Windows, it will be send to the debugger using OutputDebugString(), and can be viewed with tools like » DbgView。這只對調試編譯有效，而且需要error_reporting 包含了E_WARNING 才會起作用
track_errors
如果開啟，最後的一個錯誤將永遠存在於變數$php_errormsg 中。
html_errors
#在錯誤訊息中關閉HTML標籤。這種新的HTML格式的錯誤訊息是可以點擊，它引導使用者前往描述該錯誤或導致該錯誤發生的函數的參考資訊頁面。這些參考與 docref_root 和 docref_ext 的設定有關。
error_prepend_string string
#錯誤訊息之前輸出的內容。
error_append_string string
#錯誤訊息之後輸出的內容。
error_log
#設定腳本錯誤會被記錄到的檔案。該文件必須是web伺服器用戶可寫的。如果特殊值 syslog 被設置，則將錯誤訊息傳送到系統日誌記錄器。在Unix以及類似系統上，使用的是 syslog(3) ，而在 Windows NT 類別系統上則為事件日誌。 Windows 95上不支援系統日誌記錄。請參閱： syslog(). 如果該配置沒有設置，則錯誤訊息會被傳送到 SAPI 錯誤記錄器。例如，出現在Apache的錯誤日誌中，或在CLI中傳送到 stderr。
錯誤處理相關方法以及用法個人理解
debug_backtrace — 產生一條回溯追蹤(backtrace) 可設定參數限制回傳的堆疊數量,
可以查出呼叫該函數的堆疊資訊,對查錯很有幫助,和tp的debug類似
debug_print_backtrace();直接印回溯,和debug_backtrace類似,
##error_clear_last — 清除最近一次錯誤
error_clear_last — 清除最近一次錯誤
error_get_last — 取得最後發生的錯誤
#error_log — 發送錯誤訊息到某個地方,可將錯誤存進一個檔案,但是錯誤訊息不能有null
error_reporting — 設定應該報告何種PHP 錯誤,和php.ini 一樣
restore_error_handler — 還原之前的錯誤處理函數,
restore_exception_handler — 復原先前定義過的例外處理函數。
set_error_handler — 設定使用者自訂的錯誤處理函數,需要在錯誤之前就定義
以下層級的錯誤不能由使用者定義的函數來處理： E_ERROR、 E_PARSE、 E_CORE_ERROR、 E_CORE_WARNING、 E_COMPILE_ERROR、 E_COMPILE_WARNING，和在呼叫set_error_handler() 函數所在檔案中產生的大多數E_STRICT。
就像error_reporting 的 ini 設定能夠控制錯誤的顯示一樣， 第2個參數能夠用來屏蔽 error_handler 的觸發。如果沒有該掩碼， 無論 error_reporting 是如何設定的， error_handler 都會在每個錯誤發生時被呼叫。
set_exception_handler — 設定使用者自訂的例外處理函數
trigger_error — 產生一個使用者層級的error/warning/notice 資訊
###user_error — trigger_error 的別名#######register_shutdown_function 在php終止腳本之後執行的註冊函數,第一個參數支援函數,以及一個包含實例化類別的語句,類別方法的陣列(註冊時會先實例化該類別);(只要註冊成功,啥錯誤都可以捕獲)
Php自動載入
個人見解
#spl_autoload_register 和__autoload主要區別在於
__autoload只是個函數只能在php中定義一次,如果要載入外掛程式等,需要不斷的if else判斷,或是composer,將會很麻煩
spl_autoload_register 可以根據資料夾,或外掛程式,自訂各種處理函數,創造一個自動載入的佇列,會根據佇列一直找下去;直到佇列完畢或回傳true(找到檔案預設回傳true)
#堆疊記憶體(個人理解)
堆疊:存放使用者定義變數的
堆疊:在函數中定義的一些基本類型變數,物件的參考變數,都在堆疊空間,超出該作用域時將會自動釋放
資料補充:
#:
當檔案中定義的變數被static修飾之後,將改變到全域資料區,不佔用堆疊記憶體
##堆疊:
棧記憶體一般儲存的是函數的呼叫資訊和函數中申明的變量，因為函數的呼叫是遞歸的，外層函數一定比內層被調用的函數先載入執行，而一定等到內層被呼叫函數結束後才能結束，這個先進後出的機制就是為什麼叫棧記憶體的原因。
PS：在編譯時編譯器會先收集此函數中所有定義的變量，將他們放在函數最前面申請內存，所以他們進出棧的順序不是你在寫程式時定義的順序，而是在函數執行前進棧，函數執行完成後才出棧。
其他:
#Const,global,static修飾之後都會存放在全域數據區
超全域變數,全域變數,都屬於靜態變數,存放在全域資料區
資料較少,等待修正以及完善
Phpweb#運行模式
##Php
運行模式
:
一般是可執行程序，例如EXE文件，和WEB伺服器各自佔據著不同的進程,而且一般一個CGI程序只能處理一個用戶請求。這樣，當用 戶請求數量非常多時，會大量佔用系統的資源，如記憶體、CPU時間等，造成效能低。
2.FastCGI（常駐型CGI / Long-Live CGI）
########################################### FastCGI是CGI的升級版本，FastCGI像是常駐(long-live)型的CGI，它可以一直執行著，只要啟動後，不會每次都要花時間去Fork 一次（這是CGI 最為人詬病的fork-and-execute 模式）。 ############FastCGI是一個可伸縮地、高速地在HTTP server和動態腳本語言間溝通的介面。多數流行的HTTP server都支援FastCGI，包括Apache、Nginx和lighttpd等，同時，FastCGI也被許多腳本語言所支持，其中就有PHP。 ############FastCGI介面方式採用C/S結構，可以將HTTP伺服器和腳本解析伺服器分開，同時在腳本解析伺服器上啟動一個或多個腳本解析守護程式。當HTTP伺服器每次遇到動態程式時，可以直接交付給FastCGI進程來執行，然後將得到的結果傳回瀏覽器。這種方式可以讓HTTP伺服器專一地處理靜態請求或將動態腳本伺服器的結果傳回給客戶端，這在很大程度上提高了整個應用系統的效能。 ############Php-fpm 是php中自帶的fastcgi管理器######
3）CLI（命令行运行 / Command Line Interface）
4.Web模块模式（Apache等Web服务器运行的模式)
该模式是apache在cgi基础上的一个扩展
5.ISAPI（Internet Server Application Program Interface)是微软提供的一套面向WEB服务的API接口，它能实现CGI提供的全部功能，并在此基础上进行了扩展，如提供了过滤器应用程序接 口。ISAPI应用大多数以DLL动态库的形式使用，可以在被用户请求后执行，在处理完一个用户请求后不会马上消失，而是继续驻留在内存中等待处理别的 用户输入。此外，ISAPI的DLL应用程序和WEB服务器处于同一个进程中，效率要显著高于CGI。
Php2种与web服务器交互:
Nginx:
用户发起请求,以nginx现行握手,当nginx接收到之后,推送给php-fpm进行处理,当php-fpm繁忙时,nginx将返回504 getway
Apache:
Apache有3种运行模式,prefork,worker,Event,
根据不同的模式而创建不同的处理进程以及线程,接收到有关php时则交给apache模块处理
以上是淺析php錯誤處理，自動加載，棧堆記憶體以及運行模式的詳細內容。更多資訊請關注PHP中文網其他相關文章！
