前阵子我重新拿起 C 语言写了很久没碰过的第一个 C 项目一个 Unix wc 命令的克隆。项目标题自己写得很直白就叫 “I wrote my first C project after a long time. Unix wc clone. NO AI”。意思是隔了很久回来写 C选了一个 wc 克隆当练手项目同时明确要求全程不用 AI 帮忙。这个选择比我想象中值钱因为 wc 看起来只是统计行数、单词数、字节数实际做起来会把 C 语言最核心的几件事全部串起来文件读写、字符循环、状态判断、命令行参数、多文件统计、输出格式、错误处理和退出码。如果你也是隔了很久想回到 C或者刚学完语法不知道下一步做什么这个项目我都建议当作第一站。下面按我实际落地的顺序拆开讲包括环境准备、第一版实现、参数解析、对拍测试和最后复盘的经验。1. 为什么要选“Unix wc 克隆”当作回坑 C 的第一个项目1.1 要复刻的不只是三个数字很多人以为 wc 就是数一下文件里的行数、单词数、字节数然后打印出来。真去复刻时就会发现没那么简单。真实 wc 默认输出是三个字段行数、单词数、字节数。但它的行为由很多细节决定行数是统计换行符数量不是统计“逻辑行”单词数依赖空白字符的定义字节数要逐字节累计加不加文件名要在有没有文件参数之间切换多文件时会多打一个 total出错时要打印错误信息但继续处理后面的文件。这些细节如果不复刻自己写着玩完全没问题。但如果目标是“克隆”判断标准就只有一个在同样输入下你的程序输出和系统 wc 一致。这个标准非常客观项目完成度一下子就有了可验证性。1.2 为什么它适合隔了很久才回到 C 的人围绕 wc 克隆你会在一个很小的代码量里重新练到这些基本功文件打开、读取、关闭以及 fopen 返回值的检查逐字符循环处理 EOF用状态变量记录“当前是否在单词内”命令行参数解析处理选项和文件名多文件累加输出右对齐stderr 错误输出退出码区分成功和失败这些点几乎覆盖了 C 入门到进阶的核心环节而且每一点都能独立验证。你要是直接去做一个“学生成绩管理系统”之类的大作业经常写到一半搞不清是代码问题还是需求问题但 wc 克隆不会行为基准就在系统里躺着跑一下 diff 就知道对错。1.3 不用 AI 写项目到底在图什么现在 AI 编程工具已经非常常见写一个 wc 克隆让 AI 生成代码几十秒就能跑通。但这样做的结果是你自己对“为什么这么写”几乎没有建立体感。不用 AI 意味着所有问题都必须自己消化先想到用 getopt 还是手动解析先发现 Windows 下文本模式会影响字节数先跑到多文件输出不对称再回头修格式。这个“发现问题—定位原因—自己修好”的闭环才是写 C 项目真正的训练价值。倒不是鼓吹永远不用 AI而是说在回坑 C、重建基本功的阶段自己写一遍的收益远高于让工具代写。2. 动手前先把工具链准备好Linux、macOS、Windows 三种情况2.1 Linux 和 macOS一两条命令就能开工这个项目完全没有外部依赖只要系统里有 C 编译器就能跑。Linux 上一般是 gcc 或 clang先确认一下gcc --version clang --versionmacOS 上如果没装过命令行工具需要先执行xcode-select --install装好后就有 clang 可用。环境变量、系统头文件一般都不用自己折腾。这一步的价值在于先把“能编译、能运行、能看错误”的最小链路打通再开始写业务逻辑。2.2 WindowsVS Code 配 gcc 是最省事的组合Windows 下最容易踩坑的是环境。我比较推荐 VS Code MinGW-w64 的组合安装 VS Code装 Microsoft 官方的 C/C 扩展。安装 MinGW-w64或者用 MSYS2 的 UCRT64 环境把 gcc 所在目录加入系统 PATH。在终端验证gcc --version能输出版本号就说明环境通了。新建一个 hello.c用gcc -Wall -Wextra -o hello hello.c编译再运行。VS Code 里的 tasks.json 可以后面再配初学阶段直接在终端里敲编译命令更清晰因为你能看到完整输出。这里顺带提醒一句如果 C 盘空间紧张MinGW-w64、MSYS2 以及编译缓存都会占几个 GB安装时注意路径和磁盘余量别装完才发现 C 盘快满。2.3 最小程序先跑通顺手把 Git 仓库建好不管是哪个平台我建议先写一个什么都不干的 main 函数编译、运行、确认返回值是 0。这一步不白做它能排除掉“编译器没装好”“PATH 配置错”“VS Code 终端和系统终端壳不一致”这类环境问题。项目标题里有 clone 这个词这里容易产生误解项目叫 wc clone意思是克隆 wc 命令不是让你先git clone别人的 wc 源码。如果你想完全复刻应该从空目录开始自己建仓库mkdir mywc cd mywc git init每个里程碑提交一次比如“能统计 stdin”“支持 -l -w -c”“支持多文件”。这样后面写坏了还能回退也能清楚看到自己每个阶段解决了什么问题。3. 第一版只做一件事从 stdin 读取并统计行、单词、字节3.1 先用真实 wc 建立行为基准写代码之前先拿系统 wc 跑几组真实数据心里有个基准。我一般会准备这么几个测试文件printf hello world\n t1.txt printf hello world t2.txt printf \n\n t3.txt printf a b \t c\n t4.txt然后分别跑wc t1.txt t2.txt t3.txt t4.txt观察输出。你会发现t2.txt 没有结尾换行行数仍然是 0t4.txt 里连续空格和制表符没有导致单词数变多多文件时最后多了一行 total。这些现象就是后面写代码要满足的需求。3.2 核心计数循环一个状态变量就够了第一版先只处理 stdin不解析任何参数。统计行、单词、字节的核心逻辑大约是下面这样#include stdio.h #include ctype.h int main(void) { int c; long lines 0, words 0, bytes 0; int in_word 0; while ((c getchar()) ! EOF) { bytes; if (c \n) { lines; } if (isspace(c)) { in_word 0; } else if (!in_word) { in_word 1; words; } } printf(%7ld %7ld %7ld\n, lines, words, bytes); return 0; }这段代码有两个容易讲不清的点。第一行数为什么只统计\n。因为 wc 的语义就是“换行符数量”不是“逻辑行数量”。一个文件末尾没有换行符最后一句话在文本编辑器里看起来是一行但 wc 统计出来可能是 0 行。这不是 bug是 wc 一直以来的行为。第二单词数为什么要一个 in_word 状态。如果每遇到一次非空白字符就把单词数加一那a b中间的空格也会让单词数变成 3。正确做法是遇到空白字符时把状态置为 0遇到非空白字符时只有在状态为 0 的情况下才加一并把状态置为 1。这样连续的非空白字符只算一个单词。3.3 为什么用 getchar 而不是自己写复杂缓冲getchar 底层是带缓冲的 stdio逐字符读入对这个阶段的代码完全够用。不要一上来就上 fread 大缓冲那会引入缓冲区大小、循环边界、剩余字节处理等多个新问题。先把功能写对再考虑性能。判断“写对”的标准很简单把这个程序编译出来执行./mywc t1.txt ./mywc t4.txt和系统 wc 的结果对比数字一致就通过。系统 wc 在这种不传入文件名的情况下只打印三个数字不带文件名你的程序也要保持同样格式。4. 加上参数解析和多文件之后输出格式才是真正难点4.1 选项解析getopt 还是手动解析第二版要支持常用参数。至少应该覆盖这几个参数含义-l只统计行数-w只统计单词数-c只统计字节数-m统计字符数依赖当前 locale可作为进阶项无参数等价于 -l -w -cLinux 和 macOS 上可以直接用 getopt 来解析短选项#include getopt.h int opt; while ((opt getopt(argc, argv, lwc)) ! -1) { switch (opt) { case l: flag_l 1; break; case w: flag_w 1; break; case c: flag_c 1; break; case ?: fprintf(stderr, Usage: %s [-lwc] [file...]\n, argv[0]); return 1; } }如果工具链里没有 getopt可以手写解析从 argv[1] 开始遇到以-开头的参数就逐字符判断选项遇到第一个不以-开头的参数后剩下的都当文件名处理。手写解析的好处是什么都要自己处理对参数顺序的理解会更深。需要注意不要在处理完文件名之后还去解析后面的-x因为真实命令在这个位置已经把-x当成文件名了。4.2 多文件处理要累加要 total还要继续处理出错文件核心循环写好后把“处理一个文件”抽成函数这样 stdin、单文件、多文件都能复用。整体骨架大概是int read_stream(FILE *fp, long *lines, long *words, long *bytes) { int c; int in_word 0; while ((c fgetc(fp)) ! EOF) { (*bytes); if (c \n) (*lines); if (isspace(c)) { in_word 0; } else if (!in_word) { in_word 1; (*words); } } return ferror(fp) ? -1 : 0; }主函数里先判断有没有文件名。没有文件名时读 stdin不打印文件名有文件名时逐个打开、处理、关闭。某个文件打不开时往 stderr 打印错误继续处理后面的文件最后退出码返回 1。这个行为必须复刻因为真实 wc 不会因为一个文件不存在就中断整个任务。多文件时最后还要打印 total。打印格式要注意字段对齐。在 Linux 的 GNU wc 上数字一般右对齐到固定宽度不同系统可能有差异以你本地 wc 实测为准。如果直接裸用%ld打印字段会挤在一起diff 时必然失败。4.3 输出格式和文件名位置单文件输出长这样1 1 12 t1.txt多文件输出最后会多一行1 1 12 t1.txt 0 0 11 t2.txt 1 1 13 total所以打印函数要接收“是否显示文件名”和“是否是 total 行”两个条件。我建议把打印逻辑单独抽出来别散落在循环里否则后面加 -m、-L 时很容易改乱。4.4 Windows 上的一个隐藏差异真实 wc 统计的是原始字节数。Windows 上如果用文本模式打开文件CRLF 会被转换成 LF字节数就会和真实情况对不上。写代码时应该用二进制模式打开文件FILE *fp fopen(argv[i], rb);这个细节在 Linux 上没区别但在 Windows 上就是“看起来逻辑没错结果却始终不对”的经典坑。5. 用系统 wc 做“对拍测试”把边界情况一条条补齐5.1 对拍测试是最省力的验证方式所谓对拍就是把同一个输入分别交给系统 wc 和你的程序然后比较输出。我建议准备一个测试目录里面放各种边界样本然后跑一段简单的脚本for f in testcases/*; do wc $f /tmp/wc.out ./mywc $f /tmp/mywc.out if ! diff -u /tmp/wc.out /tmp/mywc.out; then echo FAIL: $f fi done注意 diff 会比较空白字符所以两边的字段宽度必须一致。测试文件要覆盖以下类型空文件没有结尾换行的文件只有空白字符的文件包含中文、日文等多字节字符的文件单行非常长的文件连续多个空格、制表符混合的文件这些边界情况下系统 wc 的行为往往是写 wc 克隆时最容易出错的地方。5.2 文件和参数各种组合也要测除了数据内容还要测运行方式不传文件名从 stdin 读./mywc t1.txt传入-./mywc -确认你的程序和系统 wc 在“读 stdin 但不打印文件名”这个行为上是否一致传不存在的文件看 stderr 输出和退出码传一个目录观察系统 wc 会输出什么你的程序是否也做了同样处理同时传多个文件看 total 是否出现只传-l、只传-w、只传-c看打印字段拼接我实测时最常遇到的问题就两类一类是字段顺序不对另一类是 total 和文件名位置不对。这些问题用对拍脚本几十秒就能发现手动肉眼对比反而容易看漏。5.3 发现数字正确但 diff 不一致时先看格式如果你对拍时发现数字全对但 diff 总是报错不要急着改计数逻辑先看格式。重点检查每个字段之前到底有几个空格数字和文件名之间有没有多余空格多文件 total 行是不是没有打印出错时程序是不是直接退出了没有继续处理后面文件这些都属于“功能看起来没问题但形态不一致”的边界问题。既然叫克隆形态和对错一样重要。6. 全程不用 AI 写完这个项目我复盘出的几条经验6.1 卡住时查资料和查文档的顺序不用 AI 之后查资料的路子反而更接近学习本质。我推荐的顺序是先看现象。卡住时先跑最小用例确认是编译错误、运行崩溃、数字不对还是格式不对。再看输入。查看测试文件的原始字节可以用od -c或xxd看是不是有隐藏的 CR、制表符或换行。再看文档。man 1 wc看命令行为man 3 getopt看参数解析man 3 isspace看字符分类细节。再看代码。在关键位置打印中间变量比如每个文件的 lines、words、bytes 到底是多少。最后再决定是否参考别人实现。如果你想看成熟实现GNU coreutils 或 busybox 的 wc 源码都是很好的阅读材料但要在自己写完第一版之后再读或者读之前先把行为验证明白。这个顺序能避免“报错后瞎改参数”“方向错了还一直调”的无效循环。6.2 这个框架还能怎么继续扩展第一版跑通之后可扩展方向很多难度从低到高排一下增加-m用 mbrtowc 解析多字节字符按字符数统计增加-L统计最长行的长度这是 GNU wc 的扩展选项支持从多个文件连续读取并返回正确的累计 total把计数循环改成 fread 大缓冲版本测一下吞吐量变化把测试脚本整理成一个可以自动运行的回归测试写一个 README记录你复刻了哪些行为、哪些行为故意不一致每加一个功能都重新跑一遍对拍脚本保持和维护系统 wc 一致。6.3 判断这轮练习有没有白做的标准项目做完后我建议自己回答这几个问题能不能解释为什么单词计数需要 in_word 状态变量能不能解释行数为什么按换行符统计而不是按“逻辑行”统计能不能说出 fopen 返回 NULL 时程序应该做什么为什么不能直接崩溃能不能在完全不看参考代码的情况下自己实现 -m能不能说清楚多文件 total 行的输出条件如果这些问题都很顺说明这轮“回到 C”的练习基本到位了。如果有些地方答不上来可以把对应功能拆出来再单独写一次直到能独立还原为止。最后说一句个人感受。踩完一轮坑后我发现写 wc 克隆这类小