上下文：

我知道自c++17到std::lock_guard到来之后，std::scoped_lock就被弃用了。

我也知道std::scoped_lock是首选，因为它可以处理多个互斥量，并且使用死锁避免算法的方式与std::lock相同。

在这里，我对只有一个互斥锁的情况很感兴趣，因此我们不必担心避免死锁。

我从this answer读到：

您可以考虑弃用std::lock_guard。 std::scoped_lock的单参数情况可以实现为专门化，因此您不必担心可能的性能问题。

问题：

我想知道这句话到底有多正确。

我的意思是，（通过标准）是否可以保证使用单个互斥锁std::scoped_lock是专用的，以消除由于避免死锁而造成的不必要的开销？

我的想法：

经过对该问题的调查，我从cppreference中发现了以下句子：

如果提供了多个互斥锁，则使用死锁避免算法，就像std::lock一样。

这可以让我们推断出否则不会发生这种情况（即，如果仅给出一个互斥锁）。
再次，这只是一个假设。

在这个c++ draft中，我没有看到关于这种专业化的任何明确提及。
我唯一的句子是：

当sizeof...(MutexTypes)为1时，提供的Mutex类型应满足 Cpp17BasicLockable 要求。否则，每种互斥锁类型均应满足 Cpp17Lockable 要求。

^{（重点是我的）}

我知道 BasicLockable 要求强制要求lock()和unlock()函数的存在，这些函数满足定义的here等条件。
另一方面， Lockable 要求假定为 BasicLockable 要求，并附加了一个try_lock()函数，该函数满足已定义的there等条件。

我知道要运行try_lock()使用的避免死锁算法，就需要std::lock函数。

根据上述c++草稿摘录中的内容，如果我们仅给try_lock()一个互斥量，则不需要std::scoped_lock函数。
这是否足以推断/考虑始终定义以上专业化（并且大概表现为std::lock_guard的行为）。
我会说是的，但是由于我从未见过任何明确提及，我想知道我是对的还是错过了什么？

编辑：

我刚刚注意到我错过了最重要的部分here，其中指出：

效果：用pm初始化tie(m...)。然后，如果sizeof...(MutexTypes)为0，则没有效果。否则，如果sizeof...(MutexTypes)为1，则m.lock()。 否则，lock(m...) 。

^{（重点是我的）}

回答我的询问时，std::lock仅在给定的互斥量不止一个时被调用。我应该在问这个问题之前就看过它。