php项目实践

暑假来啦

你以为暑假就是

空调WIFI西瓜

世界杯煲剧沙发

当然不是

那只是普通青年的玩法

对于有为青年

一定是有自己的暑假目标

正值毕业季

求职季

于大学生而言

为自己的职场“镀金”是当务之急

毕竟如果没有一技之长

很难突破重围，拿下满意的offer

雅腾教育助力大学生高薪就业

特开设PHP软件开发暑期实战班

采用小班现场面授

技术总监手把手辅导

注重学员理论与企业项目实战能力培养

提升企业项目开发经验

（2018php暑假班实战班开班现场照片）

本期暑假班学员来自江西各大高校

有东华理工大学

南昌工程学院

江西科技学院

江西制造学院

北京交通大学

......

专业有

软件工程

电子商务

机电一体化

模具

工商管理

......

有14级应届毕业生

有15级在校大三学生

更有16级在校大二学生

最终目的都一样

让自己拥有职业技能

提升职场竞争力

最终实现高薪就业

衷心祝愿

雅腾教育php暑期实战班圆满成功

学有所获

满载而归

梦想成真

在2010年的时候，企业经历了一个全民建站的过程，每家公司都要有自己的网站。

也是从那个时候开始，互联网公司受到越来越多求职者的青睐，高大上的办公环境，让人不知所云的扁平化管理，一个又一个的上市造富奇迹等等，即使伴随着高强度的加班，也阻止不了年轻人燃烧青春的热情。

移动互联网时代像浪潮一样，席卷而来，也有越来越多的公司互联网化，吸引着更多的人加入。

当我们想进入一个行业时，最起码的了解还是应该有的，毕竟很多事物是看起来很美。

比如当年的出租司机，大家都认为只要驾驶技术过硬，这是一份时间自由，收入也不低的职业；可是要熟悉全北京的路线，没事就看地图，要学会与不同的乘客交流，面临不规律的作息等，是职业背后很多人所没看到的。

这次，我们从一个App的从无到有经历了哪些过程，来了解一下互联网及其相关行业公司的工作模式。

01 创意产生与决策

对于创意的产生，在一家企业里是每个人都可以的，但是让创意被重视，并变成一个可执行的产品，是需要有决策者的。

一个公司如何产生创意以及决策，影响因素一般有两个，公司规模和公司的业务模式。

公司规模越大，中层权限越大，动用的资源越多，就需要更严谨的审批，这个比较好理解。

通常会让求职者产生落差感的，是业务模式。

对于创意，大多数人的第一反应是由产品部门汇总整理或直接输出。所以产品经理的工作内容是创意与创造，但事实并不是这样。

比如几年前大火的货架、社区拼团、甚至是二手车等，又或者是一些ToB业务的公司，这些公司由于是重业务模式或客户驱动模式，产品的创意来通常自于市场部门，由市场来决定解决用户需求的步骤，以及自身发展的节奏。

所以，如果你希望加入一个公司，实现微信张小龙那样改变几亿人社交方式的创意，要考虑好这两个物理因素。

02 产品与产品经理

无论是市场需求，还是产品主导，有了创意或业务方向，将由产品经理负责事情的推动。

首先，对于产品，定义绝不仅限于一个App或一个小程序，也可以是无形的策略等，如“借呗”这种借款平台，增加一种新的还款方式等，就不会有很多用户能看得见的变化。

所以本质是能作为企业与用户完成价值交换的媒介的，都是产品。

从工作内容来说，原型设计只是产品工作的一小部分，需求，生产，销售，协调等方面，都在产品经理的职责范围内。

03 如何启动

既然是一个App的产生过程，还是从这个实际情况来出发。

在创意或业务方向确定后，产品会召开产品需求会。

一般由产品经理、需求提出人、研发技术负责人、测试技术负责人等参加。

角色说明：1、需求提出人：如果有，一般是对需求做出补充解释，避免歧义。2、产品经理：给出大概的产品形态，比如是新开发一个app，还是在现有的app里增加一些功能。3、研发技术负责人（包含前后端）：评估可行性，以及当前的人力物力是否有足够资源。4、测试技术负责人：要直接理解产品的需求，以自己的理解进行测试用例编写以及做好测试计划，产品最终质量负责，还有资源评估。

可能也会有一些中高层参加，评估时间范围或者其他资源的安排。

如果采取比较高效的做事方式，产品经理在产品需求会上就会给出详细的产品说明，比如简称PRD的产品说明书。

也有些是产品经理就详细的说明，再单独跟技术开会，讨论细节，评估可行性。

04 技术生产

技术评估会主要是研发的相关负责人，给出具体技术方案与开发周期，确定与测试的对接时间等。通常需要技术的中高层或架构师参与进行评估可行性与规范性。开发工作，从这个会后，就开始啦。

（1）技术——后端

很多吃瓜群众认为所有的程序人都会修电脑，也认为所有的开发都会写app，显然现实不是这样的。

拿一个电商App来说，无论在App中，电脑浏览器还是小程序等，都有用户注册，用户登录，商品浏览，下单等功能。

用户注册的技术任务是把一条新的用户信息写到数据库中，用户登录是检查这条信息在数据库中是否存在。

App也好，网页也好，都是与用户交互的方式，对于列举的这两个功能，是不会受到这种交互的方式影响的。

所以，后端写的程序，是完成一个有逻辑的业务场景。常见的编程语言有java，go，php等，一般还要集合一些著名的框架，如spring。在使用这些编程语言的同时，也有很多数据库操作的工作。

还要注意的是，后端的程序，一个业务逻辑场景，只开发一次就够了，因为注册功能在不同场景都是一样的，不同的前端应用都可以使用，这也就是大家常说的“前后端分离”。

