简介：这份C语言课程设计ATM机源代码面向高校计算机相关专业学生及C语言初学者，用于课程设计、期末大作业或自学练手，帮助读者理解如何用C语言实现一个具备完整业务逻辑的小型管理系统。资源包共3个文件，以cpp源代码为主，另附2个txt文本文件，分别用于存放账户信息与密码数据，压缩包整体约2KB，体量轻巧，便于快速阅读与二次修改。代码实现了登录、查询余额、取款、转账和存款五项核心功能，其中取款环节对金额是否超出余额做了校验，转账与存款则涉及账户数据的读写操作，适合用来学习结构体、文件读写、循环与条件判断等知识点的综合运用。目前已有579人学习下载，读者可借此参考账户验证流程、菜单交互设计与数据持久化思路，并在此基础上扩展修改密码、交易记录查询等功能，作为课程设计答辩的起点较为实用。

1. 从一份 C 语言课程设计 ATM 机源码说起：它到底能帮你省下多少时间

如果你正在做 C 语言课程设计，选题又恰好是“ATM 机模拟系统”，那你大概率已经体会过那种感觉：需求文档看懂了，结构体也学了，文件操作也背了，但真要从零搭出一个能跑、能存、能取、能查、还能改密码的完整系统，脑子里还是一团乱麻。这份 C 语言课程设计 ATM 机源代码，解决的就是这个“从会语法到能交付”之间的断层。它不是那种只打印几行菜单的玩具代码，而是一个带账户结构体、文件持久化、密码校验、存取款流水和基础异常拦截的完整控制台程序，适合两类人：一类是时间紧、需要快速吃透课程设计评分点的同学，另一类是想拿一份能编译、能演示、能改造成自己版本的小型 C 项目练手的人。你拿到手之后，最该做的不是直接复制，而是先跑通、再拆结构、最后按自己的需求改参数。

2. 先跑通再拆解：ATM 源码的编译链路与模块地图

2.1 拿到源码后的第一件事：确认编译环境与文件清单

很多人拿到压缩包之后第一反应是双击 .c 文件，结果编译器报一堆错，心态直接崩。常见做法是先把源码目录理清楚。一个标准的 C 语言 ATM 课程设计，通常包含这几个文件：主程序入口（main.c）、账户操作模块（account.c / account.h）、文件读写模块（file_io.c / file_io.h）、界面菜单模块（menu.c / menu.h），以及一个存放账户数据的文本文件（accounts.txt 或 data.dat）。有些版本会把所有函数塞进一个 .c 文件里，这种更适合新手快速理解，但不利于后期扩展。

我一般会建议先看目录里有没有 Makefile 或者 README。如果没有，就手动确认三件事：第一，源码用的是标准 C 还是带了 Windows 特有头文件（比如 conio.h、windows.h）；第二，数据文件是相对路径还是绝对路径；第三，有没有用到中文输出。这三件事直接决定你能不能在三分钟内跑起来。

# 先看目录结构，确认文件数量和类型 ls -la # 如果看到 .c .h 和 .txt/.dat 文件，说明是标准的多文件结构 # 统计代码行数，心里有个数 wc -l *.c *.h

上面这段命令的作用是快速摸清项目规模。如果总行数在 500 到 1500 行之间，说明这是一个典型的课程设计体量，结构不会太复杂。如果超过 3000 行，那可能带了图形界面或者额外功能，需要更多时间消化。参数方面，ls -la里的-a是为了看到隐藏文件，有些源码包会把数据文件设成隐藏属性；wc -l用来统计行数，方便你判断阅读优先级。

2.2 编译命令与常见报错的第一轮排查

确认文件清单之后，下一步就是编译。Linux 和 macOS 下用 gcc，Windows 下用 MinGW 或者 Dev-C++ 自带的编译器。我一般会先试最朴素的编译方式，看看能不能过。

# 最基础的多文件编译命令 gcc -o atm main.c account.c file_io.c menu.c -I. # 如果报错提示找不到某个函数，大概率是头文件没包含或者源文件漏了 # 加上 -Wall 可以看到更详细的警告信息 gcc -Wall -o atm main.c account.c file_io.c menu.c -I.

