我终于解开了这个有趣的谜题，所以我将回答我自己的问题。不过它让我有点抓狂，所以我想它可能会帮助一些程序员。

问题定义

我想做的似乎很简单：创建我自己的小部件，并将其集成到我自己的Qt Creator(在我的本地机器上运行的版本，与标准的Qt安装一起提供)中，这样我就可以自由使用它来设计我自己的界面，使用特定的GUI设计工具。

推广一个通用的QWidget就足够了，只是不太方便
我认为在GUI设计工具中看到小部件(而不是一个不可见的矩形)并有可能修改特定的属性(而不是必须以编程方式进行)会很好
不幸的是，这并没有像我希望的那样顺利。

我甚至不能对自己的编译器负责

使用：

• 一个全新格式化的系统上的原始Win 10，没有安装任何以前的编译器
• 标准安装程序下载的MSVC 2019的默认免费版本(桌面C++开发包、工具链v14.26、编译器v16.4)
• 默认的当前Qt v5.14.0(MinGW和MSVC2017目标)，由标准Qt安装程序下载

我最初天真地编译了x64的示例(时钟小部件)。什么也没发生。然后是x86。相同的结果或缺乏相同的结果
在尝试为MinGW编译它之前，我实际上意识到这在概念上是错误的
很明显，生成的DLL必须与实际Qt Creator的原生格式相匹配，所以makefile神奇地在当前Qt Creater二进制文件中添加插件的想法完全是垃圾
我放弃了一厢情愿的想法，开始手工将DLL的适当部分放在适当的位置。

那就是我永远误入歧途的地方

我很快就看到，Qt 5.14.0附带的Qt Creator可执行文件是在win32模式下使用MSVC2017编译的(这在"关于"窗口中有说明，尽管没有明确说明编译器和/或工具链的精确版本，只是这个相当不可靠的"MSVC2017"，它也用于指定实际的MSVC2019环境)。

示例项目中定义的路径导致了一些神秘的MSVC2017子树，但根本没有发生任何事情
将DLL放在那里没有效果。删除那些已经存在的也没有效果
很明显，我的Qt Creator版本从未使用过这些DLL。我不知道它们应该有什么用处，坦率地说，我一点也不在乎。这只是又一条寒冷的小路，浪费了我更多的时间。

查看Qt Creator的"关于插件…"窗口，我注意到那里列出的所有插件都位于<Qt install root>QtToolsQtCreatorlibqtcreatorplugins中(如单击"详细信息"按钮时打开的窗口中所述)。我错误地认为这是所有插件都应该去。然而，将标准示例(可爱的小时钟小部件)的结果放入这个目录根本没有任何作用。

然后我花了一整天的时间试图理解为什么在大火中这个该死的插件不会出现。

由于当前的MSVC集成有些古怪(Qt在使用二进制兼容的MSVC2019时仍然指MSVC2017)，我开始尝试使用v14.16 Microsoft工具链(最后一个使用MSVC2017的工具链可以与Web安装程序一起安装)。

我从来没有设法让这个该死的旧版本的工具链工作
坦率地说，这个Qt/VS集成是一个泥潭。它可以归结为调用这个可怕的"vcvarsall.bat"命令文件，该文件设置了一卡车神秘的环境变量。碰巧的是，vcvarsall.bat需要一个Qt无法传递的额外命令行参数(-vcvars_ver=14.16)(它认为编译器定义无效…真倒霉…)。
您仍然可以将调用包装到另一个批处理文件(@vcvarsall.bat %* -vcvars_ver=14.16)中，并将其提供给Qt编译器设置。但即使在那时，我也无法将血腥的东西带到编译中
我错过了include之类的东西。显然，IDE必须对任何文件位置做出一些其他假设，这些文件位置使其无法在"自动检测"的MSVC版本(即当前状态下的MSVC2019当前版本)之外工作。

在浪费了这么多痛苦的时间之后，我非常生气，所以我再次搜索了Qt论坛，并被无数(主要是Linux)关于路径和编译器选项的讨论弄得一团糟。浪费了更多的时间。事实上，很多时间。

在最后一次绝望的尝试中，我使用了漂亮的进程资源管理器(没错，监视可执行文件打开的所有资源)来定位我运行的Qt Creator副本所使用的DLL。这时我终于找到了go[beep]mn目录。

从那时起，一切确实很顺利。只要编译你的小DLL并将其放在正确的位置，Bob就会成为你的叔叔。