简介针对大学生离校时闲置物品难以携带、校内缺少统一交易渠道的痛点这份C#本科毕业设计级源码给出了完整的二手闲置物品交易分享平台实现方案适合计算机专业学生作为毕业设计参考或二次开发蓝本。压缩包75.1MB共1136个文件以jpg/png图片素材、cs源码、cshtml页面、css样式和js脚本为主另含Visual Studio解决方案与项目文件、SQL数据库脚本解压后结构清晰便于直接查看项目骨架与数据表设计。系统功能覆盖搜索商品、商品展示、发布商品、添加收藏、用户管理、个人资料管理等模块前端页面与后端逻辑分层明确可支撑一次完整的毕业设计答辩演示。资源已有1145人学习下载说明在同类课题中有较好的认可度。借助这份源包读者能快速理解C# Web项目从界面布局到数据交互的实现思路复用其中的图片资源、样式与核心代码模块有效缩短毕业设计开发周期。1. 二手闲置交易分享平台这套C#毕业设计最值钱的不是代码量而是业务闭环临近毕业季很多计算机专业的同学会拿到一份标题叫“C#本科毕业设计二手闲置物品交易分享平台源代码.zip”的项目包指望解压后改个名字就交差。我的建议是先别急着重命名先花一晚上把数据流读明白。这个标题下的项目通常是 ASP.NET MVC 或 WebForms 写的二手交易站覆盖用户注册登录、商品发布浏览、下单购买、留言互动和后台管理几大块。它真正适合的人群是那些需要快速理解一个完整业务系统、并能用自己的话讲清楚“一件闲置商品从发布到成交经历了什么”的应届生。反直觉的结论是答辩老师不太在意你用了多少控件、写了多少行代码更在意“交易”和“分享”这两条线有没有被串成一个逻辑闭环——只要能在追问时把一张订单的数据流从头讲到尾这套代码就从“及格”变成了“良好”。2. 先选型再动手为什么这套代码用 ASP.NET MVC 而非 Web Forms以及拿到 zip 后按什么顺序读2.1 技术选型MVC EF SQL Server 为什么是毕业设计的安全牌现在流传出来的 C# 二手闲置交易平台毕设源码技术栈大多落在三个固定组合上ASP.NET MVC Entity Framework SQL Server或者 ASP.NET WebForms ADO.NET SQL Server。如果让我给你一个选择优先级我会明确推荐前者。逻辑很简单毕业设计答辩的追问环节老师最常问的三句话是“这个页面数据怎么来的”“这个地方为什么这么写”“如果并发大一点会怎样”。MVC 的 Controller 返回 View路由规则是 /控制器/方法/参数数据通过 ViewBag 或 Model 传给视图这条链路一句话就能讲清楚而且每一步都有明确代码位置可指。WebForms 靠事件驱动控件自动回发页面生命周期复杂你很难在紧张的答辩现场把 ViewState 和 PostBack 讲得让老师满意容易变成“黑匣子”。再从开发效率看EF 做增删改查确实省事。DbContext 里建几个 DbSet数据库表结构一变模型类跟着改不需要像 ADO.NET 那样手写大量 SqlCommand 和 DataTable 填充逻辑。对于一门只有几个月的毕设项目这种“少写胶水代码”的特性非常关键——你要把时间花在业务流程上而不是花在反复拼接 SQL 字符串上。至于为什么不推荐前后端分离的 Vue Web API 方案原因也很现实大部分本科毕设的 C# 项目包不会给你配套完整的 Vue 工程而且前后端分离意味着你要同时维护两个项目、处理跨域和 Token 认证答辩时一旦演示到某个接口请求失败排查链路明显变长。MVC 单体应用足够撑起一个“看起来完整”的二手交易系统也最容易被老师接受。拿到源代码 zip 之后第一件事不是看代码文件的多少而是确认打开方式。你先找 .sln 解决方案文件检查它依赖的 .NET Framework 版本。老一点的毕设项目常见的是 4.5 或 4.7.2你本机装的 Visual Studio 版本很可能需要做一次重定向才能把项目跑起来。右键解决方案 → 属性 → 目标框架改成你本地安装的版本如果项目里有 packages.config还要确认 NuGet 包还原是否勾选了“允许 NuGet 下载缺失的程序包”。这个步骤最容易让人心态崩——项目加载一堆黄色感叹号根本分不清是引用缺失还是框架版本不兼容先把这一关过了后面才有得聊。2.2 拿到 zip 后先读哪几个文件目录结构、SQL 脚本与 Web.config 的对应关系一个标准的 C# 二手交易平台 MVC 项目解压之后你会看到大致如下的目录骨架。我一般会按下面的顺序去读而不是从 Controllers 里随便点开一个文件/Models 数据库实体类和视图模型 /Views 前端 Razor 页面按 Controller 分文件夹 /Controllers 业务逻辑入口路由对应关系在这层 /Content CSS、图片、第三方样式库 /Scripts 前端 JS 文件 /App_Start 路由注册、过滤器配置 /App_Data 数据库脚本、Access 或本地数据库文件 /Uploads 用户上传的商品图片保存目录 Web.config 连接字符串、运行时配置你最先打开的不应该是某个 Controller而是根目录下的 SQL 脚本位置。这个 zip 里的“数据库”通常是两种形态之一要么在 App_Data 下放了一个 .mdf 文件要么给你一个 .sql 脚本让你手动在 SQL Server 里执行。我的经验是.sql 脚本比 .mdf 文件更可控——你把脚本打开看一下建表顺序和 INSERT 语句就能把整个系统的数据模型在脑子里构建出来远比盯着模型类想“这个字段哪来的”要快。-- 核心用户表示例其他表都围绕这个表做外键关联 CREATE TABLE [dbo].[Users] ( UserId INT IDENTITY(1,1) PRIMARY KEY, -- 自增主键用户唯一标识 UserName NVARCHAR(50) NOT NULL, -- 登录名界面上的用户名 Password NVARCHAR(64) NOT NULL, -- 密码字段注意存储的是加盐哈希 NickName NVARCHAR(50) NULL, -- 昵称前台展示用 Phone NVARCHAR(20) NULL, -- 联系电话 CreatedAt DATETIME DEFAULT GETDATE() -- 注册时间 );这段建表脚本里有两个参数值得你注意。INT IDENTITY(1,1)是 SQL Server 的自增主键标识种子为 1每次插入自动加 1不需要在代码里赋值NVARCHAR(50)里的 50 是字符长度如果用户名长度超了插入时会被截断或报错。很多新手复制项目后直接拿中文字符串往 VARCHAR 字段里塞结果乱码就是因为没搞明白 NCHAR/NVARCHAR 和 CHAR/VARCHAR 在 SQL Server 里对 Unicode 的支持不一样。正式写的时候凡是可能存中文的字段一律用 NVARCHAR长度根据业务定用户名、电话这些给 50 足够。Web.config 里的连接字符串是第二个阅读重点。常见写法是这样connectionStrings add nameDefaultConnection connectionStringData Source.;Initial CatalogSecondHandDB;User IDsa;Password123456;MultipleActiveResultSetsTrue providerNameSystem.Data.SqlClient / /connectionStringsData Source.表示连接本机默认 SQL Server 实例如果你装的是命名实例或者改了端口这里就要改成localhost\SQLEXPRESS或localhost,1433。Initial Catalog是数据库名称一定要和你实际还原/创建的库名完全一致大小写不敏感但拼写不能错。MultipleActiveResultSetsTrue这个参数建议保留它允许你在一个连接上同时打开多个结果集避免某些 EF 查询场景下出现“连接已存在”的报错。只要连接字符串、SQL 脚本和模型类三者的字段对得上项目跑起来的概率就已经有六成。3. 数据库设计交易平台的关键就落在商品、订单、留言三张主表的字段与状态联动上3.1 核心表清单与字段设计从需求反推结构少一张关系表后期就跳坑二手闲置交易分享平台这个标题看着宽泛落到数据库层面核心就六张表左右。我把它们在项目和答辩中的重要性从高到低列一下商品表 Goods、订单表 Orders、用户表 Users、留言/评论表 Comments、收藏表 Favorites、反馈表 Messages。你可以在这个基础上扩展积分表、举报表但毕设演示时这六张表足够支撑完整走查。我的建议是不要一上来就建十几张表表越多连外键关系越乱你写代码时的 Join 越多坑越多。商品表是整个交易闭环的中枢它的字段设计直接影响后续所有功能。我给你一个参考结构CREATE TABLE Goods ( GoodsId INT IDENTITY(1,1) PRIMARY KEY, UserId INT NOT NULL, -- 发布者关联 Users.UserId Title NVARCHAR(100) NOT NULL, -- 商品标题列表页展示 Description NVARCHAR(MAX) NULL, -- 商品详细描述 Price DECIMAL(18,2) NOT NULL, -- 价格二手物品允许议价 OriginalPrice DECIMAL(18,2) NULL, -- 原价用于显示折扣 CategoryId INT NOT NULL DEFAULT 1, -- 分类1数码 2服饰 3图书 4其他 ImageUrl NVARCHAR(200) NULL, -- 封面图保存相对路径 Status TINYINT NOT NULL DEFAULT 0, -- 0在售 1已预订 2已售出 3已下架 ViewCount INT NOT NULL DEFAULT 0, -- 浏览量列表排序可参考 IsDel BIT NOT NULL DEFAULT 0, -- 软删除标志1表示已删除 CreatedAt DATETIME DEFAULT GETDATE(), UpdatedAt DATETIME DEFAULT GETDATE() );这里几个参数需要你心里有数。DECIMAL(18,2)表示定点数总共 18 位小数位 2 位用它存价格不会出现二进制浮点数的精度误差要是图省事用FLOAT演示时商品价格很可能出现 19.99 变成 19.989999 的诡异现象。TINYINT占用 1 个字节用 0/1/2/3 四个数字代表商品状态比较时快但代码里必须写注释解释含义否则过两周你自己都忘了 2 代表什么。ImageUrl保存的是相对路径比如/Uploads/xxx.jpg不要在数据库里存完整官网地址——换一台电脑部署地址就变了你答辩时用的机器很可能和开发机不是同一台存绝对路径就是给自己埋雷。订单表相比商品表更考验状态设计。一张成功的订单应该把买家、卖家、商品、成交价、订单状态和创建时间全部记录清楚CREATE TABLE Orders ( OrderId INT IDENTITY(1,1) PRIMARY KEY, OrderNo NVARCHAR(32) NOT NULL, -- 订单编号格式建议前缀加时间戳 GoodsId INT NOT NULL, -- 关联商品 BuyerId INT NOT NULL, -- 买家用户ID SellerId INT NOT NULL, -- 卖家用户ID Price DECIMAL(18,2) NOT NULL, -- 成交时的价格快照 Status TINYINT NOT NULL DEFAULT 0, -- 0待付款 1待发货 2待收货 3已完成 4已取消 CreatedAt DATETIME DEFAULT GETDATE(), PayAt DATETIME NULL, -- 支付时间状态流转时写入 FinishAt DATETIME NULL -- 完成时间 );这张表里最容易被忽略的是Price字段。你卖的二手商品可能没几天就降价了如果订单表不冗余这个价格快照订单创建后再改商品价格历史订单金额就会跟着变答辩时老师一查就会发现数据对不上。这就是常说的“用空间换时间”冗余字段不是问题字段缺失才是问题。OrderNo建议用一个 15~20 位字符串比如日期时间戳随机数的组合方便演示时让老师看到不同订单号不重复。有了核心主表关系表就顺理成章。收藏表 Favorites 至少需要FavoriteId、UserId、GoodsId、CreatedAt四个字段用户表和商品表构成一个隐藏的“表白关系”没它前端“我的收藏”页面就得临时去别的表里拼数据。留言表 Comments 需要注意的则是ReplyId这个字段允许用户回复某条留言用ReplyId指向 Comments 表自身的主键形成自关联这样分享交流“贴吧感”就出来了。后台反馈表 Messages 则适合存两种消息用户给管理员发的反馈、管理员给用户发的回复加一个Direction字段区分发送方向即可。3.2 状态变迁与软删除让交易流程在被追问时也能自圆其说数据库字段只是静态结构真正让系统像“交易平台”的是静态字段之间的状态流转逻辑。商品的Status和订单的Status不是随便改的它们之间有一个必须保持一致的对应关系。我设计时习惯画这样一张状态机对照表商品状态可执行操作对应订单状态0 在售买家下单0 待付款1 已预订卖家标记交付1 待发货2 已售出买家确认收货3 已完成3 已下架买家取消/卖家主动下架4 已取消这个表并不复杂但它把两个独立的状态字段绑定在了一起。写代码时买家点击“购买”按钮Controller 里要先做一步判断只有当Goods.Status0时才允许生成订单生成订单后立刻把商品状态改成 1已预订防止另一个人也下单。实际操作中很多同学偷懒下单只写订单表不改商品状态结果同一件商品被五个人同时下单到后台一看全是待付款订单——答辩演示的时候这就是大翻车现场。更稳妥的做法是给商品表加一个RowVersion行版本号字段更新时带上WHERE RowVersionpreviousVersion判断能防止并发覆盖。不过这个对于毕设来说偏深了如果你想让代码更有亮点写成只读的存储过程也可以。订单状态内部流转也要遵循序列。0 → 1 → 2 → 3 是正向路径任何一步跳级都应该在代码里被拦截0 → 4 是取消路径只能从待付款状态取消已经发货的订单不允许买家单方面取消。实现上每个状态流转我建议独立写成一个小方法不要在一个大方法里用 if-else 层层叠。举例public bool UpdateOrderStatus(int orderId, byte targetStatus) { var order db.Orders.Find(orderId); if (order null) return false; // 状态机合法性校验只有特定组合允许转换 var allowed new Dictionarybyte, byte[] { { 0, new byte[]{ 1, 4 } }, // 待付款 → 待发货/已取消 { 1, new byte[]{ 2, 4 } }, // 待发货 → 待收货/已取消 { 2, new byte[]{ 3 } } // 待收货 → 已完成 }; if (!allowed.ContainsKey(order.Status)) return false; if (!allowed[order.Status].Contains(targetStatus)) return false; order.Status targetStatus; if (targetStatus 2) order.PayAt DateTime.Now; if (targetStatus 3) order.FinishAt DateTime.Now; db.SaveChanges(); return true; }这段代码给出的核心参数是那个Dictionarybyte, byte[]状态允许映射表。它的可读性远好过一长串 if-else而且答辩时你直接指着它说“我在这里用字典显式定义了状态机的允许路径”就足够加分。targetStatus是目标状态数字方法内部先读原状态再校验组合最后更新时间和状态。软删除也是这类项目容易忽略的细节。用户发布了一堆商品如果某天把商品删了订单表的外键关联就会断裂。所以我强烈建议所有主表都保留IsDel BIT DEFAULT 0字段删除操作只是把IsDel置 1列表查询一律加WHERE IsDel0过滤。它的额外好处是“删除”之后还能反悔这在答辩演示时是个很好的托底操作——老师让你演示删除商品你删完还能换回来用行动展示什么是“可恢复设计”。4. 核心业务代码实现登录、发布、上传、分页这四个点决定你答辩的从容程度4.1 登录与会话MD5 加盐与防 SQL 注入的正确写法二手交易平台的登录功能看起来简单写错的重灾区却集中在这几处明文存储密码、SQL 拼接查询、没有会话超时。第一个问题最致命。你要是打开数据库看到 Users 表里 Password 字段是“123456”一串明文那这个项目基本没法直接答辩——老师只要看一眼表数据就会质疑整个系统的安全性。正确的做法是 MD5 再加盐或者直接用 ASP.NET 自带的PasswordHasher。很多毕设源码用的是简单 MD5虽然本质上已经不符合现代安全标准但对答辩来说比明文强一个档次。此处给出一个带盐的哈希实现using System; using System.Security.Cryptography; using System.Text; public static class PasswordHelper { // 生成固定长度盐值每个用户不同 public static string GenerateSalt() { byte[] bytes new byte[8]; using (var rng RandomNumberGenerator.Create()) { rng.GetBytes(bytes); } return Convert.ToBase64String(bytes); } // 加盐哈希MD5(盐 密码)得到 32 位十六进制字符串 public static string HashPassword(string password, string salt) { string raw salt password; using (MD5 md5 MD5.Create()) { byte[] hash md5.ComputeHash(Encoding.UTF8.GetBytes(raw)); StringBuilder sb new StringBuilder(); for (int i 0; i hash.Length; i) { sb.Append(hash[i].ToString(x2)); } return sb.ToString(); } } }这里的两个参数需要说明GenerateSalt()用RandomNumberGenerator.Create()生成 8 字节随机值转换成 Base64 后作为盐每个用户的盐都不一样HashPassword把盐和密码拼接后计算 MD5输出小写十六进制字符串。登录时从数据库取出该用户的盐用同样的算法重新计算比对字符串是否相等。这样做的好处是两个人使用相同密码也不会得到相同哈希数据库泄露也不容易被彩虹表直接命中。注意 MD5 已经过时用在毕设里只是“可用”水平你可以在答辩时主动补充一句“生产环境建议升级到 bcrypt 或 SHA256”反而显得你有认知深度。登录成功后 Session 的处理同样有讲究。MVC5 里常用FormsAuthentication.SetAuthCookie或用 Session 直接存用户编号我更推荐用 Session 存UserId和UserName因为后面商品发布、下单都要频繁读当前用户身份Session 取一次就行public ActionResult Login(LoginViewModel model) { if (!ModelState.IsValid) { return View(model); } var user db.Users.FirstOrDefault(u u.UserName model.UserName); if (user null) { ViewBag.Error 用户名或密码错误; return View(model); } string hash PasswordHelper.HashPassword(model.Password, user.Salt); if (hash ! user.Password) { ViewBag.Error 用户名或密码错误; return View(model); } Session[UserId] user.UserId; Session[UserName] user.NickName ?? user.UserName; return RedirectToAction(Index, Home); }这段代码里最值得注意的一点只要用户不存在两种状态下都返回同一句“用户名或密码错误”这是防账号枚举的标准做法。db.Users.FirstOrDefault(...)是 EF 的查询它自动参数化传入的值不会把model.UserName拼进 SQL 字符串这就从源头挡掉了 SQL 注入。如果你手里的源码用的是string sql SELECT * FROM Users WHERE UserName model.UserName 这种写法请务必改掉这几乎是毕设代码里的保留项目。登录之外拥有一个全局操作权限过滤器也很重要。比如商品发布、下单这些 Controller 方法应该标注[Authorize]特性。这样未登录用户访问会被自动重定向到登录页不需要你在每个方法里手写 if 判断代码简洁度明显提升百度搜索引擎收录的 C# 入门教程里也常拿这个特性做例子。4.2 发布商品与图片上传路径拼接、GUID 重命名与扩展名校验商品发布页是二手交易平台比普通 CMS 复杂的地方因为要处理图片文件。图片上传有几个常见的“坑”文件名重复导致覆盖、中文文件名导致编码问题、用户传了非图片格式的 exe、上传目录权限不足导致保存失败。一段能同时规避上述四个问题的代码放在这里很加分[HttpPost] [Authorize] public ActionResult Publish(Goods model, HttpPostedFileBase imageFile) { if (ModelState.IsValid imageFile ! null) { // 1. 扩展名白名单校验拒绝非图片 string ext Path.GetExtension(imageFile.FileName).ToLower(); string[] allowed { .jpg, .jpeg, .png, .gif, .bmp }; if (!allowed.Contains(ext)) { ModelState.AddModelError(imageFile, 只能上传 jpg/png/gif/bmp 图片); return View(model); } // 2. 限制文件大小比如 5MB if (imageFile.ContentLength 5 * 1024 * 1024) { ModelState.AddModelError(imageFile, 图片大小不能超过 5MB); return View(model); } // 3. 用 Guid 生成新文件名保留原扩展名 string newFileName Guid.NewGuid().ToString(N) ext; string folderPath Server.MapPath(~/Uploads); if (!Directory.Exists(folderPath)) { Directory.CreateDirectory(folderPath); } string fullPath Path.Combine(folderPath, newFileName); imageFile.SaveAs(fullPath); // 4. 数据库保存相对路径方便迁移部署 model.ImageUrl /Uploads/ newFileName; model.UserId (int)Session[UserId]; model.CreatedAt DateTime.Now; model.Status 0; db.Goods.Add(model); db.SaveChanges(); return RedirectToAction(Detail, Goods, new { id model.GoodsId }); } return View(model); }拆解一下这段代码里的参数逻辑。Path.GetExtension取的是原始文件的扩展名.ToLower()保证.JPG这种大写也能通过白名单。白名单数组是你需要自行维护的扩展名集合不要用imageFile.ContentType判断因为 ContentType 可以轻易被客户端伪造。imageFile.ContentLength是浏览器上报的文件字节数服务端据此限制大小5MB 对二手商品图来说绰绰有余。Guid.NewGuid().ToString(N)生成的 32 位十六进制字符串不带连字符配合原扩展名得到新文件名从机制上杜绝了重名覆盖问题。保存路径有两处要看清Server.MapPath(~/Uploads)把虚拟目录转换成服务器物理绝对路径数据库里只存/Uploads/xxx.jpg相对路径。前者用于SaveAs写文件后者用于img srcModel.ImageUrl渲染。如果你把物理路径存进数据库一旦部署到别的电脑路径就作废了。很多同学演示时图片裂开十有八九是这里犯了错。关于Uploads文件夹还有两个容易被忽略的点。第一在 IIS 上部署时“Uploads”目录的IIS_IUSRS用户需要写入权限否则SaveAs会直接抛System.UnauthorizedAccessException。第二前端img标签的 src 不要写成绝对路径带端口用相对路径/Uploads/...在调试和部署时都不容易出问题。这两个细节属于典型的“开发时没事、部署就炸”类问题第 5 章我会再展开。4.3 分页与搜索共用一套参数ViewBag 与 ViewData 丢参数的一个坑商品列表页看起来只是全表查询加分页但当你把分页和搜索框放在同一个页面时翻页丢搜索条件就成了一道必考题。很多同学的翻页代码长这样Html.ActionLink(下一页, Index, new { page Model.PageIndex 1 })看起来没问题但点击之后搜索关键词keyword没有被带过去页面直接退回了全量列表。正确的做法是搜索框提交时就把关键词存在 ViewBag 或 TempData 里翻页链接生成时把 ViewBag 中的数据一并拼到路由对象里。我给你一个更稳的版本——用模型绑定让分页链接和查询条件保持在同一个 ViewModel 里public ActionResult Index(string keyword, int? categoryId, int page 1) { int pageSize 12; // 每页显示 12 件商品 var query db.Goods.AsQueryable(); query query.Where(g g.IsDel false g.Status 0); if (!string.IsNullOrEmpty(keyword)) { query query.Where(g g.Title.Contains(keyword)); } if (categoryId.HasValue categoryId.Value 0) { query query.Where(g g.CategoryId categoryId.Value); } int total query.Count(); var list query.OrderByDescending(g g.CreatedAt) .Skip((page - 1) * pageSize) .Take(pageSize) .ToList(); // 构造分页参数保留 keyword 和 categoryId ViewBag.Keyword keyword; ViewBag.CategoryId categoryId; ViewBag.TotalPages (int)Math.Ceiling((double)total / pageSize); ViewBag.CurrentPage page; return View(list); }分页的两个参数是page和pageSize。page是当前页码默认值为 1pageSize每页行数这里固定为 12。Skip跳过前面的行数Take取当前页的行数二者相乘就是 EF 生成的OFFSET ... ROWS FETCH NEXT ... ROWS ONLY语句只有数据量到了一定规模才会明显感受到性能差异。对于毕设项目这种“传统分页”已经够用。视图里生成翻页链接时代码应该是下面这种形式关键词和分类只会局限在当前 Action 的参数范围内传递if (ViewBag.CurrentPage 1) { a hrefUrl.Action(Index, Goods, new { keyword ViewBag.Keyword, categoryId ViewBag.CategoryId, page ViewBag.CurrentPage - 1 })上一页/a } span第 ViewBag.CurrentPage / ViewBag.TotalPages 页/span if (ViewBag.CurrentPage ViewBag.TotalPages) { a hrefUrl.Action(Index, Goods, new { keyword ViewBag.Keyword, categoryId ViewBag.CategoryId, page ViewBag.CurrentPage 1 })下一页/a }你注意看Url.Action里传入了keyword和categoryId这就是解决丢参数的钥匙。如果某个旧源码里 View 直接写a href/Goods/Index?page2那这个页面翻页必丢条件你拿到代码后第一件事就把这种硬编码改掉。另外搜索框里 keyword 的用户输入要防 XSS用Html.Encode或 Razor 默认的转义即可不要在页面上用Html.Raw(ViewBag.Keyword)输出用户输入除非你想演示“中招”。5. 部署与演示前的避坑排查这些问题不处理当场翻车是大概率事件5.1 现象IIS 部署后页面 CSS 样式丢失、图片全部裂开这个问题排在我踩坑清单的头一名。开发时用 IIS Express 访问http://localhost:xxxx/一切正常发布到本机 IIS 或答辩电脑的 IIS 后页面变成纯文本图片全裂。原因有两层第一Razor 视图里的 CSS 引用用的是绝对路径比如link href~/Content/bootstrap.min.css~在 IIS 的虚拟目录下会被解析成站点根目录再拼接/Content/...如果项目发布后没有放在网站根路径下路径就对不上。第二图片路径ImageUrl是/Uploads/xxx.jpg如果你把站点挂在二级目录http://localhost/MySite/下根路径/Uploads会被解析成http://localhost/Uploads自然 404。解决方法是把站点直接发布成 IIS 默认网站下的应用程序或者让数据库里的图片路径也带上虚拟目录名。我一般更建议把站点发布成 IIS 里的根站点演示环境最简单少一层虚拟目录就少一个路径坑。5.2 现象数据库连接失败报“无法打开登录所请求的数据库”或中文显示问号这有两种独立原因但常常同时出现。第一种是连接字符串里的Initial Catalog与你还原的数据库名称不一致你执行 SQL 脚本时建的库叫SecondHandDB连接字符串里却写着SecondHandData自然连不上。第二种是 SQL Server 实例名不对“Data Source.”只认默认实例如果你装的是 SQL Server Express实例名其实是localhost\SQLEXPRESS连接字符串不改成它就会报“网络相关错误”。中文问号的根源则在于数据库排序规则创建库时如果没指定COLLATE Chinese_PRC_CI_AS有些老版本的 SQL Server 默认排序规则不识别中文字符存进去正常读出来变成???。最简单的方法我一般直接用 SSMS 执行脚本建库右键数据库属性 → 选项 → 排序规则确认选的是Chinese_PRC_CI_AS以后所有表都默认按这个规则存一劳永逸。5.3 现象登录后没操作几分钟再点某个连接就跳回登录页这又是一个经典的“开发时没事演示时翻车”场景。默认情况下 Session 超时时间是 20 分钟但 IIS 的应用池默认会定期回收空闲进程回收后 Session 数据全部清空。你在台上演示时如果先讲了好一会儿 PPT 再切到系统操作多半刚好赶上回收直接掉线。解决方法是双重设置Web.config里给system.web节点设置sessionState modeInProc timeout60把超时延长到 60 分钟再检查 IIS 应用池的“闲置超时”和“回收时间”改成 0不回收或设成较大的值。注意 InProc 模式把 Session 存在 w3wp.exe 进程内存里应用池一回收就没了所以必须同步关掉回收。开卷考试式的忠告演示前一天就把这些配置改好再跑一次全流程别赌当天运气。5.4 现象编译后的 DLL 被直接反编译出全部源代码这不算故障而是一个安全顾虑。C# 写的程序集 .NET 编译成 IL 元数据用 dnSpy 或 ILSpy 打开几乎等于看源码。如果你不希望自己的代码被轻易拿走常见做法是加混淆器像 ConfuserEx 这种开源工具可以在发布时对程序集做控制流混淆和字符串加密。如果你只是交毕设其实不建议混淆因为答辩老师可能要用反编译工具查看你某个类的方法实现混淆后反而不好读。折中方案是对外交付时保留原始可读 DLL但在代码里不要把数据库连接字符串明文写在Web.config甚至可以把密码做一次简单加密放到配置节点里这样至少不会一眼泄露数据库口令。这个度你自己掌握答辩项目关键是“透明可解释”而不是“防破解”。5.5 现象翻页后数据重复或者突然少了一条排序不稳定最后这个坑很隐蔽。商品列表用OrderByDescending(g g.CreatedAt)排序后分页因为CreatedAt精确到秒同一秒发布的多件商品排序顺序不稳定数据库每次返回顺序可能不一样。你第 1 页看到商品 A翻到第 2 页 A 又出现了而某件商品被跳过了。解决方法是给排序加一个绝对唯一键比如query query.OrderByDescending(g g.CreatedAt) .ThenByDescending(g g.GoodsId) .Skip((page - 1) * pageSize) .Take(pageSize) .ToList();ThenByDescending(g.GoodsId)就是二次排序键GoodsId是自增主键永远唯一这样数据库的分页结果就稳定了。这属于很典型的“面试能答、实操才发现”的坑你在演示前能自己抓到这个问题会让老师觉得你有真实调试经验。6. 最后一步用“分享”把项目从及格拉到良好以及答辩现场的验证节奏“二手闲置物品交易分享平台”这个标题里“分享”二字经常被当成凑数。其实把它做足很简单在商品详情页加“收藏”按钮再加一个留言区让用户能在商品下面互相问“还在吗”“能不能便宜点”。实现上收藏表Favorites加一个不重复的联合唯一索引留言表Comments加ReplyId自关联前端用一个局部刷新或普通表单提交即可。演示时你先发布一件商品然后切换到另一个账号去收藏、留言、下单整个过程就是一条“分享—互动—交易”的链路比单纯演示增删改查完整得多。答辩现场我建议按这个节奏走先打开数据库指着表结构讲三张主表的关系再登录两个账号现场发布一件二手书、搜索、下单、再确认收货。整个流程不要超过五分钟。操作前先清空浏览器缓存提前把“Uploads”文件夹准备好商品图片不要选照片图库的大图压缩到几百 KB 的 JPG 更稳妥。真正有价值的验证不是系统跑通而是你主动在老师提问前把状态字段说清楚“商品发布时状态为 0下单后变为 1确认收货后变为 2”这可能直接决定老师提问的方向是“加分”还是“挑刺”。最后说一句我的个人习惯每次演示前我都强制自己把数据库重新还原一次再从头走一遍完整流程。这个习惯救过我很多次也让我学会了把连接字符串和上传目录这些“环境依赖”单独整理成一份部署文档。源码本身有边界边界之外的顺畅往往来自反复走查如果你能在一周内把自己项目的每一次点击都变成肌肉记忆那这套 C# 毕设源码就真正算是你的东西了。希望帮到你。本文还有配套的精品资源点击获取