这段编译命令的逻辑是：把所有 .c 文件一起编译链接成可执行文件atm，-I.表示在当前目录查找头文件。-Wall的作用是打开所有警告，很多课程设计源码在变量未初始化、函数隐式声明这些问题上会暴露出来，提前看到警告比运行时崩溃要好得多。

如果编译报错集中在conio.h或者gotoxy这类函数上，说明源码是 Windows 风格的，在 Linux 下需要替换成标准输入输出或者用 ncurses 库。常见做法是找到调用getch()的地方，改成getchar()，虽然交互体验会差一点，但至少能跑通。如果报错是“undefined reference toxxx”，那基本就是某个 .c 文件没加到编译命令里，补上就行。

提示：编译通过之后先别急着改代码，用默认账号跑一遍完整流程，确认存款、取款、查询、改密、退出这五个核心功能都能正常走通，再动手改。

2.3 账户结构体与文件持久化的设计逻辑

跑通之后，第二个要拆的就是数据结构。ATM 课程设计的核心结构体通常长这样：

// 典型的账户结构体定义 typedef struct { char card_no[20]; // 卡号，字符串存储避免前导零丢失 char password[20]; // 密码，课程设计级别通常明文或简单加密 double balance; // 余额，用 double 保证精度够用 int status; // 账户状态，0 正常 1 冻结 2 销户 } Account; // 文件存储格式一般是每行一个账户，字段之间用空格或逗号分隔 // 例如：10001 123456 5000.00 0

这个结构体的设计直接决定了后续所有操作的边界。卡号用字符数组而不是整数，是为了防止“001”变成“1”这种经典翻车。密码字段在课程设计里通常是明文存储，但如果你想让答辩老师眼前一亮，可以加一个简单的异或加密或者哈希映射，改动量不大，但能体现安全意识。余额用 double 而不是 float，是因为 float 在多次存取之后会出现精度漂移，比如 0.1 + 0.2 不等于 0.3 这种玄学问题，在金融场景里是致命的。

文件持久化的逻辑一般是：程序启动时把所有账户从文件读进内存数组，所有操作在内存里完成，退出或每次变更后写回文件。这里有个血泪经验：很多源码只在退出时写回，结果程序崩溃或者强制关闭，当天的操作全丢。稳妥的做法是每次存款、取款、改密之后立刻写回文件，虽然多几次磁盘 IO，但数据安全得多。

// 每次变更后立即写回文件的简化逻辑 void save_accounts(Account *accounts, int count) { FILE *fp = fopen("accounts.txt", "w"); if (fp == NULL) { printf("数据文件写入失败，请检查权限\n"); return; } for (int i = 0; i < count; i++) { fprintf(fp, "%s %s %.2f %d\n", accounts[i].card_no, accounts[i].password, accounts[i].balance, accounts[i].status); } fclose(fp); }

这段代码的关键点在于fprintf的格式字符串要和读取时的fscanf严格对应，否则会出现读进来字段错位的问题。%.2f保证余额只保留两位小数，避免文件里出现一长串浮点尾数。fclose不能漏，否则缓冲区不刷新，文件内容可能是空的。

3. 核心功能模块的代码拆解：从登录到流水记录

3.1 登录校验与密码错误次数限制

登录模块是整个系统的入口，也是课程设计评分里最容易拿分的地方。一个合格的登录逻辑要包含：卡号存在性检查、密码匹配、账户状态检查、错误次数限制。很多简易版本只做了密码匹配，结果答辩时被问“如果卡号不存在怎么办”就卡住了。

// 登录校验的完整逻辑 int login(Account *accounts, int count, int *current_index) { char input_card[20]; char input_pwd[20]; int attempts = 0; while (attempts < 3) { printf("请输入卡号："); scanf("%s", input_card); printf("请输入密码："); scanf("%s", input_pwd); for (int i = 0; i < count; i++) { if (strcmp(accounts[i].card_no, input_card) == 0) { if (accounts[i].status != 0) { printf("该账户已冻结或销户，请联系柜台\n"); return -1; } if (strcmp(accounts[i].password, input_pwd) == 0) { *current_index = i; return 0; // 登录成功 } else { attempts++; printf("密码错误，剩余尝试次数：%d\n", 3 - attempts); break; } } } // 如果循环走完都没找到卡号 if (attempts == 0) { printf("卡号不存在，请重新输入\n"); } } printf("错误次数过多，账户已锁定\n"); return -1; }

