★ FEATURED ARTICLE 1. 为什么你的VS里总是报“CRT_SECURE_NO_WARNINGS”这个错用微软系编译器Visual Studio、VS Code搭配MSVC工具链写C/C程序的人几乎都见过这行报错error C4996: scanf: This function or variable may be unsafe. Consider using scanf_s instead.第一次遇到的人往往一脸懵scanf不是标准库函数吗怎么就不安全了我又没写什么危险代码编译器凭什么拦我这个提示的本质是微软对标准C库函数的“安全策略”在Windows平台上像scanf、strcpy、strcat、fopen这批老牌函数存在缓冲区溢出或被恶意利用的风险微软默认把它们标记为“弃用”编译时直接抛C4996警告甚至直接中断编译。而对应的“安全版本”scanf_s、strcpy_s等是微软自己定义的扩展并不属于C标准。所以你在Linux上用GCC编译同一段代码完全不会碰到这个报错。解决这个问题最常见、最省事的方法就是在源文件顶部加一行宏定义#define _CRT_SECURE_NO_WARNINGS 1加完之后世界清净了。今天这篇就专门聊聊这个方法为什么加这一行就有效、加在什么位置、有没有副作用、对应生产环境下的更优解法是什么。2. 这个宏到底做了什么为什么能压制C49962.1 预处理指令的生效时机要理解这个宏先得弄明白编译的四个阶段预处理、编译、汇编、链接。#define属于预处理指令在真正的编译开始之前就处理完毕。_CRT_SECURE_NO_WARNINGS是一个“预定义标识符”当编译器在编译头文件时看到这个标识符存在就知道“用户主动放弃了安全警告”于是不再令C4996生效。可以这样理解微软在它的标准库头文件里写了大段类似这样的逻辑#ifdef _CRT_SECURE_NO_WARNINGS #define scanf scanf #else #pragma message(This function may be unsafe) #endif实际源码更复杂但思路一致。这个宏不是“关闭某一行代码”而是改变了MSVC对“弃用函数”的检查开关。2.2 为什么后面要写“1”很多人只写#define _CRT_SECURE_NO_WARNINGS不写后面的1其实也有效。这个1不是必须的但写上有好处当宏被当作条件表达式使用时1代表“真”语义更明确。微软本身也没规定值必须是1只要宏被定义了就行。不过项目里既有#define又有#undef的时候显式的1能避免一些工具链的静态分析误判。2.3 位置差一点效果差很多这个宏必须放在所有头文件包含之前否则无效。为什么因为头文件里的条件判断发生在头文件被解析时如果你的代码是这样#include stdio.h #define _CRT_SECURE_NO_WARNINGS 1那么stdio.h在被包含的瞬间_CRT_SECURE_NO_WARNINGS还未定义等头文件解析完宏才被定义但那时候C4996的开关已经按“未定义”处理完了。所以正确的写法必须是#define _CRT_SECURE_NO_WARNINGS 1 #include stdio.h #include string.h当然如果你用的是预编译头stdafx.h或pch.h把宏放在预编译头的最顶部更省事因为每个源文件都会先包含预编译头。3. 设置这个宏的五种方法逐个说清楚3.1 方法一源文件顶部直接写这是最原始、最直观的方式。在每一个需要用到不安全函数的.c或.cpp文件的第一行写上#define _CRT_SECURE_NO_WARNINGS 1很短但问题也明显如果工程有几十个源文件每个文件都要加一遍漏掉一个就继续报错。而且以后想移除这个宏也得挨个找、挨个删。这个方法适合单个小程序、算法练习、刷题测试一个文件搞定一切的时候。3.2 方法二项目属性里全局设置在Visual Studio中可以这样操作右键项目名选择“属性”。左侧选择“C/C” - “预处理器”。右侧“预处理器定义”一栏点下拉箭头选择“编辑”。添加_CRT_SECURE_NO_WARNINGS注意这里不用写#define也不用写1直接写宏名。整行内容用分号分隔比如_CRT_SECURE_NO_WARNINGS;WIN32;_DEBUG。确定保存后整个项目的所有源文件都生效。这个方法的核心好处是“一处配置全局生效”不用改任何代码。缺点是把“代码层面的选择”藏到了工程配置里换一台电脑、换一个工具链配置跟着工程文件走还好如果代码丢到Linux上用Makefile编译这个设置就丢失了。3.3 方法三新建一个头文件统一包含如果你仍想从代码层面管理但不想每个源文件都写一行可以自建一个头文件比如叫common.h内容如下#ifndef COMMON_H #define COMMON_H #define _CRT_SECURE_NO_WARNINGS 1 #endif然后每个源文件第一行包含它#include common.h这比在每个文件里写#define多一些隔离性。将来想改宏开关只需要改common.h一处。如果项目中原本就有统一的基础头文件直接把宏加进去即可。3.4 方法四编译器命令行参数如果你在命令行下编译例如cl /D _CRT_SECURE_NO_WARNINGS main.c或者用CMake在CMakeLists.txt中add_compile_options(/D _CRT_SECURE_NO_WARNINGS)这种方法适合自动化构建不污染源码。在CI/CD流水线里用命令行参数控制要比改代码安全得多因为代码是共享的而构建参数是按环境区分的。3.5 方法五使用#pragma warning替代宏宏控制的是_CRT_SECURE_NO_WARNINGS这个标识符但如果你只想临时压掉某个特定的警告可以用#pragma warning#pragma warning(disable:4996)或者只针对某个函数#pragma warning(push) #pragma warning(disable:4996) scanf(%d, a); #pragma warning(pop)这种方法的优点是范围可控避免“全局关闭警告”带来的隐患。缺点是代码变啰嗦而且每次处理一个警告都要写三行。对于项目里已经明确抛弃不安全函数、只偶尔兼容旧代码的情况这个方法反而更合适。4. 手把手实操从新建项目到编译通过完整走一遍流程以Visual Studio 2022为例写一个最经典的示例——用scanf读取用户输入并打印。4.1 新建一个空控制台项目打开VS选择“创建新项目” - “控制台应用” - 项目名称任意比如DemoConsole。创建完成后会自动生成一个包含main函数的源文件。4.2 尝试编译看到C4996把main.cpp内容改成#include stdio.h int main() { int number 0; printf(Enter a number: ); scanf(%d, number); printf(You entered: %d\n, number); return 0; }按下CtrlF5运行或者直接CtrlB编译。输出窗口会出现error C4996: scanf: This function or variable may be unsafe...有些VS版本的配置可能只是警告不会中断编译但很多课程作业、刷题环境会把“警告视为错误”/WX于是直接无法生成。4.3 添加宏定义验证效果在#include stdio.h上面加一行#define _CRT_SECURE_NO_WARNINGS 1再重新编译C4996消失程序正常输出。这就是最核心的“方法”本身。4.4 用属性面板设置避免改代码如果你不想在代码里加宏回到C4996报错的状态然后按3.2节的方法在项目属性的“预处理器定义”中加上_CRT_SECURE_NO_WARNINGS重新编译效果一样代码保持干净。4.5 命令行编译时的完整示例如果你装了VS的开发者命令行工具可以这样验证cl /WX /D _CRT_SECURE_NO_WARNINGS main.c其中/WX表示把警告当错误。如果去掉/D _CRT_SECURE_NO_WARNINGS编译必定失败加上后编译通过。这个对比测试能让你直观感受到宏的威力。5. 这个宏不是银弹误用会有什么坑5.1 掩盖问题而不是解决问题_CRT_SECURE_NO_WARNINGS只是让编译器闭嘴并没有让代码变安全。scanf(%s, buf)该溢出还是会溢出strcpy该越界还是会越界。把警告压下去就等于把风险压到了运行时调试难度陡增。举个例子早期某项目里大量使用了strcpy大家为了省事全都加了_CRT_SECURE_NO_WARNINGS。直到某天线上环境发现偶发性的内存内容被篡改排查了好久最后定位到一句strcpy(dest, src)其中dest分配了16字节实际拷入了32字节直接把相邻的内存区域覆盖了。这类问题在加宏后依然存在只是平时不被提醒。所以正确的心态是这个宏是开发期的免打扰工具不是生产环境的安全背书。5.2 项目迁移到Linux/跨平台时的编译差异_CRT_SECURE_NO_WARNINGS是微软平台特有的GCC和Clang上根本没这个宏也不认识它。它们的警告体系不同不靠这个宏控制。所以把代码迁到Linux后源文件里多出来的这一行会被当作普通宏定义不影响编译但也不起任何作用。GCC会用-Wformat-truncation、-Wstringop-overflow等更细粒度的选项来提示危险用法。跨平台项目里更合适的做法是封装一层“安全输入/复制”函数或者在构建系统里区分平台参数而不是依赖这一个宏。5.3 和预编译头配合时的顺序问题如果你用stdafx.h老项目或pch.h新项目宏必须放在这个预编译头的最顶部。很多新手把宏写在某个.cpp文件里而.cpp文件的第一行是#include pch.h预编译头先被解析宏定义在预编译头之后才出现结果还是不生效甚至编译器会提示“必须放在预编译头之前”。最稳妥的做法是打开pch.h第一行就是#define _CRT_SECURE_NO_WARNINGS 1然后再包含其他标准库头。5.4 静态分析工具会“以你为敌”像VS自带的代码分析器、Clang-Tidy这类工具即使编译通过也会在静态分析结果里报告“使用了不安全函数”。宏只影响编译器不等于影响分析器。如果团队把静态分析结果作为质量门禁这个宏拦不住门禁失败。6. 什么时候不该用这个宏替代方案盘点6.1 使用微软的“安全函数”版本既然微软提供了scanf_s、strcpy_s、fopen_s其实更符合其设计意图的是改用这些函数。例如char buf[20]; scanf_s(%s, buf, (unsigned)sizeof(buf));scanf_s要求显式传递缓冲区大小编译器和运行时都会做校验。缺点是这些函数不是C标准跨界到Linux时又得写一层封装。如果项目长期锁定Windows平台迁移成本可接受那用安全版本远比压警告靠谱。6.2 用标准C11的边界检查接口C11标准里其实引入了scanf_s等带_s后缀的“边界检查”函数只是一直标为“可选”。微软的实现符合C11 Annex K的精神但和其他编译器不完全兼容。所以如果追求标准合规这条路还得等生态完善。6.3 用fgets替代scanf对于“读取输入”的场景最推荐的跨平台方案是用fgets或getline。比如#include stdio.h int main() { char line[64]; int number 0; if (fgets(line, sizeof(line), stdin) ! NULL) { number atoi(line); } printf(You entered: %d\n, number); return 0; }这样既不用scanf也不涉及缓冲溢出GCC和MSVC都不报警告。6.4 用C的流操作如果项目是C最干净的做法是#include iostream int main() { int number; std::cin number; std::cout You entered: number std::endl; return 0; }C的iostream没有同样性质的C4996警告。这也是为什么很多教学代码用C但实际是C编译器编译时才会碰到这个报错——纯C编译器如GCC不报C4996只有MSVC这么干。7. 我自己在实际项目里的做法用了几年之后我对这个宏的态度分成了两种情况。如果是在刷题、做Demo、写临时脚本我直接第一行加上宏快速通过编译把时间花在逻辑上。这种场景下代码的生命周期以小时计不会进生产环境安全警告优先级让我觉得没必要过度纠结。如果是在正式项目我不会在源码里加这个宏而是走项目属性或CMake参数。因为正式项目会持续迭代我希望每次编译时编译器都能提醒我还有多少“旧代码”没迁移到安全模式。一旦加了宏这个提醒就消失了。我会把宏当作过渡措施先把项目的警告数量归零然后逐步在代码评审中把scanf换成fgets把strcpy换成memcpy_s或strncpy。迁移完一个模块就删掉一个源文件里的#define最后彻底移除。7.1 共享代码库的小技巧如果你的代码是团队成员共享的一定要在README或代码注释里写明为什么加这个宏。因为新手看到_CRT_SECURE_NO_WARNINGS很容易误解为“项目有安全问题被压下去了”进而产生恐慌。注明“仅用于Windows本地教学环境生产环境请勿照搬”能避免不少沟通成本。7.2 配合#pragma warning微调单文件里如果只有一种不安全函数我建议用#pragma warning局部禁用比如#pragma warning(push) #pragma warning(disable:4996) #include stdio.h #pragma warning(pop)这里的写法是从源头压制针对头文件的警告但依然不建议长期使用。通常做法是宏定义解决“全项目”的压制pragma解决“单点”的压制两者各司其职。7.3 一个常常被忽略的细节_CRT_SECURE_NO_WARNINGS对C文件同样有效不是只能用在.c文件上。另外它不只是管scanf还管strcpy、strcat、sprintf、fopen、gets这些旧式函数。所以当你一次看到“n个C4996”时这一个宏能全部压掉。8. 快速排查清单加宏后还是报错怎么办有时候明明加了宏C4996还是冒出来常见原因有这么几种症状可能原因解决办法宏写在#include之后预处理顺序不对把#define移到所有#include之前宏写在pch.h但源文件先包含其他头预编译头顺序冲突检查项目是否启用了强制预编译头宏写在.c源文件但warning来自.cpp文件编译对象不匹配确认所有报错文件都加了宏或全局配置项目属性设置了/WX且宏未生效属性配置没应用到当前配置检查“活动解决方案配置”是Debug还是Release宏名拼写错误少了下划线或多了空格复制标准写法_CRT_SECURE_NO_WARNINGS使用了nginx或第三方库的旧代码源码被定义在系统目录用#pragma warning(disable:4996)包住include遇到宏设置正确但还报错的情况优先怀疑预编译头。我曾经帮人排查过一个项目源文件里明明有宏但预编译头管理混乱某些源文件没走预编译头宏的定义顺序还是不对。9. 从更长远的视角看待C4996警告C4996本身不是什么严重的语法错误它代表的是“平台厂商对旧代码的安全态度”。微软敢把标准库函数标为弃用是因为它有足够的影响力也因为它提供的替代方案基本覆盖了日常需求。这对开发者来说是一把双刃剑一方面安全感提升了另一方面“弃用”两个字意味着你写的代码不具备最佳跨平台性。我见过不少入职一两年的开发者在简历上写“精通C/C”但连这段警告的含义都解释不清楚。这种基础细节恰恰是区分“用过”和“理解”的试金石。每次遇到这个警告多花十秒想想它背后的库函数设计逻辑比单纯加一行宏然后忘掉要值得多。我个人现在的习惯是新建项目时尽量避开会导致C4996的函数维护旧项目时先用宏过渡再逐步替换。这个顺序既能保证效率又不至于让代码变成一堆压着警告的参数拼凑。核心原则很简单——编译器帮你发现问题你有权选择忽略但你得知道忽略的是什么、代价是什么。
阅读完成 · 觉得有帮助？
