似乎std::string是位于的仅标头文件Community/VC/Tools/MSVC/?/include/xstring，所有生成的代码都应包含在构建目标中。
如果我是对的，Microsoft如何保证下一个Visual Studio版本不会更改xstring以及其std::string内部结构？
更新1：
我对此问题有很多反对意见，所以让我解释一下为什么我决定问这个问题。
我面临着奇怪的崩溃，而且我不明白为什么会这样。我使用最新的Qt 5.13.0（MSVC2017_x64），并且我使用Visual Studio 2017编译了一些外部库。所有库都已/MDd通过dumpbinutil 进行了检查。
当我尝试运行任何调用Qt库和的代码时std::string，我得到了错误的结果（并最终崩溃）。
这是一个非常简单的示例：
#include <QApplication.h>
int main(int argc, char** argv) {
QString s1("Test");
std::string s2 = s1.toStdString(); // here we have s2 variable with wrong internal structure
return 0;
}
我的想法是QtCore DLL库具有std::string与std::stringVisual Studio 2017 不兼容的内部结构。但是Qt是使用Visual Studio 2017创建的（可能与我当前的Visual Studio不同，因为有几个次要版本），所以我决定问一下它们是否兼容。
更新2：
问题出在_ITERATOR_DEBUG_LEVEL。看起来Qt是用2级编译的，而我所有的外部库和应用程序都是用0级编译的。
此选项影响许多C ++标准库类的内部结构，并带来此类副作用。因此，当我们进入内部toStdString()并创建时std::string，我们具有2级和一个内部结构。当我们在应用程序代码中时，我们具有0级和另一个内部结构。我们将具有一种内部结构的对象分配给具有另一种内部结构的对象。
无论如何，我现在对某些内部结构有了更好的了解。
Microsoft如何保证下一个Visual Studio版本不会更改xstring和std :: string内部结构？
因为他们做出保证还是不保证的决定。
例如，Visual Studio 2015到2019是二进制兼容的。
那是做出来的决定。如果您说的是正确的，结果就是该平台上的某些实现细节std::string被冻结。这对于图书馆来说并不罕见。libstdc ++ std::list::size多年来一直不符合C ++ 11，因为它们在不破坏二进制兼容性的情况下无法添加所需的成员变量。
In short, this is basically a project management decision, and if they ever change the header in a way that breaks things, they will tell you that binary compatibility has been broken and you need to rebuild and relink things accordingly.
As for your Qt issue, it does smell like a binary compatibility issue. But you say that both Qt and your application have been built in Visual Studio 2017 with /MDd, which would appear to rule that out. I would ask the Qt community for further help, possibly with slightly more information about your environment and about where you obtained Qt. Also ensure that you're using the version of Qt that's intended — perhaps there are multiple installations? Which one's on your include path?