怎么让php程序崩溃

1、怎么让php程序崩溃，程序员真的既是体力活又是脑力活吗？

首先声明：我现在要说大实话了，作为程序员的大家不要玻璃心哈。如果你们感觉我说的非常对，说的是大实话的话，你们一定要给我点赞。

程序员这个职业分的工种很多，真的是很多，很多。而大部分人选择的程序员的工种，在我看来是体力活，是体力活，是体力活。而少部分工种是脑力活。

我为什么这么说呢？那哪些工种是体力活，哪些是脑力活呢？咱们一起举个例子，来看看。

软件应用开发工程师在我看来，大部分的工作其实都是体力活，尤其是对于工作2年以上的应用层开发工程师，真的是每天 80% 的代码都是重复代码，都是在粘贴复制，修修改改，修修补补。

在大学中学习的离散数据，算法啊，统计学，线代啊，看似动脑的知识，在真正的应用层编程中其实大多数情况下都是用不到的。

这种开发其实写多了真的挺烦的。

算法工程师和架构师这样的工作，其实真的是脑力活。相信大家学习算法的时候都是体验过的，尤其是将来大数据，人工智能的带动下，算法，确实是一个非常耗费脑力的工作。

其实架构师也是非常需要动脑子的，尤其是遇到各种复杂情况下，高并发，高可用以及各种复杂环境，如果处理啊，都需要特别动脑子。

不知道大家发现了没有？其实不管哪个行业，虽然感觉程序员行业是高智商的行业，但是本质上每个人都不爱动脑子。

程序员这个行业，有人说饱和了，有人说没饱和。对，饱和了的都是体力的工种，初级，中级的应用开发工程师的岗位，你看看人工智能，大数据，算法工程师饱和不饱和？肯定不饱和啊！就拿头条来讲，到处高薪聘请算法工程师。

当然，可能这么说也不对，并不是大家不喜欢动脑子，而是确实有时候，脑子不够用， 所以才去干体力活的。

而且，程序员这个工作，其实也是熟能生巧的工作，熟能生巧的背后，最后，都会成为体力活。一个活，干久了，用久了，可能就那么点东西，熟练了，形成了自然的记忆，不用想，可能就敲出来了，到了最后，感觉都是体力活。

其实，程序员这个行业，这点不好，为什么不好？因为技术更新迭代太快了，你可能刚花两年用熟了这个技术，之后，随着时代和科技的发展，淘汰了，又出了新的技术，你又要去学习了，这个学习的过程可能需要你动脑子。

真的是活到老，练到老，学到老，就成了：体力->脑力->体力，进入了一个熟练，体力，学习，脑力，熟练，体力的循环当中了，这就是程序员这个行业的悲哀。

所以，程序员这个职业，也不是一般人能干的。

2、传奇游戏崩溃怎么解决？

一、准备工作

1、建立问题清单：归纳收集出现问题的情景，具体表现，看看有什么特征和规律，针对这些规律的诊断可以做出比较准确的定性分析和认知。

2、记录收集：记录触发异常行为的事件，以及反馈给客户或技术支持人员的日志，以及Slog中的异常堆栈，这些日志可以让你更有效地分析问题，排查故障。

二、异常排查

1、请求能否成功回复：需要确保游戏客户端能够成功发出请求，并且可以从服务器正确获取返回内容，也就是服务器收到请求和发送响应后，客户端能够正确接收到。这里可以结合日志分析客户端请求能否正常建立连接、发送请求等。

2、检查服务器端：检查服务器端是否可以正常处理，比如php、asp、nodejs等应用服务是否正常运行，以及日志里抓取的错误信息是否分析出客户端请求的是否准确，以及可以正常返回成功状态给客户端的。

3、检查客户端：检查客户端是否可以正常处理，也就是判断服务器返回的是否正确，分析具体是哪个代码出现异常，准确定位代码可以有效进行调试。

三、优化建议

1、尽量不使用易出错的代码：游戏开发时，应尽量避免使用易出错的代码，比如eval、switch、goto等易出错的特性，主要原因是这类语句很容易触发异常情况，如果你不能避免，应在开发和测试阶段进行可靠的检查和调试工作。

