这几个才是正规项目开始的地方。

yii-base-web，yii-base-api 和 yii-base-cli 这几个参考才是正式开始的地方

demo 是某些人练手的地方，确实不友好。

https://github.com/yiisoft/docs 的 Roadmap 还有很多，不知道什么时候呢，我等了 2 年了。

@dvaknheo

直接看这个吧 https://github.com/yiisoft/yii-base-web

@dvaknheo
既然你放出了你得框架（ https://github.com/dvaknheo/duckphp ），
那么我就去看一下吧：

你的 hello world 代码，虽然只有几行，但是存在几个点，我看了之后基本不会用，也会劝别人不要用。

```
<?php
require_once __DIR__.'/../vendor/autoload.php';

class Main
{
public function index()
{
echo "hello world";
}
}
$options=[
'namespace_controller'=>'\\', // 设置控制器的命名空间为根
'skip_setting_file'=>true, // 跳过配置文件
];
DuckPHP\DuckPHP::RunQuickly($options);
```

第一：echo "hello world"; 而不是 return "hello world"？直接在控制器里面输出 html 这也是一绝了（绝迹的绝），你想让其他人都学样在控制器 echo html 吗？为什么其他框架都要采用 return 呢？

第二：namespace_controller 这是什么配置，双斜杆为根，什么奇葩？单独只让自己知道一个标准？我是不看源码心里没底。好的框架不应该直接一看就知道是什么吗？和 yii 的 'controllerNamespace' => 'api\controllers' 比一下，后者我一看就知道是什么意思，我用的着这简写吗，我在给别人还是自己挖坑吗？你真要少代码，因为反正都隐藏了，不如直接不配置，约定俗称。

第三：skip_setting_file=true 脱裤子放屁？不应该是不写配置就是自动跳过配置吗？


第四：DuckPHP\DuckPHP::RunQuickly($options)？莫非还有一个 RunSlowly($options)？有什么问题是直接一个 DuckPHP\DuckPHP::Run($options)解决不了的？


第五：Controller 写在入口文件？这得多 demo 啊？这是 micro/slim/flask 这类函数式框架的写法吧？


对于你的提到 Yii3 demo 增加了复杂度，我是同样看法的，应该可以更加简单，不妨先看看 yii2 吧，如果 yii3 真就这样，反正不用就是了，现在也在难产中，什么时候出来不知道。
我 yii 2 目前够用（除了那个和 bootstrap3 绑定外）。

对于以上评价，可能显得刻薄，请谅解。
敬佩你写开源框架的精神。

Yii3 确实被玩坏了，你的判断是对的，我也有这种感觉，团队成员现在动力不大了，因为 PHP 的发展空间就摆在这里，这个轮子不好玩了，意义不大了，我们都要承认。

PHP 要续命，目前我看只有写出一个好的基于云原生的框架，然后提供这个框架之上的大量现成程序，改下就能用。（类似 thinkphp 的 fastadmin，微擎的应用商店，这些都是中国特色，老外是不屑玩的）。

其实我也做过推荐，也能理解吧。

1，推荐外层的是根据用户浏览历史标签来的；
2，购物车页面的推荐才是根据用户当前选择的产品，推荐相关产品；

而亚马逊主要是根据用户购买历史，而不是浏览历史。


还有一个是性能问题，按照浏览历史用户通常看得太多，filter 不好实现啊，filter 之后基本没有价值了。

另外一个因为推荐的都是广告位，是主营收入呢，都被加入 filter 之后，平台怎么赚钱呢，难道学 AMAZON ？收入怕得大降，被竞争对手打死，被投资人骂死，Aamzon 交易手续费高啊，所以药不能停，只能继续牺牲消费者利益，保证平台利益了。

说过狗东的笑话：你上午卖了一款 iPhone，下午给你推荐另外一家店铺同型号更便宜的，我究竟要不要退货呢？

以前在深圳 30 层办公，
有次肇庆地震了，
椅子蹦了几下，
大家先是心里一慌，
然后又安静下来了，
反正电梯已经无法上去了，走楼梯也晚了。

昨天跑到 32 层，
按向下的电梯（我们电梯 2 梯 4 户停 16 层我住 11 平时觉得速度还挺快的），
不巧两个都下行过程中，那个等啊，大概 3 分钟吧，平时我都是 30 秒到 1 分钟的啊。
这时候我就想以后不住高层。

还有打雷时候，停电停水时候，谁来分享下？

原来是会员就不会出广告

看这个帖子，在 firefox 下出现广告了，而 chrome 就不会。

@dvaknheo


一：



<?php
// ...
echo Alert::widget()
//..
?>

