企业官网建设流程全解析

如果你刚装好VS2022，兴冲冲想敲出人生第一个C语言程序，大概率会遇到一个让人心里咯噔一下的场景：Hello World老老实实打印出来了，结果一旦用到scanf，编译器立刻翻脸，甩出一行红色波浪线和一条报错——“'scanf': This function or variable may be unsafe. Consider using scanf_s instead.”很多新手在这一步就被劝退了，以为是自己写错了、VS装坏了，甚至怀疑C语言这门课是不是该换个工具学。其实不是，这只是VS2022默认开启的安全检查在跟你较劲。

这篇文章就是来帮你把这道坎彻底迈过去的。我会从零开始，带你走一遍VS2022下真正的C语言起步流程：环境怎么装、工程怎么建、Hello World每一行到底在干嘛、scanf为什么被针对、以及三种最实用的解决办法。后面还附带了我自己带学生、带同事时总结的输入缓冲区排查经验，属于那种“教材里不写、但考试和作业天天考”的东西。适合C语言零基础、刚用VS2022、以及被C4996警告折腾到怀疑人生的朋友。

1. 初装VS2022时被忽视的两个环节：工作负载与工程模板

1.1 安装时没勾选“使用C++的桌面开发”，等于白装一半

很多朋友下载VS2022之后，安装界面一路默认就点“安装”，装完打开软件发现：新建项目里找不到C++相关的任何模板，或者能打开却写不了C语言代码。这个问题的根源基本都出在安装时漏掉了工作负载。

VS2022的安装机制不像以前老VC6那样装完就有完整的编译工具链，它把很多功能拆成了“工作负载”让你按需勾选。对写C语言的人来说，必须勾选的核心选项叫**“使用C++的桌面开发”**。别被这个“C++”三个字骗了，这个工作负载里内置的MSVC编译器和相关工具链，既能编译C++，也完全支持编译标准C语言。C语言和C++在编译阶段使用同一套底层工具，所以你学C语言时写出来的代码，实际上就是靠这套C++工具链来编译的。

如果你已经装完了VS2022但没勾这一项，也不必卸载重装。打开Visual Studio Installer，找到已安装的VS2022版本，点“修改”，把“使用C++的桌面开发”勾上，点右下角的“修改”按钮等它装完就行。这个过程需要联网，而且下载体积不算小，耐心等待即可。

还有一个容易忽略的细节：vs_installer.exe的安装界面里，右侧还有一个“安装位置”标签页，里面有个“单个组件”的入口，很多教程会让新手去搜索单独安装某个SDK组件。其实完全不用，就用默认的“使用C++的桌面开发”这一项就能覆盖99%的C语言学习需求，千万不要自己手动去组合安装组件，容易漏掉关键的MSVC编译器版本。

1.2 新建项目：选“空项目”还是“控制台应用”，结果差很多

装好环境之后，打开VS2022，选择“创建新项目”。你可能在模板列表里看到一堆似懂非懂的名字，最让新手纠结的是这两个：空项目和控制台应用。

先说结论：学习C语言，推荐选空项目，手动添加源文件。虽然控制台应用模板能一键生成一个“Hello World”，但它默认生成的是C++风格的源码，而且自动挂了一堆预编译头文件机制（就是那个pch.h），对学纯C语言的新手来说，这些额外的机制更像干扰项，让你分不清哪些是语言本身的语法、哪些是IDE帮你搭的脚手架。

空项目则干净得多。新建完成后，你在“解决方案资源管理器”里看到的是一个什么都没有的工程，这时候需要右键“源文件”文件夹，选择“添加”→“新建项”，在弹窗里选“C++文件(.cpp)”——这里要特别注意，VS2022没有单独的“C文件”选项，文件后缀决定了编译方式，.c后缀的文件才会被当成C语言编译，.cpp后缀会被当成C++编译。所以新建完之后，手动把文件名改成main.c（注意后缀名一定要改），或者新建时直接命名为main.c，编辑器弹窗可能会提示“是否要保存为C语言源代码”，点是就行。

这个过程我自己带人的时候反复强调过，因为真有很多同学建完项目，文件后缀还是.cpp，写了半天纯C语法也能编译通过，但偶然用到某些C/C++有别语法差异的写法时就会出怪问题：比如C语言中struct使用时必须带struct关键字，而C++可以省略。这种差异会在你后续学习时变成一颗颗地雷。所以从第一天起，就养成用.c后缀的习惯，省掉后面一堆麻烦。

2. 第一个Hello World：逐行拆解背后编译器干了哪些活

2.1 写一个标准的Hello World，以及窗口一闪而过的真相

