简介：面向初学C语言及课程设计的学生，这份DevC++通讯录管理系统项目完整覆盖通讯录的录入、显示、排序、查找、插入、删除与修改等核心功能；通讯录字段涵盖姓名、单位、手机、分类、EMAIL、QQ等，排序支持按姓名、单位、城市等多种方式，查找与修改均可按姓名快速定位，并扩展了按分类统计和文件保存/读取能力，可直接在DevC++中打开运行。资源包为RAR压缩格式，共7个文件，包含main.c源代码、DevC工程文件、CSV数据文件、可执行exe及编译中间文件，整体约51KB，轻量易用。已有128人学习/浏览。通过这个项目可以理解结构体数组、文件流操作、排序查找算法和模块化程序设计，非常适合K12阶段信息技术课程设计、C语言期末作业或自学练手；运行后还能直接查看录入数据在CSV中的变化，帮助快速掌握通讯录管理系统的完整实现思路。
1. 通讯录管理系统还值得写？它考的是三个被忽视的C语言基本功
“通讯录管理系统”是 C 语言练习里的老三样，但标题里的“2”说明你已经写完第一版：第一版能把联系人加上去、显示出来、草草存个文件；第二版要补齐的是别人看不到的部分——数据模型怎么组织、文件读不进来自动恢复、程序退出前占用的堆内存释放干净没有。DevC++ 这层环境又决定了很多坑和教室里的 Linux 不一样：编译器是 TDM-GCC，字符集和控制台编码都带着 Windows 特征，很多人程序跑到一半乱码或闪退，问题出在环境而不是逻辑。这篇按我维护课程设计和命令行小工具的习惯，把结构体设计、存储选型、文件读写、功能拆分完整走一遍，最后把 DevC++ 里的编译选项和调试技巧补齐。新手能跟完，写了几年 C 的也能带走两个参数和一种测试套路。
2. 通讯录数据模型：定长字段、结构体数组与链表的选择
2.1 联系人结构体的字段设计：先定宽度，再谈功能
通讯录系统的核心不是菜单，是Contact这个结构体。字段宽度决定了文件格式、查找方式、内存占用和后续所有函数的签名。我一般把字段宽度写成宏，而不是散落在结构体里的魔法数字：
#define NAME_LEN 32 #define PHONE_LEN 16 #define EMAIL_LEN 48 #define GROUP_LEN 12 #define REMARK_LEN 128 typedef struct { char name[NAME_LEN]; char phone[PHONE_LEN]; char email[EMAIL_LEN]; char group[GROUP_LEN]; char remark[REMARK_LEN]; } Contact;字段用定长数组而不是char *，这是一个刻意的选择。定长数组的优点是：文件读写直接按字节块处理，链表节点的增删不需要为每个字符串单独 malloc/free，调试器里展开节点能直接看到字符串内容。缺点是空间浪费，姓名 32 字节一般够用，备注 128 字节也不是特别宽裕。如果你要支持超长备注，就得把remark改成char *，并在写入文件前检查指针是否为空——这是第二版最容易漏掉的空指针来源。
phone不设计成数字类型是多数初版通讯录的教训。电话号码可能有+86、分机号、短号，用整数存会丢掉前导零和特殊字符。既然不是拿来计算的，就永远是字符串。同理，group字段用固定宽度，便于后续按分组排序时直接strcmp。
2.2 三种组织方式对比：静态数组、结构体数组和链表的边界
联系人存下来之后，用什么结构把它们串起来？三种常见方案各有限制，先看结论：
| 存储方式 | 插入/删除代价 | 查找复杂度 | 内存管理复杂度 | 典型容量 |
|---|---|---|---|---|
二维字符数组char arr[N][M] | 删除需整行搬移 | O(N)，且逐字节比较 | 无动态内存 | 适合姓名+号码两字段 |
结构体数组Contact arr[N] | 删除需 memmove 搬移 | O(N)，字段语义清晰 | 无需手动释放 | 几百条以内够用 |
| 单向链表 | 删除只需改指针 | O(N)，但缓存不友好 | 每个节点一次 malloc/free | 取决于堆上限 |
静态数组实现最简单，在 DevC++ 里跑课程设计完全没有问题：
#define MAX_CONTACTS 256 Contact contacts[MAX_CONTACTS]; // 全局数组，避免栈溢出 int contact_count = 0; // 当前联系人数量 int add_contact(Contact *c) { if (contact_count >= MAX_CONTACTS) { fprintf(stderr, "通讯录已满，当前上限 %d\n", MAX_CONTACTS); return -1; } contacts[contact_count++] = *c; // 结构体整体赋值 return 0; }结构体数组的方案里，contacts[contact_count++] = *c这行代码做了整块内存拷贝，比逐字段赋值可靠。MAX_CONTACTS用宏定义而不是写死 256，是因为第二版通常会加“导入导出”功能，导入前先检查行数有没有超上限。全局数组放在函数外面，避免在 main 的栈上分配几十 KB 导致 DevC++ 默认栈大小下出问题。
数组方案的容量是固定的，删除中间元素要memmove把后面所有元素前移一位，这在几百条数据时不是问题。但如果你的“通讯录管理系统 2”要求支持上万条数据导入，数组方案就要改成动态扩容：realloc时把容量翻倍，而不是每次加一条就扩容一次，否则插入复杂度退化成 O(N²)。这个优化放到最后一章再展开。
2.3 链表方案：增删自由的代价是释放与查找
链表在通讯录系统里最大的价值不是性能，而是让你练会两件事：指针的挂接和内存的释放。单向链表节点定义：
typedef struct Node { Contact data; struct Node *next; } Node; Node *create_node(const Contact *src) { Node *p = (Node *)malloc(sizeof(Node)); if (!p) { perror("malloc failed"); exit(EXIT_FAILURE); } p->data = *src; // 嵌套结构体整体拷贝 p->next = NULL; return p; }创建节点时，p->data = *src一次拷贝整个 Contact。这里有个细节：如果以后把Contact里的字段改成char *指向堆内存，这个函数就会变成浅拷贝，两个节点会指向同一块字符串内存，释放时导致 double free。所以定长字段在链表方案里同样是为了减少内存所有权问题。
删除链表节点最常见的错误是释放之后继续访问next。正确写法要先把后继指针保存下来：
Node *delete_by_name(Node *head, const char *name) { Node dummy; // 栈上的虚拟头节点 dummy.next = head; Node *cur = &dummy; while (cur->next) { if (strcmp(cur->next->data.name, name) == 0) { Node *victim = cur->next; // 先保存要释放的节点 cur->next = victim->next; // 先摘链 free(victim); // 再释放内存 break; } cur = cur->next; } return dummy.next; // 新链表头 }虚拟头节点是处理“删除的是头节点”情况的经典技巧，避免写if (head->name == ...) head = head->next这种特判分支。函数最后必须返回dummy.next，因为头节点可能被删掉了。调用方要把返回值重新赋给外部头指针，否则链表头就丢了。
链表的查找只能顺序遍历，这决定了它的适用场景：频繁插入删除、不经常按位置访问、数据量在千条以内。如果你的系统还要做按姓名排序，链表排序会比数组麻烦得多，所以很多通讯录项目最终选择数组。我的建议是：课程设计用结构体数组，代码量少、排错容易；想练指针和堆内存管理就选链表，但要把free_list写对。
3. 通讯录文件读写：竖线分隔文本比二进制更抗坑
3.1 文本还是二进制：可调试性优先
通讯录持久化有两种路线：文本文件和二进制文件。很多教材喜欢演示fwrite直接把结构体数组写进文件，几行代码搞定，读回来也是一个fread的事。但二进制格式的问题在于：结构体里有char数组，写入的是原始字节，文件无法用记事本或type命令检查；换一台编译器，结构体对齐方式变化，老文件可能就读不出来了。
| 维度 | 文本格式 | 二进制格式 |
|---|---|---|
| 可读性 | 可以直接查看、手工修改 | 乱码，无法肉眼检查 |
| 跨平台 | 换行符有差异，但可处理 | 结构体布局可能不兼容 |
| 坏数据恢复 | 一行读失败可跳过 | 一个字段错位整块报废 |
| 调试 | printf 可直接看到解析结果 | 必须用调试器看内存 |
| 存储大小 | 稍大，但通讯录规模无所谓 | 紧凑 |
通讯录这种规模的数据，文件大小根本不是瓶颈。文本格式最大的好处是：程序读不出来时，你可以打开文件看看到底是分隔符写错了，还是编码乱了。所以我在这里只用文本格式。
3.2 保存函数：用|做字段分隔符，逐行写入
写入函数设计成接收数组、数量和文件路径，不依赖全局变量，这样的函数可以单独做单元测试：
int save_to_file(const Contact *list, int count, const char *path) { FILE *fp = fopen(path, "w"); if (!fp) { perror("fopen for write"); return -1; } for (int i = 0; i < count; i++) { // 竖线分隔字段，避免姓名含空格导致按空格解析出错 fprintf(fp, "%s|%s|%s|%s|%s\n", list[i].name, list[i].phone, list[i].email, list[i].group, list[i].remark); } fclose(fp); return 0; }字段分隔符不用空格，因为姓名和备注里完全可能出现空格；用|是因为它极少出现在人名和电话号码里。如果哪天真有人把竖线写在备注里，解析函数要把这个字段过滤掉，或者改用\t。写入时没有显式保存总条数，因为读取时逐行数就行，少一条多一条都靠行数决定。
更稳妥的写入策略是：先写临时文件，全部成功后rename覆盖原文件。这样程序在写到一半崩溃时，原文件不会被截断成半截。DevC++ 环境里rename要包含<stdio.h>，Windows 下注意目标文件不能正被其他程序打开。
// 保存前先写 tmp 文件 save_to_file(list, count, "contacts.tmp"); remove(path); // Windows 下 rename 不覆盖旧文件，要手动删 rename("contacts.tmp", path);这个“先写临时文件再替换”的做法从课程设计到生产代码都成立，是文件写入最廉价的完整性保障。
3.3 读取函数：fgets 按行读，sscanf 按模式解析
读文件比写文件难一个量级，因为你要处理行尾、缺字段、坏行，还有 Windows 的 CRLF 换行。DevC++ 在文本模式打开文件时会把\r\n转成\n，但为了兼容性，读取函数里显式把\r和多余的换行去掉最稳妥：
int load_from_file(Contact *list, int cap, const char *path) { FILE *fp = fopen(path, "r"); if (!fp) return 0; // 文件不存在不报错，按空通讯录处理 char line[512]; int n = 0; while (fgets(line, sizeof(line), fp)) { line[strcspn(line, "\r\n")] = '\0'; // 去掉 \r 和 \n Contact c; int parsed = sscanf(line, "%31[^|]|%15[^|]|%47[^|]|%11[^|]|%127[^\n]", c.name, c.phone, c.email, c.group, c.remark); if (parsed == 5 && n < cap) { list[n++] = c; // 整条记录合法才加入 } else { fprintf(stderr, "第 %d 行格式错误，已跳过: %s\n", n + 1, line); } } fclose(fp); return n; }这里%31[^|]的意思是读取最多 31 个非竖线字符，正好对应name[32]的缓冲区，留一位给\0。每个字段的最大宽度必须和结构体定义一致，这是文本格式最容易踩的坑：结构体改宽了，这里忘了改，读入的字符串就会被截断。strcspn(line, "\r\n")是去掉行尾的标准写法，返回第一个匹配字符的下标，把它替换成\0。
坏行的处理原则是“跳过但告知”。如果一行里只有 4 个字段，parsed会返回 4，这段数据如果直接赋值会给用户留一个空字段。宁可舍弃这一行，也不能把错位数据混进列表里。这也是第二版和第一版的差别：第一版只要读出来就行，第二版要能容忍脏数据。
4. 通讯录功能模块：菜单循环、查找排序与内存收尾
4.1 菜单循环里的输入缓冲问题
功能拆分两步走：外层是死循环菜单，内层是 switch 分发。菜单本身不复杂，复杂的是scanf缓冲区里的残留换行。第一次输入数字后按回车，换行符留在缓冲区，下一次循环如果调gets或者scanf("%c")，读到的就是刚才那个换行，表现出来就是“菜单跳了一下”或者“跳过输入姓名”。
int main(void) { int choice; while (1) { printf("1.新增 2.删除 3.查找 4.修改 5.显示 0.保存并退出\n"); scanf("%d", &choice); // 清空本行剩余输入，防止残留换行影响后续 fgets int ch; while ((ch = getchar()) != '\n' && ch != EOF) ; if (choice == 0) break; switch (choice) { case 1: add_contact_interactive(); break; case 2: delete_contact_interactive(); break; case 3: search_contact_interactive(); break; case 4: modify_contact_interactive(); break; case 5: print_all(); break; default: printf("无效选项\n"); break; } } return 0; }while ((ch = getchar()) != '\n' && ch != EOF);这段是清空缓冲区的常规操作，比fflush(stdin)可靠。fflush(stdin)在标准 C 里是未定义行为，DevC++ 的 glibc 版本下可能正好有效，但换到别的编译器就失效了，这点在 DevC++ 写课程设计时尤其要提醒自己。
混用scanf和fgets的问题不止这一个。如果用户输入“1 2 3”再回车，scanf("%d")读到 1，清缓冲的循环把后面的字符全部丢掉，这时要提示用户重新选择。想让交互更友好，可以改成整行读入再解析，但代码量会上去，练习阶段先用清缓冲的方案就够了。
4.2 查找与排序：按姓名和分组两条路
查找是通讯录最高频的操作，按姓名精确匹配是基础功能：
int find_by_name(const Contact *list, int count, const char *name) { for (int i = 0; i < count; i++) { if (strcmp(list[i].name, name) == 0) { return i; // 返回数组下标 } } return -1; // 未找到 }返回下标而不是返回Contact *，是因为调用方经常需要在找到后执行修改或删除，拿到下标就能同时操作contacts[i]。如果要支持模糊查找，把strcmp换成strstr(list[i].name, name)即可，但strstr是子串匹配，名字“张”会把“张三”和“小张”都搜出来，提示语里要说清楚“包含”而不是“等于”。
排序用插入排序比冒泡更合适，因为插入排序在基本有序的数据上接近 O(N)，而且不需要额外空间。按姓名排字典序的示意：
void sort_by_name(Contact *list, int count) { for (int i = 1; i < count; i++) { Contact key = list[i]; int j = i - 1; while (j >= 0 && strcmp(list[j].name, key.name) > 0) { list[j + 1] = list[j]; // 后移 j--; } list[j + 1] = key; } }这段代码里Contact key = list[i]是一次整体拷贝，和链表章节里p->data = *src是同一套语义，理解了一个就理解了另一个。排序前先想清楚：联系人界面里显示的序号是数组下标，排完序后下标变掉了，界面上的“第几号联系人”要不要跟着更新？这种关联问题在第二版里很容易被忽略。
4.3 删除链表的边界条件与释放返回值
数组删除用 memmove 前移就完了，链表删除要复杂一点。链表改指针时，最经典的坑有三个：删掉的是头节点、删掉的是尾节点、删除后没有把新头传出去。前面第 2.3 节的delete_by_name用虚拟头节点把头节点特判消掉了，但调用方仍然要接住返回值：
Node *head = build_list_from_array(contacts, contact_count); head = delete_by_name(head, "张三"); // 必须接收返回值 print_list(head); free_list(head);如果漏了head =这一行，删掉头节点时外部指针还指向已释放的内存，下一次访问就是 use-after-free。DevC++ 的调试器不一定每次都能抓到这种错，表现往往是“有时候正常有时候崩”。
释放整个链表是个无趣但必须写对的函数：
void free_list(Node *head) { while (head) { Node *next = head->next; // 先存 next free(head); // 再释放当前 head = next; // 移到下一个 } }这轮写完心里要有数：malloc 和 free 的次数必须对等。链表方案里每个节点一次 malloc，释放次数要和创建次数一致。想知道有没有泄漏，最简单的方法是在main结尾加一行全局计数：malloc_count和free_count，每次都手动++，程序退出前打印两个数是否相等。这个方法土，但在 DevC++ 里比装内存检测工具更快。
5. DevC++ 调参、回归测试与调试宏，把课程设计收成可维护版本
5.1 先把编译参数调对
DevC++ 自带的编译器是 TDM-GCC，默认可能按 GNU 标准编译，但对 C99 的支持并不是完整开启的。打开“工具→编译选项→编译器”，在“编译时加入以下命令”里粘贴：
-std=c11 -Wall -Wextra-Wall -Wextra会把你漏掉的函数返回值、未使用的变量、比较类型不匹配全部警告出来。第一版你写的代码可能出来几十条警告，不要慌，一条条看，尤其是“uninitialized”和“implicit declaration”这两类，基本就是 bug 所在。.c文件后缀也要确认，DevC++ 有时会默认为.cpp，导致代码按 C++ 语法编译，malloc的返回值需要强转，写起来很别扭，还会掩盖NULL头文件没包含的问题。
5.2 中文乱码的根源与两个编码参数
Windows 控制台默认用 GBK，现代 GCC 默认按 UTF-8 解释源码。源码里printf("通讯录")是 UTF-8 字节，控制台按 GBK 解码，显示就乱码。解决方案有两种：要么把编辑器编码改成 GBK，要么给编译器传两个参数：
-finput-charset=GBK -fexec-charset=GBK-finput-charset告诉 GCC 源码本身是 GBK 编码；-fexec-charset告诉 GCC 生成的字符串常量也按 GBK 编码。两个一起用，程序在 Windows 控制台里就不会乱码。如果以后要把程序挪到 Linux 下跑，记得把这两个参数去掉，Linux 终端默认 UTF-8，留着反而乱。
5.3 用重定向做回归测试，用日志宏关掉调试输出
通讯录系统功能少，但菜单要一遍遍点。测试速度最快的办法不是手动点，而是把输入写到文件里，用重定向跑：
contact.exe < test1_in.txt > test1_out.txt fc test1_out.txt test1_expect.txt<把test1_in.txt的内容当作键盘输入，>把程序的 stdout 全部写进输出文件，fc是 Windows 下的文件比较命令，输出一致就说明这次测试通过。准备三个测试文件：正常增删查、空通讯录导出导入、坏行文件读入。这三条路径跑通，程序基本就稳了。
测试时如果程序里写了printf调试信息，这些信息会混进输出文件干扰fc比较。解决办法是给调试打印加一个编译开关：
#ifdef DEBUG #define LOG(fmt, ...) fprintf(stderr, "[DBG] " fmt "\n", ##__VA_ARGS__) #else #define LOG(fmt, ...) ((void)0) #endif日常加断点查看时，在文件开头写#define DEBUG就行；跑回归测试时把它注释掉，LOG展开成空操作，stdout 只剩业务输出。之所以用 stderr 而不是 stdout，是因为重定向2>可以单独把调试日志导到另一个文件，测试比较完全不受影响。这个宏在通讯录这个规模下有点杀鸡用牛刀，但它教会你的模式——用宏控制代码段开合——会在后续所有 C 项目里重复出现。
本文还有配套的精品资源，点击获取