2、调试工具的使用：调试工具可以帮助开发者方便地定位出现异常的代码和现象，以及跟踪程序流程。在开发调试过程中，应多加利用调试工具，如visual studio、xcode等，及时定位和修复问题，提高游戏稳定性。

3、非格式字符串是什么意思？

比较通用的来说，这些字符会造成程序系统的崩溃，降低程序安全性，增加程序使用难度，这些字符可以叫非法字符。

其实有的非法字符是程序设计者在程序中定义的、或者可以避免的字符，有些字符在某些人眼里可能非法，但是在另外一些高级设计师眼里不一定就是非法。

不论asp，php，或者数据库，或者平时使用的小软件都会存在的。

非法字符串有：',*%()=

4、如何成为一名PHP架构师？

先明确这里所指的PHP工程师，是指主要以PHP进行Web系统的开发，没有使用其的语言工作过。工作经验大概在3~4年，普通的Web系统（百万级访问，千成级数据以内或业务逻辑不是特别复杂）开发起基本得心应手，没有什么问题。但他们会有这样的误点：

◆ 除了PHP不使用其它的语言，可能会点shell 脚本。

◆ 对PHP的掌握不精（很多PHP手册都没有看完，库除外）。

◆ 知识面比较窄（面对需求，除开使用PHP和MYSQL，不知道其它的解决办法）。

◆ PHP代码以过程为主，认为面向对象的实现太绕，看不懂。

这些PHPer在遇到需要高性能，处理高并发，大量数据的项目或业务逻辑比较复杂（系统需要解决多领域业务的问题）时，缺少思路。不能分析问题的本质，技术判断力比较差，对于问题较快能找出临时的解决办法，但常常在不断临时性的解决办法中，系统和自己一步步走向崩溃。那怎么提高自己呢？怎么可以挑战难度更高的系统？

更高的挑战在那里？

结合我自己的经验，我列出一些具体挑战，让大家先有个感性的认识。

高性能系统的挑战在那里？

◆ 如何选择Web服务器？要不要使用fast-cgi 模式；

◆ 要不要使用反向代理服务？选择全内存缓存还是硬盘缓存？

◆ 是否需要负载均衡？是基于应用层，还是网络层？ 如何保证高可靠性？

◆ 你的PHP代码性能如何，使用优化工具后怎么样？ 性能瓶颈在那里？ 是否需要写成C的扩展？

◆ 用户访问有什么特点，是读多还是写多？是否需要读写分离？

◆ 数据如何存储？写入速度和读出速度如何？ 数据增涨访问速读如何变化？

◆ 如何使用缓存？ 怎么样考虑失效？数据的一致性怎么保证？

高复杂性系统的挑战在那里？

◆ 能否识别业务所对应的领域？是一个还是多个？

◆ 能否合理对业务进行抽象，在业务规则变化能以很小的代价实现？

◆ 数据的一致性、安全性可否保证？

◆ 是否撑握了面向对象的分析和设计的方法？

这里所列出的问题，你都能肯定的回答，说明在技术上你基本已经可能成为架构师了。如何你还不能回答，你需要在以下几个方向加强。

怎么样提高，突破瓶颈

如何你还不能回答，你需要在以下几个方向加强：

◆ 分析你所使用的技术其原理和背后运行的机制，这样可以提高你的技术判断力，提高你技术方案选择的正确性；

◆ 学习大学期间重要的知识，操作系统原理，数据结构和算法。知道你以前学习都是为了考试，但现在你需要为自己学习，让自己知其所以然；

◆ 重新开始学习C语言，虽然你在大学已经学过。这不仅是因为你可能需要写PHP扩展，而且还因为，在做C的应用中，有一个时刻关心性能、内存控制、变量生命周期、数据结构和算法的环境；

◆ 学习面向对象的分析与设计，它是解决复杂问题的有效的方法。学习抽象，它是解决复杂问题的唯一之道。

5、甚至淘宝也从KISSY转向了React？

React已经在蚂蚁金服使用了一年多的时间，基于React/React-Native我们开发了移动端和pc端的基础组件react-componentantdantm，整合业界最佳实践推出了简单易用的开发工具ant-tool和应用架构roof，服务于蚂蚁金服以及阿里集团的多个业务，取得了良好效果；本次分享将介绍我国过去一年基于React的最佳实践以及展望

