简介：这是一套基于VS2005与SQL Server 2005开发的校园一卡通管理系统，面向初学C#与数据库开发的软件专业学生，可用于理解从需求分析、数据库建模到前后端交互的完整项目流程。压缩包共87个文件，约2.5MB，核心包含30个C#源码文件、界面与资源文件、SQL脚本与数据库文件，以及需求说明书、详细设计说明书、数据字典等文档和Power Designer生成的物理/概念数据模型，结构清晰，便于对照学习。系统覆盖卡片管理、用户信息管理、交易记录查询等模块，涉及用户认证与权限管理、事务处理、报表统计、数据安全等关键知识点，能帮助读者掌握C#编程和SQL Server数据库实操技巧。已有358人学习，适合作为课程设计或入门实战项目参考。 这片儿地儿我太熟了。十几年前在学校里折腾的“校园一卡通系统（vs2005+sql2005）”，现在回头看，技术栈虽然老，但里面那些架构思路、坑和解决办法，放到今天依然有参考价值。无论你是计算机专业的学生做课程设计，还是刚进公司接了个维护老系统的活儿，这篇东西都能帮你少走不少弯路。
1. 项目概况与技术选型逻辑
1.1 核心需求：一卡通不只是扣钱
一卡通系统听起来简单，就是拿张卡刷一下扣个钱。但真做起来，牵扯的东西比想象中多得多。
我当年接到的需求是这样的：新生入学批量发卡、食堂消费扣款、超市小额支付、开水房计费、图书馆门禁、晚归考勤。表面上看是“刷卡扣钱”，实际上要拆解成几个独立的子系统，再让他们协同工作。
核心的东西有这么几块：
- 卡账户管理：发卡、挂失、补卡、退余额
- 消费终端管理：售饭机、饮水机、门禁机，每一台都要能远程控制
- 交易流水：每一笔刷卡记录都要实时上传，且不能丢、不能错
- 对账汇总：每天要对各终端的销售总额，跟卡账户的扣款总额对上账
这里最容易被新手忽略的是“离线交易”。食堂售饭机不可能保证网络永远在线，要是网断了就不让刷卡，那食堂门口得排长队。所以终端必须支持离线记账，网络恢复后再补传流水。这就引出了数据一致性的麻烦，我在后面专门讲。
1.2 为什么选择VS2005 + SQL2005
现在回头看，VS2005和SQL2005都是2005年底发布的产品，放在今天确实老掉牙。但当时选它，不是没有理由的。
首先是部署环境。学校机房清一色Windows Server 2003，数据库用SQL2005是顺理成章的事。VS2005对应的.NET Framework 2.0，在Windows Server 2003上运行非常成熟。什么LINQ、Entity Framework，听都没听过，但WinForm做桌面客户端、ASP.NET WebForm做管理后台，在当时是标准答案。
其次是开发效率。一卡通项目里面有大量桌面终端程序，用Visual Studio 2005的WinForm开发效率是真的高，拖拖控件、写写事件，一套售饭机的界面UI半天就能出来。而C#跟SQL Server的配合，通过ADO.NET直接操作，那叫一个丝滑。你让我用Java写个Socket通信对接刷卡器，我得折腾一周，C#两天搞定。
最关键的是SQL2005的稳定性。它的性能调优、索引视图、在线索引操作，放在当时都是顶尖的。而且学校里懂SQL Server的运维老师多，出了问题好找人。你要是整个Oracle，学校老师不熟，你走了之后没人敢碰系统。
2. 数据库设计与核心模块实现
2.1 核心表结构：别把余额当成一个字段
数据库设计是一卡通系统的命根子。表结构设计不好，后面维护就是噩梦。我在这里总结的核心设计思路，就是“三表分离原则”。
首先是卡账户表。这里面最重要的不是余额，而是卡的状态和密钥。状态字段我用的是int型，0表示正常、1表示挂失、2表示冻结、3表示注销。密钥则是防止卡被复制的，每张卡有个唯一的卡号，再加上一个加密后的密钥串，后台扣款时要校验。
然后是交易流水表。这张表是只增不改的，核心字段包括：流水号、卡号、终端机号、交易类型（消费/充值/退款）、金额、交易时间、上传状态。重点是在终端机上给每笔交易生成本地流水号，上传后数据库再分配全局流水号，两者对应。这样离线交易补传的时候，不会因为网络问题丢失数据。
最后是日汇总表。每天凌晨跑一个作业，把昨天的交易按终端机汇总，跟卡账户扣款总额对账。对不上的，系统自动标记为差异记录。这个设计帮我大忙了，后续排查丢单问题全靠它。
2.2 并发扣款用存储过程，别在代码里做加减法
售饭机的并发量，虽然比不上双十一那种级别，但饭点的时候，几百台终端同时扣款，如果直接在代码里先SELECT余额再UPDATE余额，绝对出问题——丢失更新。
我当时的解决方案是，把扣款操作封装成一个存储过程，放在SQL2005上跑：
CREATE PROCEDURE proc_Deduct @CardNo VARCHAR(20), @Amount DECIMAL(10,2), @TerminalNo VARCHAR(10), @Result INT OUTPUT AS BEGIN SET NOCOUNT ON DECLARE @Balance DECIMAL(10,2) DECLARE @ErrMsg VARCHAR(200) BEGIN TRAN -- 锁定该卡的行，防止并发扣款 SELECT @Balance = Balance FROM CardAccount WITH (UPDLOCK, ROWLOCK) WHERE CardNo = @CardNo IF @Balance IS NULL BEGIN SET @Result = -1 -- 卡不存在 ROLLBACK TRAN RETURN END IF @Balance < @Amount BEGIN SET @Result = -2 -- 余额不足 ROLLBACK TRAN RETURN END UPDATE CardAccount SET Balance = Balance - @Amount WHERE CardNo = @CardNo INSERT INTO TransLog (CardNo, TerminalNo, Amount, TransTime, Status) VALUES (@CardNo, @TerminalNo, @Amount, GETDATE(), 0) SET @Result = 0 -- 成功 COMMIT TRAN END这里技术上有三个关键点：
第一，WITH (UPDLOCK, ROWLOCK)锁定了这条卡记录。同一时刻，多台售饭机同时扣这张卡，只有一台能拿到锁，其他全部等待，从根源上避免了余额扣成负数。
第二，先查余额，不足直接回滚，防止透支。这条逻辑我用在餐卡上效果很好，但在水控系统上是另外一套逻辑，允许小额透支，后面再讲。
第三，扣款和记录流水在同一个事务里，要么全成功要么全失败，不会出现钱扣了但没记录的尴尬情况。
3. 部署环境实战：Win7下安装SQL2005的问题
3.1 为什么非要装SQL2005专业版
项目做完以后，遇到的最头痛的问题，反而是环境部署。
学校那边为了图省事，新配的服务器直接装了Windows 7专业版（当时Win7刚出，学校急着“尝鲜”），然后要求我把系统部署上去。但我们的数据库备份文件是用SQL2005做的，数据库文件格式是mdf，SQL2008能直接挂载，SQL2005的维护计划、作业调度脚本却不一定兼容。学校机房里几台老终端还在用SQL2005的客户端，你贸然升到SQL2008，终端连不上。
所以在Win7上安装SQL2005专业版，成了整个部署环节里最有技术含量的一步。
3.2 安装步骤和踩坑记录
我前前后后装了三遍才成功，核心步骤是这样的：
第一步，Win7默认自带.NET Framework 3.5，但SQL2005需要的是.NET 2.0。微软官方说2.0是3.5的子集，但实际安装SQL2005时还是会一直报错。我的解决办法是：在控制面板→程序和功能→启用或关闭Windows功能里，手动勾选.NET Framework 3.5（包括.NET 2.0和3.0），让系统自动下载安装。
第二步，SQL2005的安装程序Setup.exe，在高分屏和UAC打开的状态下会显示异常。解决办法是右键安装程序，属性→兼容性→勾选“以兼容模式运行这个程序”→选择Windows 7，并且勾选“以管理员身份运行”。这个操作看起来是玄学，但真的管用。
第三步，安装到“系统配置检查”时，它会提示IIS功能缺失。如果你只用数据库引擎，不需要Reporting Services报表服务，这个警告可以直接忽略，勾上“运行而不检查”继续装就行。
第四步，装完SQL2005必须立即打补丁。微软后续发布的Service Pack，建议直接上SP4。不打补丁的话，SQL2005在Win7上有两个致命问题：一是数据库服务占用的内存会不断上涨而不释放，二是SQL Server Management Studio偶发闪退。装上SP4后这两个问题基本绝迹。
最后再提一句，SQL2005安装的时候不要装在默认的C盘路径，后面要备份数据库文件的时候，路径权限问题会让你哭。直接整个数据库目录放到D盘，后面维护省心得多。
4. 常见故障排查实录
4.1 刷卡丢流水：时间不同步是罪魁祸首
项目上线后第一周就接到食堂反馈，说有学生刷卡显示成功，但后台查不到交易记录。
排查下来，发现是终端机的系统时间跟服务器差了三个小时。离线交易的时候，终端本地生成流水号，到了上传的时间，服务器判定这笔流水的生成时间在未来——因为终端时间比服务器快——就直接拒绝入库了。
解决办法是双管齐下：一是终端每次启动时，强制跟服务器对时，时间偏差超过五秒就自动校准；二是在数据库端，给流水上传存储过程加上校验逻辑，时间异常的流水不直接丢弃，而是先存进待处理区，人工确认后补单。
4.2 水控系统被恶意透支
餐卡那边扣款逻辑严密了，但水控这边又出了幺蛾子。
水控系统是按时间计费的，一秒钟扣一分钱。学生卡里余额不足时，按道理应该立即断水。但水控终端是离线模式，只能靠本地缓存的余额判断。有个聪明的学生把钱刷到剩几毛钱，然后故意让终端处于离线状态，就能无限喝水。
我的补救方案是在水控终端里加了一个“最大透支额度”参数。离线状态下，单卡透支上限是2块钱，超过这个额度，终端强制停机。这个方案算不上完美，但在离线场景下已经是能想到的最优解了。你不可能让每台终端都实时联网查询余额，那成本太高了。
4.3 饭点高峰期数据库连接池被打满
上线第二周，中午12点饭点，数据库直接假死，CPU瞬间飙到100%，看监控全是连接请求堆积。
查代码发现是客户端每做一次操作，都new SqlConnection()然后Close()。表面看是关闭了，但连接池里的连接没有物理断开，只是标记为可用。高峰期上千个连接同时涌进来，SQL2005直接炸了。
解决办法是在连接字符串里设置Max Pool Size=100，同时在代码里统一使用using块确保连接释放。更重要的是，在数据库端做了连接数的监控脚本：
SELECT DB_NAME(dbid) AS DBName, COUNT(*) AS [Connections] FROM sys.sysprocesses GROUP BY dbid这样一眼就能看出哪个数据库占用了多少连接。后来把循环打开连接的代码全部重写成批量操作，一次连接处理一整批流水上传，数据库瞬间就稳了。
5. 实操心得与复盘
这套系统我断断续续维护了两年多，最深的体会是：老技术不等于坏技术，关键是你的设计思路是否清晰。
VS2005 + SQL2005这套组合，放到今天确实有些跟不上时代，但它帮助我把一个业务逻辑极复杂的系统完整落地了，而且稳定跑了几年。它让我把重点放在了业务本身，而不是天天折腾框架升级。现在很多新项目，光搭环境就要一周，业务逻辑还没想明白，技术选型倒是换了好几轮。
最后再说一个我自己总结的开发顺序建议：做这类系统，先设计数据库，再设计存储过程，最后写代码。顺序反了，后面一定反复改。数据库里的每一个字段都意味着一条业务规则，字段设计得草率，上层代码写得再漂亮也是空中楼阁。
做技术的人，总想着用什么新框架新语言，但真正值钱的，永远是你对业务的理解和解决问题的能力。这个校园一卡通项目，让我在数据库事务、并发控制、离线数据同步这些方面的经验，到现在还在受益。
本文还有配套的精品资源，点击获取
