和语言关系不大，写渣代码的人，用任何语言都是这种渣代码。
看起来连接口都没用，如果不是免维护的项目，感觉基础离及格还是查的很远的，也仅是感慨。

装完就卸了，电脑里没 mp3 。

@SharkIng 你应该有个脚本，能完整的还原你 web server 的环境，工具倒是没用过，我是完全 shell 。

拆分从来都不是看长短，看职责是否单一，一个函数是否知道太多内容，是否做到关注分离了，是否易于单元测试。废话就不说了。

你觉得别人开源的方式你不喜欢，不去关注或者不去用就行了。
干嘛还要在人家面前大喊“大家快来看呀，这有个哈哈哈哈”。
我觉得好多程序员有种让人很不适的表达风格，就是特别爱凑热闹，特别爱扯淡，别人认真讲话的时候你就喜欢嘻嘻哈哈的围着别人跳，各种调侃，感觉这种风格本身特别屌丝（是的贬义词）。
对于这个项目（姑且这么说吧）的作者，我想说的是你当然有表达自己的自由毕竟是自己的东西，但是长远看缺乏学术精神和专业态度（文档、测试、行文与表达的风格等等）的东西对吸引用户非常不利。当然啦，个人看法。。。

一半一半吧，两台不断， 两台时有丢包。

笑死了，还随机 ss ， 你就算在一亿个 ip 里随机，也能找到你的知道吗。
核心玩法是，不能只用一个跳板机。
通常就是 ssh 登录跳板，在跳板里继续 ssh ， 这样中间隔着四五台机器，再在最终跳板机发动攻击，结束之后还要一个个机器销毁证据什么的。
或者 vpn 套 ssh ， 总之就是不能只用一个跳板，这样运营商会直接根据那台机器的 ip 找到你的请求记录。
另外题主的问题的标准答案是，一般玩这个的，手里常年养着一批跳板（肉鸡）。

什么小鱼小虾瞎编的一个词，你也跟着激动：）
栈这个字，研究它本身意义也不大。

反馈下， github 登录之后仍然要输入用户名之类的。
能否更纯粹些？
发现大陆的网站特别喜欢这样，第三方登录之后还得重新申请帐号：）

黑石礁观光团路过。

@pein 我没有要改接口， 我说的 1 中不是改这个接口，是重新实现。
你的 salt 如果也存在数据库中， 应该还需要覆写一两个 auth 类的方法，具体我没看源码，不过估计也不是特别麻烦。

一个月 2w 多的 engineer 很不错了。看你自己年龄吧，如果还能在漂两年，攒点钱再回去也不错。
一年工资，回家够办个相当不错的工作了。

上一条点错按键，就发出去了。
本来是搜点资料无意中进来了，看到有人问题就回答下，索性顺便回复一下吧。

Laravel 国内相对不是特别热，的确和国人英语水平有很大关系（我英语也很差，自学的），增加了学习和使用成本，不过感觉中文资料已经够用了，尤其是官方文档，基本想了解的东西都能在上面找得到。我觉得既然做了这一行，那英语早晚都得是必须攻克的东西，否则变量取个名都要想半天，会很闹心。

搭建过程和其它现代框架一样 composer ， composer 本身的网络不稳定相信网上有好多镜像可用，我是不用镜像，如果不能顺畅 update ，通常是退出命令重新来（类似刷新网页），多试几次通常就可以。

可扩展性、代码可读性我还没涉及到，还有 soa ，听起来挺高大上的。 源码目前除了 loc 之外，其它也没太看。

模版引擎和 Smarty 显然没什么可比性，相差了近乎 10 年的东西，两个时代了，刚接触 php 的时候记得 ecshop 还是什么用的。 blade 引擎和 twig 风格类似，我觉得比 Smarty 简单好多，方便不懂 php 的直接往里套变量。你喜欢的话也可以直接写原生的 <?php ?> 。

你要是说 laravel 灵活差，那还没看到 yii 呢，哈哈，当改一个 script 地址都要去控制器里改调用的方法，那才是醉了。 laravel 的错误提示也还好，目前我还没碰到需要去搜提示才能解决的问题，通常就是直接照着他提示的行数去找相应 bug ，或者下个断点就出来了。