基于 React 的前端架构在蚂蚁金服的实践

今天我的主题是是基于React的终端架构，其实还是主要侧重于前端，终端是我们未来前端的一个方向我在阿里的工作分为两个阶段第一个阶段是2010年进淘宝之后，一直做的就是 kissy 类库开发还有周边的工具2014年的时候去了蚂蚁金服，蚂蚁金服的开发策略是全栈开发，所以需要一个技术转型，所以我们这边就选择了React

首先介绍一下蚂蚁金服前端的业务特点蚂蚁金服是由支付宝进化而来的，现在是四大业务，支付宝个人消费，然后是蚂蚁聚宝，主要侧重于理财的，网上银行侧重于企业银行业务的开发，还有一个是侧重于个人消费的O2O的口碑，这个是我们的四大业务

前端面临的业务非常多，而且目前移动端都是结合 web 混合式的，大家可能也听说过阿里已经开发了一个 weex的框架，或者结合react-native来做动态化等等其实它的语言甚至都是javascript，就是对于前端来说这些都是一样的

除了移动端的东西之外，每一个APP的业务下面都会有对应的很多的后台业务支撑，比如做运营的话，就需要运营平台，阿里的特色就是特别注重运营，其实我们内部有很多这种运营平台，都是给小二用的

然后对于蚂蚁的话，蚂蚁有很多的商家，商家也需要商户平台来管理自己的运营只靠专业前端是那么对于前端来说，这么多业务在国内前端都普遍欠缺的情况根本做不过来的所以蚂蚁的一个战略就是说前端不要只做前端的事情了，就是把这些业务的前端工作教会全栈来做

前端就要像DBA一样要提供一些业务支持，提供一些资源服务的一些支持转型就是说我们要走全站研发这样一个模式业务需求最好都是有对应的全栈来做，然后结合产品经理做快速响应需求而前端要做的事情就是要打造一个适合全栈开发的基础设施

前端团队也是在进行转型，不再直接的投入业务，不再像一个资源一样，哪里有业务需求就去哪里而是要进行一个转型，我们只提供服务，而我们服务的输出就是我们的技术产品，就是我们基于 React做的一些类库，或者是做了一些设计的封装，那么培训全栈直接用就可以了

我后面所讲的前端架构面向的观众其实都是全栈的开发，不是前端开发，所以我们的架构会有一些改变

首先我们选择的底层类库是React，我们为什么要选择React技术站，而没有像以前那样我们基于jquery或者 kissy继续做，其实有一些原因

首先React技术栈是比较先进的，它是目前流行的函数式，基于不可变数据并且它是非常务实，在 facebook全网都有应用，经过大量实战考验

第二个是生态圈非常繁荣，React是从2013年发布到现在 star 一直在涨，现在已经四万多了，并且 redux, react-router等等这些类库层出不穷，并且质量非常高

第三个是适用性广，适用性广的话也是根据我们的特点，我们要打造全栈工程师，就希望他们能够用尽量少的技术来应对各种应用场景，无论是 native 端还有web端都希望用一种技术来开发，而React的话，就是提供了我们这样的技术，比如说React和React-Native

第四个是我没写出来，是针对我们公司的，因为蚂蚁金服的后端开发人员是以JAVA开发为主，而React技术栈的整个架构和后端的JAVA架构其实是比较类似的，比较容易被后端开发所接受经过这一年的验证，也确实证明这一点，非常容易上手

我们选型的核心技术是React，ES2015然后还有 typescript是目前正在推进的一个改进，也是特别贴近我们公司的业务，因为我们后台的应用非常复杂，业务逻辑非常多，后端开发是用JAVA，有很多的类型保护这个系统不会轻易的崩溃等等当他们转到前端以后，发现前端太灵活了，根本搞不清楚这个对象里面有哪个方法，属性是什么类型，经常会传错或者运行时抛错，而导致一些对我们前端来说是不可思议的错误我们现在在引进 typescript来对我们的技术产品做一个静态类型的增强，避免一些无谓的错误

