不该。构造函数应仅负责对象定义而非执行初始化，避免副作用-heavy操作如数据库连接；参数加工易致重复赋值，宜用工厂方法或setter；子类重写构造函数必须调用父类构造函数，否则丢失关键初始化。
不该。构造函数里做太多初始化，轻则拖慢对象创建速度，重则引发依赖循环、异常难以捕获、测试不可控等问题。
__construct() 里执行数据库连接或 HTTP 请求会怎样
这类操作属于「副作用-heavy」行为，直接放在 __construct() 中会导致：对象无法被安全地实例化（比如配置未加载完就 new）、单元测试必须 mock 全链路、错误堆栈难以定位（异常发生在 new 的那一刻，而非业务调用点）。更隐蔽的问题是：如果多个类在构造时都连 DB，而 DB 连接池已满，整个服务启动就会卡死或超时。
常见错误现象：Fatal error: Uncaught mysqli_sql_exception: No such file or directory 出现在 new Database() 行，但真实原因是环境变量没注入，而这个错误掩盖了更上游的配置加载失败。
实操建议：
- 把连接逻辑拆到独立方法（如
connect()或ensureConnection()），首次调用时懒加载 - 用依赖注入容器管理连接对象，而不是让类自己创建
- 若必须在构造时检查可用性，只做轻量探测（如
extension_loaded('mysqli')），不做实际连接
PHP 8.0+ 属性提升后，还能不能在 __construct() 里加工参数
能，但容易重复赋值。比如用了构造器属性提升声明 public function __construct(public string $name)，又在函数体里写 $this->name = trim($this->name); —— 这属于对同一属性两次赋值，既无必要，也干扰静态分析工具对数据流的判断。
使用场景：你确实需要标准化输入（如大小写、截断、过滤），但应优先考虑封装成独立方法或类型转换器，而不是塞进构造函数体。
实操建议：
- 属性提升 + 构造函数体为空，是最清晰的信号：该属性仅作接收和存储
- 若需加工，改用私有属性 + 显式 setter 或工厂方法，例如
User::fromRawInput($raw) - PHP 8.1+ 可结合
readonly属性与构造后不可变语义，此时再加工就是逻辑矛盾
子类重写 __construct() 却忘了调用 parent::__construct() 的后果
不是“可能出错”，而是“一定丢失父类关键初始化”。CodeIgniter 4、Laravel 的基控制器、甚至自定义的 ServiceBase 类，往往在父类 __construct() 中绑定容器、注册事件监听器、初始化日志实例 —— 这些不会自动继承。
常见错误现象：调用 $this->db->table() 报 Call to a member function table() on null，但 $this->db 是父类注入的属性，因父构造没执行而仍是 null。
实操建议：
- 只要父类有
__construct()，子类重写时第一行必须是parent::__construct(...) - 用 PHPStan 或 Psalm 配置规则检测「missing parent constructor call」
- 在父类构造函数开头加日志或断言（如
assert($this instanceof static)），便于快速发现漏调用
真正难处理的不是“要不要做”，而是“谁来负责做”——构造函数只该回答“我是什么”，不该回答“我要做什么”。初始化逻辑一旦跨过这个边界，后续的调试、替换、测试成本就会指数级上升。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
