语境：
我知道std::lock_guard自从c++17与std::scoped_lock.
我也知道这std::scoped_lock是首选，因为它可以处理多个互斥体并使用与死锁避免算法相同的方式std::lock。
我对我们只有一个互斥锁的情况感兴趣，因此我们不需要关心避免死锁。
我从这个答案中读到：
你可以考虑
std::lock_guard弃用。的单参数案例std::scoped_lock可以作为一种特化来实现，这样您就不必担心可能出现的性能问题。
问题：
我想知道这句话有多少是真的。
我的意思是，是否保证（按标准）使用单个互斥锁std::scoped_lock将被专门化，以便消除由于避免死锁处理而导致的任何不必要的开销？
我的想法：
在对该问题进行了一些调查后，我从cppreference中发现了以下句子：
如果给定了多个互斥锁，则使用死锁避免算法，就像 by 一样
std::lock。
这可以让我们推断出这样的事情不会发生（即如果只给出一个互斥锁）。
但再一次，这只是一个假设。
从这个c++ 草案中，我没有看到任何关于这种专业化的明确提及。
我得到的唯一一句话是：
当
sizeof...(MutexTypes)为1时，提供的Mutex类型应满足Cpp17BasicLockable要求。否则，每个互斥锁类型都应满足Cpp17Lockable要求。
（强调我的）
我知道BasicLockable要求要求存在满足此处定义的条件lock()的功能。
另一方面，Lockable要求假定BasicLockable要求，并添加了满足其中定义的条件的功能。unlock()try_lock()
我知道该try_lock()函数是运行std::lock.
从上面的c++草稿摘录中所述，try_lock()如果我们只给std::scoped_lock.
这是否足以推断/考虑始终定义上述专业化（并且可能表现得std::lock_guard如此）。
我会说是的，但由于我从未看到任何明确提及它，我想知道我是对的还是我错过了什么？
编辑：
我刚刚注意到我错过了这里最重要的部分：
效果
pm：用初始化tie(m...)。那么如果sizeof...(MutexTypes)是0，则没有影响。否则，如果sizeof...(MutexTypes)是1，那么m.lock()。否则，lock(m...)。
（强调我的）
std::lock只有当有多个给定的互斥体时才会调用它回答我的询问。我应该在问问题之前看到它...