我们要打造适合全栈的前端基础设施，这个是我们目前的一个架构图

底层是基于 npm 的，在公司内部对应于 tnpm，大家如果熟悉JAVA的话，就是相当于 maven的这种包管理工具，然后我们会 ant-tool 这样一个编译工具，对应JAVA的话，相当于JAVAC等等的一些工具然后在这之上的话会有一些基础组件，然后基于这些组件我们会封装出适合全栈开发用的一些技术产品通常是融合我们的设计的，比如 antd，然后再结合我们提供的应用架构，全栈就可以基于整个体系来进行业务开发了

首先是包管理器，生态圈很重要，npm 是整个世界上所有的语言中生态最繁华的，里面基本上是应有尽有，所以说我们选择了 npm，并且也是React生态圈推荐的一个管理工具

在我们内部的话，其实阿里在很早以前就已经开始了 nodejs 应用，在我们内部的话，npm 也是有对应的镜像 tnpm，这样的话，前端可以把我们内部的一些应用模块也发到 tnpm 去，各个业务之间想共享模块的话，就直接从 tnpm 拉取就可以了，另外为后期的优化打造了一个坚实的基础

工具方面我们也是基于业界的一些优秀方案进行封装，webpack的功能是非常强大的，配置也是非常复杂的，配置文件可能经常就有几百行的样子所以说对于全栈开发来说，除了业务开发，还要熟悉 webpack 的配置等等我们希望全栈能够专注于业务我们根据自己的经验把它封装起来，这样的话就是一个简单的命令行工具，可以实现代理，构建，离线打包等，还有代码规范的约束

最终输出是一个脚手架，因为直接用工具的话，还是比较复杂的因为还知道它的很多命令啊，怎么用啊，直接输出脚手架，我们会把这些开发工具通过npm script来暴露出来，这样就可以直接进行开发还有构建等等，不需要了解更多工具细节了

我们目前组件分成三大部分，首先是底层的react-component，这个在 github上开源了，这些底层组件的话通常是不涉及设计的，就是它没有设计要素在里面，只是实现结构和功能，那么在基于这个组件，会有基于我们的设计的封装，还有移动端的封装

因为React是跨终端的，所以这些组件，在编写的时候也是考虑了多终端下面的运行，如果是通用组件的话，就是没有前缀，然后这些组件的话经常是用PC还有PAD 等大屏设备上的如果有m 前缀的话，这些都是我们单独为移动端 UI的交互所实现的同时会适配web和native，组件的API是一样的，如果运行环境支持 react-native 的话，那么业务就可以跨终端运行了

组件规范包括assets，样式的话我们目前选择是BEM，然后通过 prefixCls 来适配不同的设计，这样的话底层组件不仅能够适配蚂蚁金服的 ant design 设计上，还可以适配到阿里巴巴的其它一些设计

源码 src 部分是ES6，目前是向 typescript迁移，并且部分组件的话会适配 react-native如果基于这套脚手架来实现的话，会支持很多开源的一些基础设施，比如 travis 持续集成平台，coverall 测试覆盖率平台

组件开发时通过 npm run dev启动开发服务器，可以访问示例地址进行开发测试通过 npm test在终端测试，还可以进行 npm run chrome-test，在 chrome 中进行可视化测试，还可以进行debug

通过 pre-commit 进行提交检测，代码检测通过后才会真正的提交到代码库

目前采用的是ES2015，所以是不能是直接发到 npm上面用的，我们用 npm run pub 命令，执行编译和发布，把 es6/typescript编译为 ES5代码，进行提交发布，构建项目展示页这样就完成了组件的一个完整的开发流程

组件开发完成还不是真正的完成，还需要样式来适配，我们对外暴露的是一个设计语言，包括封装好的组件，组件包含功能设计和交互，这些是全公司统一的，有一定的设计原则，然后还有一些设计模式的沉淀，有对应的工具，参考案例，然后会培训全栈来开发，培训产品经理设计

Ant design是跨终端的，它可以后台，也可以针对移动端遵循的原则其实首先是非常实用的，这个设计语言我们是希望能够统一蚂蚁金服的设计第二它是小而美的，它的组件是非常多的，可以根据业务特点按需使用

