简介：一套基于C#语言的本科毕业设计项目，即二手闲置物品交易分享平台，提供了完整可运行的源代码。项目针对高校毕业生离校时闲置物品携带不便、校园内缺少统一交易渠道的实际需求，设计了搜索商品、商品展示、发布商品、添加收藏、用户管理、个人资料管理等核心模块，覆盖前后端基本交互逻辑，适合计算机相关专业学生用于课程设计、毕业设计参考或二次开发。压缩包共1136个文件，体积约75.1MB，包含大量C#源文件（.cs/.cshtml）、前端样式与脚本、jpg/png等图片素材、动态链接库及项目配置文件，同时附带数据库脚本和Visual Studio解决方案，便于直接导入编译学习。这套源码已有1144人学习，资源结构清晰，按文件类型和模块组织，读者可借助完整源码理解ASP.NET MVC或Web Forms项目的目录与分层方法，也可根据需求替换界面和扩展业务功能，从而减少从零搭建系统的时间。
1. 毕设选“二手闲置交易平台”，为什么这个题目年年都有人做、还年年都能过
每年毕业季，C# 方向的本科毕设里，“二手闲置物品交易分享平台”几乎是个绕不开的经典题。它不冷门、不炫技，但胜在功能边界清晰：用户、商品、订单、消息、分享，每个模块都能对应到数据库设计和三层架构，工作量恰到好处。一个压缩包丢给答辩老师，能讲清楚“我做了个什么系统、用了什么技术、难点在哪”，比空谈微服务和大数据要实在得多。
这套源码包真正值钱的地方，不是那几个页面和几张表，而是它把“物品交易 + 社交分享”两条业务线揉在了一个系统里。你在简历上可以老实写“独立完成一个面向校园场景的 C2C 交易平台”，面试官顺着问下去，你至少能说出用户认证怎么做、商品状态怎么流转、并发下单如何防超卖——而这些恰好是本项目的核心。
接下来我按自己平时带毕设的思路，把这个“源代码.zip”拆开讲透：先看架构和工程结构，再讲数据库设计、后端核心逻辑、前端调用方式，最后是打包部署和答辩前必查的雷区。你不一定完全照抄代码，但照着这个骨架走，能省下至少两周的弯路。
2. 拿到压缩包先别急着解压：工程结构、开发环境和三层架构的对应关系
很多同学解压后第一件事是双击.sln然后 F5，结果报一堆缺包、缺 SDK 的错误。这个项目本身不复杂，但环境的坑比代码的坑多。我们先花一节把“这个东西本来是给什么环境准备的”搞清楚，再动手改。
2.1 解压后先看这四样东西，判断项目是不是完整
不管压缩包里是.rar还是.zip，解压后第一件事不是开 Visual Studio，而是按顺序检查下面四个关键项：
提示：没有 .sln 文件不代表不能运行，但说明原作者的交付习惯不太规范，后面可能要自己建解决方案。
第一，确认有没有.sln或.csproj文件。.sln是 Visual Studio 的解决方案入口，.csproj是单个项目文件。找不到 .sln 时，可以直接在 VS 里“打开项目或解决方案”选中.csproj，Visual Studio 会按项目自身依赖生成解决方案。
第二，看有没有packages.config或App.config/Web.config。packages.config是旧版 .NET Framework 项目的 NuGet 依赖清单，有它说明项目用的是经典 ASP.NET WebForms 或 MVC 5 体系。App.config是桌面程序（WinForms/WPF）的配置，Web.config才是 Web 项目的。
第三，找数据库脚本。正常交付的毕设源码包会带db.sql、script.sql或者database目录。如果只有代码没有 SQL 脚本，说明数据库要自己从实体类反推，工作量会大很多。
第四，看有没有README或使用说明.txt。哪怕是三行字，也能告诉你有没漏文件、数据库版本是什么、默认账号密码是什么。
2.2 C# 版本和框架选型：这决定了你能不能用新语法
二手交易平台这种典型管理系统，最常见的实现形式是 ASP.NET MVC 5 + EF6 + SQL Server，或者 ASP.NET Core。这两种路线的代码写法和依赖差异非常大，建议拿到代码先打开项目文件确认 target framework。
如果是.NET Framework 4.7.x或 4.8，那代码里大概率用的是System.Web.Mvc，async/await可以用但要注意HttpContext的线程安全问题。如果是.NET 6或.NET 8，项目里会出现Program.cs加app.MapControllers()这类新式写法，程序集引用完全走PackageReference。
我见过最典型的翻车现场：一个 2020 年的 MVC5 项目，工程文件里写着<TargetFrameworkVersion>v4.6.1</TargetFrameworkVersion>，而 VS 2022 默认没装 4.6.1 的 Developer Pack，F5 一编译就报“无法找到 .NETFramework,Version=v4.6.1 的参考程序集”。这种问题不是代码bug，是环境缺组件，装一个对应的 Developer Pack 即可，不要去把项目的 TargetFramework 强改成 4.8——除非你有把握所有第三方库都向下兼容。
2.3 三条腿走路：表现层、业务层、数据层在代码里怎么对上号
不管原作者命名多随意，只要架构没塌，你一定能从目录或命名空间里发现这三层。我们以最常见的 MVC5 项目为例：
表示层是Controllers、Views和Models（或ViewModels）。Controllers里面的每一个类对应一类页面操作，比如AccountController管登录注册、ProductController管商品发布和列表、OrderController管交易流程。Views下面的子目录跟 Controller 名字一一对应。
业务层通常叫Services或BLL。这一层不直接碰数据库，只接收 Controller 传来的参数，处理业务规则——比如“发布商品时必须登录”“订单生成后商品状态要改为已下架”。有的毕设代码会把业务规则全写在 Controller 里，这种代码虽然能跑，但答辩时老师很容易追问“如果我要在网页之外再做一个手机端，业务逻辑怎么复用”，答不上来就会减分。
数据层是DAL、Repository或Models下的DbContext类。用 EF6 的项目会有一个继承自DbContext的类，里面通过DbSet<Product>方式暴露表。用三层原生 ADO.NET 的项目则是一堆SqlHelper加XxxDAL类。
对应关系理清楚后，你改代码就只需要顺着一条线走：页面点击 -> Controller 动作 -> Service 方法 -> DAL 查询 -> 返回 JSON 或 View。如果原作者把三层混在一起写，你也不用强拆，答辩能说清楚“我现在的代码是两层结构，但业务逻辑已经抽成部分类，后续可以平滑升级为三层”，这个说法也能过关。
2.4 第一个最小目标：把项目在本地跑起来
环境对齐后，按下面顺序操作，任何一步失败都有明确排查方向：
# 1. 确认数据库服务在本地已启动，并记录身份验证方式 # 常见做法：SQL Server 用 Windows 身份验证；MySQL 用 root / 123456 # 注意要跟连接字符串里的配置完全一致 # 2. （推荐）先还原 NuGet 依赖 nuget restore 解决方案名.sln # 3. 找到 Web.config（Web项目）或 App.config（桌面项目）中的 connectionStrings # 将 data source / server 改成 .\SQLEXPRESS 或 localhost # initial catalog 改成你要用的数据库名，比如 SecondHandDB<!-- Web.config 中的连接字符串，是最常见的 SQL Server 写法 --> <connectionStrings> <add name="DefaultConnection" connectionString="Data Source=.;Initial Catalog=SecondHandDB;Integrated Security=True;" providerName="System.Data.SqlClient" /> </connectionStrings># 4. 在 SQL Server Management Studio 中执行数据库脚本 # 打开 .sql 文件，选择目标数据库（先手动建一个空库再执行） # 看到“命令已成功完成”提示，说明表和基础数据已经进去# 5. Ctrl+F5 启动，打开浏览器后检查首页是否正常渲染 # 如果报“找不到 System.Web.Mvc”这类错误，打开“工具 -> NuGet 包管理器 -> 管理解决方案的程序包” # 把 MVC 版本统一安装回项目引用的版本，不要升级到 6.x，新版包在旧工程里常出怪问题上述步骤做完，系统基本就能在本机跑起来了。逻辑说明放在这里：先保证环境与源码一致，再谈改代码；不然你永远分不清是“程序有问题”还是“配置有问题”。
3. 二手交易平台的数据底座：数据库设计、E-R 核心表和状态流转
一个交易平台能不能讲出东西，全看数据库设计。答辩老师最喜欢问“为什么商品表和订单表要这么分”“订单状态用什么字段存”。这一章直接给出一套相对标准的设计，你的表不一定要完全一样，但核心思路要对齐。
3.1 五张核心表和它们解决什么问题
第一类是用户表SysUser，字段包括Id、UserName、PasswordHash、NickName、AvatarUrl、Phone、CreateTime。注意密码不能明文存储，哪怕微软官方教程都要求用PasswordHasher或加密算法处理后再入库。如果原代码直接insert into 用户表 values('admin','123456')，那是典型的教学 demo 风格，你在答辩稿里要主动说明你做了改进。
第二类是商品表Product，字段建议包含Id（主键）、SellerId（外键引用用户表）、Title、Description、Price、OriginalPrice、CategoryId、Status（0草稿/1在售/2已下架/3已卖出）、ViewCount、PublishTime。这里最容易出现的坑是卖家删除商品——如果直接物理删除，那么历史订单里关联的商品信息会变成空壳，订单表查不到商品详情。所以交易平台一律建议使用逻辑删除：加一个IsDeleted布尔字段，查询时统一过滤。
第三类是订单表TradeOrder，主键Id、OrderNo（业务编号，下单时用Guid.NewGuid().ToString("N")生成）、ProductId、BuyerId、SellerId、Amount、Status、CreateTime、PayTime、FinishTime。订单状态建议用 int 存，而且只允许向后流转：待付款(1) -> 待发货(2) -> 待收货(3) -> 已完成(4) / 已取消(5)。
第四类是收藏和点赞表Favorite，字段为Id、UserId、ProductId、CreateTime，加上用户和商品的外键联合唯一索引，防止同一用户重复收藏同一商品。
第五类是消息/评论表Message，用于实现“分享”部分的社交性：Id、FromUserId、ToUserId、Content、CreateTime、IsRead。不要小看这张表，它把你和“普通二手商城”区分开——物品买家可以对卖家留言咨询，这条线是“分享”两个字的直接落地。
3.2 外键、索引和 DELETE 的三种策略
数据库脚本建好后，紧接着要检查三处细节，直接影响系统在答辩演示时会不会翻车：
外键约束：Product.SellerId必须引用SysUser.Id，TradeOrder.ProductId必须引用Product.Id。如果脚本里没建外键，你要在 SSMS 里手动补上。举个例子：
-- 添加外键约束：订单表关联商品表 ALTER TABLE dbo.TradeOrder ADD CONSTRAINT FK_TradeOrder_Product FOREIGN KEY (ProductId) REFERENCES dbo.Product(Id);默认值：CreateTime字段的最好设定是getdate()（SQL Server）或DEFAULT CURRENT_TIMESTAMP（MySQL），不行的话在 C# 代码里构造实体时赋值DateTime.Now，否则每次新插入记录都会报“CreateTime 不能为空”的异常。
删除策略：主表和子表之间不要开ON DELETE CASCADE，尤其用户表和商品表。删除用户时级联删除他的商品和订单，会导致卖家历史交易记录全部消失，这在“分享平台”场景下等于把用户的数据所有权给清了。正确做法是软删——用户禁用用IsActive字段，商品删除用IsDeleted字段。
3.3 订单状态机：用一张表理解整个业务闭环
这里给一个可直接抄的状态定义和流转关系，配合 C# 里的常量类使用：
| 状态值 | 名称 | 可执行操作 | 跳转目标 |
|---|---|---|---|
| 1 | 待付款 | 支付 / 取消 | 2 / 5 |
| 2 | 待发货 | 卖家发货 | 3 |
| 3 | 待收货 | 买家确认收货 | 4 |
| 4 | 已完成 | 无 | 无 |
| 5 | 已取消 | 无 | 无 |
对应到 C# 代码里，通常是这样的常量定义：
// OrderStatus.cs —— 订单状态常量类，避免到处写魔法数 public static class OrderStatus { public const int PendingPayment = 1; // 待付款 public const int PendingDelivery = 2; // 待发货 public const int PendingReceipt = 3; // 待收货 public const int Finished = 4; // 已完成 public const int Cancelled = 5; // 已取消 // 判断当前状态是否可以执行某个操作 public static bool CanTransit(int fromStatus, int toStatus) { // 只允许相邻合法流转 return (fromStatus == PendingPayment && (toStatus == PendingDelivery || toStatus == Cancelled)) || (fromStatus == PendingDelivery && toStatus == PendingReceipt) || (fromStatus == PendingReceipt && toStatus == Finished); } }这个类的存在让业务逻辑的可读性提高一个档次，答辩时你可以说“我没有把状态判断散落在各个 Controller 里，而是集中在一个静态状态机里管理，后续要加‘申请退款’等新状态，只需要在这里加流转规则”。
4. 把“交易 + 分享”业务跑通：Controller 路由、EF 查询和防超卖关键代码
数据库铺好后，核心工作是在 C# 后端把业务串起来。这里选三个高频功能拆开讲：用户登录会话、商品发布与列表、下单与防超卖。这三个功能覆盖了“交易”和“分享”两条主线的 80% 工作量。
4.1 登录与身份认证：Session、Cookie 和过滤器三位一体
MVC5 项目最稳妥的方案还是 Forms 认证加Session。用户在登录表单输入用户名和密码后，校验通过则写入Session["UserId"]和Session["UserName"]，然后在需要登录的 Controller 或 Action上打[Authorize]标签。
// AccountController.cs —— 登录动作的核心逻辑（省去参数校验） [HttpPost] [AllowAnonymous] public ActionResult Login(LoginViewModel model) { // 1. 先查数据库，比对用户名和密码哈希 var user = db.SysUsers.FirstOrDefault(u => u.UserName == model.UserName); if (user == null || !VerifyPassword(model.Password, user.PasswordHash)) { ModelState.AddModelError("", "用户名或密码错误"); return View(model); } // 2. 会话记录身份，FormsAuthentication 会发一个加密 Cookie Session["UserId"] = user.Id; Session["UserName"] = user.NickName; FormsAuthentication.SetAuthCookie(user.UserName, false); return RedirectToAction("Index", "Home"); }参数说明：AllowAnonymous表示这个 Action 即使不登录也能访问；SetAuthCookie的第二个参数false表示不生成持久 Cookie，关闭浏览器即失效。判断当前用户是否登录时，优先使用User.Identity.IsAuthenticated，不要用Session["UserId"] != null来拦截页面，因为前者和[Authorize]过滤器联动，后者偶尔会因为 Session 丢失而把已登录用户踢回登录页。
4.2 商品发布与列表：EF6 里查询、排序、分页的标准姿势
商品列表页要看“最新发布”和“价格排序”，使用 EF6 的语法时最核心的一点是：在真正 ToList 之前不要中断 IQueryable 链式调用，否则数据全部加载到内存再筛选，数据量一大就卡。
// ProductController.cs —— 商品列表（分页 + 分类筛选） public ActionResult Index(int? categoryId, int pageIndex = 1, int pageSize = 12) { // 延迟执行：此时还没有真正访问数据库 IQueryable<Product> query = db.Products .Where(p => p.Status == ProductStatus.OnSale && !p.IsDeleted); // 分类筛选是可选参数，有值才追加条件 if (categoryId.HasValue && categoryId.Value > 0) { query = query.Where(p => p.CategoryId == categoryId.Value); } // 先按发布时间倒序，再取分页数据 var totalCount = query.Count(); // 首次触库：得到总数 var list = query.OrderByDescending(p => p.PublishTime) .Skip((pageIndex - 1) * pageSize) // 跳过前 N 条 .Take(pageSize) // 取当前页 .ToList(); // 第二次触库：得到结果 ViewBag.TotalCount = totalCount; ViewBag.PageIndex = pageIndex; ViewBag.PageSize = pageSize; return View(list); }这段代码里最容易忽略的是Count()和ToList()触库的时间点不同。如果有人在Where后面直接加foreach遍历再分页，那就等于全表加载。Skip和Take是 EF 翻译成 SQL 的OFFSET FETCH，不是内存操作，所以分页性能没问题。
发布商品的 Action 设计相对简单，核心是把IEnumerable<HttpPostedFileBase>接收的图片保存到~/Upload/目录，并把路径列表拼成 JSON 字符串存入商品表的Images字段。代码略，但你要注意：Server.MapPath("~/Upload/")在 MVC5 里仍然好用，如果换成 ASP.NET Core 就要用IWebHostEnvironment.WebRootPath。
4.3 下单防超卖：数据库事务和行锁才是关键
二手平台卖的是单件商品，不是库存多的标品，所以超卖风险集中在“两个买家同时抢一件在售商品”。最常见的坑是：先查商品状态，再生成订单，最后改商品状态。三步之间一旦没有事务和隔离级别保护，同一件商品可能被下两单。
正确做法是使用数据库事务，并且把状态更新放在 SQL 层面先执行，也就是先“锁定”这件商品，再插入订单：
// OrderController.cs —— 创建订单：使用事务防止并发超卖 [HttpPost] [Authorize] public ActionResult CreateOrder(int productId) { var buyerId = (int)Session["UserId"]; using (var transaction = db.Database.BeginTransaction()) { try { // 1.（关键）直接 UPDATE 商品状态，SQL 层面用行锁保证同一条记录只会被一个事务成功更新 // 这里用 ExecuteSqlCommand 而不是先 Select 再 SaveChanges，就是为了避免竞态条件 int affectedRows = db.Database.ExecuteSqlCommand( "UPDATE dbo.Product SET Status = @p1 WHERE Id = @p0 AND Status = @p2", productId, ProductStatus.OnSale, // 参数名按顺序对应当前 SQL Server 版本可省略 ProductStatus.OnSale); if (affectedRows == 0) { transaction.Rollback(); return Json(new { success = false, msg = "商品已被下单或下架" }); } // 2. 事务内插入订单，失败则整体回滚 var order = new TradeOrder { OrderNo = Guid.NewGuid().ToString("N"), ProductId = productId, BuyerId = buyerId, SellerId = db.Products.Find(productId).SellerId, Amount = db.Products.Find(productId).Price, Status = OrderStatus.PendingPayment, CreateTime = DateTime.Now }; db.TradeOrders.Add(order); db.SaveChanges(); transaction.Commit(); return Json(new { success = true, orderNo = order.OrderNo }); } catch (Exception ex) { transaction.Rollback(); return Json(new { success = false, msg = "服务器异常，请重试" }); } } }这段代码的精髓在于用UPDATE ... WHERE Status = 在售的“条件更新”作为并发闸门——两个请求同时进来时，数据库行锁会保证第一个 UPDATE 成功，第二个 UPDATE 因为 WHERE 条件已不满足而影响 0 行，于是直接判定为“已被抢”。如果只用SaveChanges先查后改，第二条并发请求一定读到旧值为在售，就能插入重复订单。这也是为什么毕设答辩时“防超卖”是一个容易得分的考点。
4.4 分享功能：消息记录怎么和商品、订单挂上钩
“分享”体现在两块：一个是商品页面的“分享到站内私信”，另一个是收藏夹的社交属性。简单做法是Message表里加一个ProductId可空字段，用户对某个商品发起咨询时，FromUserId为咨询人，ToUserId为卖家，ProductId为商品主键。这样卖家的“消息中心”能从Message表里GroupBy ProductId拉出所有会话概要。不要把聊天内容直接嵌在订单里，因为用户可能在未下单前就咨询商品，这样消息就和订单脱钩了。
5. 前端页面与前后端交互：从 Razor 视图到 jQuery Ajax 的衔接细节
C# 毕设的界面通常不追求花哨，但“能演示、不白屏、不报 500”是底线。这一章重点讲页面层和代码层的三个关键衔接点。
5.1 Razor 视图里避免写业务代码
MVC5 的.cshtml文件是服务端渲染模板，但很多同学会把 EF 查询直接写进@{}代码块，导致页面加载极慢。视图里只做展示和简单循环，数据全部由 Controller 通过ViewBag或强类型 Model 传递。
@* Product/Index.cshtml —— 商品卡片列表片段 *@ @model IEnumerable<二手交易平台.Models.Product> <div class="row"> @foreach (var item in Model) { <div class="col-md-3 col-sm-6"> <div class="card"> <img src="@item.CoverImageUrl" class="card-img-top" alt="@item.Title" /> <div class="card-body"> <h5 class="card-title">@item.Title</h5> <p class="card-text text-danger">¥ @item.Price.ToString("0.00")</p> <a href="@Url.Action("Detail", "Product", new { id = item.Id })" class="btn btn-primary btn-sm">查看详情</a> </div> </div> </div> } </div>@item.CoverImageUrl是商品的第一张图，它来自商品Images字段的 JSON 拆解。如果图片字段为空，<img src="">会显示一个破碎图标，建议在 Controller 组装 ViewModel 时判断一下并给默认图路径，比如写死为/Upload/default.png。
5.2 fetch 和 jQuery Ajax 选哪个
如果项目基于 MVC5 默认模板，jQuery 已经预置在Scripts目录里，直接用$.ajax是成本最低的方案。ASP.NET Core 6+ 项目默认没有 jQuery，建议用原生fetch配合@Url.Action生成接口地址。
// 下单按钮的 jQuery 写法（MVC5 时代最常见） $('#btnBuy').click(function () { var productId = $('#productId').val(); $.ajax({ url: '@Url.Action("CreateOrder", "Order")', type: 'POST', data: { productId: productId }, dataType: 'json', success: function (response) { if (response.success) { alert('下单成功，订单号：' + response.orderNo); window.location.href = '@Url.Action("MyOrders", "Order")'; } else { alert(response.msg); } }, error: function () { alert('网络异常，请重试'); } }); });这段代码有几个点容易被忽略。data里传的是 JSON 对象，但 jQuery 在 POST 请求中默认会把它序列化成application/x-www-form-urlencoded，在 MVC 的 Action 参数int productId能正确绑定。如果你的项目改成了 ASP.NET Core 的 Web API，则要在[ApiController]的 Action 参数上标[FromBody]，否则来自 JSON 的请求没法绑定到简单类型参数。
5.3 上传图片：路径、回显和一次性校验三个坑
商品发布页里的图片上传是最容易在演示时出洋相的功能，常见问题有三个：
坑一：文件保存路径错。代码写成Server.MapPath("~/Upload/")但~/Upload目录不存在，VS 开发服务器下有时会自动创建，发布到 IIS 后不会。解决办法是在Application_Start或首次上传时用Directory.CreateDirectory强制建目录：
// 文件上传工具类片段 string uploadDir = Server.MapPath("~/Upload/"); if (!Directory.Exists(uploadDir)) { Directory.CreateDirectory(uploadDir); } string fileName = Guid.NewGuid().ToString("N") + Path.GetExtension(file.FileName); file.SaveAs(Path.Combine(uploadDir, fileName));坑二：回显路径是相对路径，发布后 404。数据库中存/Upload/xxx.jpg是正确做法，页面直接<img src="/Upload/xxx.jpg">没问题。如果你在 Action 里用Server.MapPath加工后把物理路径存进数据库（例如E:\site\Upload\xxx.jpg），那换一台电脑就全裂图。数据库存的一定是 URL 相对路径。
坑三：只允许图片，却接收了 exe 等任意文件。校验不能只靠前端扩展名判断，后端取文件后要验证ContentType或文件头，至少用扩展名白名单拦截：
// 图片扩展名白名单 string[] allowExt = { ".jpg", ".jpeg", ".png", ".gif" }; var ext = Path.GetExtension(file.FileName)?.ToLower(); if (!allowExt.Contains(ext)) { ModelState.AddModelError("", "仅支持 jpg、png、gif 图片"); return View(model); }6. 带着这份“避坑清单”去跑通：环境、编译、数据、答辩四类问题
这一章是毕设期间真正能省下时间的部分。每个问题都是真实场景记录，按“现象 -> 原因 -> 解决”三段写，方便你直接定位。
6.1 一运行就报“找不到 System.Web.Mvc”或黄色页面 YSOD
现象：F5 启动后浏览器出现红色错误页，错误信息包含System.Web.Mvc或System.Web.Optimization等字样。
原因：通常是三个原因叠在一起。第一，项目用了 NuGet 包管理器还原，但还原时网络中断导致 DLL 缺失；第二，某次手痒把所有包点击“更新”升级到了 MVC 6，项目引用碎裂；第三，Web.config 里compilation debug="true" targetFramework="4.6.1"和目标框架不一致。
解决：先在“工具 -> NuGet 包管理器 -> 程序包管理器控制台”执行Update-Package -Reinstall Microsoft.AspNet.Mvc，强制重装包并恢复引用。然后打开packages.config看已安装的版本，比如Microsoft.AspNet.Mvc 5.2.7，再去每个 csproj 里搜HintPath，确认引用路径中packages目录名与版本号一致。手改最快的方式是删除整个packages文件夹，然后重新还原。
6.2 SQL Server 连不上：与提供的用户名或密码登录失败
现象：运行后页面跳转到登录页或直接 500，查看异常信息为Login failed for user 'sa'或Cannot open database "SecondHandDB" requested by the login。
原因：连接字符串中配置的用户是sa，但本机 SQL Server 用的是 Windows 身份验证模式，或者没启用sa；其次，数据库名和实际不一致。
解决：在 SSMS 中确认 SQL Server 实例名，然后在Web.config中改连接字符串：
<add name="DefaultConnection" connectionString="Data Source=.;Initial Catalog=SecondHandDB;User ID=sa;Password=xxx;" providerName="System.Data.SqlClient" />如果不想处理sa密码复杂度问题，直接把Integrated Security=True并注释掉 User ID/Password，配上 Windows 身份验证模式即可。提示：连接字符串里Data Source=.;的.指本机默认实例；若安装了命名实例如SQLEXPRESS，要写成.\SQLEXPRESS。
6.3 页面点击“购买”没反应，浏览器 Network 里看到 500
现象：商品详情页能打开，F12 的 Network 面板里CreateOrder请求返回 500 Internal Server Error。控制台日志可能提示 “Cannot insert explicit value for identity column” 或 “Invalid column name”。
原因：前一版测试数据里插入了脏数据，主键Id的自增种子被破坏；或数据库脚本和实体模型不对齐，EF 生成的 SQL 引用了表中不存在的列。
解决：执行批量清理脏数据并重置自增，然后重启应用：
-- 清除订单表中所有测试数据并重置自增种子 TRUNCATE TABLE dbo.TradeOrder; -- 若订单被外键引用，改用 DELETE 并 DBCC CHECKIDENT DELETE FROM dbo.TradeOrder; DBCC CHECKIDENT ('dbo.TradeOrder', RESEED, 0);TRUNCATE速度快但不支持有外键引用，所以如果是被 FK 约束就改用DELETE+DBCC CHECKIDENT。重置后重新走一遍下单流程；若还是 500，打开 SQL Server Profiler 或让异常先展示出来（临时把customErrors mode="Off"），把 EF 生成的 SQL 复制到 SSMS 执行，对比实体属性与表列名差异。
6.4 答辩前准备：代码讲不出亮点时，往这三个方向补
很多同学的代码能跑通但答辩时讲不出深度。其实只要在原系统里做三个小改进，就能让答辩老师眼前一亮。
第一个方向是“商品搜索”。原项目可能只按名称模糊查询，你可以升级为按分类 + 价格区间 + 成色多条件组合过滤，核心代码在 Controller 中追加过滤条件，配合前端表单。第二个方向是“用户信用积分”，在用户表加一个CreditScore字段，卖家完成一单加 2 分，买家确认收货后给卖家评价，订单关闭后结算积分。这个改进工作量很小，但把“交易 + 分享”平台变成了“信用社区”，语义马上不一样。第三个方向是“站内通知”，在新表Notice中保存点赞、留言、下单成功等事件，用户登录后读取未读数量并显示在导航栏角标上。
答辩陈述时，建议话术是：基础功能有一 二三，我个人在Product和Order之外加了一个Favorite关联表和Message表，让“分享”不只是转发链接，而是站内用户之间的真实互动。再补充一句：并发场景下我用事务加状态条件更新防止一物多卖，并用CHECKIDENT解决测试数据污染问题。这些细节加起来，已经超过本科生毕设的平均完成度。
7. 最后的临门一脚：把 Visual Studio 项目打包成一个能演示的版本
演示阶段不再建议依赖 VS 内嵌的 IIS Express，万一答辩电脑没装开发环境，整个就卡死在第一步。下面这套流程我每次带人演示都用，稳定且不依赖第三方工具。
7.1 发布网站：IIS Express 换成目录发布
在 Visual Studio 中右键项目名 -> “发布”，目标选“文件夹”。发布的目录里会出现bin、Views、web.config等，这就是可直接挂到 IIS 的成品。发布完成后，把整个文件夹拷到答辩电脑（或本机 IIS），然后在 IIS 中新建应用程序池和网站，物理路径指到该目录。
# 目录发布出来的结构至少要包含四个部分 # bin/ （编译好的 DLL 和第三方库） # Views/ （Razor 编译后的视图文件，发布时会预编译为主 DLL） # web.config （连接字符串、HTTP 模块配置，注意里面不含源代码） # Upload/ （上传图片目录，为空也要保留，否则第一次上传报目录不存在）提示：发布版本里只有 DLL，没有
.cs源文件；如果你在博客或网盘上分享源码包，记得把.sln、.csproj、.cs和.sql脚本一起放进去，否则下载方只能部署运行却没法改代码。
7.2 数据库导入脚本的两种兜底方式
答辩演示机如果没装 SQL Server，最保险的办法是在演示前把数据库整体备份为.bak文件，并在目标机 SQL Server 中执行还原：
-- 目标数据库还原 RESTORE DATABASE SecondHandDB FROM DISK = 'D:\backup\SecondHandDB.bak' WITH REPLACE, RECOVERY;如果没有.bak，就用.sql脚本重建。脚本执行顺序要注意：先建库（CREATE DATABASE），再切库（USE），然后建表，最后插入基础数据（分类数据、管理员账号）。如果脚本没有CREATE DATABASE语句，你可能要先手动建好空库，再指定执行。个人经验是，两种方式都预演一遍，因为.bak还原偶尔会因为版本不兼容失败，而.sql脚本只要字符集没有问题几乎百发百中。
7.3 演示前必调的三处“面子工程”
第一处是管理员账号。原项目默认密码如果不记得，直接打开数据库客户端执行一条 SQL 把已知用户临时改成已知密码——如果代码里用的哈希，改成明文前确认验证逻辑。建议提前在本地跑通一次账号密码，不要现场猜。
第二处是演示数据。空库演示容易让老师觉得系统没什么内容。提前往Product表插入 8~10 条不同分类的商品数据，图片路径存成占位路径，并保证全部Status=1。插入后跑一遍列表页，确认没有裂图、没有分页越界。
第三处是杀软和防火墙。Windows Defender 有时会拦截 IIS 进程访问 Upload 目录；如果用的是局域网 IP 让老师访问，需要在中控防火墙里放行 IIS 的80/8080端口。你把这两项都处理完，演示时就只剩业务操作，不会有环境层面的干扰。
写到最后也聊聊我自己的习惯：带任何毕设项目，我都会先搭一个“最小可运行闭环”——一个 Controller 加一个视图加一张表，跑通之后再谈其他功能。这个项目真正的价值不在代码量，而在那几个边界场景：并发防超卖、软删与级联取舍、图片上传校验。你能把这些边界讲清楚，比多写一百行 CRUD 更让人信服。希望这篇笔记能帮你把源码包拆出真正的门道，也少熬几个“环境配不上”的夜。祝答辩顺利。
本文还有配套的精品资源，点击获取
