C语言课程设计ATM机源代码：从能跑到能交的完整方案

简介：这份C语言课程设计ATM机源代码面向正在学习C语言、需要完成课程设计或想通过小项目巩固语法与逻辑的在校学生。代码围绕模拟银行ATM的核心业务展开，涵盖用户登录验证、余额查询、取款、转账与存款五项功能，其中取款环节对金额与余额关系做了约束判断，转账则涉及多账户间的数据交互，适合用来练习结构体、数组、文件读写与菜单循环等知识点。压缩包共3个文件，以cpp源代码为主，另附两个txt文本用于存放账户名、密码及客户数据，整体仅2KB，体量轻便，便于快速阅读与二次修改。目前已有579人学习下载，可作为课程设计参考或入门练手素材，帮助读者理解小型管理系统的模块划分与数据组织方式。

1. 从一份“能跑但不敢交”的ATM课设说起

每年课程设计季，总有人拿着一个能编译、能存取款、但一被追问就说不清逻辑的C语言ATM机程序来找我。问题不在代码能不能跑，而在于它没有“方案感”：需求没写清、模块没切开、异常没兜住，答辩时老师随便问一句“密码输错三次怎么处理”就露馅。这份C语言课程设计ATM机源代码要解决的，正是从“能跑”到“能交、能讲、能改”的落差。它适合两类人：一是第一次做课程设计、需要一套完整结构照着搭的学生；二是带课设、想找一份可拆解参考实现的助教或开发者。下面我按需求、设计、实现、避坑、验收的顺序，把这份源码拆成一份可以直接参考的完整方案。

2. 需求与总体设计：把ATM拆成账户、交易、界面三层

2.1 先立需求边界，别一上来就写main

课程设计最容易翻车的地方，是拿到题目直接开写main，写到一半发现“转账要不要校验对方账户”“挂失后还能不能取款”这些规则没定，只能回头改结构。我一般会先花半小时把需求边界钉死，这份ATM源码对应的需求通常收敛为下面几类，写进设计文档第一页就能挡住答辩一半的追问。

把这张表当成“需求基线”，后面每个函数都能对应到某一行，答辩时被问“这个功能为什么这么设计”，直接指回表格即可。需求里没写的细节，比如取款上限、明细保留条数，通常的做法是设成宏定义放在头文件里，既方便改，也显得有工程意识。

2.2 三层结构：数据层、业务层、界面层各管什么

这份源码的总体架构我建议按三层切，不是为了炫技，而是为了让每个.c文件职责单一，出问题能快速定位。数据层负责账户和交易记录的持久化，业务层封装存取款、转账、校验等规则，界面层只做菜单渲染和输入输出，三层之间通过函数调用单向依赖，界面层不直接碰文件。

atm/ ├── include/ │ ├── account.h // 账户结构体与账户操作声明 │ ├── transaction.h // 交易记录结构体与流水操作 │ └── ui.h // 菜单与输入输出声明 ├── src/ │ ├── main.c // 程序入口，主循环 │ ├── account.c // 账户增删改查、密码校验 │ ├── transaction.c // 存取款、转账、流水写入 │ └── ui.c // 菜单、提示、输入解析 └── data/ ├── accounts.dat // 账户数据文件 └── trans.log // 交易流水文件

这样切的好处很直接：账户结构体只出现在account.h，交易逻辑只依赖账户接口，界面层换一套菜单样式不影响业务代码。很多课设把全部逻辑塞进一个main.c，改一个提示语都要翻三百行，答辩时老师让“加一个修改密码功能”，当场就卡住。分层之后，加功能就是加一个函数加一个菜单项，改动面可控。

2.3 核心数据结构：账户与交易记录怎么定义

数据结构定得好，后面一半的坑自动消失。账户结构体我一般会带上状态位和错误计数，交易记录单独成结构，用文件追加写的方式落盘。下面这段是账户定义的关键部分，字段含义写在注释里，答辩时可以直接讲。

// include/account.h #define MAX_ACCOUNTS 100 // 最大账户数，课设规模够用 #define PWD_LEN 7 // 6位密码 + 结束符 #define NAME_LEN 32 typedef enum { ACC_NORMAL = 0, // 正常 ACC_FROZEN = 1, // 密码错误锁定 ACC_LOST = 2 // 挂失 } AccStatus; typedef struct { char card_no[20]; // 卡号，唯一主键 char name[NAME_LEN]; // 户名 char pwd[PWD_LEN]; // 密码，课设阶段明文存储 double balance; // 余额，单位元 AccStatus status; // 账户状态 int err_count; // 连续密码错误次数 } Account;

