我的已经改成 100 了。

r#3 @lyklykkkkkkk 不把问题提出来怎么会知道能不能解决问题呢？不尝试解释一下怎么会知道又怎么会知道能不能解决问题呢？ 「整体团结」即使大家都掩饰问题？

r#6 @Yamade 这么开玩笑不合适吧。

r#20 @curiousjude fix ：或有 100%的把握。

这个我个人的看法是，除非错得离谱或没有 100%的把握，还是不要改了。很多人觉得拼错了没什么大不了，我是很鄙视的，因为拼写错误而花大时间 debug 是很让人吐血的。

有很多很懒的人，明明一开始就发现错误了，因为懒就是不改，后面日积月累，不断坑人。

英文的注音，请不要用中文标注，用音标，不然越纠正越错。

这么说吧，如果说只是想找个工作， PHP 做电商，保你未来 5 年工作无忧。
但是追求不能这么低。

各位不要太激动啊，@gaitana 并没有说不支持使用框架，而是说 PHP 不要使用框架，鼓励大家使用原生的语法处理模板，使用内置函数直接处理问题等。当然这些我个人都不赞同。

我对 @gaitana 这种一刀切的观点是不赞同的，没有具体的应用场景就直接说 PHP 不应该使用框架，这才是「会对新人造成误导」。

@gaitana 我觉得你没有说服我。
1. ORM 的问题，你举的例子没有说服力，「->」和「.」哪个更好看这个完全是主观的，我就觉得没有什么区别，况且 ORM 又不只是为了更好看。 ORM 本身就是为了解决使用的原生 SQL 的不便，和一些其他问题（比如安全处理）才创造出来的，除非你指出 ORM 无法解决这些问题，或在某些场景下没有必要，才有说服力。

2. 至于你说的 PHP 内置函数的问题，我并不觉得框架（或库）对一些函数进行封装就一定是不合理的，比如 curl 系列函数，纯面向过程，那么如果你不对它封装一下写 OOP 程序应该很不好处理吧，具体可以参照一下 Facebook 的 SDK 。我觉得框架重新封装一些函数不仅仅是为了更好看，也是为了统一接口，这样才能保持一定的灵活性，当然有时很难平衡这个度。

3. 我觉得框架存在的意义是更便利地解决解决一些通用的问题，比如你们之前提到的 Route ， ORM ， Templating ，如果问题这些在你的应用场景下不存在或不重要，那自然可以不用框架。你提出的模板解决方法，功能性是有缺失的，比如布局处理，全局的安全处理（比如 htmlentities ）等。

@Felldeadbird 这不就是用框架了吗？ 所以不能说 PHP 不应该用框架。按照你们的观点，应该是说市面上没有好用的框架。

@gaitana 能具体解释一下「 PHP 语言特性决定了不适合造框架，原生语言用的熟的话比框架更方便」吗？

这些 不 具体讨论这个页面妥不妥就给楼主扣帽子的，让我感到很诧异。

我也觉得不妥。这个页面的设计像是在纪念灾难吗？

这些具体讨论这个页面妥不妥就给楼主扣帽子的，让我感到很诧异。

简历最后致谢的英文：
1. take time to do而不是to doing
2. take time就行了，不要加定冠词the
3. have a nice day就可以了，前面的hope you多余

@laoertongzhi 入职两个月，工作太轻松，离职！

不是应该PS4吗？

调查结果：原来是里面混入了控制字符。