这段代码的逻辑说明：外层while控制最多三次尝试，内层for遍历所有账户查找匹配卡号。找到卡号后先检查状态，再比对密码。密码错误时attempts自增并break跳出内层循环，回到外层继续。如果卡号不存在，attempts不变，但会提示重新输入。参数方面，current_index用指针传出，是为了让后续的存款取款操作知道当前操作的是哪个账户。strcmp返回 0 表示字符串相等，这是 C 语言里最容易写反的地方，记住“0 就是相等”。

注意：scanf("%s", input_card)存在缓冲区溢出风险，如果输入超过 19 个字符会覆盖相邻内存。课程设计级别可以接受，但如果你想写得规范一点，改成fgets或者限制宽度scanf("%19s", input_card)。

3.2 存款、取款与余额更新的边界处理

存款和取款看起来简单，但边界条件特别多。存款要拦截负数金额和超大金额，取款要拦截余额不足、金额不是整数倍、单次超额等情况。这些细节就是课程设计能不能拿优秀的关键。

// 存款操作 void deposit(Account *acc) { double amount; printf("请输入存款金额："); scanf("%lf", &amount); if (amount <= 0) { printf("存款金额必须大于零\n"); return; } if (amount > 50000) { printf("单次存款不能超过 50000 元\n"); return; } acc->balance += amount; printf("存款成功，当前余额：%.2f 元\n", acc->balance); save_accounts(accounts, account_count); // 立即写回 } // 取款操作 void withdraw(Account *acc) { double amount; printf("请输入取款金额："); scanf("%lf", &amount); if (amount <= 0) { printf("取款金额必须大于零\n"); return; } if ((int)amount % 100 != 0) { printf("取款金额必须是 100 的整数倍\n"); return; } if (amount > acc->balance) { printf("余额不足，当前余额：%.2f 元\n", acc->balance); return; } if (amount > 20000) { printf("单次取款不能超过 20000 元\n"); return; } acc->balance -= amount; printf("取款成功，当前余额：%.2f 元\n", acc->balance); save_accounts(accounts, account_count); }

存款逻辑里，amount <= 0拦截负数，amount > 50000拦截异常大额。取款逻辑里，(int)amount % 100 != 0判断是否为百元整数倍，这是 ATM 模拟的常见约束。amount > acc->balance拦截余额不足。每次操作后调用save_accounts立即持久化，避免数据丢失。参数方面，acc是指向当前登录账户的指针，直接修改结构体内容，不需要返回值。

这里有个容易忽略的点：scanf("%lf", &amount)里的%lf是 double 的格式符，如果写成%f会导致读取错误，金额变成乱码。这是 C 语言里经典的翻车点，编译不报错，运行时才出问题。

3.3 查询、改密与交易流水的实现方式

查询功能一般分两种：查余额和查流水。查余额简单，直接打印acc->balance就行。查流水就需要额外维护一个交易记录数组或者链表，每次存款取款都追加一条记录。

// 交易记录结构体 typedef struct { char card_no[20]; char type[10]; // "存款" 或 "取款" double amount; double balance_after; char time_str[30]; // 时间字符串 } Transaction; // 追加一条交易记录 void add_transaction(Transaction *trans, int *trans_count, const char *card_no, const char *type, double amount, double balance_after) { strcpy(trans[*trans_count].card_no, card_no); strcpy(trans[*trans_count].type, type); trans[*trans_count].amount = amount; trans[*trans_count].balance_after = balance_after; time_t now = time(NULL); struct tm *t = localtime(&now); strftime(trans[*trans_count].time_str, 30, "%Y-%m-%d %H:%M:%S", t); (*trans_count)++; }

改密功能要注意两点：第一，新密码要确认两次，防止输错；第二，改密后要立即写回文件。很多源码改密只改内存不写文件，重启之后密码又变回去了，这种 bug 在演示时特别尴尬。

交易流水的实现方式取决于你的数据结构课掌握程度。用固定大小数组最简单，但超过容量会溢出；用链表更灵活，但代码量大。课程设计级别，我一般建议用数组加计数器，容量设 1000 条，足够演示用。strftime用来格式化时间字符串，%Y-%m-%d %H:%M:%S是标准格式，注意time_str数组要留够空间，30 个字符是安全值。