由此可见，后端程序员用代码创造的东西，只是提供了完成业务逻辑的服务，并不需要去做App或者写网页。

（2）技术——前端

有了后端的支持，前端可以更专注于这个“前”字了，给用户提供一个实体，比如App或页面、小程序等，让用户可以切实感受到企业提供的服务，同时为用户提供更好的交互体验，更快的页面加载速度等，是通常定义的前端工作的范畴。

前端有技术栈三剑客，是html，css，javaScript（跟java语言没有直接关系呦），这基本是前端同学必备的技术了。同时，由于企业的项目都会往越来越复杂的方向发展，vue等知名框架，也成了前端同学的必要学习内容之一。

（3）技术——测试

有些公司，测试团队也叫做QA（质量保障）团队。如果一个研发告诉测试某个内容是“1”，测试去看一下，是不是“1”，那这件事就没有意义了。

在这样一个前提下，测试团队会形成自己对产品需求的理解，来确定什么是符合质量要求的。

测试工作通常又分功能测试、自动化测试、黑盒测试、白盒测试等。阶段上也分，单元测试、系统测试、回归测试等。（请大家耐心等待我们的详细拆解文）

只有测试通过的技术项目，才可以进行到上线准备以及最终的上线环节，这中间的过程，由产品经理来协调。

（4）技术——运维

大家都知道，我们写的程序都运行在服务器上，那么服务器的日常维护，软硬件的管理，以及权限的管理等，都是运维的工作内容。

运维会负责程序发布到服务器这个环节，一般的企业都有严格的流程，比如用git作为代码仓库和版本管理，jenkins作为发布工具等。

05 运营

运营的职位，也细分了很多类，对于一个App，我们可以讨论两个大类。

（1）产品运营

运营的工作内容，跟产品的内容是紧密相关的。比如电商、支付类等，这些业务，用户不用互联网服务，也不影响自己的正常生活。那么如何让用户使用自己的产品，并安装App就是产品运营要做的工作了。

可能要对接广告服务商，投放广告；设计、发放优惠券；举办各种活动等。让尽可能多的用户了解自己的服务，并经常使用。

（2）用户运营

用户运营更关注的是用户的生命周期，比如拉新、留存、转化到付费、复购、流失前挽留、沉睡唤醒、挽回等。

拿内容类App来做对比，可以很好的区分产品运营和用户运营，比如知乎。

很多用户装了知乎，每天都打开看一下，但里面空空如也，那这个产品马上就会死掉了。

用户运营会设计策略，如积分、等级、回报等，诱导用户多发自己擅长的内容，多解答问题，以此来提高整体用户体验也用户生命周期的质量。

虽然研究的是用户，但是也很好的保证了产品的价值。

运营毕竟也是一个从业人数众多的职位，请大家耐心等待我们的运营职位详细拆解文。

至此，一个App从创意，到被推向用户，让用户熟悉，就介绍完了。

我以下面三个例子为例，来说下PHP代码优化。

1、使用require与使用require_once 的对比。

2、提前计算一个for循环的长度。

3、比较for、foreach和while 循环在访问数组元素时的性能。

在这里，具体的理论东西我不会太多说。我将从实际代码的角度让大家比较直观的了解下那个是最佳的代码实践。能够认识到代码的不同写法确实能给我们的整体性能带来提升。

PHP性能调优之PHP代码最佳实践

除此之外，还有一些其他的优化技术，比如file_get_contents获取内容的问题。使用逗号而不是句点来链接字符串，或者在字符串包含变量时使用双引好而不是单引号等等。这些大家可以自己在工作中测试和验证一下。

1、require 与 require_once。

说明，我的测试文件路径存放在了 : /var/shared/htdocs/myapp/models/MyModels/ 目录下。

加载四个外部类文件的基本代码：

require_once 代码片段

A类到D类分别是：

A到D类的代码片段

以上4个空类均可以帮助我们模拟一个需要在主脚本中使用外表PHP文件的PHP脚本。我们排除任何额外的函数调用。专注与使用 require_once（）文件的加载。

将每一个类放在单独的文件中： classA.php、classB.php、ClassC.php、classD.php

将这些文件与代码放在同一个目录下。重启WEB服务器，使用ab测试工具进行测试。

ab命令模拟10万个请求，同一时间有5个并发请求，命令终止后，应该可以看到类似如下的结果。

ab -c 5 -n 100000 localhost /index.php

require_once ab 测试结果截图

使用此ab命令测试require_once（）。我们可以看到，相应时间为99毫秒。我们的结果还说明，该脚本每秒可以支持100.63个请求。

现在，让我们将require_once（）函数调用改成required（）。重启WEB服务器，然后重新运行 ab 命令。结果如下所示：

require 代码片段

每秒可支持的请求数量有所提升，从 100.63增加到了105.44.这个结果还说明，代码的相应时间从最初的99.37毫秒降低到了94.84毫秒，减少了5毫秒。

require ab 测试结果截图

2、提前计算 for 循环的长度：

在进入循环之前计算循环长度是理工一个可以使用的优化技术。

如下图所示的代码是一个简单的for 循环。它将便利数组$items 并分10此计算出数值。要确定那些地方可以进行优化，你需要一步一步的分析嗲吗做了什么。

没有提前计算数组长度模拟代码片段

如上，代码循环10次，则count($items )计算10次。

如上代码，从10此计算数组长度降低到一次计算数组长度。我们可以使用函数 microtime() 来准确的计算出减少9次count()函数调用可以节省多少时间。如下所示：

计算没有提前计算数组长度时候执行时间片段

