__construct和__destruct是php类生命周期的关键钩子：前者用于强制初始化、资源预加载及参数校验，后者是释放系统资源的最后机会，但不保证执行；二者需协同设计以防资源泄漏或状态错乱。
PHP 的 __construct 和 __destruct 不是“要学的语法点”，而是你写类时几乎必然要面对的生命周期钩子——用错时机或忽略细节，轻则资源泄漏，重则对象状态错乱。
什么时候必须写 __construct
不是“想初始化就写”，而是当类依赖外部输入、需要提前准备资源、或必须阻止无参实例化时才需要它。
- 需要强制传参：比如
new Database($host, $port)，不写__construct就没法校验或赋值 - 要提前打开文件/连接数据库：这些操作不能拖到第一次调用方法时才做，否则容易漏处理失败路径
- 父类构造函数有参数，子类又没显式定义
__construct→ 父类逻辑直接被跳过（PHP 不会自动代理） - 注意：PHP 8.0+ 中，如果只定义了
__construct但没声明参数类型或默认值，而调用时传了null或类型不符，会直接报Fatal error，不是 Warning
示例：
class Logger {
private $file;
public function __construct(string $path) {
$this->file = fopen($path, 'a');
if (!$this->file) {
throw new RuntimeException("Cannot open log file: $path");
}
}
}
__destruct 不是“清理收尾”，而是“最后的机会”
它不保证一定会执行（比如 exit()、致命错误、Apache 进程被 kill），更不保证执行顺序——多个对象互相引用时，析构顺序不可预测。
- 别在里面做耗时操作：它运行在脚本结束前，阻塞整个请求退出
- 不能依赖 $this->xxx 还有效：PHP 在析构期间可能已开始释放属性，访问未初始化或已被 unset 的属性会触发 Notice
- 数据库连接、文件句柄这类系统资源，必须在这里
fclose()/mysqli_close()，否则可能撑爆连接池上限 - 别试图在
__destruct里抛异常：PHP 会转成Fatal error，且无法被捕获
示例：
public function __destruct() {
if (is_resource($this->file)) {
fclose($this->file); // 必须判空，否则 fclose(null) 报 Warning
}
}
两个方法一起用时最常踩的坑
它们不是独立模块，而是一对生命周期开关——中间任何环节出问题，都会让 __destruct 变得不可靠。
- 构造函数里抛异常 → 对象没创建成功 →
__destruct根本不会触发（这点和 C++ 不同） - 构造函数里开了资源但没做 try/catch，异常一抛，资源就泄露了（
__destruct压根没机会跑） - 把数据库连接存在属性里，但连接对象本身也带
__destruct（比如 PDO），双重关闭可能报错 - CLI 模式下，
__destruct在脚本退出时才触发；Web 模式下，响应发完就可能触发——别假设它总在“响应后”执行
真正难的不是写这两个方法，而是判断“哪些事必须放进去”和“哪些事其实该交给调用方负责”。比如日志刷盘、事务回滚、缓存失效——这些逻辑是否真的属于对象自身生命周期，还是应该由业务层显式控制，得看具体场景。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