环境就绪后，在main.c里敲入这最经典的一段代码：

#include <stdio.h> int main() { printf("Hello, World!\n"); return 0; }

然后你会面临两种运行方式的选择：按F5（调试运行）和按Ctrl+F5（开始执行不调试）。新手最经典的困惑场景是——按F5运行，黑色控制台窗口一闪而过，什么都看不清就关了，然后怀疑程序是不是没跑起来。这其实不是程序的问题，而是F5模式在程序结束后默认会直接关闭窗口。

Ctrl+F5运行则会在程序结束后自动停留在“请按任意键继续”的状态，方便你查看输出。很多教程会推荐你用Ctrl+F5，但我的建议是：调试和学习阶段直接用F5，然后在这段代码的return 0;前面加一句getchar();，这样程序会在输完内容后停下来等你按一个回车再结束。原因很简单，你迟早要学着用F5的断点调试功能，趁早习惯F5不会吃亏。

这段代码的信息量其实比看起来大得多。#include <stdio.h>是预处理指令，作用是告诉编译器把标准输入输出库的声明“粘贴”进来，printf和你要用的scanf都是这个库里定义的函数，没有这行，编译器根本不知道printf是什么东西。int main()是整个程序的入口，操作系统从main开始执行你的代码。printf("Hello, World!\n");把字符串输出到控制台，其中的\n是换行符，它和你在键盘上按回车键产生的效果是一样的，但注意它是字符序列，不是字符串里一个普通换行。return 0;则表示程序正常结束，并把状态码0交给操作系统，0一般代表成功，非0代表异常。

2.2 用int main()而不是void main：VS2022为什么对你额外宽容

你可能在网上刷到过别人写void main()，甚至不少大学的旧PPT里也这么写。但在标准C语言（C99及以后的标准）里，main函数的返回值类型被规定为int，必须返回一个整数值给操作系统。void main其实是很多老编译器（比如早期Turbo C）带偏出来的写法，C标准里从来没有正式支持过。

那为什么你在VS2022里写void main()有时候也能编译通过，也能运行？因为VS2022的C编译器为了兼容历史代码，把这种写法当作警告级别的问题处理，通常只是给个C4091之类的警告甚至什么都不提示，不会直接报错。换个环境，比如你在GCC（Linux下用的编译器）里写void main()，编译直接就是错误：warning: return type of 'main' is not 'int'，有些版本甚至直接不给过。所以，“能在VS里跑”和“写的是符合标准的C语言”是两回事。

还有一个类似的原则要提醒：main函数末尾最好加return 0;。有些教材说“C99以后main可以省略return，编译器会默认返回0”，这个说法本身没错，但那是编译器在背后帮你补了默认逻辑。新手阶段，我建议每次都白纸黑字写上return 0;，编程里最忌讳的事情之一就是依赖“隐式行为”——你自己都不确定程序是怎么结束的，早晚会踩坑。

2.3 中文乱码：源文件编码与控制台代码页不一致的老问题

Hello World输出英文没问题，但一旦把字符串改成中文，很多人发现控制台显示出来就是一团乱码。这个问题不管在老版本还是2022里都存在，根源是VS2022的源文件默认存储编码（UTF-8）和Windows控制台默认代码页（通常是936，也就是GBK编码）不一致。

解决中文乱码有三个实用路子。第一，在main函数最前面调用system("chcp 65001");，这行代码会在程序启动时把控制台代码页切换到UTF-8，需要加#include <stdlib.h>。第二，在项目属性里找到“高级”→“字符集”，把“Unicode字符集”改成“使用多字节字符集”，这个方法对旧工程的兼容效果最明显，但有的新项目改了之后中文反而不显示，原因还是源文件编码的锅。第三，如果你用的是VS自带的编辑器，打开“文件”→“高级保存选项”，把编码改成“简体中文（GB2312）—代码页936”，再保存重新编译，控制台显示中文就正常了。

我的个人建议是优先用第一种方案，因为system("chcp 65001")只是程序内部的一条指令，不会改你的工程配置，也不会把手动拷贝到别的电脑上的代码弄乱。乱码问题本身不影响语法学习和调试，但在作业演示、期末答辩这种场景里，输出一堆乱码会显得非常不专业，所以值得花一分钟处理好。

3. scanf报错的本质：C4996不是语法错误，而是安全策略

3.1 “This function or variable may be unsafe”到底在说什么

回到开头那个刺眼的报错。把鼠标停在scanf上，VS2022会给出完整的警告内容：

错误 C4996: 'scanf': This function or variable may be unsafe. Consider using scanf_s instead. To disable deprecation, use _CRT_SECURE_NO_WARNINGS.