我个人会选择

<?=Alert::widget(['class'=>'my-custom'])?>

更加灵活，而不是从控制器传入，
框架的核心有一条是逻辑分离，减少大脑负载，
yii model 负责规则配置、数据操作，
控制器负责接收请求、组装数据，
视图负责展示，
如果采用控制器传入，那么就不是在视图定制了，而是在控制器定制界面，
如果你连这条不清楚，
那么你的框架我非常不看好，
而且会劝别人不要用，
因为大家会找不到这个界面的代码写在哪里，
我是不会去维护这样的代码的。


二：

action="<?= $urlGenerator->generate('site/contact') ?>"


Url::to(['site/contract'])方法是可以用的。


三：

其实最希望的是 View 里 一个命名空间都不用，代码简洁得多。

前面有提到视图负责展示逻辑，你记住这句就可以了，只要没有脱离这个本质，再多命名空间，那么代码也是清晰和直白的。

代码的清晰条理性重要性很重要，你说的 view 一个命名空间不用，Yii 至少有 5 种选择:

1，将展示逻辑放在控制器；（展示逻辑不分离，不推荐）
2，隐式引用；（没有代码提示，不好 DEBUG，不直观，不推荐）
3，模板引擎；（个人认为 php 本身就是最好的模板引擎，不推荐）
4，采用 ajax ；（这个可以）；
5，调用 rest 接口；（这个也可以）

你有第六种办法，还是用了其中一种？


四：

配置 rule VS 手动 debug

rule 可以自动生成(gii)，改好 rule 就会错误提示一致，不会出 bug，不需要 debug 了，所以这就是自动驾驶，你现在和我说手动挡好？


五：

安全

比如内置了 jwt，rules 验证，cookie 加密，防注入等等，这些基本是目前框架标配吧。
你感觉不到，因为你看的是普通模板，不是高级模板，普通模板是隐藏了这些的，不表示它不存在，且你没有看官方文档，直接上手一个 demo 了。
比如需要配置 cookieValidationKey 你知道是做什么用的吗？
比如为什么配置文件要分为 local 和非 local ？
environments 里面的 prod 和 dev 又是做什么用的？


六：

有没有默认配置，让我的 业务工程看起来简单。


https://www.yiiframework.com/
首页 5 个步骤第一个步骤：安装 composer，下载标准模板，运行 yii serve 。
三行命令项目都跑起来了，进入开发了，你说没有默认配置？



七：
比如模拟某个人操作，没必要用 curl 模拟从他登录开始吧。
拿到 uid，直接调用 service 业务层就行了。

Model 还可以用，Console 也可以用，其他都可以用，不必重复，
Yii3 最大的不同和目的就是将 jq,bt 等前端框架从核心中分离出来。
至于这个 demo 你可以看成秀技术的，Yii 其实一直都是紧跟 PHP 版本的。


八：

php7.4 预加载，解决了一部分性能问题。但是并没有完全解决

还是请举出一个除了不能常驻内存之外的性能问题例子出来，不能说空话啊，写程序的不能空对空，得摆事实。



九：
一个请求过来，框架的 hello world 要比纯 php 的 helloworld 跑多出很多 php 代码。

现实是大家都用框架，WHY ？
都是大牛们为了优雅好玩的？
大牛们都傻？
老板也傻？
层次不同而已，你看到的是自己写得爽，对其他任来说是团队合作有一套默契的规范，能够高效解决问题。

十：

为了追求性能和模式，所谓 [WEB] 高手们抛下了 PHP 改用 go 、java 、c#，留下一个所谓“优雅”的 PHP 开发氛围。

你还是可以不用框架啊，而且你还是可以自己写一个框架啊，所以有什么好说的。
环境变了，
你以为 PHP 还是嵌入 html 中用，
其实已经经历过我前面提到过的 cake,zend,yii,laravel 多个时代了，
现在即将进入云原生时代了，
你期望 PHP 什么都能解决，
我只期望它做好 Web 即可，
至少现在开发一个人人商城，微擎这样的软件，我找不到更好的语言，
至于其他，至少我还会 Python,node,go,还在学习 C++和 C#，哪个适合我就用哪个，有什么好纠结的。



建议先看完官方手册，以及下载官方推荐的几个开源项目下来用用，然后自己动手写一个商业项目，想想这个框架适合场景，再来评价框架好坏更好。
当然还需要看下软件工程，软件思想的书籍。
知道你想骗我，想多从我这里掏点东西，自己快速学走捷径，先满足你吧。
然后有一天你会明白“欲速则不达”的道理。

结构应该表意，这是写代码基本规范，应该尽量遵守。