执行十次该代码并计算平均值，我们得出，10万次循环的总执行时间为0.046毫秒，重启服务器，然我们测试下如下代码，其中包含优化了的for 循环

提前计算过数组长度执行时间代码片段

我们再次运行10此代码并获取平均值。使用此代码，我们看到，for 循环的平均执行时间为0.0095,减少了0.036毫秒。优化过的代码快了0.036毫秒。

3、使用 foreach 、for 、while 循环访问数组元素。

访问数组数据的方法是可以优化的。方法是使用foreach 循环替代 while 或 for 循环。优化数据访问的方法至关重要。因为很多的web 应用程序需要从数据库或者XML 文件中读取数据并且必须遍历每一条记录后才能将数据显示给用户。为了演示这种优化，我们将使用如下的代码：

foreach 循环代码片段

如上创建了一个数组$items ，其中包含10万个元素，每个元素还有155个字节的字符串，代表数据库中的典型数据。在后该代码设置了开始时间并使用foreach 循环访问数组的每一个元素，最后，我们以毫秒为单位显示所示是时间。我么连续执行10次代码，然后计算出每次执行时间的平均数值，其结果是0.0078毫秒。

while 循环代码片段

重启服务器且运行该代码10此后，我们再次计算平均执行时间。用while 循环访问数组中的单个元素的平均时间为0.0099 毫秒。

最后一组循环比较的是for 循环。我们使用如下代码，按照同样的基准循环流程，重启服务器，执行代码10次并计算：

for 循环执行时间代码片段

上述三种循环基准的结果列于如下表中。表宗结果可以证明，使用foreach 循环访问数组是最好的方法。

三种循环执行时间比较

从上面的几个例子，我们可以感受到代码优化的重要性。

ThinkPHP框架常用的是MVC模式，M是模型、V是视图，C是控制器。通过MVC模式将数据从数据库中查询出来，然后传递到页面中。下面我们来说一下具体的情况；

程序

一、视图渲染

模板定位规则：当前模块/view/当前控制器名（小写）/当前操作（小写）.html。在5.1.6版本后系统会以简洁模式定位模板文件位置，规则如下：当前模块/view/当前控制器（小写）_当前操作（小写）.html

1、Fetch方法

fetch方式是渲染模板时最常用的方法，在使用此方法的前提是控制器类需要继承系统控制器基础类。使用方式如下：

（1）、不需要传递任何参数，框架会自动定位到模板文件；

return $this->fetch();

（2）、传递一个参数，框架会定位至当前控制器下的参数一模板文件；

return $this->fetch('edit');

（3）、传递两个参数，框架会定位至参数一控制器下的参数二模板文件；

return $this->fetch('member/read');

注意事项：在书写参数时请不要书写任何后缀，参数只是目录名称或文件名称而已。

（4）、视图根目录下文件

如果想把view文件夹内的单独文件进行渲染，可以在参数位置进行如下书写：

return $this->fetch('/menu');

（5）、特殊模板文件或特殊位置文件

如果项目中存在特殊模板文件，又不想移动位置，可以通过如下方式进行调用：

return $this->fetch('./template/menu.html');

上面书写的目录位置是相对于当前项目入口文件位置（public目录），模板文件后缀无固定要求，可以为html、php、tpl等格式

PHP代码

2、助手函数方式

如果控制器未继承系统基础控制器类，同样可以实现视图模板的输出，框架提供了助手函数view()，可以使用如下命令：

return view();

可传递参数及数据，常见的使用方式如下：

return view('模板文件路径','数据');

3、直接解析模板方式

项目中某些页面可能通过直接解析模板的方式就可以实现功能，那么我们可以通过最简单的方式对模板文件进行输出。使用如下命令：

return $this->display();

此方式会直接渲染内容，同样模板标签在视图中可以正常使用。

HTML模板

二、视图赋值

1、assign方法

在继承系统基础控制器类后可以通过如下命令进行视图赋值：

$this->assign("名","值");

批量赋值方式：

$this->assign(['名'=>'值','名'=>'值']);

2、方法传入参数方式

此方式在进行视图渲染中提及到了，通过设置模板文件位置时携带数据。命令如下：

$this->fetch('path',['名'=>'值','名'=>'值']);$this->display('path',['名'=>'值','名'=>'值']);

3、助手函数赋值方式

这种方式是项目开发过程中最常见的模式，助手函数无需继承基础控制类，相对而言代码更加精简、可读性更高。命令如下：

return view('path',['名'=>'值','名'=>'值']);

4、公共模板变量赋值方式

可以使用视图类的share静态方法进行全局公共模板变量赋值。命令如下：

use think\facade\View;// 赋值全局模板变量View::share('name','value');// 或者批量赋值View::share(['name1'=>'value','name2'=>'value2']);

视频过滤

三、视图过滤

1、局部过滤

在单独方法内进行视图过滤操作。命令如下：

// 使用视图输出过滤return $this->filter(function($content){returnstr_replace("\r\n",'<br/>',$content);})->fetch();

2、全局过滤

如果进行全局过滤方式，需要在初始化方法中进行设置。命令如下：

protected functioninitialize(){$this->view->filter(function($content){returnstr_replace("\r\n",'<br/>',$content); });}

总结：视图过滤方式可以理解过对视图模板中内容进行了替换操作，可以通过此方式减少代码空行，无用的缩进。减少代码体积。

四、模板引擎

框架中内置了模板引擎，默认可以忽略对此进行设置，同时框架支持自定义引擎模式。在配置目录（config目录）下的template.php文件中可进行配置。

默认提供了两种扩展引擎：think-angular、twig（都不是很完美，不建议使用

