禁止在构造函数中启动定时器，因其易致内存泄漏、野指针和状态不一致；应延迟至对象完全就绪（如mounted、show后）再创建，并绑定生命周期自动清理。
定时器函数在构造函数中直接创建，是高风险操作——它极易导致内存泄漏、野指针调用和状态不一致，尤其在对象尚未完全初始化或可能提前销毁的场景下。
禁止在构造函数中启动未绑定生命周期的定时器
构造函数执行时，对象处于“半初始化”状态：虚函数表可能未就绪（C++），this 指针可能不可靠（Qt），或组件实例尚未挂载（前端框架）。此时若启动 setTimeout、setInterval 或 QTimer::singleShot，回调一旦触发，很可能访问到未初始化成员、已析构内存或已被卸载的上下文。
- ❌ 错误示例（JavaScript）：
constructor() { this.timer = setTimeout(() => this.update(), 1000); }
组件若在 1 秒内被销毁，this.update仍会执行，this已失效。 - ❌ 错误示例（Qt/C++）：
Worker::Worker() { QTimer::singleShot(500, this, &Worker::init); }
若Worker构造失败中途抛出异常，this不完整，信号槽连接却已注册，后续触发将崩溃。
避免闭包捕获不稳定的 this 或局部变量
构造函数中定义的 Lambda 或匿名函数，若捕获 this 或栈上变量，在定时器回调执行时，这些值可能已失效或被覆盖。
- Qt 中 Lambda 捕获
this后，若对象被delete，回调触发即野指针访问； - JavaScript 中构造函数内
const data = new BigObject(); setTimeout(() => console.log(data), 2000)，即使实例被回收，data仍被闭包强引用，无法释放； - 正确做法：延迟到对象完全就绪后再设置定时器（如 React 的
useEffect、Vue 的mounted、Qt 的QObject::connect在show()后）。
不支持自动清理的定时器必须显式解耦生命周期
原生定时器（setTimeout、QTimer 无父对象）不会随宿主对象销毁而自动清除。构造函数中创建，等于把清理责任“甩给调用方”，但调用方往往不知情或遗漏。
- ✅ Qt 推荐：将
QTimer*设为类成员，并在构造时指定this为父对象：timer_ = new QTimer(this);—— 父对象析构时自动 delete 子对象； - ✅ JavaScript 推荐：不存于构造函数，改用受控生命周期的封装，例如：
class SafeTimer { start(cb) { this.id = setTimeout(cb); } stop() { clearTimeout(this.id); } }，并在组件销毁钩子中调用stop()； - ⚠️ 禁止：在构造函数中调用
setInterval却不保存 ID，或保存了 ID 却未提供对应clearInterval接口。
构造异常时定时器残留引发资源泄漏
若构造函数内部抛出异常（如分配失败、配置校验不通过），已创建但未被管理的定时器对象不会自动销毁，成为“孤儿定时器”。
- C++ 中：用裸指针
new QTimer后异常抛出，delete语句未执行，内存与事件循环资源双重泄漏； - 解决方案：使用智能指针（
QScopedPointer<qtimer></qtimer>）或 RAII 封装，确保异常安全； - JavaScript 中虽无析构概念，但应避免在构造函数中做任何异步副作用，把副作用推迟到
init()或生命周期钩子中。