我之前用的是 Yii ，后来觉得有些过度封装了。接触 Laravel 有 2 个月。 Laravel 的性能是我所知道的最差的框架之一（我自己也 ab 了几次）。 好在现在的我已经不把性能作为选择框架的首要考虑，写着爽，语法糖多，开发速度快就行，用句《 yii for beginner 》作者的话说， Laravel 可以让你变成更好的 PHP 程序员。在使用过程中，深深感觉到作者为了用户所做的那些各种贴心的设计，之前其它框架所不支持的 Orm 的多态关联，多个中间表的多态关联，竟然一个方法就搞定。还有就是作者的注释非常的有趣而且言简意赅。速度的事，以后再说喽，实在不行就改写路由，加内存缓存， config 入驻内存等等乱七八糟的常规优化呗。速度问题是个小问题。

PHP 是一门用户数量很多语言，大家的水平悟性以及努力程度也不尽相同，如果一个框架能让自己水平提高稍微一点点，还是值得用的，这就是我选择 Laravel 的原因。倒也不是什么粉丝。还没脑残到成为一个语言或框架的粉丝，只是既然写 php ，就用一个自己觉得爽的吧。还有就是 laravel 的生态圈太强大了。基本 laracast 视频走一圈就知道大概咋回事。语言比较没逻辑 抱歉啦各位。

@xuxu @raincious @pein
1, 实现自己的 HasherContract 类（ implements Illuminate\Contracts\Hashing\Hasher ），其中的加密解密都用自己的方式。
2 ，增加自己的 CustomHashServiceProvider ，继承自目前系统中的（ extends Illuminate\Hashing\HashServiceProvider ），在其中 register 方法中将上面新建的 HasherContract 类绑定到 app()['hash'] 上（$this->app->singleton('hash', function() { return new CustomHaser; })）；
3 ， config/app.php 中的 Illuminate\Hashing\HashServiceProvider::class 替换为 2 中新建的。
至此你的应用 auth check 过程将由你新建的 hasher 接管。

另外 bcrypt 是基于因子的加密，为的是防止未来攻击者计算能力提高，彩虹表碰撞时间越来越短，方便使用者调节加密层数，默认情况下因子设置的比较大。
你加密慢，黑客解密也慢，很难去否定 bcrypt ，就我的理解，这算是目前最完美的密码方案之一。用所谓流量大，并发高去理解加解密也很不合适，因为只有登录、注册时才会调用 bcrypt 函数，这两种行为相比日常房问简直是杯水车薪（除非你的应用每秒几十个人注册）。


缺点：
1.中文资料严重不足，搜个错误提示都搜不到，必须各种翻墙
2.手册可读性差，或者说严重不符合国人的习惯
3.搭建过程繁琐
4.composer 不给力
5.packagist 上的 vendor 容易涉及版权问题（一旦涉及就被下架，然后再也找不到了，例如 Excel ）
6.自己扩展着实不意
7.代码可读性非常的差，层级过多（是太 TM 的多了）
8.无法方面的支持 soa
9.模板引擎太过于强大，未定义参数全报错
10.自定义配置较差

优点：
1.ORM 模型，连 TP 都来仿了
2.模板引擎很强大，用惯了 Smarty ，再用 blade ，感觉有点诡异

总结：
1.都说 laravel 强大性能高，真心没觉得，没基础的小白看手册都看不懂，有经验的又觉得其灵活性较差、排查 BUG 困难。
2.以我目前看来： laravel 适合做单个项目（例如：一个 cms 系统、图片系统、中小 ERP ），并不太适合移动互联网的高并发应用。（可能是我错了）

可耻的谎言。
如果调用一个接口就能清空前端数据，那么天猫的可靠性也太差了吧！
权限、验证什么都不做？企业负责人签名都不需要，就直接能清空人家数据？

说 sublime 的绝对是坑你呢，那玩意咋重构阿？ 改个命名空间，还要一个个重新组织文件？