这里有两个设计取舍值得说。第一，status用枚举而不是多个布尔字段，挂失和锁定互斥，枚举天然表达“同一时刻只有一种状态”，比is_frozen加is_lost两个变量不容易出矛盾。第二，err_count放在账户里而不是全局变量，因为锁定是针对单个账户的，全局计数会导致“A账户输错把B账户锁了”这种玄学问题。密码明文存储是课设阶段的常见简化，如果想让方案更完整，可以在设计文档里注明“生产环境应存哈希”，这一句往往能加分。

3. 模块实现：从开户到转账的关键代码与设计说明

3.1 账户模块：开户、校验与密码错误锁定

账户模块是整个系统的基础，开户要保证卡号唯一，登录要处理密码错误计数，锁定后要拒绝所有交易。下面这段是登录校验的核心逻辑，把“查账户、判状态、比密码、计数、锁定”五步串起来，每一步失败都有明确返回码，界面层据此给提示。

// src/account.c int account_login(const char *card_no, const char *pwd, Account *out) { int idx = find_account(card_no); // 按卡号查下标，-1表示不存在 if (idx < 0) return ERR_NO_ACCOUNT; Account *acc = &g_accounts[idx]; if (acc->status == ACC_LOST) return ERR_ACCOUNT_LOST; if (acc->status == ACC_FROZEN) return ERR_ACCOUNT_FROZEN; if (strcmp(acc->pwd, pwd) != 0) { acc->err_count++; // 只累加当前账户 if (acc->err_count >= 3) { acc->status = ACC_FROZEN; // 达到3次直接锁定 save_accounts(); // 状态变更立即落盘 return ERR_PWD_LOCKED; } save_accounts(); return ERR_PWD_WRONG; } acc->err_count = 0; // 登录成功清零 save_accounts(); *out = *acc; // 拷贝一份给上层用 return OK; }

这段代码的设计说明有三点。返回码用宏定义而不是直接返回0/1，界面层可以区分“密码错”和“账户锁定”，提示语更准确，答辩时也能讲出“错误分类”的意识。状态变更后立刻调用save_accounts()，是为了防止程序异常退出导致锁定状态丢失，这是很多课设忽略的点，老师一问“锁定后重启程序还锁不锁”就能看出差别。*out = *acc拷贝而不是返回指针，避免上层误改全局数组，属于防御性写法，成本很低但显得考虑周全。

3.2 交易模块：存取款、转账与流水落盘

交易模块的关键是“先校验、再改余额、最后写流水”，三步顺序不能乱。以取款为例，金额必须是100的整数倍、不能超过余额、账户状态正常，三个条件都过了才动余额。下面这段把校验和流水写入放在一起，流水用追加模式写文本文件，方便直接打开查看。

// src/transaction.c int do_withdraw(const char *card_no, double amount) { if (amount <= 0 || (int)amount % 100 != 0) return ERR_AMOUNT_INVALID; int idx = find_account(card_no); if (idx < 0) return ERR_NO_ACCOUNT; Account *acc = &g_accounts[idx]; if (acc->status != ACC_NORMAL) return ERR_ACCOUNT_STATE; if (acc->balance < amount) return ERR_BALANCE_LOW; acc->balance -= amount; // 先改内存余额 save_accounts(); // 再落盘账户 write_trans(card_no, "WITHDRAW", amount, acc->balance); // 最后写流水 return OK; }

write_trans内部用fopen(path, "a")追加写，每行格式为“时间 卡号 类型 金额 余额”，这样即使程序崩溃，已完成的交易流水也不会丢。转账则是两次余额变更加两条流水，中间要校验对方账户存在且状态正常，任何一步失败就回滚内存余额，不能出现“扣了钱没到账”的情况。这里有个血泪经验：转账的两次save_accounts()最好合并成一次，先改两个账户的内存余额，再统一落盘，否则写到一半断电会出现账不平。课设阶段虽然不要求处理断电，但设计文档里写一句“转账采用先改内存后统一落盘”，答辩时是个加分点。

3.3 界面层与主循环：菜单状态机怎么组织

界面层最忌讳写成一堆if-else嵌套，主循环里套着登录循环、登录循环里套着业务循环，读起来像迷宫。我一般用“状态机 + 函数表”的方式组织，主循环只负责读输入、分发到对应处理函数，每个处理函数返回下一个状态。下面是一个简化的主循环骨架。

// src/main.c typedef enum { ST_WELCOME, ST_LOGIN, ST_MENU, ST_EXIT } State; int main(void) { load_accounts(); // 启动时加载账户文件 State st = ST_WELCOME; char cur_card[20] = {0}; // 当前登录卡号 while (st != ST_EXIT) { switch (st) { case ST_WELCOME: st = ui_welcome(); break; case ST_LOGIN: st = ui_login(cur_card); break; case ST_MENU: st = ui_menu(cur_card); break; default: st = ST_EXIT; break; } } save_accounts(); // 退出前兜底落盘 return 0; }