翻译过来就是：这个函数可能不安全，建议你用scanf_s替代；如果想禁用这个弃用警告，就定义_CRT_SECURE_NO_WARNINGS。

这不是说你调用了scanf编译器就不肯编译，也不是说scanf在C语言标准里被删除了。scanf在C语言标准中依然是标准库函数，在任何符合标准的编译器里都合法可用。VS2022给这个警告，是因为它默认开启了一项叫SDL（安全开发生命周期）的检查机制，这套机制对很多传统C库函数比较敏感，因为scanf家族函数在读取字符串时不检查缓冲区边界，容易导致缓冲区溢出——典型的恶意攻击入口。

所以你见到C4996，可以理解成VS出于安全策略对scanf亮黄牌，但它实际上不会阻止你编译和运行（在VS2022里它被归为“错误”级别的报错，原因是项目默认把C4996算作错误而非警告）。搞清楚这个成因，你就知道网上那些“让你改代码”和“让你关掉安全检查”的两派建议，到底在争论什么了。

3.2 三种解决C4996的实操方案与我的推荐取舍

解决这个报错，主流做法有三条路，每一条我都亲手试过，也清楚它们的适用场景：

方案一：在项目里定义_CRT_SECURE_NO_WARNINGS宏。操作路径是：右键项目名称→属性→C/C++→预处理器→预处理器定义，点编辑框右边的下拉箭头，选择“编辑”，在窗口里添加_CRT_SECURE_NO_WARNINGS，保存后重新编译，scanf的报错立刻消失。这个方案的好处是代码一行不用改，适用于所有用到scanf、strcpy、gets等函数的场景；缺点是改了宏之后，VS会把这些函数的警告全部屏蔽，你也就失去了对缓冲区溢出隐患的提示。

方案二：把scanf改成scanf_s。scanf_s是VS提供的安全版本，读取字符串类型时需要额外传一个缓冲区大小参数，比如scanf_s("%s", str, 20);。这个方案的好处是彻底符合VS的安全策略，代码编译零警告；坏处是scanf_s不是C标准库函数，是VS特有的扩展，你以后这套代码拿到Linux或者别的IDE上去编译，scanf_s会直接报未声明，跨平台性很差，而且很多教材、考题、OJ平台（在线判题系统）只认scanf。

方案三：在项目属性里关闭SDL安全检查。找到“C/C++”→“SDL检查”，把“否”保存。这个方案对scanf也有效，副作用比较小，但属于关闭整体安全防护机制，如果之后你要写课设项目、参加安全相关的科目考核，被老师看到关掉SDL，可能印象不太好。

我的推荐很明确：学习阶段优先方案一，因为在写作业、上题库时scanf是标准写法，以后去OJ平台刷题也无缝切换。如果你以后工作中真要写商业化代码，再老老实实学scanf_s或更安全的输入方式也不迟。另外，_CRT_SECURE_NO_WARNINGS不只管scanf，它还管strcpy、gets、sprintf等一批“告警老函数”。新手用方案一改完之后，如果细心的同学发现把gets等函数一起能用且不报警了，就说明这个宏的作用范围你真正理解了。

3.3 宏加在哪一层最有效：源文件顶部还是工程属性

上面方案一说的是工程属性里加宏，但也有不少网帖让你在源文件顶部写这行：

#define _CRT_SECURE_NO_WARNINGS #include <stdio.h>

这两种做法有本质区别。源文件顶部定义宏，只对这个.c文件生效；工程属性里定义宏，对整个项目的所有.c文件生效。对学习阶段的单文件程序来说，两者效果相同，但工程属性显然更干净，因为你不必在每个源文件里都复制粘贴那行宏。不过需要注意一种特殊情况：如果你把宏定义写在#include <stdio.h>之后，实际上已经晚了，因为很多标准头文件在预处理阶段就已经根据宏标记做了决定，所以宏必须写在前，且要在所有包含头文件语句之前。

如果你用的是工程属性方法，还有一种隐蔽雷点：配置下拉框里默认是“Debug”还是“Release”要分清。很多人只在Debug配置里加了宏，后来切换到Release模式一编译又报错了。项目属性里的配置默认只针对当前选中的配置，想去掉这种割裂，就把“配置”那栏从“Debug”改成“所有配置”，再操作一次，这样Debug和Release就都不报警了。这个细节以前很多同事就翻过车，题目的写法也经常用“在Debug下能编译，换Release就炸”来坑人。

4. 从printf到scanf：一次输入的数据流动，藏着新手最容易踩的坑

