用umi测试了一下，没有发现这种情况. 考虑是不是对query做了操作

我感觉继承 应该是向上查找个一个过程， 当我们需要访问一个类中的属性， 首先会看当前类有没有， 若没有就到它的父类中查询！ var_dump()打印一个子类的时候是可以看到父类的私有属性， 但是不能访问

我感觉继承 应该是向上查找个一个过程， 当我们需要访问一个类中的属性， 首先会看当前类有没有， 若没有就到它的父类中查询！ var_dump()打印一个子类的时候是可以看到父类的私有属性， 但是不能访问

我感觉继承 应该是向上查找个一个过程， 当我们需要访问一个类中的属性， 首先会看当前类有没有， 若没有就到它的父类中查询！ var_dump()打印一个子类的时候是可以看到父类的私有属性， 但是不能访问

必须明确：private, public和protected这几个关键字，和继承一毛钱的关系都没有。人家叫做“可见性（Visibility）”。基类不能控制自己的所有成员都被子类继承走，但可以约束某些被继承的的成员，对子类新增补的成员不可见。

依赖注入是面向对象编程里面用来解耦的设计模式. {代码...} 对比下过程式的写法: {代码...}

我对DI的观点一向是，与其说依赖注入，不如说是依赖管理，其实有些类似于composer、pip、maven这种更高一层管理应用与库之间的依赖工具，DI框架会带来这些好处（前提是好的DI框架）：

解耦、方便unit test，显式注入的比较方便管理、最蛋疼的是隐式注入、半天找不到源文件。 laravel的DI其实也就是Requests和services了。

{代码...} 这说明父类的私有变量已被子类继承

已解决，原因是未实现 SessionHandlerInterface::read() 导致刷新后 $_SESSION 被设置为空值，接着导致调用 write 后写入了这个空值。

对属性或方法的访问控制，是通过在前面添加关键字 public（公有），protected（受保护）或 private（私有）来实现的。被定义为公有的类成员可以在任何地方被访问。被定义为受保护的类成员则可以被其自身以及其子类和父类访问。被定义为私有的类成员则只能被其定义所...

运行上面的代码你就会发现，最初的时候属性未赋值前打印两个实例化的类的所有属性值，对比给属性赋值之后再次打印的两个类的属性值，我们会发现，其实sonClass并没有继承baseClass的private name属性，而对于类（sonClass）中未定义的属性（$name），php会默认自动创...

作为框架，因为不确定使用者和项目需求，所以其代码在保持特色的同时要考虑兼容，这也是为什么所有的DB封装在提供了Query builder的基础上依然支持 query, exec方法的原因。

假设硬删除，那某个人恶意建了删删了建（虽然相册总数做了限制），id 就会留下许多“空洞” 那有什么问题么? MySQL 的自增主键本来就只保证递增,不保证依次.