状态机的价值在于“任何时刻程序处于哪个界面”是显式的，调试时打印一下st就知道卡在哪。ui_login内部调用account_login，成功返回ST_MENU并写入cur_card，失败留在ST_LOGIN或回ST_WELCOME。ui_menu根据用户选择调用交易函数，处理完回到ST_MENU。这种写法比嵌套循环清晰得多，加一个“修改密码”菜单项只需要在ui_menu里加一个分支，主循环完全不用动。输入解析上，我习惯用fgets读整行再sscanf解析，避免scanf残留换行符导致的“菜单跳两下”问题，这个坑后面避坑章节还会提。

4. 避坑与排查：课设里最容易翻车的五个点

4.1 现象：菜单输入后直接跳过，像“自动连点”

原因几乎都是scanf("%d", &choice)后面跟getchar()或fgets混用，scanf把回车留在缓冲区，下一次读字符串直接读到空行。解决方式是统一用fgets读整行，再用sscanf解析数字，或者每次scanf后清空缓冲区。我一般直接封装一个read_int()函数，内部fgets加sscanf，全项目只用它读数字，从源头堵住。

4.2 现象：重启程序后余额回到初始值，交易白做

原因是只改了内存里的g_accounts，没有在每次余额变更后落盘，或者落盘函数写错了路径。排查时先看save_accounts()的fopen返回值，很多课设不检查返回值，目录不存在时静默失败。解决方式是每次状态变更后立即save_accounts()，并在fopen失败时打印错误码。另外数据文件路径建议用相对路径加固定目录，别用绝对路径，换台机器就找不到文件。

4.3 现象：密码输错三次锁定了，但换个卡号再输错，前一个账户也锁了

原因是错误计数用了全局变量，或者err_count没跟着账户走。解决方式是把err_count放进Account结构体，登录校验只操作当前账户的计数，登录成功清零。这个坑很隐蔽，因为单账户测试时完全正常，多账户才暴露，答辩时老师如果让“开两个账户互相验证”，没改的话当场翻车。

4.4 现象：转账后两边余额加起来对不上，或者出现负数

原因是转账只扣了转出方没加接收方，或者校验顺序错了，先加后扣导致中间状态被其他逻辑读到。解决方式是转账函数里先校验双方账户状态和转出方余额，再同时改两个账户的内存余额，最后统一落盘。任何校验失败直接返回，不动余额。调试时可以在转账前后打印两个账户余额，一眼看出哪步漏了。

4.5 现象：程序在某个操作后直接崩溃，没有任何提示

最常见的是数组越界和空指针。账户数组固定大小MAX_ACCOUNTS，开户时不判满，第101个账户写越界；或者find_account返回-1后没判断就直接g_accounts[idx]。解决方式是在所有数组访问前判下标范围，find_account的返回值必须判断，开户前判g_account_count < MAX_ACCOUNTS。课设阶段可以不开编译优化，配合-fsanitize=address跑一遍，越界和野指针基本无处遁形。

5. 验收与答辩：怎么证明这套ATM真的能交

验收这件事，我一般分两步走：先自己按清单跑一遍，再模拟答辩被追问。自测清单不用长，但每条都要能复现，下面这张表是我带课设时常用的验收项，照着跑一遍，大部分低级问题当场暴露。

答辩环节，老师最爱问的无非三类：为什么这么设计、异常怎么处理、能不能加功能。第一类用第2章的需求表和分层图回答，重点讲“为什么账户状态用枚举”“为什么错误计数放账户里”。第二类直接翻避坑章节，把“密码锁定后重启还锁不锁”“转账中途失败怎么办”讲清楚，比背代码有用。第三类现场加功能是常见套路，比如“加一个修改密码”，这时候分层结构就体现价值了：在account.c加一个change_pwd函数，在ui_menu加一个菜单项，主循环不动，五分钟能演示完。如果代码全塞在main.c，现场改就是灾难。

还有一个技巧：答辩前把数据文件清空，从开户开始完整演示一遍，别用预置数据。老师看的是流程完整性，不是数据多少。演示时故意输错一次密码、故意取一笔超额的钱，把异常分支主动亮出来，比等着被问更从容。从那以后我每次带课设验收，都强制自己先按清单跑一遍再让学生演示，因为自己跑的时候能发现“预置数据掩盖了开户逻辑没写”这种问题。希望这份拆解帮到你，把这份C语言课程设计ATM机源代码当成骨架，按你的需求表往里填肉，交出去的东西才站得住。

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