users:null vs users:[] 通常后者能明确告诉我们这是一个空的 User 列表
user:{} vs user:null 通常后者表示这个用户不存在而不是这用户存在但是属性为空
user: {id:''} vs user:{id:null} 区别是一个表示 id 为空字符串，一个表示 id 没有设置
user:{orders:[]} vs user:{orders:null} 当然选前者
book:{author:null} vs book:{author:''} 当然选前者
book:{author_name:null} vs book:{author_name:''} 应该还是选前者表示作者名未设置而不是被设置未空字符串，但是这条动态类型语言比较难办，那么可以商量来。

以上可以衍生到数据库设计上。

如果以上很难办，
通常是因为缺少一个合适的框架，
比如 django rest 和 yii rest 只需要数据库设计合理通常就没这些问题。

作为一个从 cake,ci,kahana,zf,yaf,yii1,yii2...一路用过来的人来说，每次接触一个新的流行框架，都学习了一种新的解决问题的办法，每一种框架的流行都是有其道理的，他的道理就是他迎合和解决了那个时段的主要问题。
至少我用起来，写的代码是越来越安全了，团队效率是越来越高了，而不是越来越低了，代码性能定位越来越容易了，而不是性能问题越来越突出了。

@dvaknheo

这东西怎么来的。 一两个特例马上能教人懂，多了没法马上会啊。
Yii 定位是 advanced 框架，强调是安全、可配置、可扩展、性能可见。不是 ci，cake 等脚手架、helper 类之类的框架。

View 里不能做任何计算，不能 include 非 View 的代码。
可以啊，你看的是伪 demo 吧随便找一个，既然是 PHP 文件，不能计算，你是来搞笑的吗？ https://github.com/yiisoft/yii-demo/blob/master/views/contact/form.php
，
当然可以 include，但是你得搞对路径啊，但是建议采用$this->render 替代。

Laravel 优雅的带着 PHP 优雅的 Java 化。当初 PHP 上手就干的年代，这是 PHP 的优势。
上手就干是 4.3 以前的优势，后来的主要优势是社区、开源项目、官方库。


现在一堆代码，业务相关的没几行，这还是 PHP 么。
因为已经不需要写这么多业务代码了，你配置好 rule 之后，自动驾驶了，自动驾驶你不应该关心是否有方向盘，而应该是自动驾驶是否可靠。

ORM 就非用不可么，Data struct 不容易理解么
有 Yii::$app->db->createCommand 和 Query 任你调用

有好用的文件路由不用，非得手写路由 (src/Factory/AppRouterFactory.php)
route 不用任何配置都可以跑的，你用的是官方 demo 么？


配置文件里一堆 use (config/web.php)
是的，这次改版最大的变化之一了。
为了遵守 psr 规范，让各大框架组件能够通用目标，牺牲小我为大我。。牺牲精神值得赞扬，但是我也觉得太多了，其实以前是隐藏的，现在变得开放出来的。也可以理解框架为了变得通用，不得不做各种抽象，比如缓存，日志，数据库为了兼容各种方案，不得采用各种适配器。如果你自己写一个框架，不用兼容那么多场景，那么这块确实是可以简化的（笑）。

MVC 缺层都是大家的共识了， 业务逻辑层叫 Service 或 Logic 我都无所谓，但直接 Controller 里调用 ORM，以前 10k 行的 Controller 啊。 从 Controller 里把业务逻辑剥离出来，跑命令行测试不好么。
和 Yii2 无本质区别，加了类型的 PHP 。。。作者 samdark 以前是搞 JAVA 的？或者指使代码写多了，记性不好了，加了类型便于 IDE 方法提示，如果你记性一致很好，那么可以不要这个类型提示，代码一样可以跑的。
至于你说的 Service 和 Logic 有什么必要吗？参考我上一个回复


PHP 开发速度很快，运行速度也很快。 没必要为了那些优雅牺牲开发速度，运行速度。
开发速度，得看工具和生态，Yii 有 gii，有各种数据服务器端，客户端验证，各种第三方库。
运行速度，性能优化得看性价比、定位速度和解决方案，Yii 等框架提供了 debug，性能问题一目了然。我在一台 4 核 8G 得 CPU 也可以跑一年几亿得交易额，我觉得性能非常好了，如果再发展，我是能花钱可以添加一点机器资源的。Yii 的四层 cache 设计方案，可以让你控制缓存在页面，局部 HTML，数据，请求级别。


