简介：武汉理工大学计算机基础与编程实验课程中的网吧计费管理系统项目包，面向高校计算机基础与编程课程的学习者与课程设计参考者，围绕网吧计时收费、上机管理与超级管理员扩展功能展开，帮助读者理解一个完整小型管理系统的需求拆解与代码组织方式。压缩包共325个文件、约33.1MB，包含9个c源文件、10个h头文件、2个vcxproj工程文件与2个exe可执行程序，另有obj、ipch、tlog、pdb等编译与调试中间文件，以及sample样例数据和txt说明文档，便于直接运行、对照阅读与二次修改。目前已有3179人学习下载。项目保留较完整的Visual Studio工程结构与构建产物，读者可据此复现计费规则、上机时长控制、用户与管理员权限区分等模块，并参考超级管理员功能的扩展思路，适合作为课程实验报告、课程设计或小型管理系统入门练手的对照材料。
1. 从“菜单能跑”到“账面能对上”：网吧计费管理系统在计算机基础与编程实验里真正要交的东西
机房最后一排，一个同学指着屏幕问我：上机两个半小时，为什么扣了三次钱。这是网吧计费管理系统这类计算机基础与编程实验课设里最典型的翻车现场：菜单循环能跑、增删改查能演示、登录登出都正常，可一碰到跨零点、跨费率时段、余额不足自动下机、程序被强杀这些边界，账目立刻对不上。这套方案要交付的不是一个会打印菜单的控制台作业，而是一个角色边界清晰、每一笔钱都能倒推出来的完整课设：普通用户上机下机查余额，管理员管机位和账单，超级管理员改费率、强制下机、冲正错账并留下审计痕迹。适合正在做 C 语言课程设计、需要一份讲得清设计取舍、也扛得住答辩追问的人。
2. 需求与角色建模：上机、下机、计费、超级管理员四条主线的边界划分
课设的需求文档通常写得很薄，一页纸列十几条功能就完了。真正决定后面代码好不好写的，是把这十几条功能归到四条主线上：谁在上机、钱怎么算、账怎么存、谁能改规则。这四条线各自的边界划清楚了，模块划分几乎自动就出来了。
2.1 三个角色与一张权限矩阵
最省事的写法是用一个isAdmin布尔量区分所有人，登录成功判断一下真假，然后进两套菜单。这个写法在前半学期没问题，一旦题目要求扩展超级管理员，就会立刻露馅：布尔量只能表达“是”和“不是”，表达不了“管理员能开机能下机但不能改费率”这种分级关系。我的处理方式是把角色定义成有序的等级，权限判断统一走一张表，而不是散落在每个菜单的if里。
三者的性质其实不一样。普通用户是“被规则约束的人”，他的所有操作都在自己的卡内闭环；管理员是“按规则执行的人”，他能操作别人的卡和机位，但改不了规则本身；超级管理员是“能改规则的人”，费率、起步价、免费时长这些参数动一下，全场的账都会跟着变，所以他的每一个动作都必须留痕。把这三者当成权限轴上的三个刻度，而不是两种身份，后面的代码会干净很多。
| 功能 | 普通用户 | 管理员 | 超级管理员 |
|---|---|---|---|
| 查询本人余额与账单 | 允许 | 允许 | 允许 |
| 本人上机 / 下机 | 允许 | 允许 | 允许 |
| 代他人开机、强制下机 | 禁止 | 允许 | 允许 |
| 查看全场账单、按卡号检索 | 禁止 | 允许 | 允许 |
| 开户、挂失、补办卡 | 禁止 | 允许 | 允许 |
| 修改费率、起步价、免费时长 | 禁止 | 禁止 | 允许 |
| 账单冲正（退钱撤销） | 禁止 | 禁止 | 允许 |
| 查看审计日志 | 禁止 | 禁止 | 允许 |
这张表建议直接抄进课设文档的“权限设计”一节，答辩时被问到“超级管理员和普通管理员到底差在哪”，指着表念就行，比临场解释靠谱得多。
2.2 计费状态机：一张卡在系统里只有五种状态
状态乱是这类系统最常见的病根。一张卡在数据库里同时有isOnline、isFrozen、hasUnpaid三个标记，组合起来就是八种情况，代码里到处写if (online && !frozen)，改一次需求就要崩一次。正确做法是把状态收敛成单值枚举，任何时刻一张卡只可能处在五种状态之一。
/* card.h —— 单值状态，避免多个布尔量组合出非法状态 */ enum { ST_IDLE = 0, /* 空闲，可以上机 */ ST_ONLINE = 1, /* 上机中，有开始时间无结束时间 */ ST_SETTLING= 2, /* 结算中，过渡态，防重复扣费 */ ST_FROZEN = 3, /* 冻结，挂失或欠费，禁止上机 */ ST_CLOSED = 4 /* 注销，只保留历史账单 */ };ST_SETTLING这个过渡态是很多人会省掉的，省掉就会遇到一个很尴尬的场景：验收时老师手快，连点两下“下机”，第一遍结算扣了钱、写了账单，第二遍因为结束时间已经被清空，要么重复扣一次，要么算出负数时长。正确的流转是ONLINE → SETTLING → IDLE，进入结算前先原子地把状态置成SETTLING，任何再次进入下机流程的调用直接返回“该卡正在结算中”。这个态只存在几毫秒，但它是防止重复扣费的唯一保险。
剩下的合法流转只有几条：IDLE → ONLINE（开机，写开始时间戳和机位号）、IDLE ↔ FROZEN（挂失与解挂）、SETTLING → FROZEN（结算时余额不足，扣到欠费后冻结）、IDLE → CLOSED（销卡）。非法流转一律在业务层拦掉并返回明确错误码，别指望界面层去判断。
2.3 数据实体与字段设计
课程实验一般不允许上数据库，四个文本文件就够撑起整个系统。字段设计的关键是“能从账单倒推出计费过程”，所以账单表不能只存一个总金额，还要把当时的费率、计费分钟、计费方式一起存进去，否则答辩时被问“这两块四是怎么来的”，你只能现场口算。
| 文件 | 实体 | 关键字段 | 说明 |
|---|---|---|---|
| cards.txt | 上机卡 | 卡号、姓名、密码、角色、状态、余额、开始时间戳、机位号 | 一张卡一行，状态用单值枚举 |
| bills.txt | 账单 | 账单号、卡号、机位、开始/结束时间戳、计费分钟、费率快照、金额、是否已冲正 | 只追加不修改，冲正靠标记位 |
| config.txt | 费率配置 | 日间价、夜间价、最小计费单位、起步价、免费时长 | 超级管理员可改，改动写审计 |
| audit.log | 审计日志 | 时间、操作人、动作、明细 | 追加写，只增不删 |
余额字段用double存“元”在实验课上问题不大，但要统一只保留两位小数，所有写入前用%.2f格式化，避免浮点误差累积成58.499999。账单里的“费率快照”不是冗余设计，它保证了一个人 21:00 上机、23:00 下机时，即使这中间超级管理员改了费率，他的账仍然按上机时的价格算——这一点在后面避坑那一章还会再提。
3. 总体架构设计：单进程控制台程序的三层结构与四个模块
课程实验的代码量通常在 1500 到 2500 行之间，这个体量刚好卡在一个尴尬的位置：全写进main.c也能跑，但改需求会痛苦；上完整的分层框架又显得用力过猛。我的做法是分三层、四个模块，每个模块一两个.c文件，总文件数控制在八个以内，既能讲清楚设计，也不至于让助教翻半天找不到入口。
3.1 分层切法：界面层不碰数据，存储层不碰规则
三层的职责边界只有一句话：界面层负责所有printf和scanf，业务层负责所有判断和计算，存储层负责所有fopen。这句话看着简单，但它挡住的是这类课设里最普遍的一种写法——在菜单的case 3:里直接fopen("cards.txt", "w")然后把整个数组循环写一遍。这种写法一旦出现两次以上，两处保存逻辑就会不一致，最后表现为“改了余额但重启后没变”。
依赖方向必须是单向的：ui → service → store，反过来一律不允许。业务层函数里出现printf就是越界，存储层函数里出现“余额够不够”这种判断也是越界。验收时如果老师问“如果我要把这个系统改成图形界面，需要改多少”，你能回答“只重写 ui 那一层，业务和存储一行不动”，这个设计就算立住了。
四个模块的划分对应四条主线：
| 模块 | 文件 | 职责 | 对外接口特征 |
|---|---|---|---|
| 鉴权与角色 | auth.c | 登录校验、角色判定、权限矩阵 | 只返回状态码和角色值 |
| 卡与机位 | card.c | 开户、挂失、开机、强制下机 | 全部基于卡下标操作 |
| 计费与账单 | billing.c | 计时、分段计价、结算、冲正 | 纯计算 + 账单写入 |
| 存储与日志 | store.c | 四个文件的读写、审计追加 | 不包含任何业务规则 |
3.2 模块职责与函数接口约定
接口约定是这套方案里最值得抄的部分。三条规矩定下来，后面写代码基本不会互相踩脚：第一，业务函数一律返回int，0表示成功，负数是错误码，正数留给需要返回下标的场景；第二，业务函数不调用exit()，出错就把错误码往上抛，由界面层决定是重试还是退回主菜单；第三，所有字符串参数都传const char *并在函数内部做空指针检查。
/* service.h —— 业务层对外只暴露这些，界面层看不到结构体内部 */ #define OK 0 #define ERR_NOT_FOUND -1 #define ERR_BAD_PWD -2 #define ERR_FROZEN -3 #define ERR_NO_MONEY -4 #define ERR_STATE -5 /* 状态不允许该操作，比如对已上机的卡再开机 */ #define ERR_IO -6 int auth_login(const char *cardNo, const char *pwd, int *roleOut); int card_open_seat(const char *cardNo, int seatId, long now); int card_force_off(const char *cardNo, const char *op, long now); int bill_settle(const char *cardNo, long now, long *billIdOut); int bill_reverse(long billId, const char *op); int rate_update(const RateConfig *cfg, const char *op);这套错误码的好处是可测。写完之后你可以脱离界面，直接写一个几十行的自测函数，按顺序调用auth_login("C0001","123456",&r)、card_open_seat(...)、bill_settle(...)，看返回值对不对，不用每次都在菜单里点十几下。答辩演示前跑一遍自测，比手动点菜单可靠得多。
3.3 存储格式：为什么选带分隔符的文本而不是二进制
fwrite整个结构体数组确实一行就能存完，但它有两个致命问题：换一台机器、换一个编译器，结构体对齐和int长度可能就不一样，读出来全是乱码；出问题时用记事本打不开，等于给自己造了个黑匣子。文本格式虽然多写几行代码，但调试成本低一个数量级。
cards.txt —— 一行一卡，字段用竖线分隔 C0001|张三|123456|0|0|58.50|0|-1 C0002|李四|654321|0|1|42.00|1730000000|7 bills.txt —— 一行一账，费率快照跟着账单走 1001|C0002|7|1730000000|1730003600|60|3.00|3.00|0 config.txt —— 键值对，超级管理员改的就是这几行 dayRate=3.00 nightRate=2.00 minUnit=30 minCharge=1.00 freeMinutes=5竖线做分隔符是因为它不会出现在卡号、姓名和数字里。但姓名是用户输入的，必须做过滤：读取和写入前都检查一遍，含竖线或换行的输入直接判为非法，返回ERR_STATE让界面层提示重输。这个小检查不做，某天有人把姓名输成张|三，整个文件的行列就全错位了，读出来的余额会跑到机位号那一列去，排查起来非常费劲。
config.txt用键值对而不是固定顺序，是为了让超级管理员改费率时不用关心行序，也方便以后加新参数——加一行holidayRate=5.00就能扩展，老文件读进来缺哪个键就用默认值兜底。
4. 核心模块实现：登录鉴权、计时计费、超级管理员功能怎么落地
4.1 登录与角色鉴权
登录函数只做三件事：找卡、验密码、判冻结。角色值通过出参返回，界面层拿到角色后决定渲染哪套菜单。这里容易犯的错是把“菜单渲染”和“权限判断”混为一谈——只在界面上不给普通用户显示“修改费率”这一项，是很不安全的，因为菜单是死的人是活的，随便输个数字就越过去了。正确的做法是双保险：界面层按角色隐藏菜单项，业务层再用权限矩阵拦一次。
/* auth.c —— 角色值越大权限越高，权限判断统一走位掩码表 */ enum { ROLE_USER = 0, ROLE_ADMIN = 1, ROLE_ROOT = 2 }; /* 位掩码：1=普通用户 2=管理员 4=超级管理员 */ static const int ROLE_BIT[3] = {1, 2, 4}; /* 每个动作允许哪些角色，7 表示三种角色都行，6 表示管理员及以上 */ static const int ACTION_NEED[] = { /* ACT_VIEW_SELF_BILL */ 7, /* ACT_OPEN_SEAT */ 6, /* ACT_FORCE_OFF */ 6, /* ACT_EDIT_RATE */ 4, /* ACT_REVERSE_BILL */ 4, /* ACT_VIEW_AUDIT */ 4 }; int can_do(int role, int action) { if (role < ROLE_USER || role > ROLE_ROOT) return 0; /* 非法角色一律拒绝 */ return (ROLE_BIT[role] & ACTION_NEED[action]) != 0; } /* 返回卡下标（>=0）或错误码；roleOut 供界面层选菜单 */ int auth_login(const char *cardNo, const char *pwd, int *roleOut) { int idx; if (cardNo == NULL || pwd == NULL || roleOut == NULL) return ERR_STATE; idx = card_find(cardNo); if (idx < 0) return ERR_NOT_FOUND; if (strcmp(g_cards[idx].pwd, pwd) != 0) return ERR_BAD_PWD; if (g_cards[idx].status == ST_FROZEN || g_cards[idx].status == ST_CLOSED) return ERR_FROZEN; *roleOut = g_cards[idx].role; return idx; }密码在实验课里用明文存储是可以接受的，但答辩时最好主动说一句“生产环境要做加盐哈希，课程实验为了演示方便保留明文”——主动交代比被问出来好。真要加分，加一个十几行的简单散列函数把密码存成十六进制串，工作量不大但很能体现工程意识。
can_do这种写法还有个实际好处：加新功能时只需要在ACTION_NEED数组末尾加一行，权限逻辑一行不用改。如果按常规写法，每个菜单case里写一遍if (role == ROLE_ROOT)，加三个功能就是三处重复判断，改一次权限规则要满文件找。
4.2 计时结算：逐分钟扫描比时间段拼接更可靠
计费是这个系统里唯一有数学含量的地方，也是唯一容易算错的地方。很多人的第一反应是按时间段切分：从开始时间到 22:00 算日间，22:00 到次日 8:00 算夜间，再按小时数乘单价。这个思路在纸面上没问题，落到代码里要处理的边界特别多——开始时间本身就在夜间怎么办、结束时间跨了两个零点怎么办、时间段恰好卡在整点怎么办。
我的做法是反过来：从开始时间开始，一分钟一分钟往后扫，每一分钟按当时所处的时段累加单价，扫完再统一取整。
/* billing.c —— 逐分钟累加，跨零点、跨时段、跨天都不需要额外分支 */ static double rate_of(time_t t, const RateConfig *cfg) { struct tm lt; struct tm *p = localtime(&t); if (p == NULL) return cfg->dayRate; lt = *p; /* 立刻拷走：localtime 返回的是静态区指针 */ if (lt.tm_hour >= 22 || lt.tm_hour < 8) return cfg->nightRate; return cfg->dayRate; } /* 结算：outMin 实际计费分钟（已按计费单位取整），outFee 应收金额 */ int bill_calc(time_t start, time_t end, const RateConfig *cfg, int *outMin, double *outFee) { double raw = 0.0; int minutes = 0; int unit, charged; time_t t; if (outMin == NULL || outFee == NULL || cfg == NULL) return ERR_STATE; if (end <= start) { *outMin = 0; *outFee = 0.0; return OK; } for (t = start; t < end; t += 60) { /* 每分钟累加一次单价 */ raw += rate_of(t, cfg) / 60.0; minutes++; } if (minutes <= cfg->freeMinutes) { /* 免费时长优先，判在起步价之前 */ *outMin = minutes; *outFee = 0.0; return OK; } unit = (cfg->minUnit > 0) ? cfg->minUnit : 1; charged = ((minutes + unit - 1) / unit) * unit; /* 向上取整到计费单位 */ *outMin = charged; *outFee = raw * charged / minutes; /* 按实际单价折算到计费分钟 */ if (*outFee < cfg->minCharge) *outFee = cfg->minCharge; /* 起步价兜底 */ return OK; }几个参数的含义和改法：freeMinutes是免费时长，判在起步价之前，这样“前 5 分钟免费”和“最低消费 1 元”不会互相打架；minUnit是最小计费单位，30 表示不足半小时按半小时算，改成 1 就是精确到分钟；向上取整用(n + unit - 1) / unit * unit这个整数技巧，比调ceil()少一次浮点转换。
localtime那行拷贝是个血泪经验。localtime返回的是内部静态缓冲区的指针，连续调用两次，第二次会覆盖第一次的结果。放在循环里如果写成struct tm *a = localtime(&t1); struct tm *b = localtime(&t2);，a和b指向同一块内存，a的值会莫名其妙变成b的——而且这种 bug 不会报错，只会让计算结果在某些时刻诡异偏移，特别难查。
还有一个容易被忽略的细节：tm_isdst字段。如果你用mktime从struct tm反推时间戳，一定要把它显式设成-1，让系统自己判断夏令时，否则在启用了夏令时的环境里时间戳会差一小时。国内环境基本不受影响，但代码写成-1不花成本，属于白捡的健壮性。
4.3 超级管理员的扩展功能：费率、强制下机、冲正、审计
题目标注“含扩展超级管理员功能”，这个扩展到底扩展什么，是答辩时最容易被追问的地方。我的理解是四个能力，缺一个都撑不起“超级”两个字：改费率、强制下机、账单冲正、看审计日志。
改费率必须是热生效的，不能要求重启程序。做法是把RateConfig放在全局只读区，rate_update先校验参数（价格不能为负、免费时长不能超过最小计费单位），再写config.txt，最后刷内存。同时要把改动记进审计日志，写明改了哪一项、从多少改到多少。
强制下机解决的是异常退出的问题。有人直接按电源键关机，卡的状态永远停在ONLINE，余额既不会扣也不会退，第二天这个人再来上机时会提示“该卡已在上机中”。超级管理员需要一个入口，按最后落盘的时间戳给他补一次结算，或者直接退回IDLE并标记本次不计费。
账单冲正是最能体现角色差异的功能：管理员能看账单但不能改，超级管理员能把一笔账退回去。这里有两个必须做的防护，一是防重复冲正（账单上带reversed标记，冲过一次就不能再冲），二是冲正金额原路退回余额而不是覆盖余额。
/* billing.c —— 冲正：退钱 + 标记 + 留痕，三步缺一不可 */ int bill_reverse(long billId, const char *op) { int b, c; char detail[128]; if (op == NULL) return ERR_STATE; b = bill_find(billId); if (b < 0) return ERR_NOT_FOUND; if (g_bills[b].reversed) return ERR_STATE; /* 已冲正，拒绝二次操作 */ c = card_find(g_bills[b].cardNo); if (c < 0) return ERR_NOT_FOUND; g_cards[c].balance += g_bills[b].amount; /* 原路退回，不做覆盖赋值 */ g_bills[b].reversed = 1; sprintf(detail, "bill=%ld card=%s amount=%.2f", billId, g_bills[b].cardNo, g_bills[b].amount); return audit_append(op, "REVERSE_BILL", detail); }审计日志是这四个能力的地基。没有日志，冲正就是一笔糊涂账——钱退了，但没人知道是谁退的、什么时候退的、为什么退。日志格式设计成五段：时间、操作人、动作、明细、结果，用竖线分隔，追加写不覆盖。
/* store.c —— 追加写，一行一条，出锅时肉眼就能复盘 */ int audit_append(const char *op, const char *action, const char *detail) { FILE *fp; time_t now; struct tm *p; if (op == NULL || action == NULL || detail == NULL) return ERR_STATE; fp = fopen("audit.log", "a"); if (fp == NULL) return ERR_IO; now = time(NULL); p = localtime(&now); fprintf(fp, "%04d-%02d-%02d %02d:%02d:%02d|%s|%s|%s\n", p->tm_year + 1900, p->tm_mon + 1, p->tm_mday, p->tm_hour, p->tm_min, p->tm_sec, op, action, detail); return (fclose(fp) == 0) ? OK : ERR_IO; }日志要写进课设文档的“扩展功能说明”里，并且明确列出会被记录的六类动作：登录失败、修改费率、强制下机、账单冲正、开户销卡、配置读取失败。答辩时打开audit.log给老师看一眼，比口头说“我做了日志功能”有说服力得多。
4.4 持久化与写坏文件的兜底
保存逻辑如果直接fopen("cards.txt","w")然后循环写，有一个致命窗口："w"模式一打开，原文件就被清空了，此时如果程序崩溃或者磁盘写满，得到的是一个空文件或者半截文件，所有卡号和余额一起蒸发。课程实验里这种情况不常见，但演示时手抖关掉窗口，或者机房机器突然重启，就足够让你重做一遍数据。
标准做法是先写临时文件，成功后再改名覆盖，并且保留一份上一版备份。
/* store.c —— 写临时文件 + 原子改名，任何一步失败都不动原文件 */ int cards_save(const Card *arr, int n) { FILE *fp; int i; if (arr == NULL || n < 0) return ERR_STATE; fp = fopen("cards.tmp", "w"); if (fp == NULL) return ERR_IO; for (i = 0; i < n; i++) { if (fprintf(fp, "%s|%s|%s|%d|%d|%.2f|%ld|%d\n", arr[i].cardNo, arr[i].name, arr[i].pwd, arr[i].role, arr[i].status, arr[i].balance, arr[i].loginTs, arr[i].seatId) < 0) { fclose(fp); remove("cards.tmp"); return ERR_IO; /* 写失败就把半成品删掉 */ } } if (fclose(fp) != 0) { remove("cards.tmp"); return ERR_IO; } remove("cards.bak"); /* 上一版留作后悔药 */ rename("cards.txt", "cards.bak"); return (rename("cards.tmp", "cards.txt") == 0) ? OK : ERR_IO; }配套的还有启动自检。程序启动时读完全部卡，扫一遍有没有状态是ST_ONLINE但开始时间戳是几十个小时前的记录——这种基本都是上次异常退出留下的僵尸卡。自检逻辑不自动处理，而是把这几张卡列出来，提示“发现 N 张疑似异常上机卡，请超管使用强制下机处理”。自动扣钱风险太大，交给人工判断更合适。
上机时也要立刻落盘一次，不能等三个小时下机才写文件。多写一次磁盘的开销在课程实验里完全可以忽略，但换来的是一旦程序挂了，至少上机时间还在，能按落盘时间补算。
5. 常见问题排查：五类在验收现场最容易翻车的情况
5.1 时间与计费类
现象一：跨零点之后金额翻倍，或者算出来是负数。22:00 上机、次日 1:00 下机，本该是 2 小时日间加 1 小时夜间，结果按 3 小时日间价扣，甚至因为结束时间小于开始时间直接算出负时长退钱。原因很简单：只取了上机时刻的单价乘总时长，或者用end - start之后没做正数校验。解决办法就是 4.2 那套逐分钟扫描，同时在bill_calc入口加一句if (end <= start) return 0，把非法时长挡在外面。负数账单是最容易被老师一眼看穿的错误，一定要守住这道门。
现象二：账单上显示扣了 0.00 元，但卡里少了 1 元。免费时长和起步价同时生效时，两个口径打架了：结算函数返回的分钟数走的是免费逻辑，返回的金额却走了起步价逻辑。原因是扣款和写账单用的是两套计算。解决办法是只留一个出口——bill_calc算出什么就扣什么、就写什么，扣款前先判断*outFee <= 0直接跳过余额扣减，起步价只在“计费分钟数大于免费时长”时才生效。凡是涉及钱的地方，计算和落库必须是同一个值，中间不允许再算一遍。
5.2 文件与状态类
现象三：演示到一半机房断电，重启后那张卡永远“上机中”，谁也开不了机。因为只在正常下机时才写文件，异常退出时内存里的状态全丢了，磁盘上还是三小时前的样子。解决分三层：上机成功立刻落盘、上机期间每分钟写一次心跳时间戳、启动时扫描超时未下机的卡并提示超管介入。心跳的频率不用太高，60 秒一次足够，写的内容就是卡的loginTs字段更新，成本很低。
现象四：管理员改了费率，正在上机的人按新价格结账。老师如果 22:00 上机，你 22:30 演示“修改费率”，他下机时金额就变了，被问一句“那我这半小时到底按哪个价”就答不上来。原因是结算时读的是当前配置，而不是上机时的配置。解决办法是在卡记录里存一份费率快照，或者更简单地在上机时把当时的费率写进一条 session 记录，结算以 session 里的快照为准。账单里那个“费率快照”字段就是为这个准备的，它不只是给人看的，结算时真的要用。
5.3 环境与演示类
现象五：在自己电脑上编译通过的代码，拷到机房机器上满屏报错。常见的有三类：变量在语句之后声明（C99 特性，老编译器不认）、用了//单行注释、用了snprintf或localtime_r这类非 C89 标准函数。原因很单纯——机房装的是十几年前的编译器。解决办法是把所有变量声明提到代码块最前面、注释统一用/* */、字符串拼接改用sprintf并自己保证缓冲区够大（卡号和姓名都很短，128 字节足够）。写代码时养成这个习惯，一次写完两边都能编，比临交作业前搬着电脑去机房改要省事得多。
6. 验收与答辩：把系统跑成一条别人挑不出毛病的演示线
演示这件事，准备的顺序和写代码是反的。代码是自底向上写的，演示必须自顶向下设计：先想好五分钟里要展示哪几条主线，再倒推需要准备什么数据。我的习惯是准备三份数据文件：一份干净的初始数据（三张卡、两个机位、余额充足），一份故意造出来的错账（有一条待冲正的账单、一张僵尸卡），一份极端时间数据（跨零点的上机记录）。三份数据覆盖了正常流程、异常修复、边界计算三种场景，老师随便指哪个都能接住。
演示脚本按这个顺序走，全程不超过六分钟：
| 步骤 | 操作 | 预期现象 | 判据 |
|---|---|---|---|
| 1 | 普通用户登录，查看余额 | 只出现四个菜单项，看不到费率 | 界面层已按角色裁剪 |
| 2 | 该用户上机，机位 7 | 状态变上机中，记开始时间 | cards.txt立刻更新 |
| 3 | 用管理员登录，尝试改费率 | 菜单里无此项，直接输编号被拒 | 业务层二次拦截生效 |
| 4 | 人为把开始时间改成 20:00，下机 | 2 小时日间 + 3 小时夜间 | 金额 12.00，计费 300 分钟 |
| 5 | 超级管理员登录，冲正上一笔 | 余额退回，账单标记已冲正 | 再冲一次返回错误 |
| 6 | 打开audit.log | 六条以上记录，含冲正明细 | 时间、操作人、金额齐全 |
第 4 步是整场演示的核心，也是最容易出彩的地方。日间价 3 元、夜间价 2 元、最小计费单位 30 分钟、免费时长 5 分钟，20:00 到次日 1:00 正好 300 分钟，其中 120 分钟日间、180 分钟夜间，算下来 6.00 + 6.00 = 12.00 元。这个数字提前算好写在纸上，现场跑完对一遍，对上了就说明计费逻辑没问题，对不上当场就能定位是时段判断错了还是取整错了。答辩时老师最爱问的“如果这个人 21:50 上机呢”，你也可以直接口算：10 分钟日间加 180 分钟夜间，再按 30 分钟向上取整到 210 分钟，金额约 7.33 元。
被问到的三个高频问题，答案提前想好。问“为什么不用数据库”，答“课程实验限定标准库，文本文件配合原子写入已经能满足几百条数据的可靠性要求，换数据库只是把store.c换掉，上层不用动”。问“为什么用数组不用链表”，答“卡的数量在课程场景里有上限，数组支持按下标随机访问，查找和结算都更快，链表在这里没有优势”。问“超级管理员和普通管理员区别在哪”，别背功能列表，讲性质：“管理员按规则执行，超管改规则本身，所以超管的每个动作都要进审计日志”。
从那以后我每次交这类课设，都会在截止前一天把程序拷到机房机器上裸跑一遍，把每一步的余额和时间戳抄在纸上手工对一次账——账面能对上，剩下聊的就都是设计取舍了。希望帮到你。
本文还有配套的精品资源，点击获取