4.1 最常写错的取址符：为什么scanf总往&上较劲

scanf和printf最大的区别，在于printf是“把变量的值拿出来打印”，而scanf是“把键盘输入的东西存进变量”，这个“存进去”的动作要求你告诉它变量的地址，而不是变量本身。所以你写scanf("%d", &a);，中间的&是取地址运算符，表示“变量a在内存中的地址”，scanf才能按图索骥，把读到的整数写进那块内存。

新手最经典的错误就是漏掉&，写成scanf("%d", a);，然后发现程序编译时往往只是警告，运行时行为诡异——读了半天输入，变量a里的值根本没变。更可怕的是，如果那变量恰好存了一个非法地址，程序可能直接崩溃或者让你调试到怀疑人生。所以在初学阶段我有个很土但实用的口诀：“scanf一律要加&，除非你读的是字符数组名（字符串），因为数组名本身就是地址。”这句口诀到后面学指针时会自己理解，但先用着不吃亏。

另一个经常被忽略的点是，scanf的格式串里的\n很容易把新手坑了。比如有人写scanf("%d\n", &a);，希望“输入一个数并回车”，但实际运行时你会发现程序不会立即结束，必须再输入一个额外的字符才能返回。原因在于\n会要求和空白匹配，而空白字符匹配会一直消耗输入里的空白，直到出现非空白字符才停。所以入门阶段，scanf格式串里不要加无意义的空白符和\n，这是硬经验。

4.2 输入缓冲区：为什么同一个scanf会被“跳过”或被上一次的回车坑

如果你连续写两个scanf，一个读数字一个读字符，就会发现一个让人拍桌子的现象：第二个scanf根本没让你输入，直接就“读”走了。这里必须引入输入缓冲区的概念——控制台送进来的数据不会立刻到达程序，而是先进入一块内存区域，scanf再从这块区域按格式读取。

看这段代码：

int num; char ch; scanf("%d", &num); scanf("%c", &ch);

你输入65并按下回车，控制台缓冲区里其实是三个字符：'6'、'5'、'\n'。第一个scanf用%d格式读取时，它看到6和5，把它们解析成整数65，读完了，但那个'\n'回车符还留在缓冲区里。第二个scanf用%c格式读取字符，%c不会跳过空白字符，于是它看到的第一个字符就是缓冲区里剩的'\n'，直接把换行符读进了ch。于是程序完全跳过手动输入，直接输出一个“回车”。

应对这个坑有三个职业级处理方式：第一个是第二个scanf的格式串里写"%c"时前面加一个空格，即scanf(" %c", &ch);，这个空格会告诉scanf跳过所有的空白字符（包括上次的回车）。第二个是主动把缓冲区里的残留清掉，调用getchar();去消费掉那个回车，但它只能消费一个字符，如果有更多残留就还得循环。第三个是在读到字符前用while (getchar() != '\n');把当前行清空，但这个方法要知道当前位置不能误吞掉下一个需要的输入。

我在教学里最喜欢让新手做的练习是：写一个程序，先读一个整数，再读两个字符，然后要求按顺序打印出来。做完这个练习，你对缓冲区的理解基本就上了一个量级，比背十遍概念都管用。

4.3 基本格式说明符配对备忘录

新手还经常被%d、%f、%s这些说明符和变量类型的对应关系坑到。这里列一个极简对照表，你可以先抄到笔记里，写代码时对照着用：

其中最容易写错的组合是double配了%f，这在scanf里属于未定义行为，可能读出来的数字是乱码；在printf里则可能会被默认当作float处理，行为也说不准。另一个高发错误是用%s读字符串时，忘记给字符数组留终止符'\0'的空间，比如定义char name[10]却想着能读入10个字符，实际上最多只能读入9个字符加一个结束符。VS2022里用%s配合scanf时，如果数组定义太小还会触发缓冲区溢出相关的检查，所以宁可把数组开大一点，也不要抠那几个字节。

5. 编译通过不算完：新手自查清单与两个值得养成的好习惯

5.1 编译无报错，程序却行为诡异？优先查这三处

很多新手看到编译零错误、零警告就以为大功告成，其实编译通过只是最低门槛。参照我过去几年的经验，第一学期C语言上机课里九十%的“编译通过但运行不对”都出在这三处：

第一，scanf里的&有没有漏。这一点前面已经花了大篇幅说，不再赘述。自查方法是，看到scanf("%格式", 变量)，立刻追问一句：这是不是该加&。第二，格式说明符和变量类型是否匹配。写了double x; scanf("%f", &x);这种就是典型的“编译能过、结果乱来”。第三，缓冲区残留的回车有没有被“读”走。判断方法是，如果程序里有先读数字再读字符的结构，十有八九会被这个坑咬一口，主动用scanf(" %c", ...)的空格技巧。