4、）

五、扩展

如果只想获得解析文件而不进行渲染，如果生成静态HTML文件，采用纯静态化模式。可以使用如下命令：

$html = $this->fetch()->getContent();

此方式返回字符串，可以继承文件创建方式，批量生成HTML静态文件，便于网站优化。

六、总结

1、依据场景，选择不同的渲染方式；

2、合理的进行模板赋值；

3、牢记特殊模板文件位置是基础项目入口文件位置；

4、模板文件配置目录为：config/template.php文件；

前言

工欲善其事，必先利其器。当你使用PHP编程，就需要对它的运行状况有所了解，否则事倍功半。

从今天起，和大家聊一聊 phpinfo() 函数所展示的信息含义。

phpinfo() 有什么用

它是一个系统函数，你可以直接编写代码 <?php phpinfo();?>，然后通过网页访问它，就能看到一个类似于这样的网页。

该网页包含了当前PHP的各种配置信息、扩展模块的信息等。以前有一种软件叫“探针”，专门用来探测服务器当前的PHP相关信息，现在随着虚拟主机的没落，已经越来越少人用啦。

如何阅读 phpinfo 的信息？

整个网页内容非常多，但主要分为四个部分

基本信息，也就是最顶部的内容。配置信息（Configuration）各种模块的信息PHP Credits，荣誉名单，记录对PHP语言有帮助的人PHP License 版权许可说明

基本配置

本文和大家说说基本信息中，各项内容的含义。（以我当前使用的PHP版本为例）

PHP 版本

最顶端：PHP Version 7.2.3，就是我们当前PHP的版本。

System

Darwin mac.local 17.5.0 Darwin Kernel Version 17.5.0: Fri Apr 13 19:32:32 PDT 2018; root:xnu-4570.51.2~1/RELEASE_X86_64 x86_64

运行此PHP的操作系统信息（我是mac机）

Build Date

Mar 19 2018 11:50:19

编译时间

Configure Command

'./configure' '--prefix=/usr/local/opt/php723' '--exec-prefix=/usr/local/opt/php723/' '--enable-debug' '--enable-fpm' '--with-iconv=/usr/' '--with-config-file-path=/usr/local/etc/php723' '--with-openssl=/usr/local/opt/openssl' '--enable-bcmath' '--with-curl' '--enable-exif' '--with-gd' '--with-mysqli' '--with-pdo-mysql' '--enable-zip' '--with-libzip' '--enable-mysqlnd' '--enable-sockets' '--enable-mbstring' '--enable-soap' '--with-freetype-dir=/usr/local/opt/freetype' '--with-xmlrpc' '--with-jpeg-dir=/usr/local/opt/jpeg' '--with-png-dir=/usr/local/opt/libpng' '--with-libxml-dir=/usr/local/opt/libxml2' '--without-gmp'

编译时，使用的各项配置信息。

Server API

FPM/FastCGI

当前采用的服务模式为 FCGI（快速通用网关接口协议），实现该协议的服务为 FPM（也就是PHP-FPM），与 NGINX 搭配的时候，基本都是通过它来进行通讯的，以后有机会和大家细聊。

Virtual Directory Support

disabled

虚拟目录支持，目前是禁用状态（disabled）也就是不支持。

Configuration File (php.ini) Path

/usr/local/etc/php723

PHP.ini 的所在目录。

Loaded Configuration File

/usr/local/etc/php723/php.ini

php.ini 所在的完整文件路径。

Scan this dir for additional .ini files

(none)

Additional .ini files parsed

(none)

PHP API

20170718

PHP核心版本，一般大版本变更时，此日期会随之变化（应该是核心版本的发布或编译日期）

其他

剩下的就不一一说明了，需要额外提醒的是，此处出现的 zend 是PHP解释器名字，你也可以认为它就是PHP核心，除此之外还有 zend框架、zend代码混淆、zend代码编辑器，注意不要把自己弄混了。

总结

今天先和大家介绍下基本信息，其中像PHP版本、configure的编译配置、php.ini的路径、php api 的版本等几项，是我们日常开发中需要用到的。其余的，大家有兴趣可以自己行了解。

明天开始，介绍第二部分：各种扩展库。

在开发过程中，我们需要写控制器、模型、验证代码。最后要写模板代码，如果是前后端分离项目则不用写模板了。直接在接口中返回数据就可以了。模板代码包含了很多知识，下面举例介绍一下；

代码

变量输出