后面两个就是它是有统一的交互和动画，形成一个统一的品牌输出

实现包含两个部分，第一个就是PC端的实现，PC端的实现就是antd，这个库的话目前已经开源，在ATM里面包含了很多组件，它是对底层组件的一个封装，然后融合设计，形成了一个统一UI，用户只需要组件，进行一些布局和拼装

我们也在进行国际化，蚂蚁金服现在也在进行一些国际化的业务，那么对于多语言的支持也是有非常强烈的需求同时我们在国外的话也有一些影响，一些国外的开发者希望我们能够更国际化一些，现在会增加一些国际化的文件，对文档进行翻译，我们是和国外的开发者一起进行的，我们翻译之后会请那些国外开发者来 review

使用的时候不需要关心样式，和那个JAVA里面的import是一样的直接通过标签化的使用，进行一些业务处理会有一个 babel 插件进行按需加载，如果直接用 import antd的话，打包后会很大所以有了这个插件之后，可以进行按需加载

Ant.design是一个SPA的单页面应用，依赖一个工具叫 bisheng.目前 antd在国内外取得了比较好的影响目前 star有4200多了

ant design mobile一方面要考虑web端，要考虑小屏场景，另外一个就是我们要考虑react-native，能够同时用在web和react-native，并且通过React组件的封装达到一致的API比较 react-native，如果 react-native 有的组件，web端也要实现，如果 react-native 没有的话，web 端和 native 都要实现

antm web 端基础设施和 antd 是一样的，ios 和 android 是单独的基础设施，可以通过 npm 命令来直接运行展示

三套组件定位不一样配置也不一样底层组件配置多， antd主要满足蚂蚁金服的统一品牌，配置少，交互设计固定，面向用户是全栈用户和初级的前端用户扩展性也不一样只有组件不行，还需要应用框架，组件拼装，处理了展示层的问题，业务要和服务器进行交互，处理数据和联动，这样的话就需要应用框架，应用框架的话我们目前是有两套方案，我们之前开发了非常简单的一个数据绑定库，因为我们在做业务的时候发现经常碰到数据联动的需求我们采用经典的订阅和发布模式 另外对于一些特别复杂的业务，比如说像金融云，使用起来挺麻烦的

后面我们侧重于社区，会从社区里面找一些优秀的类库形成企业端的应用框架

单页应用需要一个库来响应URL变化获取数据获取数据之后传给React渲染，渲染之后响应交互，响应交互之后我们再处理数据，把这个数据再传给服务器，或者对这个数据进行一个二次加工，然后再传给对应的组件来进行服务，比较固定的流程

我们就选择了一些优秀类库来实现这种场景比如说URL到数据这样的一个控制，我们可以通过 react-router 来实现，那么当这个UR发生变化之后，那么React就会重新渲染我们的组件，这个组件就可以获取数据，然后获取数据的话我们可以通过新的标准，以及 fetch 来方便我们和服务器来进行内部交互

有了数据之后，通过redux把数据映射到react，通过CSS module，避免了CSS冲突通过脚手架的形式来输出来，组件放在哪里，还有那个路由放在哪里，都是通过目录的形式来约定，这样的话就是避免了代码的腐化前面是说服务器交互的话，服务器交互我们用的是 fetch/falcor两种方案基于 async/await 把异步回调转化为同步调用

另外一个就是 falcor, 通过 falcor可以**减少了页面请求，特别是首屏的展现，提高响应速度

最后下开发流程，通过 npm 下载 antd 和其他需要的类库，然后拼装组件后结合应用架构完成业务需求业务落地主要是antd，从发布一年多以来，覆盖全部系统40%，新的业务占有率是100%

未来是希望能够把静态类型引入到类库中去，这样的话减少传统的后端开发人员开发前端代码时的错误

移动端的目标是 web 和 native 齐头并进，达到组件API的兼容，能够在各个终端快速迁移服务器端探索 falcor 或 graphql，通过这种统一数据模型来规范前后端交互 完善国际化的资源和文档，支撑蚂蚁金服的国际化发展

最后是业务模式库，和业务方面结合，规范我们的业务，通过提供通用的业务组件来更好的支持多业务线之间的共享