Qt解决_mm_loadu_si64找不到标识符问题

0、版本更替的“惊喜”

原本岁月静好地沉浸在VS2015+Qt5.9的舒适圈里，直到某天想用C++17的酷炫功能时，才发现这组合像一台老式收音机——只能播放经典老歌。于是怒装VS2022+Qt6.8，瞬间进入“量子计算”时代。

万万没想到，回头维护老项目时，Qt Creator一脸无辜地表示：“亲，您的古董代码和新时代编译器之间，大概隔了一个银河系的距离呢~”编译失败的红字，仿佛在嘲笑人类对技术进步的盲目乐观。

1、bug出现

写代码就像在拆炸弹——剪对了线岁月静好，剪错了线直接升天。

你刚按下保存键，优雅地合上IDE，仿佛一位完成交响乐的大师。第二天打开项目，编译器却突然发疯：“找不到标识符”_mm_loadu_si64，还贴心地附赠32连击报错大礼包。屏幕上赫然显示：

C:\Program Files (x86)\Windows Kits\10\Include\10.0.26100.0\ucrt\wchar.h:313: error: C3861: “_mm_loadu_si64”: 找不到标识符

晕，真是人在家中坐，bug天上来。此刻的心情：

• 我的代码昨天还是乖宝宝，今天怎么就变异了？
• 我连"wchar.h"长啥样都不知道，锅却精准空投到头上
• 怀疑人生三连：我动了啥？系统抽啥风？宇宙规律是不是崩了？

2、分析原因

1. 首先，我的代码在linux虚拟机中编译正常，可以排除自身修改代码的原因；
2. 其他项目代码通过我最新的Qt环境是可以编译成功的，说明新版本Qt是没问题的；
3. 这个地方报了一个Windows SDK的头文件，会不会是因为之前新装了VS2022，导致SDK的环境变量也跟着一起升级了？

按照这个思路，我顺藤摸瓜，果然发现Windows下SDK是有多个的（此处建议大家可以对比之前的编译记录或者配置）：

所以真相就是，当前使用的SDK比较新，老版本Qt无法支持，或者是需要适配环境变量才能正常支持。
但是呢，我这个项目又是老项目，不想因为这一个影响了本地全局环境，于是我采用修改pro文件的方式适配修改。

3、解决方案

在.pro文件中进行修改：

QMAKE_INCDIR += "C:/Program Files (x86)/Windows Kits/10/Include/10.0.10240.0/ucrt" \"C:/Program Files (x86)/Windows Kits/10/Include/10.0.10240.0/um" \"C:/Program Files (x86)/Windows Kits/10/Include/10.0.10240.0/shared"QMAKE_LIBDIR += "C:/Program Files (x86)/Windows Kits/10/Lib/10.0.10240.0/ucrt/x64" \"C:/Program Files (x86)/Windows Kits/10/Lib/10.0.10240.0/um/x64"

当然可以根据实际需要进行配置部署，因为我只是为了本地windows调试编译debug，所以就直接用wins宏进行隔离；

问题成功解决！