简介武汉理工大学计算机基础与编程实验课程中的网吧计费管理系统项目包面向高校计算机基础与编程课程的学习者与课程设计参考者围绕网吧计时收费、上机管理与超级管理员扩展功能展开帮助读者理解一个完整小型管理系统的需求拆解与代码组织方式。压缩包共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 模块职责与函数接口约定接口约定是这套方案里最值得抄的部分。三条规矩定下来后面写代码基本不会互相踩脚第一业务函数一律返回int0表示成功负数是错误码正数留给需要返回下标的场景第二业务函数不调用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 —— 键值对超级管理员改的就是这几行 dayRate3.00 nightRate2.00 minUnit30 minCharge1.00 freeMinutes5竖线做分隔符是因为它不会出现在卡号、姓名和数字里。但姓名是用户输入的必须做过滤读取和写入前都检查一遍含竖线或换行的输入直接判为非法返回ERR_STATE让界面层提示重输。这个小检查不做某天有人把姓名输成张|三整个文件的行列就全错位了读出来的余额会跑到机位号那一列去排查起来非常费劲。config.txt用键值对而不是固定顺序是为了让超级管理员改费率时不用关心行序也方便以后加新参数——加一行holidayRate5.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换掉上层不用动”。问“为什么用数组不用链表”答“卡的数量在课程场景里有上限数组支持按下标随机访问查找和结算都更快链表在这里没有优势”。问“超级管理员和普通管理员区别在哪”别背功能列表讲性质“管理员按规则执行超管改规则本身所以超管的每个动作都要进审计日志”。从那以后我每次交这类课设都会在截止前一天把程序拷到机房机器上裸跑一遍把每一步的余额和时间戳抄在纸上手工对一次账——账面能对上剩下聊的就都是设计取舍了。希望帮到你。本文还有配套的精品资源点击获取
