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_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运行模式:

1）CGI（通用网关接口/ Common Gateway Interface）

一般是可执行程序，例如EXE文件，和WEB服务器各自占据着不同的进程,而且一般一个CGI程序只能处理一个用户请求。这样，当用 户请求数量非常多时，会大量占用系统的资源，如内存、CPU时间等，造成效能低下。

1. 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）

1. 4.Web模块模式（Apache等Web服务器运行的模式)

该模式是apache在cgi基础上的一个扩展

1. 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模块处理