简介面向初学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.hWindows 下注意目标文件不能正被其他程序打开。// 保存前先写 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 的支持并不是完整开启的。打开“工具→编译选项→编译器”在“编译时加入以下命令”里粘贴-stdc11 -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-charsetGBK -fexec-charsetGBK-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 项目里重复出现。本文还有配套的精品资源点击获取
