前段时间整理电脑翻出一个很久没打开的 C 语言工程目录。上一次正经写 C可能还是大学刚毕业那会儿。为了把手感捡回来我给自己定了一个很保守的目标写一个 Unixwc命令的克隆支持-l、-w、-c三个选项既能从文件读也能从标准输入读并且这次不让 AI 帮我写一行代码。选wc当恢复项目是因为它看起来短其实五脏俱全。它要处理命令行参数、流式输入、状态切换、边界条件、性能分析这些恰好是 C 语言最容易让人栽跟头的地方。而且它足够小小到一晚上能写完第一版也足够深深到可以持续打磨好几天。这次重写最直接的收获不是“我能写一个 wc 克隆”而是我终于知道自己以前哪些地方是囫囵吞枣哪些概念只是听说过并没有真正理解。1. 为什么是 wc为什么不用 AI1.1 wc 不是玩具项目一个只支持三个选项的wc看起来好像很简单很多人第一反应是“三五个printf就能写完”。但真正动手之后才会发现它其实很像一个微型编译器前端先要解析命令行选项然后从文件或标准输入获取字节流再对字节流做状态识别最后还要考虑输出格式和错误处理。每一步都藏着细节。真实 Unixwc的行为比直觉要严格得多。例如wc file输出三列分别是行数、单词数、字节数然后再跟文件名wc -l -w -c file时列的顺序也是行、单词、字节wc file从标准输入读输出时不再有文件名那一列多个文件时最后还会输出一个“总计”行所谓的“行数”在很多实现中统计的是换行符字符的数量而不是逻辑上的“文本行数”。这些细节不亲手实现一遍是记不牢的。比如一个没有换行结尾的文件编辑器会显示它有一行但wc -l的结果很可能是0。我第一次实现时就把行数默认从 1 开始结果和系统wc对不上查了很久才发现是我的“直觉”错了而不是程序错了。1.2 “不用 AI”不是情怀而是为了重新建立手感现在写代码很多人习惯打开编辑器就喊 AI 补全。我平时也会用 AI 做代码审查和测试用例生成但这次故意不用。原因很简单对于刚把 C 捡起来的人来说AI 补全会切断“发现问题-定位问题-理解问题”这条完整链路。举例来说如果你让 AI 写一个“从文件读取并统计字节数”的循环它可以三秒钟给你一个正确版本但你不会知道为什么fgetc的返回值要用int而不是char不会知道EOF其实是-1也不会知道直接把返回值塞进char变量里在非 ASCII 环境下可能出错。这些细节只有亲手踩过印象才会深。所以这次我给自己定了一条规定AI 可以看但不能写。遇到不会的语法和库函数就去翻man手册或者查标准文档。过程确实慢可每解决一个问题接回来的是一个知识点而不是一团模糊的“它反正能跑”。2. 先把接口和输入模型想清楚2.1 需求定义小但边界要完整动手写代码前我先在一张纸上写了第一版需求支持-l统计行数支持-w统计单词数支持-c统计字节数默认行为等于-l -w -c同时开启支持一个或多个文件参数如果文件参数是-或者没有任何文件参数就从标准输入读取输出格式尽量对齐系统wc方便后续用 diff 做对照测试。没有一开始就加入 GNU 的-m字符数和-L最长行宽度因为第一步需要先保证核心框架正确再考虑扩展。这个取舍很重要任何小工具都可以在第一个版本里缩小范围先把主干跑通。2.2 程序结构先拆成三个函数我的第一版程序没有刻意用很复杂的设计只是拆成了三个函数int main(int argc, char *argv[]); void count_stream(FILE *fp, Counts *counts); void print_counts(const Counts *counts, const char *filename);main负责解析参数、打开文件、处理错误。count_stream负责真正扫描输入流。print_counts负责格式化输出。这种拆分最直接的好处是核心逻辑count_stream不关心参数从哪来也不关心结果打印到哪后续加文件列表、加标准输入改动都会被隔离在main内部。对应的结构体可以这样定义typedef struct { long lines; long words; long bytes; } Counts;用long而不是int是为了避免大文件统计时溢出。32 位int在几十 GB 的文件面前是不够稳妥的。2.3 选手动解析参数而不是 getopt解析命令行参数时最标准的做法是调用 POSIX 的getopt。但对于这个项目我选择手动解析argv。原因不是getopt不好而是这个项目的参数只有三个手动解析足够简单还能顺便复习指针和数组的用法。我定义了一个很朴素的解析规则遇到以-开头并且后面跟字符的参数就把它当作选项其余参数当作文件路径。-lwc这种合并写法也允许这样可以和系统wc的习惯保持一致。int i 1; for (; i argc; i) { if (argv[i][0] - argv[i][1] ! \0) { for (int j 1; argv[i][j] ! \0; j) { switch (argv[i][j]) { case l: do_lines 1; break; case w: do_words 1; break; case c: do_bytes 1; break; default: fprintf(stderr, unknown option: -%c\n, argv[i][j]); return 1; } } } else { // 当作文件路径处理 files[file_count] argv[i]; } }这段逻辑不算优雅但足够清晰。唯一需要注意的是-作为参数时有特殊含义它表示标准输入。这个特例如果漏掉后续就很难从命令行把标准输入和其他文件混在一起测试。3. 核心计数逻辑一个字符一个字符地读3.1 fgetc 是起点fread 是优化第一版核心循环我用了fgetc因为它的语义最简单每次读一个字节遇到EOF就结束。这样统计字节数、行数、单词数都可以在同一个循环里完成。void count_stream(FILE *fp, Counts *counts) { int c; int in_word 0; while ((c fgetc(fp)) ! EOF) { counts-bytes; if (c \n) { counts-lines; } if (isspace(c)) { in_word 0; } else if (!in_word) { in_word 1; counts-words; } } }这个循环的核心是in_word这个状态标记。它记录“当前是不是正在一个单词中”。遇到空白字符就把状态清空遇到非空白字符时如果之前不在单词里就说明开启了一个新单词于是words。这个状态机很小但很关键。如果不加in_word而是简单统计“非空白字符连续段的个数”很容易在连续空格、制表符、换行符交替出现时出错。真实文本里完全可能连续出现很多个分隔符状态机能保证只计一次开始。3.2 isspace 的判定范围isspace是 C 标准库函数它判定的是“空白字符”包括空格、\t、\n、\v、\f、\r等。用它是比较省事的做法但要注意它接收的参数类型也是int并且它的行为依赖当前 locale。实际落地时可能因为isspace对某些字符的判定和系统wc不一致导致输出对不上。最稳妥的办法是先明确这个工具按“非空白字符组成的连续序列”来定义单词还是按更复杂的 Unicode 规则来定义。对于第一版克隆用isspace已经足够但要在文档里写清楚这一假设。3.3 行数的定义要跟 Unix 保持一致wc -l统计的不是“逻辑行数”而是换行符\n的个数。这一点我在前面提过但太容易出错了值得单独说。比如一个文件内容只有hello没有换行。用很多编辑器看它显示为 1 行但wc -l输出是0。原因是wc不做“文本行解析”它只计数换行符。如果你想让这个文件被计为 1 行通常意味着你要自定义规则把“最后一个不是换行符结尾的尾段”也算作一行。GNUwc的行为是只统计换行符数量。所以为了和系统工具对齐我的实现直接统计c \n的次数不做额外处理。这样最简单也最不容易引起歧义。3.4 字节和字符的边界-c统计字节数这个非常直接每读一个fgetc返回值bytes。但很多初学者会把字节和字符搞混。在 UTF-8 环境下一个中文字符通常占用 3 个字节如果你统计的是字节数那么wc -c和wc -m会得到不同结果。我这个版本的克隆只实现-c所以只按字节计数不关心多字节序列的内部结构。如果确实要支持-m就需要引入宽字符处理机制比如mbrtowc之类的函数还要处理 locale 切换。这个难度会明显提高适合作为下一步的挑战而不是第一版的路障。4. 容易被忽略的边界条件和性能陷阱4.1 测试用例应该这样构造我在写代码之前列了一个非常原始的测试清单。这些用例看起来很简单但正是抓 bug 最快的路径空文件行数 0单词数 0字节数 0。内容只有一个a没有换行行数 0单词数 1字节数 1。内容只有a\n行数 1单词数 1字节数 2。内容为hello world\n行数 1单词数 2字节数 12。内容为a b c\n多个连续空格行数 1单词数 3。内容以换行结尾、但最后一行没有字符行数不额外增加。构造这些样例时最好用printf配合转义字符避免因为编辑器自带的行尾转换干扰判断。例如printf hello world\n | ./mywc4.2 标准输入和文件输入的差异wc从标准输入读取时输出格式和从文件读取时不一样这也是很容易忽略的一点。系统wc file不会输出文件名。如果我的程序总是在输出末尾追加文件名那对比测试就会失败。实现上文件名为空时print_counts只打印三个数字。文件名是-时也应该不打印文件名。这种细节只有对照真实命令的输出才会发现。另外从标准输入读取时fopen不适用需要用已经打开的stdin。还要考虑如果参数列表里既有文件又有-程序要按顺序依次处理。顺序错了输出顺序也会和系统wc不一致。4.3 性能问题什么时候才需要优化第一版用fgetc逐字符读取在几十 MB 的文件上完全没问题。但如果你处理的是几 GB 的日志文件逐字符函数调用可能就会成为瓶颈。优化的方式也很直接用fread读入一大块缓冲区然后在内存里扫描。这个思路和fgetc版本的核心逻辑基本一致只是把“每次读一个字符”换成了“每次读一块”。char buf[BUFSIZ]; size_t n; while ((n fread(buf, 1, sizeof(buf), fp)) 0) { for (size_t i 0; i n; i) { unsigned char c buf[i]; // 这里使用与 fgetc 版本相同的逻辑 } }但注意不要一开始就上缓冲区版本。先用fgetc写出正确逻辑再用性能工具去测量是否有优化必要。过早优化会让状态机、缓冲区剩余、fread返回值这些新的复杂度过早进入你的视线反而不利于建立正确的心智模型。如果最终采用fread版本还要注意fread返回的是读取的元素个数它的类型是size_t不是int。缓冲区里每个元素都是unsigned char处理时要避免符号扩展问题。5. 测试与对照怎么证明你的 wc 是对的5.1 用 diff 和系统 wc 做对照写完了程序并不能证明它是对的。最简单可靠的验证方式是用系统自带的wc做参照物把两个程序的输出拿去做 diff。我写了一个很简单的测试脚本思路for file in test1.txt test2.txt empty.txt; do diff (./mywc -l -w -c $file) (wc -l -w -c $file) done这里用到了 bash 的进程替换。如果你的 shell 不支持也可以先分别输出到临时文件再用diff比较。这个脚本能发现大量输出格式、计数逻辑不一致的问题。还有一个很好用的工具思路用dd生成随机大文件然后对比字节数。这样能验证在读入二进制内容时程序不会因为某个字符等于EOF而提前终止。dd if/dev/urandom of/tmp/random.bin bs1M count10 ./mywc -c /tmp/random.bin wc -c /tmp/random.bin如果两个输出一样至少说明-c的循环能正确处理带任意字节值的文件。5.2 常见 bug 排查链路如果你发现自己的输出和系统wc对不上不要急着改代码先按顺序排查先看现象是行数不对、单词数不对、还是输出格式不对再看输入文件最后有没有换行文件路径是不是-是不是从标准输入读再看环境当前 locale 是什么isspace行为是否受 locale 影响文件是不是二进制再看参数解析-lwc这种合并参数是否被正确处理未知选项是否报错再看核心状态机in_word的初始值是多少每次遇到分隔符时是否正确归零遇到EOF时有没有多余计数实际调试过程中最容易出问题的地方是“单词数多 1”或者“行数少 1”。多 1 通常是EOF被误判成一个单词少 1 通常是没有正确计算文件开头的第一个非空白字符。5.3 测试不能只测正常流很多工具在正常输入时可以工作一旦遇到缺失文件、权限不足、目录路径就马上崩溃。C 项目里尤其要处理错误。fopen返回NULL时要打印合适的错误信息并设置退出码为非零。多个文件里如果有一个打不开不能直接退出应该继续处理剩下文件并在最后还是返回非零退出码。这个改进会让程序从“玩具版”变成“工具版”。虽然不影响核心计数却决定了你以后愿不愿意在真实命令行里使用它。6. 这个小项目真正沉淀下来的东西6.1 一个可复用的小工具设计框架做完这个 wc 克隆我把过程整理成一套适用于大多数命令行小工具的开发框架总共四步定义输入边界明确支持哪些参数、参数怎么写、是文件还是标准输入、多文件顺序如何处理。画出状态机核心逻辑里有哪些状态状态之间怎么切换。比如此处的in_word。先写核心再补外壳先用一个文件路径跑通核心计数再补参数解析、多文件、错误处理、格式对齐。用参照物做对照测试如果有系统自带工具就尽量让输出格式保持一致然后用 diff 自动化验证。这套框架不只适用于 C也适用于 Python、Go、Node.js 里的命令行工具。只要是一个“从输入到输出”的小程序都可以先这样设计。6.2 重新理解 C 语言的设计哲学写完这个项目我对 C 有了更具体的一些理解。C 语言不替你隐藏任何东西。fgetc返回int是为了把EOF和普通字节区分开FILE *是对底层文件描述符的一层薄封装但仍然要求你手动关闭缓冲区溢出不会有运行时提示未初始化变量不会自动归零。这些不是 C 的缺点而是它的设计取舍。以前学 C 的时候很多写法是背下来的。这次重新写完我终于能把“为什么这么写”和“不这么写会怎么样”对上了。比如fgetc为什么不能直接返回char因为合法的字符可能包含0xFF而EOF是-1如果用一个char变量存0xFF和EOF会产生歧义。这种问题AI 补全不会告诉你只有自己把字面量打印出来才会明白。6.3 下一步什么时候可以重新引入 AI我不建议永远拒绝 AI。这次“不用 AI”是一种刻意练习目的是补基础。如果你已经能独立写通一个类似wc的小工具对参数解析、状态机、输入输出、测试对照都有了手感那再让 AI 参与反而可以提升效率。比如让 AI 帮你审查代码里的边界漏洞让它对比你的实现和 GNU wc 的差异让它帮你生成更完整的多字节字符测试语料。这些都是 AI 很擅长的事而且不会替代你的判断。但如果你的目标是学习 C 语言本身最糟糕的路径是自己连需求都没分析清楚就直接让 AI 生成一版完整代码然后“跑通”就算完。这种情况下你得到的是一个可运行的结果却错过了所有可能让你成长的过程。回到最初的项目。这个 wc 克隆最终只有几百行代码和真正 GNUwc的复杂实现相比实在算不上什么。但对我个人而言它的价值不在代码量而在这次重写让我重新建立起了对 C 语言底层机制的掌控感参数解析、状态切换、字节流、错误处理、测试对照每一个环节都重新过了一遍脑子。如果你也想把一门放下很久的语言捡起来我会建议不要从大型项目开始也不要直接依赖 AI。选一个像wc这样“看着简单、其实有深度”的经典工具自己动手写一遍。过程中你会发现恐惧和不熟悉不是来自语法而是来自你太久没有对每一个细节负责。