很多站长朋友们都不太清楚php脚本入口封装，今天小编就来给大家整理php脚本入口封装，希望对各位有所帮助，具体内容如下：
本文目录一览： 1、 国外主流PHP框架对比评测 2、 .如何在php脚本中引入装在其他模块代码,至少写出两种不同的方法并指出他们的差异 3、 PHP中的各种框架 4、 PHP命令执行PHP脚本，结束之前，内存会回收吗 国外主流PHP框架对比评测最近简单的使用了目前在国内用的比较多的几个主流国外PHP框架（不包括国内框架） 大致对这些框架有个直观上的感受 简单分享一下 对于哪些做框架选型的时候 权当一个参考
主要参考的框架包括 CodeIgniter CakePHP ZendFramework Symfony 我对很多框架也没有认真使用 只是简单试用了一下 可能很多看法不成熟或者是错误的 请大家指正 一起成长
CodeIgniter
优点
配置简单 全部的配置使用PHP脚本来配置 执行效率高 具有基本的路由功能 能够进行一定程度的路由 具有初步的Layout功能 能够制作一定程度的界面外观 数据库层封装的不错 具有基本的MVC功能
快速简洁 代码不多 执行性能高 框架简单 容易上手 学习成本低 文档详细 自带了很多简单好用的library 框架适合小型应用
缺点
把Model层简单的理解为数据库操作
框架略显简单 只能够满足小型应用 略微不太能够满足中型应用需要
评价
总体来说 拿CodeIgniter来完成简单快速的应用还是值得 同时能够构造一定程度的layout 便于模板的复用 数据操作层来说封装的不错 并且CodeIgniter没有使用很多太复杂的设计模式 执行性能和代码可读性上都不错 至于附加的 library 也还不错 简洁高效
CakePHP
优点
CakePHP是最类似于RoR的框架 包括设计方式 数据库操作的Active Record方式 设计层面很优雅 没有自带多余的 library 所有的功能都是纯粹的框架 执行效率还不错 数据库层的 hasOne hasMany 功能很强大 对于复杂业务处理比较合适 路由功能 配置功能还不错 自动构建脚手架（scaffold）很强大 适合中型应用 基本实现过了MVC每一层 具有自动操作命令行脚本功能
文档比较全 在国内推广的比较成功 大部分都知道CakePHP 学习成本中等
缺点
CakePHP非常严重的问题是把Model理解为数据库层操作 严重影响了除了数据库之外的操作能力
CakePHP的cache功能略显薄弱 配置功能稍嫌弱 CakePHP不适合大型应用 只适合中型应用 小型应用来说略微的学习成本高了点
评价
总体来说CakePHP框架代表了PHP框架很重要的一个时代和代表 并且目前发挥着很重要的作用 不少自己写的框架都模仿了CakePHP的方式 是个里程碑式的产品 CakePHP透露著RoR的敏捷开发方式和把数据库操作认为是唯一Model的设计思想 作为开发快速应用和原型是绝好的工具 同样 用来做Web 网站的开发框架 也是值得选择的
Zend Framework
优点
官方出品 自带了非常多的 library 框架本身使用了很多设计模式来编写 架构上很优雅 执行效率中等 MVC设计中 比较简洁 具有路由功能 配置文件比较强大（能够处理XML和php INI） 各种 library 很强大 是所有PHP框架中各种功能最全面的 包括它不仅是一个框架 更是一个大类库（取代PEAR） 这是它的主要特色 能够直观的支持除数据库操作之外的Model层（比 CodeIgniter 和 CakePHP 强） 并且能够很轻易的使用Loader功能加载其他新增加的Class Cache功能很强大 从前端Cache到后端Cache都支持 后端Cache支持Memcache APC SQLite 文件等等方式 数据库操作功能很强大 支持各种驱动（适配器）
文档很全 在国内社区很成熟 并且目前不少Web 网站在使用 学习成本中等
缺点
MVC功能完成比较弱 View层简单实现（跟没实现一样） 无法很强大的控制前端页面
没有自动化脚本 创建一个应用 包括入口文件 全部必须自己手工构建 入门成本高
Zend Framework 作为一个中型应用框架问题不大 也能够勉强作为大型应用的框架 但是作为一个很成熟的大型PHP框架来说 还需要一些努力
评价
作为官方出品的框架 Zend Framework的野心是可以预见的 想把其他框架挤走 同时封装很多强大的类库 能够提供一站式的框架服务 并且他们的开发团队很强大 完全足够有能力开发很强大的产品出来 所以基本可以确定的是Zend Framework前途无量 如果花费更多的时间去完善框架 同样的 Zend Framework架构本身也是比较优雅的 说明Zend官方是有很多高手的 设计理念上比较先进 虽然有一些功能实现的不够完善 比如View层 自动化脚本等等 这些都有赖于未来的升级 总体来说Zend Framework是最值得期待的框架 当然 你目前要投入你的项目中使用也是完全没问题的
Symfony
优点
Symfony 是我了解的PHP框架中功能最强大的 而且我使用时间比较长 但是很多功能还是没有挖掘出来 它完整实现了MVC三层 封装了所有东西 包括 $_POST $_GET 数据 异常处理 调试功能 数据检测 包含强大的缓存功能 自动加载Class（这个功能很爽） 强大的i n国家化支持 具有很强大的view层操作 能够零碎的包含单个多个文件 非常强大的配置功能 使用yml配置能够控制所有框架和程序运行行为 强大到让人无语 能够很随意的定义各种自己的class 并且symfony能够自动加载（auto load）这些class 能够在程序中随意调用 包含强大的多层级项目和应用管理 Project > Application > Module > Action 能够满足一个项目下多个应用的需要 并且每层可以定义自己的类库 配置文件 layout 非常强大的命令行操作功能 包括建立项目 建立应用 建立模块 刷新缓存等等
Symfony绝对是开发大型复杂项目的首选 因为使用了Symfony 将大大节约开发成本 并且多人协作的时候 不会出现问题 在Project级别定义好基础Class以后 任何模块都能够重用 大大复用代码
缺点
数据库操作model采用了重量级的propel和creole 不过在我测试的版本中已经把他们移到了addon里 可用可不用
缓存功能无法控制 每次开发调试总是缓存 需要执行 symfony cc symfony rc 来清除和重建缓存
效率不是很高 特别是解析模板和读取配置文件的过程 花费时间不少
学习成本很高 并且国内没有成熟的社区和文档 连中文手册都没有 相应的要掌握所有功能 需要花费比较多的时间
评价
Symfony绝对是企业级的框架 唯一能够貌似能够跟Java领域哪些强悍框架抗衡的东西 强悍的东西 自然学习复杂 但是相应的对项目开发也比较有帮助 自然是推荐复杂的项目使用Symfony来处理 觉得是值得 后期的维护成本比较低 复用性很强 相应的如果使用Symfony的应该都是比较复杂的互联网项目 那么相应的就要考虑关于数据库分布的问题 那么就需要抛弃Symfony自带的数据库操作层 需要自己定义 当然了 Symfony支持随意的构造model层
总结
以上数款框架 各有特色 而且都是开源项目 不过框架针对的项目不一样 一般来说 CodeIngiter 比较适合小型项目 CakePHP 和 Zend Framework 比较适合中型项目 Symfony 比较适合大型重量级项目 在项目选型的时候 要充分考虑框架的可以定制性 扩展性 因为每个项目都无法确定你是否会随着需求的变化进行改变
相对来说 Zend Framework 和 Symfony 应对变化的能力比较强 特别是能够随意定制 model 层的Class 能够非常方便增加自己业务或者数据处理类 我是个人比较推荐在中大型项目中使用的框架
CodeIngiter 和 CakePHP 在中小型项目中同样能够发挥重大作用 快速开发和原型构建 非常适合目标不清晰的原型项目的开发
当然了 也许 自己写一个框架更适合
lishixinzhi/Article/program/PHP/201311/21441
.如何在php脚本中引入装在其他模块代码,至少写出两种不同的方法并指出他们的差异1. require('xxx.php');
2. require_once('xxx.php');
3. include('xxx.php')
4. include_once('xxx.php');
require引用文件， 如果文件不存在会抛出一个fatal error，程序会终止运行， include引用文件， 如果不存在会抛出warning, 可以用@错误抑制符抑止。 如：@include('xx.php');
require_once和include_once和其他两个一样， 不同的是， 在引入的时候PHP会检查是否曾经引入过文件， 字面上理解为， 只引用一次。（不使用once多次引用同一文件会报错）
如果确定文件只被引用一次， 最好不使用once， 因为会影响效率。
PHP中的各种框架CodeIgniter、CakePHP、ZendFramework、Symfony这几个是国外的，你可以参考下
CodeIgniter
优点：
1. 配置简单，全部的配置使用PHP脚本来配置，执行效率高;具有基本的路由功能，能够进行一定程度的路由;具有初步的Layout功能，能够制作一定程度的界面外观;数据库层封装的不错，具有基本的MVC功能
2. 快速简洁，代码不多，执行性能高，框架简单，容易上手，学习成本低，文档详细;自带了很多简单好用的library，框架适合小型应用
缺点：
1. 把Model层简单的理解为数据库操作
2. 框架略显简单，只能够满足小型应用，略微不太能够满足中型应用需要
评价：
总体来说，拿CodeIgniter来完成简单快速的应用还是值得，同时能够构造一定程度的layout，便于模板的复用，数据操作层来说封装的不错，并且CodeIgniter没有使用很多太复杂的设计模式，执行性能和代码可读性上都不错。至于附加的 library 也还不错，简洁高效。
CakePHP
优点：
1. CakePHP是最类似于RoR的框架，包括设计方式，数据库操作的Active Record方式;设计层面很优雅，没有自带多余的 library，所有的功能都是纯粹的框架，执行效率还不错;数据库层的 hasOne, hasMany 功能很强大，对于复杂业务处理比较合适;路由功能，配置功能还不错;自动构建脚手架(scaffold)很强大;适合中型应用;基本实现过了MVC每一层;具有自动操作命令行脚本功能;
2. 文档比较全，在国内推广的比较成功，大部分都知道CakePHP，学习成本中等
缺点：
1. CakePHP非常严重的问题是把Model理解为数据库层操作，严重影响了除了数据库之外的操作能力
2. CakePHP的cache功能略显薄弱，配置功能稍嫌弱;CakePHP不适合大型应用，只适合中型应用，小型应用来说略微的学习成本高了点
评价：
总体来说CakePHP框架代表了PHP框架很重要的一个时代和代表，并且目前发挥着很重要的作用，不少自己写的框架都模仿了CakePHP的方式，是个里程碑式的产品;CakePHP透露着RoR的敏捷开发方式和把数据库操作认为是唯一Model的设计思想，作为开发快速应用和原型是绝好的工具;同样，用来做Web2.0网站的开发框架，也是值得选择的。
【 Zend Framework 】
优点：
1. 官方出品，自带了非常多的 library，框架本身使用了很多设计模式来编写，架构上很优雅，执行效率中等;MVC设计中，比较简洁，具有路由功能，配置文件比较强大(能够处理 XML和php INI)，各种 library 很强大，是所有PHP框架中各种功能最全面的，包括它不仅是一个框架，更是一个大类库(取代PEAR)，这是它的主要特色;能够直观的支持除数据库操作之外的Model层(比 CodeIgniter 和 CakePHP 强)，并且能够很轻易的使用Loader功能加载其他新增加的Class;Cache功能很强大，从前端Cache到后端Cache都支持，后端 Cache支持Memcache、APC、SQLite、文件等等方式;数据库操作功能很强大，支持各种驱动(适配器)
2. 文档很全，在国内社区很成熟，并且目前不少Web 2.0网站在使用，学习成本中等
缺点：
1. MVC功能完成比较弱，View层简单实现(跟没实现一样)，无法很强大的控制前端页面
2. 没有自动化脚本，创建一个应用，包括入口文件，全部必须自己手工构建，入门成本高
3. Zend Framework 作为一个中型应用框架问题不大，也能够勉强作为大型应用的框架，但是作为一个很成熟的大型PHP框架来说，还需要一些努力
评价：
作为官方出品的框架，Zend Framework的野心是可以预见的，想把其他框架挤走，同时封装很多强大的类库，能够提供一站式的框架服务，并且他们的开发团队很强大，完全足够有能力开发很强大的产品出来，所以基本可以确定的是Zend Framework前途无量，如果花费更多的时间去完善框架。同样的，Zend Framework架构本身也是比较优雅的，说明Zend官方是有很多高手的，设计理念上比较先进，虽然有一些功能实现的不够完善，比如View层，自动化脚本等等，这些都有赖于未来的升级。总体来说Zend Framework是最值得期待的框架，当然，你目前要投入你的项目中使用也是完全没问题的。
【 Symfony 】
优点：
1. Symfony 是我了解的PHP框架中功能最强大的，而且我使用时间比较长，但是很多功能还是没有挖掘出来;它完整实现了MVC三层，封装了所有东西，包括 $_POST，$_GET 数据，异常处理，调试功能，数据检测;包含强大的缓存功能，自动加载Class(这个功能很爽)，强大的i18n国家化支持;具有很强大的view层操作，能够零碎的包含单个多个文件;非常强大的配置功能，使用yml配置能够控制所有框架和程序运行行为，强大到让人无语;能够很随意的定义各种自己的 class，并且symfony能够自动加载(auto load)这些class，能够在程序中随意调用;包含强大的多层级项目和应用管理：Project --> Application --> Module --> Action，能够满足一个项目下多个应用的需要，并且每层可以定义自己的类库，配置文件，layout;非常强大的命令行操作功能，包括建立项目、建立应用、建立模块、刷新缓存等等;
2. Symfony绝对是开发大型复杂项目的首选，因为使用了Symfony，将大大节约开发成本，并且多人协作的时候，不会出现问题，在Project级别定义好基础Class以后，任何模块都能够重用，大大复用代码
缺点：
1. 数据库操作model采用了重量级的propel和creole，不过在我测试的版本中已经把他们移到了addon里，可用可不用
2. 缓存功能无法控制，每次开发调试总是缓存，需要执行 symfony cc, symfony rc 来清除和重建缓存;
3. 效率不是很高，特别是解析模板和读取配置文件的过程，花费时间不少;
4. 学习成本很高，并且国内没有成熟的社区和文档，连中文手册都没有，相应的要掌握所有功能，需要花费比较多的时间
评价：
Symfony绝对是企业级的框架，唯一能够貌似能够跟Java领域哪些强悍框架抗衡的东西;强悍的东西，自然学习复杂，但是相应的对项目开发也比较有帮助，自然是推荐复杂的项目使用Symfony来处理，觉得是值得，后期的维护成本比较低，复用性很强。相应的如果使用Symfony的应该都是比较复杂的互联网项目，那么相应的就要考虑关于数据库分布的问题，那么就需要抛弃Symfony自带的数据库操作层，需要自己定义，当然了，Symfony支持随意的构造model层。
【 总评 】
以上数款框架，各有特色，而且都是开源项目，不过框架针对的项目不一样，一般来说 CodeIngiter 比较适合小型项目，CakePHP 和 Zend Framework 比较适合中型项目，Symfony 比较适合大型重量级项目，在项目选型的时候，要充分考虑框架的可以定制性、扩展性，因为每个项目都无法确定你是否会随着需求的变化进行改变。
相对来说，Zend Framework 和 Symfony 应对变化的能力比较强，特别是能够随意定制 model 层的Class，能够非常方便增加自己业务或者数据处理类，我是个人比较推荐在中大型项目中使用的框架。CodeIngiter 和 CakePHP 在中小型项目中同样能够发挥重大作用，快速开发和原型构建，非常适合目标不清晰的原型项目的开发。了解一个框架最好的方式就是使用它，学习它最好的方式就是看视频。
仁者见仁，智者见智，在项目挑选框架的时候，请先认真考察项目的需求和未来的变化，然后选择合适的框架，让项目开发速度和后期维护性得到一个合理的平衡，当然了，也许，自己写一个框架更适合。
PHP命令执行PHP脚本，结束之前，内存会回收吗再详细说下问题：
unix下，用php命令来执行php脚本，在php结束之前，内存有没有机会被回收？新的GC算法有没有机会被调用？
出现这个问题，是因为线上有个 离线数据导入脚本，需要把几千万行数据筛选入库，发现，在执行过程中，到达一定程度，就会抛出 内存使用超过最大值。
1 Fatal error: Allowed memory size of 293601280 bytes exhausted
那第一想到的就是程序是不是有什么bug，造成内存超出，看了半天没有发现问题，于是，突然出现了这个疑问。 那要解决这个疑问，最好的办法就去翻源码吧。
在之前我这么说：
都知道，PHP5.3有了新的垃圾回收机制：GC，它不是重点，不谈它的原理。
经过翻阅PHP源码，发现，调用这个的时机是在 main/main.c ::php_request_shutdown这个函数中，
12 /* 7. Shutdown scanner/executor/compiler and restore ini entries */ zend_deactivate(TSRMLS_C);
php_request_shutdown，通过名字就能看出，它是在php请求结束的时候执行的，在这里会执行 gc_collect_cycles 来清理内存。
其实这句话是没错，但它只针对于SAPI接口（之前我就错在这个地方。），在用PHP命令执行php脚本的时候，是不会执行这个php_request_shutdown的。
那回到最初的问题，过程中到底有没有执行GC呢？
为了更直观有效的知道答案，我选择了最BT，最暴力的方法，拦截gc_collect_cycles，输出error_log到文件，只要执行了，
那肯定会输出log来。
重新编译PHP后，果不其然，符合官方的说法，只要buckets满超过默认值1000，就会启动GC来清理没用的内存，防止内存泄露。
那问 “什么时间 触发的GC呢？”，答 “buckets超过1000的时候啊”，这不屁话嘛，要的是真真正正的执行流程，so。。不断的debug,
不断的grep，不断的step，不断的C+T，终于搞清楚了。下面就来根据官方的说法详细谈谈，PHP到底是怎么触发的。
有一点要注意，PHP的命令入口 和 sapi接口的入口 是不同的，我就载在这个地方，以为都公用一个。
测试代码以官方文档为例：
1234567891011121314 <?phpclass Foo{ public $var = '3.1415962654';} for ( $i = 0; $i <= 1000000; $i++ ){ $a = new Foo; $a->self = $a;} echo memory_get_peak_usage(), "\n";?>
这样的代码，在PHP5.3之前，肯定会造成大量的 内存泄露，不过，谁在开发时又能开发出这么变态的代码来？除非这个人很变态。^.*
那PHP的命令入口是什么？流程又是什么？
主要函数流程如下：
入口main函数（sapi/cli/php_cli.c） ==》php_execute_script(main/main.c)==>zend_execute_scripts(Zend/zend.c)==>execute(Zend/zend_vm_execute.h)
调用GC的地方在execute里。
简单描述下这个过程，
main 是入口，它的作用是根据我们传递的参数做不同的设置，最后会把我们的php脚本作为一个zend_file_handle指针传递给
php_execute_script函数，zend_file_handle其实就是把FILE*做了一下封装，保存了一些其他的文件信息。
php_execute_script会做一些文件检查工作，把php脚本加到 哈希表included_files中。
php_execute_scripts 会执行 zend_compile_file函数来解释我们写的PHP代码，最后执行execute。
应该都知道 Zend把脚本解析完会生成op代码保存到 哈希表：active_op_array中，execute会逐个执行每个op，
op基本上都对应一个ZEND_ASSIGN_*_HANDLER这样的一个宏，它就保存在active_op_array->opline->handlers中。
在进入到 execute之后：
首先初始化execute_data，它保存了很多重要信息，上下文信息，然后调用 ZEND_VM_SET_OPCODE宏，
把execute_data->opline的指针指向active_op_array->opline->handlers。
之后，execute会执行一个while循环，逐条执行opline：
123456789101112131415161718192021222324 while (1) { int ret;#ifdef ZEND_WIN32 if (EG(timed_out)) { zend_timeout(0); }#endif if ((ret = EX(opline)->handler(execute_data TSRMLS_CC)) > 0) { switch (ret) { case 1: EG(in_execution) = original_in_execution; return; case 2: op_array = EG(active_op_array); goto zend_vm_enter; case 3: execute_data = EG(current_execute_data); default: break; } } }
每个handlers都会执行一个宏：ZEND_VM_NEXT_OPCODE()，它意思就是跳到下一个Opline，这样就能逐条执行了。
最后跟踪 上面的PHP代码会执行 ZEND_ASSIGN_SPEC_CV_VAR_HANDLER这个宏，它是干嘛的？他就是 变量赋值
下面代码执行的操作：
1234 class A{ }$a=new A();
这里就会执行 这个宏。
在这个宏里有段代码：
12345678910111213141516171819202122232425262728293031 static int ZEND_FASTCALL ZEND_ASSIGN_SPEC_CV_VAR_HANDLER(ZEND_OPCODE_HANDLER_ARGS){ zend_op *opline = EX(opline); zend_free_op free_op2; zval *value = _get_zval_ptr_var(opline->op2, EX(Ts), free_op2 TSRMLS_CC); zval **variable_ptr_ptr = _get_zval_ptr_ptr_cv(opline->op1, EX(Ts), BP_VAR_W TSRMLS_CC); if (IS_CV == IS_VAR !variable_ptr_ptr) { if (zend_assign_to_string_offset(EX_T(opline->op1.u.var), value, IS_VAR TSRMLS_CC)) { if (!RETURN_VALUE_UNUSED(opline->result)) { EX_T(opline->result.u.var).var.ptr_ptr = EX_T(opline->result.u.var).var.ptr; ALLOC_ZVAL(EX_T(opline->result.u.var).var.ptr); INIT_PZVAL(EX_T(opline->result.u.var).var.ptr); ZVAL_STRINGL(EX_T(opline->result.u.var).var.ptr, Z_STRVAL_P(EX_T(opline->op1.u.var).str_offset.str)+EX_T(opline->op1.u.var).str_offset.offset, 1, 1); } } else if (!RETURN_VALUE_UNUSED(opline->result)) { AI_SET_PTR(EX_T(opline->result.u.var).var, EG(uninitialized_zval_ptr)); PZVAL_LOCK(EG(uninitialized_zval_ptr)); } } else { value = zend_assign_to_variable(variable_ptr_ptr, value, 0 TSRMLS_CC); if (!RETURN_VALUE_UNUSED(opline->result)) { AI_SET_PTR(EX_T(opline->result.u.var).var, value); PZVAL_LOCK(value); } } /* zend_assign_to_variable() always takes care of op2, never free it! */ if (free_op2.var) {zval_ptr_dtor(free_op2.var);}; ZEND_VM_NEXT_OPCODE();}
free_op2.var保存的是 new A的对象.
free_op2.var这个是哪儿来的呢?
在整个execute期间,维持一个 execute_data结构,里面有个 Ts指针
1 union _temp_variable *Ts;
它用来保存一些临时的变量信息,比如 new A(),这个会保存到Ts链表里,
opline->op2.u.var这个里面保存了此临时变量所在的位置,然后Ts+这个值是一个zval*指针,它就保存了new A产生的对象.
在代码中
1 if (free_op2.var) {zval_ptr_dtor(free_op2.var);};
zval_ptr_dtor会根据free_op2.var的值执行到 Zend/zend_execute_API.c::_zval_ptr_dtor函数中,
1234567891011121314151617181920212223242526 ZEND_API void _zval_ptr_dtor(zval **zval_ptr ZEND_FILE_LINE_DC) /* {{{ */{ zval *zv = *zval_ptr; #if DEBUG_ZEND>=2 printf("Reducing refcount for %x (%x): %d->%d\n", *zval_ptr, zval_ptr, Z_REFCOUNT_PP(zval_ptr), Z_REFCOUNT_PP(zval_ptr) - 1);#endif Z_DELREF_P(zv); if (Z_REFCOUNT_P(zv) == 0) { TSRMLS_FETCH(); if (zv != EG(uninitialized_zval)) { GC_REMOVE_ZVAL_FROM_BUFFER(zv); zval_dtor(zv); efree_rel(zv); } } else { TSRMLS_FETCH(); if (Z_REFCOUNT_P(zv) == 1) { Z_UNSET_ISREF_P(zv); } GC_ZVAL_CHECK_POSSIBLE_ROOT(zv); }}
GC_ZVAL_CHECK_POSSIBLE_ROOT(zv);
它就是最终GC算法执行的地方.
gc_collect_cycles就在这个宏中执行了..
所以..
回到上面的问题,
php无论在SAPI接口或命令端,都会执行 GC算法来进行垃圾内存回收.
关于php脚本入口封装的介绍到此就结束了，不知道本篇文章是否对您有帮助呢？如果你还想了解更多此类信息，记得收藏关注本站，我们会不定期更新哦。
查看更多关于php脚本入口封装 php数据库操作类封装的详细内容...