这问题我之前排查过好几次，太懂这种找不到隐藏依赖的抓狂感了！C2872的歧义问题通常是因为rpcndr.h里的byte类型和你代码里（或者其他依赖库）的byte定义撞车了，先给你说怎么揪出这个隐藏的包含链，再给你解决歧义的办法：

• 用编译器预处理器输出追踪完整包含链
  不管你用VS还是其他编译器，都能让它输出预处理器展开后的完整文件。比如VS里，给你的源文件加/P编译选项：

  cl /P your_source_file.cpp
  

  编译后会生成一个.i后缀的文件，打开它搜索rpcndr.h，往上翻就能看到是哪个头文件直接或者间接把它引进来的——比如很可能是windows.h、objbase.h这类和COM/RPC相关的系统头文件，或者某个第三方库的头文件嵌套包含了它。

• 用IDE的“转到定义”逆向溯源
  如果你用Visual Studio，右键点击代码里报歧义的byte，选“转到定义”，IDE会列出所有匹配的定义，其中一个肯定来自rpcndr.h。然后在这个头文件的编辑界面，看顶部的“包含层次结构”（VS在右侧导航栏里有这个选项），就能一目了然看到从你的源文件到rpcndr.h的完整包含链。

• 检查项目设置与系统头文件默认行为
  有时候是项目的附加包含目录里的第三方库悄悄引了rpcndr.h，或者Windows SDK的某些头文件默认会包含它。你可以先检查自己的代码里有没有直接包含windows.h这类大而全的系统头文件，很多时候这类头文件会嵌套一堆子头文件，包括rpcndr.h。

• 显式指定命名空间
  如果你的代码用的是C++17的std::byte，或者自己定义的byte，直接加上命名空间前缀就能区分开。比如用std::byte代替裸的byte，或者如果是自定义的，加上你自己的命名空间。要是rpcndr.h里的byte属于某个命名空间（比如RPC），也可以显式写RPC::byte来调用它。

• 调整头文件包含顺序
  把你自己定义byte的头文件，或者依赖的第三方库头文件，放在系统头文件（比如windows.h）之前包含。编译器是按包含顺序解析类型的，优先解析的定义会覆盖后面的，这样就能避免歧义。

• 禁用不必要的系统头文件自动包含
  比如包含windows.h之前，定义RPC_NO_WINDOWS_H宏，这样windows.h就不会自动包含rpcndr.h了：

  #define RPC_NO_WINDOWS_H
  #include <windows.h>
  

  要是你不需要RPC相关的功能，这个方法特别有效，还能减少编译时间。

内容的提问来源于stack exchange，提问作者athos