4. 避坑与排查：ATM 课程设计里最容易翻车的五个地方

4.1 文件读写格式不匹配导致数据错乱

现象：程序启动后读到的账户数据全是乱的，卡号变成数字，余额变成 0。原因：写入时用fprintf(fp, "%s %s %.2f %d\n", ...)，读取时用fscanf(fp, "%s %s %f %d", ...)，%f和%lf不匹配，或者字段顺序写反了。解决：把写入和读取的格式字符串放在一起对照，确保类型和顺序完全一致。稳妥做法是写一个read_accounts函数和save_accounts函数，两者格式字符串逐字段核对。

4.2 字符串数组越界导致程序崩溃

现象：输入较长的卡号或密码后，程序直接闪退或者输出乱码。原因：char card_no[20]只能存 19 个字符加一个结束符，scanf("%s", card_no)不限制长度，输入超长字符串会覆盖相邻内存。解决：把scanf("%s", ...)改成scanf("%19s", ...)，或者用fgets读取后手动去掉换行符。所有字符数组都要留至少一个字节给\0。

4.3 余额用 float 导致精度漂移

现象：连续存取几次之后，余额出现 0.000001 这样的尾数，对账对不上。原因：float 是单精度浮点，十进制小数在二进制里无法精确表示。解决：把float balance改成double balance，输出时用%.2f格式化。如果对精度要求更高，可以用整数存“分”，显示时除以 100。

4.4 登录后未校验账户状态

现象：已经冻结或销户的账户还能正常登录和取款。原因：登录逻辑只比对了密码，没有检查status字段。解决：在密码匹配成功后加一层if (accounts[i].status != 0)判断，冻结和销户账户直接拒绝登录。这个点在答辩时经常被问到，加上之后能体现业务完整性。

4.5 修改密码后未同步写回文件

现象：改密后当前会话能用新密码，重启程序后旧密码又生效了。原因：改密函数只修改了内存中的结构体，没有调用save_accounts。解决：在改密成功后立即调用写回函数，和存款取款保持一致。养成“任何变更立即持久化”的习惯，能避免大部分数据不一致问题。

5. 进阶改造与验证：让这份 ATM 源码真正变成你的作品

跑通、拆完、避过坑之后，如果你想让这份课程设计从“及格”变成“优秀”，有几个改动方向成本低但效果明显。第一个是加一个管理员模式，用独立密码进入，可以查看所有账户、冻结解冻、重置密码。这个功能在答辩时很加分，因为它体现了权限分级的思想。实现方式是在主菜单加一个隐藏入口，比如输入卡号时输入admin，然后走另一套逻辑。

第二个是给密码加一层简单加密。不用上 AES 那么重，一个异或加密就够：

// 简单的异或加密，密钥可以设成固定值 void encrypt_password(char *pwd) { char key = 0x5A; for (int i = 0; pwd[i] != '\0'; i++) { pwd[i] ^= key; } } // 存储前调用一次，读取后调用一次，两次异或还原

这段代码的逻辑是：对密码每个字符和固定密钥做异或运算，存储加密后的结果。读取时再异或一次就还原了。参数key可以改成从配置文件读取，但课程设计级别固定值就够了。注意加密后的字符串可能包含不可打印字符，如果直接写进文本文件会出问题，所以要么用二进制模式存储，要么把加密结果转成十六进制字符串再存。

第三个是加一个简单的日志系统，把每次操作的时间、卡号、类型、金额追加到log.txt里。这个改动只需要在add_transaction里多写一行fprintf，但能让你的项目看起来专业很多。验证方法也很简单：跑一遍完整流程，然后打开log.txt看记录是否完整、时间是否正确、金额是否对得上。

我自己的习惯是，每次改完一个功能，就删掉数据文件重新初始化一遍，从登录到退出完整走一次，确认没有回归问题。这个习惯帮我拦住了至少三次“改 A 功能弄坏 B 功能”的翻车。从那以后我每次交付课程设计之前，都强制走一遍“删数据、重编译、全流程”的检查，希望帮到你。

本文还有配套的精品资源，点击获取