讲真，我动力再足一点，写个同功能的 插进这些框架的 demo 中， 让大家见识一下应该用什么样的手段最符合 PHP 的快速开发模式。
我倒觉得是时候去框架了，不过我认为值得尝试解决方案是云函数+UI 仓库+项目仓库，看看国内大厂和国外新兴就知道，越来越向 low code 发展了，但是 low code 的基础是大量成熟的解决方案，所以我认为当前符合 PHP 的快速开发模式就是一套成熟的云原生的框架加各种 demo 。其他的话我并不看好。

@zjsxwc

symfony 确实是标杆，甚至比以前 zf 做得更好，值得尊敬。目前在 PHP 界都在向 psr 靠拢。

@HiCode

1 、PHP 从一开始流行就是因为适合小型项目，开发效率及运行效率都不错；

同楼上的回复，这是 4.3 以前的优势，后来的主要优势是社区、开源项目、官方库

2 、PHP 大流行后，部分有追求的程序员希望给 PHP 加一点 B 格，开始用各种模式要求 PHP，让 PHP 往 Java 方向发展。但 PHP 是脚本语言，Java 不是，Java 本身有足够的性能可以支撑起各种设计模式的性能损耗（但还是经常被吐槽太重太慢）——而 PHP 并没有这个性能来支撑。

PHP 为什么性能不好，知道吗？
解决性能问题首先要做是定位，通常说 PHP 性能不好的，不能常驻内存导致的吧，至少我还没有发现其他 PHP 性能不好的地方，至少我觉得够用了，举一个其他例子？
常驻内存可以用 swoole 之类的解决下，当然也没必要仅限于用 PHP 开发。


3 、各类设计模式在 PHP 项目中的普及，确实提高了效率，增强了一丢丢的团队协作，但开发的复杂性和性能的损耗却让 PHP 失去了他最开始的拥趸。

PHPer 也可以学习的，而且以前的方式还是可以用啊，为什么大家都愿意用了呢？因为以前的方式已经发展到头了啊，满足需求了啊，新的方式适用新的方向。

4 、为了追求性能和模式，所谓高手们抛下了 PHP 改用 go 、java 、c#，留下一个所谓“优雅”的 PHP 开发氛围。

高手们抛弃 PHP 采用 GO，
不是因为性能和模式。
而是环境，
环境变化了，
恐龙就不能生存了，
云计算、大数据的环境来了，
人类为了掌握周边环境降低风险，
天生就会自动去觉察掌握学习周边环境便于生存，
go 和 PHP 方向还是不一样的，
如果你用 go 去开发一个电商网站，
比如人人商城这类的这时候你会觉得还是 PHP 好，
如果你去开发一个 FQ 工具或者爬虫或者即时通讯服务端，无疑 GO 跨平台编译，协程让你飞起来。
如果我们学习后不能思考工具的适用场景，那么就不是真学了，这也是码农和架构师的却别吧，码农拿着锤子都是钉子，架构师所有工具都能恰如其分的使用。

一般不用写 sql 了吧，复杂查询用 orm 自动关联出来。

如果需要对一些操作进行封装，比如对多个批量操作采用事务，可以写在 model，便于复用。

其实不用太在乎写在哪里，而应该在乎是否好用好用，便于用即可，实际写写看。

比如用户充值，需要修改余额和生成充值记录，那么直接用$user->recharge($money)我觉得是比较方便和复用的，那么对我来说就是适合的，
因为如果写在控制器里面，那么不能复用，
如果单独抽取 service 层，你用的时候就得 UserService::Recharge($user_id,$money)，UserService 里面你得再次实例化 User，当然你也可以直接传$user 进去，但是我懒。
代码怎么简单明了够用就怎么写吧，大部分时候代码行数越少就越容易维护。

淘宝几十一个吧

基本是无解的：
1，count 本来就慢，无解；
2，采用>,<限制查询范围，如果需要精准就无解；
3，采用按时间分区表，也许有用，试试看，估计效果不会很明显，写入性能下降；

所以如果能业务限制采用 2，如果机器资源没有限制采用 3，如果需要实时 count 则需要采用缓存小范围 count

"一个人住 120 平米的房子，60 寸的电视，顶配台式机、NAS 看剧，撸狗、楼下就是菜市场每天做好吃的给自己吃，跑步打球健身，周末带父母去附近旅游。。。这么爽干嘛要结婚生孩子？"


不建议去。

东部新一线城市有房有车 远大于 二线省会。

应该是因为缺乏目标，
找到什么事情，
是你愿意做一辈子的吧。

郑州？
为什么我一些朋友和同事，
老家郑州或者读书郑州，
都不打算再回去了，
因为空气差。。。。

nuc10i7 最新款 淘宝只需要 3300 多一点。