VS2017编译Unicode代码遇C2664错误，VS2008正常，为何选ANSI函数？

我之前帮不少开发者排查过类似的问题，咱们一步步拆解这个问题：

编译错误的本质是编译器没有把PathFindExtension映射到宽字符版本PathFindExtensionW，反而默认选择了ANSI版本PathFindExtensionA，导致你传入的宽字符参数LPCOLESTR（本质是const WCHAR*）无法转换为ANSI类型LPCSTR，触发了C2664类型不匹配错误。

这里主要有两个关键差异：

1. 编译器类型检查与宏定义的严格性变化 #

• 在VS2008中，当你设置“Unicode字符集”时，会自动全局定义_UNICODE和UNICODE宏。此时PathFindExtension作为一个宏，会被自动展开为PathFindExtensionW（宽字符版本），而LPCOLESTR和PathFindExtensionW要求的参数类型LPCWSTR是完全等价的（都是const WCHAR*），所以编译毫无压力。
• VS2017对类型匹配的检查更严格，同时如果你的项目中_UNICODE宏没有被正确定义（比如某几个源文件单独设置了多字节字符集，或者代码里不小心写了#undef _UNICODE），PathFindExtension就会默认绑定到ANSI版本PathFindExtensionA，这时传入宽字符参数自然就报错了。

2. 头文件与链接依赖的隐性差异 #

VS2008可能默认帮你包含了shlwapi.h并链接了shlwapi.lib，但VS2017需要你显式配置这些依赖。如果shlwapi.h没有被正确引入，编译器找不到PathFindExtension的宏定义，就会直接把它当成ANSI版本的函数声明，同样会触发类型错误。

给你三个靠谱的解决方向：

• 方法1：确保_UNICODE宏全局生效
  右键项目 → 属性 → 配置属性 → C/C++ → 预处理器 → 预处理器定义，确认里面包含_UNICODE;UNICODE（注意用分号分隔），同时删掉_MBCS（多字节字符集的宏）。另外检查代码中有没有#undef _UNICODE这类取消宏定义的语句。

• 方法2：显式调用宽字符版本函数
  直接绕过宏的不确定性，手动调用PathFindExtensionW：

  WCHAR *szExtension = PathFindExtensionW(lpwszFileName);
  

  如果你坚持用TCHAR，确保_UNICODE宏正确定义后，TCHAR*会自动映射为WCHAR*，也能正常匹配。

• 方法3：补全头文件与链接依赖
  在代码顶部添加头文件引用：

  #include <shlwapi.h>
  

  同时链接shlwapi.lib——要么在代码里加#pragma comment(lib, "shlwapi.lib")，要么在项目属性 → 链接器 → 输入 → 附加依赖项中添加shlwapi.lib。

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