为何同一段C代码mingw32可编译但VS2019报C2440类型转换错误

这个报错既不是Visual Studio额外自定义的安全校验规则，也不是MinGW实现了什么特殊的自动类型转换，核心是两个编译器对语言标准的默认执行严格度、以及你当前使用的编译模式差异导致的：

• 先明确基础的语言标准规则：代码中书写的宽字符串字面量（比如L"administrator"这类带L前缀的字符串）类型为const wchar_t[N]（N为字符串长度加末尾空终止符的长度），退化为指针时的类型是const wchar_t*，对应Windows SDK定义的LPCWSTR类型；而报错信息里的LPWSTR是不带const限定的wchar_t*，指向可写内存块。按照C/C++标准要求，把带const限定的指针直接赋值给去掉const限定的指针属于非法类型转换——这种转换会允许代码通过非const指针修改只读的字符串字面量，运行时会直接触发内存访问异常。
• MinGW32底层使用GCC编译器，编译C代码时默认开启宽松兼容模式，不会严格执行const限定符校验规则：这类const到非const的指针隐式转换默认不会被判定为编译错误，最多在开启高等级警告选项时给出提示，因此代码可以正常完成编译。
• 你在VS2019中编译的文件后缀为.cpp，IDE会自动将其识别为C代码，走C编译模式。C标准对const限定符的转换约束远严于C模式，MSVC编译器在C模式下会严格执行标准规则，直接将这种丢失const限定的转换判定为编译错误；哪怕你把文件后缀改为.c走纯C编译模式，高版本MSVC默认也会对这类不安全转换抛出高级别警告。

• 如果对应字符串在后续逻辑中不需要被修改，直接将接收赋值的LPWSTR类型变量改为LPCWSTR（即const wchar_t*）即可，这是最符合语言标准、无运行时隐患的修复方式。
• 如果后续逻辑确实需要修改该字符串内容，不要直接把字符串字面量赋值给可写指针，先申请一块可写的wchar_t内存块，将字面量内容拷贝到该内存块后再做后续操作。

不要用强制类型转换暴力去掉const限定来绕过编译报错，这种写法会留下严重的运行时隐患：字符串字面量存储在进程的只读内存段，强行写入会直接触发程序崩溃。

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