实现unique_unlock：std::unique_lock反向功能的实现方案咨询

• 未校验互斥量持有状态，直接触发未定义行为
  构造函数中直接调用m_.unlock()，如果传入的互斥量此时并没有被当前线程持有，std::mutex::unlock属于标准明确规定的未定义行为，可能引发死锁、程序崩溃、数据错乱等不可预期的问题。
• 未禁用拷贝/移动语义，存在重复操作风险
  编译器会默认生成该类的拷贝构造、拷贝赋值、移动构造、移动赋值函数，如果对象被拷贝/移动，会出现多个unique_unlock实例持有同一个互斥量引用的情况，析构时会多次调用lock()直接导致死锁；如果中间存在手动操作互斥量的逻辑，还会触发更多未定义行为。建议补充删除拷贝/移动相关函数：

  unique_unlock(const unique_unlock&) = delete;
  unique_unlock& operator=(const unique_unlock&) = delete;
  unique_unlock(unique_unlock&&) = delete;
  unique_unlock& operator=(unique_unlock&&) = delete;
  

• 析构函数调用lock()存在异常终止风险
  C++析构函数默认带有noexcept属性，而std::mutex::lock()在操作失败（比如互斥量已被销毁、系统资源不足等场景）时会抛出异常，一旦析构阶段触发异常，会直接调用std::terminate强制终止程序。
• 和标准库锁守卫状态不同步
  如果用户是通过std::unique_lock/std::lock_guard这类标准库锁守卫持有互斥量，直接把互斥量传入unique_unlock操作会导致标准库守卫的内部持有状态和实际互斥量状态不一致，标准库守卫析构时会再次调用unlock()，触发未定义行为。
• 不支持状态查询与手动提前控制
  没有提供类似owns_lock、提前重锁这类接口，无法提前结束临时解锁的状态，也无法判断当前实例是否正在控制互斥量的解锁状态，使用灵活度极低，边界场景很容易出错。

内容的提问来源于stack exchange，提问作者shoosh