1、常见的输出方式是使用大括号（{ }）的形式，里面写入变量名称。在runtime/temp目录下可以看到编译后的文件，括号解析成了<?php ?>的形式，并且里面包含htmlentities。命令如下（注意$ 和 { 之间不能存在空格）：

{$data}

2、原样解析，如果解析富文本内容时使用，使用示例：

{$data|raw}

3、默认值，使用示例：

{$data|default='这是一个默认值'}

4、系统变量输出，主要是获取用户昵称，使用示例：

{$Think.session.name}

5、常量输出，使用示例：

{$Think.PHP_VERSION}

6、配置输出，主要是获取基础网址，使用示例：

{$Think.config.default_module}

PHP

使用函数

1、框架内置规则：

2、应用方式：

2.1、单函数应用，使用示例：

{$data.name|md5}

2.2、多函数应用，使用示例：

{$name|md5|upper|substr=0,3}

互联网开发

运算符

1、常见运算符

2、三元运算符

2.1、默认写法

{$status?'正常':'错误'}

2.2、简单写法，表示有则输出，无则输出默认值

{$name ??'默认值'}

2.3、为真写法，表示为真的时候才输出默认值

{$name?='默认值'}

2.3、真假写法、表示为真输出值，否则输出默认值

{$name ?:'NO'}

2.4、表达式写法，表达式为真则输出值一，否则输出值二

{$a==$b ?'yes':'no'}

程序代码

原样输出

原样输出使用较少，如果想让输出内容不被模板标签所解析，使用如下命令进行输出：

{literal} Hello,{$name}！{/literal}

模板注释

模板注释和代码注释是两种方式，模板注释不会在页面上查看到被注释的代码，而代码注释则可以查看的到。使用方式如下：

{/* 这是模板注释内容*/} 或 {// 这是模板注释内容 }

模板布局

模板布局总结来说就两点：配置和模板；

配置分为模块配置和应用配置，一般情况下后台多应用模板布局方式，在后台模块config/template.php文件内（默认不存在，需手动创建）设置如下代码：

'layout_on'=>true, //开启布局模式'layout_name'=>'layout', //布局文件名称，可设置为 'index/layout'目录形式'layout_item'=>'{__REPLACE__}' //输出替换变量

模板继承

在实际项目开发过程中使用较少，主要是因为继承过于麻烦。

包含文件

在实际项目开发过程中，前端页面使用较多，使用方式较为单一；

1、使用模版文件，多个文件使用逗号分隔；

{include file="public/header,public/menu"/}

2、传入参数，此方式需注意模板中变量值必须存在；

{include file="Public/header" keywords="开源WEB开发框架"/}

开发代码

输出替换

1、配置，在应用或模块配置目录下的template.php文件中进行如下代码配置：

'tpl_replace_string'=>['__STATIC__'=>'/static','__JS__'=>'/static/javascript',]

2、总结，优点：方便更改；但是不建议使用，建议在开发过程中设置好目录位置。

标签库

标签库类似于Java的Struts中的JSP标签库，每一个标签库是一个独立的标签库文件，标签库中的每一个标签完成某个功能，采用XML标签方式（包括开放标签和闭合标签）。具体内容请参考官方文档。

内置标签

1、普通循环标签，使用示例：

{volist name="list" id="vo" key="k"}{$k}.{$vo.name}{/volist}

如果没有指定key属性的话，默认使用循环变量i

2、控制输出行数，如输出其中的第5～15条记录，使用示例：

{volist name="list" id="vo" offset="5" length='10'}{$vo.name}{/volist}

3、比较标签（不常用）

4、SWITCH标签（不常用），使用示例：

{switch User.level} {case 1}value1{/case} {case 2}value2{/case} {default /}default {/switch}

5、资源文件加载（常用），使用实例：

{load href="/static/js/common.js,/static/css/style.css"/}

互联网

标签扩展

此扩展在开发过程中并不常用，使用起来较为麻烦。

随着互联网的不断普及，行业网站建设已经成为国内企业提高核心竞争力的主要措施，基于PHP语言开发的动态 网站因拥有数据处理快、优质的信息管理、快捷的执行速度、系统安全度高以及完整性控制等方面的优势而逐渐被广泛应用。文 章从PHP语言的简要介绍入手，以PHP语言进行网站开发模型设计，通过对行业网站的设计目标和开发工具进行分析，以期为 行业网站建设实践提供理论依据。

PHP语言的概述

根据动态网站要求，PHP语言作为一种语言程序，其 专用性逐渐在应用过程中显现，其技术水平的优劣与否将 直接影响网站的运行效率。其特点是具有公开的源代码， 在程序设计上与通用型语言，如C语言相似性较高，因此 在操作过程中简单易懂，可操作性强。同时，PHP语言具 有较高的数据传送处理水平和输出水平，可以广泛应用在 Windows系统及各类Web服务器中。如果数据量较大， PHP语言还可以拓宽链接面，与各种数据库相连，缓解数 据存储、检索及维护压力。随着技术的发展，PHP语言搜搜索引擎还可以量体裁衣，实行个性化服务，如根据客户的喜 好进行分类收集储存，极大提高了数据运行效率。

PHP语言的优势分析与同类型语言相比，PHP语言优势明显：

PHP语言是一种供客户免费使用的语言，即使客户不 同，也无须额外付费，这成为其应用的第一大优势。

PHP语言的编程设计与C语言有较高的相似性，易于 开发人员操作。

PHP语言的受众面积较大，在行业网站建设过程中， 从小型网站到大型网站均可使用。

PHP语言在补丁漏洞升级过程中，核心部分植入简单 易行，且速度快。

PHP语言在数据库应用过程中，可以从数据库调取各 类数据，执行效率高。

应用PHP语言进行网站建设时的注意事项

PHP语言应用过程中，要求开发人员熟悉该语言，特 别是软件版本、特性等诸多环节，否则容易造成冲突，使配置问题难以处理。因此，在网站开发设计过程中，应避免单 独进行环境搭配。

结论

从上述实践性分析可以看出，与其他常用语言相比， PHP语言优势明显。较好的可移植性、可靠性以及较高的 运行效率使PHP语言在当下行业网站建设中独占鳌头。利 用PHP语言进行行业网站设计，能够实现数据库的实时性 更新，网站的日常维护和管理简单易行，进而提高用户的使 用效率。原创文字：来源海洋网络 http://www.hy755.cn/ 版权所有，转载注明出处，并保留本链接

今天介绍一下网站里面常见的用户登录功能的实现

用户登录

我们先想一想实现思路，先帮常用的代码放在一个include文件，里面放一些链接数据库，常用函数等公用文件。然后常用的用户信息修改。我们看看需要哪些页面

代码文件

公用的头部文件和公用的底部文件单独放在一个页面，方便后期维护。然后就是登陆，注册，逻辑处理。

代码是最基础的实现原理。在原理掌握的基础长就可以进行深化，封装成class文件，简化代码和文件，我们先从最基础的实现原理来看看怎么实现。

登陆的界面

首先是基本的登陆页面。不含css，后期可以把页面美化一下。

然后看看数据提交到了loginCheck.php页面进行哪些逻辑处理

php逻辑代码处理

我们分析代码 显示引用配置文件，我们看看配置文件，也就是最基本的数据库信息，定义一个数组

数据库配置

然后在看看mysql.fun.php通过文件名称我们可以知道这是一个操作数据库的代码，我们把一些常用的数据库操作方在这个里面。然后在去调用。

数据库链接操作

注意@的用途，感兴趣的朋友去删除这个看看效果。

接着分析代码就是接受用户名和密码，执行查找数据库操作，存在这个记录就跳转到main.php页面，不存在就跳转到login.php页面。这样也就类似实现一个后台登陆管理功能的实现。登陆成功进入后台，登陆失败禁止登陆。原理是不是很简单。有兴趣的朋友快去制作一个登陆功能吧。

登陆后台模板

小编收集了一下后台界面模板和登陆界面模板，想加强这方面的也去试试吧。

网站后台管理界面

这样就实现了一个最基本的后台管理功能。

小程序入局者越来越多，微信小程序第一个开发，相当于确立了非官方标准，之后的支付宝小程序俨然改了一个名字版的微信小程序存在，再到之后的百度智能小程序，开发框架及标准都是一样的。

一张图集齐bat小程序

三家小程序除了三个文件，app.json,app.js,app.wxss,index.wxml叫法不同外，其他近乎一样

app.json 对应的是配置文件

app.js 三家一样的，都是javascript文件，前后端同学应该都懂

app.wxss 这个叫法不一样，但是都是css的超集[支持css的绝大部分语法，基本可以理解就是css]

index.wxml 这个就是对应就是网页三剑客的html了，只是有一些稍微的区别而已。

对于入门phper来讲，最简单也最高效的开发框架非tp（thinkphp）莫属了，为啥呢？有中文文档，国人开发，清晰的文档及国人高效论坛的支持。进化到thinkphp 5版本的tp以api接口为定义，更加符合现在小程序的开发逻辑， 也更贴合现在前端环境的MVVM架构。

在开发小程序环境下，对于传统的mvc架构，砍掉了v，只剩下mc。小程序端相当于v。

thinkphp5开发将主要着重于mc方面的开发

在接下来的课程中，我们将基于thinkphp5+wepy的方式讲解价值百万小程序商城的开发。

欢迎关注我门的百家号，持续更新小程序商城开发系列

尽管大多数 PHP 开发人员都知道如何使用 Composer，但并不是所有的人都在有效地或以最好的方式使用它。 所以我决定总结一些对我日常工作流程很重要的东西。

大部分技巧的理念是「 Play it safe 」，这意味着如果有更多的方法来处理某些事情，我会使用最不容易出错的方法。

Tip #1: 阅读文档

我是认真的。 官方的文档 写得非常棒，现在只需几个小时的阅读，会给你未来节省很多时间。你会惊讶于 Composer 如此之多能。

Tip #2: 认识 "项目" 和 "库" 间的不同

创建的是“项目”还是“库”，意识到这点非常重要。这两者在使用过程中，都存在非常巨大的差异。

库是一个可重用的包，需要作为一个依赖项进行添加 - 比如 symfony/symfony, doctrine/orm 或 elasticsearch/elasticsearch.

而典型的项目是一个应用程序，要依赖于多个库。它通常不可重用（其他项目不需要它成为一个依赖项）。像电子商务网站、客户服务系统等类型的应用就是典型的例子。

在下面的 Tip 中，我会更仔细地讲解库和项目两者的区别。

Tip #3: 为应用程序使用指定的依赖版本

创建应用程序时，应使用最清晰的版本号定义依赖项。 如果需要解析 YAML 文件，就应该以 "symfony/yaml": "4.0.2" 这样的形式明确依赖项。

即使依赖的库遵循了 语义化版本 规范，也会因次版本号和修订号的不同破坏后向兼容性。 例如，使用形如 "symfony/symfony": "^3.1"，有可能存在在 3.2 版本废弃的东西，而这会破坏你的应用程序在该版本下通过测试。或者可能在 PHP_CodeSniffer 中存在一个已修复的 bug ，代码就会检测出新的格式问题，这会再次导致错误的构建。

依赖的升级要慎之又慎，不能撞大运。下面 Tip 当中会有一条对此进行更详细的讲解。

听起来有些危言耸听，但是注意这个要点就会避免你的合作伙伴向项目中在添加新库时不小心更新了所有依赖（代码审查时可能忽略这一点）。

Tip #4: 对库依赖项使用版本范围

创建库时，应尽可能定义最大的可用版本范围。比如创建了一个库，要使用 symfony/yaml 库进行 YAML 解析，就应这样写：

"symfony/yaml":"^3.0 || ^4.0"

这表示该库能从 Symfony 3.x 或 4.x 中任意版本中使用 symfony/yaml 。这相当重要，因为这个版本约束会传递给使用该库的应用程序。

万一有两个库的请求存在冲突，比如一个要 ~3.1.0 ，另一个需要 ~3.2.0 ，则安装会失败。

Tip #5: 开发应用程序要提交 composer.lock 文件到 git 版本库中

创建了 一个项目，一定要把 composer.lock 文件提交到 git 中。 这会确保每一个人——你、你的合作伙伴、你的 CI 服务器以及你的产品服务器——所运行的应用程序拥有相同依赖的版本。

乍一看有些画蛇添足，在 Tip #3 中已经提过要使用明确的版本号的约束了啊。这并不多余，要知道你使用的依赖项的依赖项并不受这些约束绑定（如 symfony/console 还依赖 symfony/polyfill-mbstring）。如果不提交 composer.lock 文件，就不会获取到相同版本的依赖集合。

Tip #6: 开发库要把 composer.lock 文件添加到 .gitignore 文件中

创建 一个库 （比如说叫 acme/my-library）， 这就不应该把 composer.lock 文件提交到 git 库中了。该文件对使用该库的项目 It 不会有任何影响 。

假设 acme/my-library 使用 monolog/monolog 作依赖项。你已经在版本库中提交了 composer.lock，开发 acme/my-library 的每个人都可能在使用 Monolog 的老旧版本。该库开发完成后，在实际项目中使用该库，就可能存在安装的 Monolog 是一个新版本 ， 而此时就会和该库存在不兼容。可是你在之前根本就不会注意到兼容问题就因为这个 composer.lock！

因此，最佳处理方式就是把 composer.lock 添加到 .gitignore 文件中，这样就避免了不小心提交它到版本库中引发的问题。

如果还想确保该库与它的依赖项的不同版本保持兼容性，那继续阅读下一个 Tip ！

Tip #7: Travis CI 构建依赖项的不同版本

当前 Tip 仅适合库（对于应用程序要指明具体的版本号）。

如果你在构建开源的库，很有可能你会使用 Travis CI 来跑构建过程。

默认情况下，在 composer.json 文件约束允许的条件下，composer 安装会安装依赖的最新可能版本。这就意味着对于 ^3.0 || ^4.0 这样的依赖约束，构建安装总是使用最新的 v4 版本发行包。 而 3.0 版本根本不会测试，所构建的库就可能与该版本不兼容，你的用户要哭了。

幸好，composer 为安装低版本依赖项提供了一个开关 --prefer-lowest （应使用 --prefer-stable ，可阻止不稳定版本的安装）。

已上传的 .travis.yml 配置类似下面的格式：

代码详见 my mhujer/fio-api-php library 及 the build matrix on Travis CI

虽然这解决了多数的不兼容问题，不过仍然要记得，依赖项的最低和最高版本间有太多的组合。他们仍旧可能存在不兼容的情况。

Tip #8: 按名称对 require 和 require-dev 中的包排序

按名称对 require 及 require-dev 中的包排序是非常好的实践。这在衍合一个分支时可以避免不必要的合并冲突。假如你把一个包添加到两个分支文件中的列表末尾，那每次合并都可能遇到冲突。

手动进行包排序的话会很乏味，所以最好办法就是在 composer.json 中 配置一下 即可：

以后再要 require 一个新的包，它会自动添加到一个正确位置（不会跑到尾部）。

Tip #9: 进行版本衍合或合并时不要合并 composer.lock

如果你在 composer.json （和 composer.lock）中添加了一个新依赖项，并且在该分支被合并前主分支中添加另一个依赖项，此时就需要对你的分支进行衍合处理。那么 composer.lock 文件就会得到一个合并冲突。

千万别试图手动解决冲突，这是因为 composer.lock 文件包含了定义 composer.json 中依赖项的哈希值。所以即使你解决了冲突，这个最终合并结果的lock文件仍是错误的。

最佳方案应该这样做，用下面一行代码在项目根目录创建一个 .gitattributes 文件，它会告诉 git 不要试图对 composer.lock 文件进行合并操作：

/composer.lock -merge

推荐 Trunk Based Development 方式（常用佳品，不会有错），使用临时的特性分支纠正这种问题。当你有个临时分支需要即时合并时，因此导致的 composer.lock 文件合并冲突的风险极小。你甚至可以仅仅为添加一个依赖项而创建分支，然后马上进行合并。

假如在衍合过程中 composer.lock 遇到合并冲突又当如何呢？ 使用主分支版本解决，这样仅仅修改 composer.json 文件即可（新增一个包）。然后运行 composer update --lock ，就会把composer.json 文件的修改更新到 composer.lock 文件中。现在把已经更新的 composer.lock 文件提交到版本暂存区，然后继续衍合操作。

Tip #10:了解 require 和 require-dev之间的区别

能够意识到require 和require-dev模块之间的区别是非常重要的。

需要运行在应用中或者库中的包都应该被定义在 require (例如： Symfony, Doctrine, Twig, Guzzle, ...)中。如果你正在创建一个库， 注意将什么内容定义为 require。因为这个部分的 每个依赖项同时也是使用了该库的应用的依赖。

开发应用程序(或库)所需的包应该定义在require-dev (例如：PHPUnit, PHP_CodeSniffer, PHPStan)中。

Tip #11: 安全地升级依赖项

我想大家对如下事实存有共识：应该定期对依赖项升级。 此处我想讨论的是依赖项的升级应该放在明处且慎之又慎，而不能是因其他活计的需要才顺手为之。如果在重构应用的同时又升级了库，那么就很难区分应用崩溃的原因是重构还是升级带来的。

可用 composer outdated 命令查看哪些依赖项需要升级。追加一个 --direct （或 -D）参数开关是个聪明之举，这只会查看 composer.json 指定的依赖项。还有一个 -m 参数开关，只查看次版本号的升级列表。

对每一个老版本的依赖项进行升级都要尊循如下步骤：

创建新分支在 composer.json 文件中更新该依赖项版本到最新版本号运行 composer update phpunit/phpunit --with-dependencies （使用升级过的库替换 phpunit/phpunit）检查 Github 上库的版本库中 CHANGELOG 文件，检查是否存在重大变化。 如果存在就升级应用程序本地测试应用程序（使用 Symfony 的话还能在调试栏看到弃用警告）提交修改（包括 composer.json 、 composer.lock 及其他新版本正常运行所做的必要修改）等 CI 构建结束合并然后部署有时需要一次升级多个依赖项，比如升级 Doctrine 或 Symfony。这种情况下，就要在升级命令中把他们全部罗列出来：

composer update symfony/symfony symfony/monolog-bundle --with-dependencies

或者使用通配符升级所有指定命名空间的依赖：

composer update symfony/*--with-dependencies

这全都是很乏味的工作，但相对于不小心升级依赖项而言，这提供了额外保障。

一个可接受的简捷方式就是一次升级所有 require-dev 中的依赖项（如果程序代码没有修改的话，否则还是建议创建独立分支以便代码审查）。

0 重译

Tip #12: 在 composer.json 中定义其他类型的依赖

除了定义库作为依赖项外，也以在这儿定义其他东西。

可以定义应用程序和库所支持的 PHP 版本：

"require":{"php":"7.1.* || 7.2.*",},

也能定义应用程序和库所需要的扩展。在尝试 docker 化自己的应用时，或是你的同伴头一次设置应用环境时，这招超级实用。

"require":{"ext-mbstring":"*","ext-pdo_mysql":"*",},

（当 扩展版本不一致 时，版本号要用 * ）。

Tip #13: 在CI构建期间验证 composer.json

composer.json 和 composer.lock 应当一直保持同步. 因此, 一直为他们保持自动核对是一个好主意. 将此添加成为你的构建脚本的一部分将会确保 composer.lock 与 composer.json 保持同步:

composer validate --no-check-all --strict

Tip #14: 在 PHPStorm 中使用 Composer 插件

这里有一个 composer.json plugin for PHPStorm. 当手动修改 composer.json 时，插件会自动完成及执行一些验证.

如果你在使用其他 IDE (或者只是一个编辑器), 你可以使用 its JSON schema 设置验证.

Tip #15: 在 composer.json 中指明生产环境的PHP版本号

如果你和我一样，有时还 在本地环境跑PHP最新预释版本， 那么就会处于升级依赖项的版本不能运行于生产环境的风险。现在我就在使用 PHP 7.2.0 ，也就意味着我安装的库可能在 7.1 版本中运行不了。如果生产环境跑的是 7.1 版本，安装就会失败。

不过不用担心，有个非常简单的解决办法，在 composer.json 文件的config 部分指明生产环境的 PHP 版本号即可：

"config":{"platform":{"php":"7.1"}}

别把它和 require 部分的设置搞混了，它的作用不同。你的应用就可以运行 7.1 或 7.2 版本下，而且同时指定了平台版本为 7.1 （这意味着依赖项的升级版本要和 平台版本 7.1 保持兼容）：

Tip #16: 使用自有托管 Gitlab 上的私有包

推荐使用 vcs 作为版本库类型，并且 Composer 决定获取包的合适的方法。比如，从Github上添加一个 fork，使用它的 API 下载整个版本库的 .zip 文件，而不用克隆。

不过对一个私有的 Gitlab 安装来讲会更复杂。如果用 vcs 作版本库类型，Composer 会检测到它是个 Gitlab 类型的安装，会尝试使用 API 下载包（这要求有 API key。我不想设置，所以我只用 SSH 克隆安装了) ：

首先指明版本库类型是 git：

然后指明常用的包：

"require":{"package-namespace/package-name":"1.0.0"}

Tip #17: 临时使用 fork 下 bug 修复分支的方法

如果在某个公共的库中找到一个 bug，并且在Github上自己的 fork 中修复了它， 这就需要从自己的版本库里安装这个库，而不是官方版本库（要到修复合并且修复的版本释出才行）。

使用 内嵌别名 可轻松搞定：

可以通过 设置 path 作为版本库类型 在本地测试这次修复，然后再 push 更新版本库。

文章发布后，我收到了一些建议，提供了更多的使用技巧。它们分别是：

Tip #18：使用 prestissimo 加速你的包安装

Composer 有个 hirak/prestissimo 插件，通过该插件能够以并行的方式进行下载，从而提高依赖包的安装速度。

那么，这么好的东西，你现在该如何做？你仅仅需要马上全局安装这个插件，然后就可以自动地在所有项目中使用。

composer globalrequire hirak/prestissimo

Tip #19: 当你不确定时，测试你的版本约束

即使在阅读 the documentation 之后，书写正确的版本约束在一些时候也是很棘手的.

幸运的是, 这里有 Packagist Semver Checker 可以用来检查哪个本部匹配特定的约束. 他不是仅仅的分析版本约束, 他从 Packagist 下载数据以来展示实际的发布版本.

查看 the result for symfony/symfony:^3.1

Tip #20: 在生产环境中使用使用权威类映射文件

应该在生产环境中 生成权威类映射文件 。这会让类映射文件中包含的所有类快速加载，而不必到磁盘文件系统进行任何检查。

可以在生产环境构建时运行以下命令：

composer dump-autoload --classmap-authoritative

Tip #21: 为测试配置 autoload-dev

你也不想在生产环境中加载测试文件（考虑到测试文件的大小和内存使用）。这可以通过配置 autoload-dev 解决（与 autoload 相似）：

Tip #22: 尝试 Composer 脚本

Composer 脚本是一个创建构建脚本的轻量级工具。关于这个，我有另文述及。

总结

如果你不同意某些观点且阐述出你为什么不同意的意见（不要忘记标注 tip的编号）我将很高兴。

翻译：Summer