如果这三个方向都排查过还不对，那就下一招：把中间结果用printf打出来。很多人不爱打印中间变量，觉得“代码明明就是这个意思”，其实编程里讲证据，不靠感觉。在关键步骤后打印变量当前值，能迅速定位是哪一步开始出错的，这比盯着代码发呆高效得多。

5.2 从第一天就保持的工程习惯：头文件保护与代码注释

最后说两个与VS2022本身关系不大、但长期受益的习惯。第一个是头文件的保护宏，等学到自己写头文件后会懂，现在可以先在意识里埋下种子：每个头文件建议这么写：

#ifndef MY_HEADER_H #define MY_HEADER_H // 头文件内容 #endif

这个写法叫头文件保护，防止同一个头文件被重复包含引发重定义错误。VS2022的模板有时候会自动生成类似#pragma once的预处理命令，效果类似但属于编译器扩展；上面这个#ifndef写法是标准C，跨平台通用。第二个习惯是代码注释。第一次写项目时，用//在复杂逻辑的上一行写一句“这段话打算干什么”，不要嫌麻烦。我在带项目时经常发现，很多人半年后回头看自己写的代码，完全想不起当初的思路，这时候注释就是救命稻草。

注释和代码风格一开始可以很简陋，但一定要有。VS2022自带的代码格式化快捷键是Ctrl+K、Ctrl+D，写完后按一下，缩进全齐，阅读体验立刻不一样。一个整洁、有注释、缩进规范的main.c，哪怕逻辑简单，也会让人第一眼就觉得“这代码是认真写的”。

5.3 关于“备份版本”的建议：折腾配置前先留一份能跑的

既然聊到VS2022里的各种项目配置，不得不提一个我亲自踩过的坑：为了治scanf报错，我在项目属性里一通操作，结果工程文件被改坏，整个项目无法编译，最后只能重新建工程。后来我养成了一个习惯——每次要动项目配置、加预处理器宏、改字符集之前，先把当前这个能编译的源文件复制一份到桌面存档。源文件是纯文本，存着不占地方，万一配置折腾坏了，把源码拷回新工程里，几分钟就满血复活。

这一点对新手尤其重要。因为VS2022的.vcxproj工程文件是XML文本，里面配置项繁多，有时候属性面板里的某个值被误改，你连在哪改回来的都找不到。有了“当前能跑的源代码备份”，你就永远有一条退路，学习的心态也会稳很多。我在指导同学做课设时，也总跟我们说：代码本身才是你宝贵的资产，IDE的工程文件丢了就丢了，源码在手，天下我有。

6. 动手试一遍：从报错到跑通的完整示例

为了把前面所有内容串起来，我写了一个完整的练习程序，里面包含：处理掉scanf的C4996问题、中文输出、读入整数和字符并正确输出。你可以在VS2022里照着敲，敲完之后按照前面讲的原因，把scanf(" %c", &ch)中的空格去掉试试，再想想为什么程序会多读一次。

#define _CRT_SECURE_NO_WARNINGS #include <stdio.h> #include <stdlib.h> int main() { system("chcp 65001"); int age; char gender; printf("请输入年龄："); scanf("%d", &age); printf("请输入性别(M/F)："); scanf(" %c", &gender); printf("年龄：%d，性别：%c\n", age, gender); return 0; }

第一次运行时，在输入年龄回车之后，你会看到程序正常等你输入性别，这是“格式串前加空格”起了作用。如果你尝试把scanf(" %c", &gender);改成scanf("%c", &gender);，再次运行就能直观地体会到缓冲区残留问题——性别读进去的直接是回车符，输出性别时光标会换行而非打印字母。这种亲手对比试错，比看十篇博客都印象深刻。

再试一试，如果你新起一个工程，把main.c通过右键“添加”→“现有项”的方式加进工程，而原文件里没有定义_CRT_SECURE_NO_WARNINGS，你就会知道我们前面讲的“宏加在哪一层最有效”到底差多远：源文件里的宏跟着文件走，工程属性里的宏跟着工程走，两者截然不同。

整个流程跑完，你应该已经掌握VS2022下C语言入门最核心的几个基础操作：建工程、写源码、处理C4996、应对输入缓冲区问题。这些几乎就是C语言第一学期上半段全部“环境坑”的精髓。后面学指针、结构体、文件操作时，再遇到和缓冲区、取地址、编码相关的问题，你已经有排查思路，不会再被劝退了。