基于.Net的智慧阅读书城系统开发实战：从数据库到答辩全解析

先解释一下这个标题：基于 .Net 的智慧阅读书城系统，本质上就是做一个网上图书商城，按课程设计/毕业设计的标准去完成需求分析、数据库设计、前后端代码和论文文档。功能上包含前台图书展示、用户注册登录、搜索、购物车、订单结算，以及后台的书籍、分类、订单、用户管理。换一个更直白的说法，就是一套完整的“网上书店”全栈应用，只是技术栈固定在了 .Net 上。

如果你正在为课程设计或毕业设计发愁，或者拿到了类似的源码但不知道怎么讲清楚、改明白，这篇内容希望帮到你。我会从项目定位、数据库、核心模块、常见坑和答辩准备几个方面展开，基本是我自己做完这个方向的课设后沉淀下来的经验，不会只给你堆概念。

1. 先弄明白自己要交一个什么东西

很多同学拿到的别人分享的源码，第一反应是打开 Visual Studio，点“运行”，然后想：能跑起来就万事大吉。但课程设计不是这样过的，答辩时老师会拆开问：功能有哪些、数据库怎么设计的、某个业务是怎么实现的、为什么这样写。如果说不清楚，即便功能再全，分数也会打折。

1.1 课程设计里的书城系统，究竟是一个什么定位

书城系统属于典型的“信息管理系统 + 电商基础功能”混合体。相对写算法、写游戏，它的逻辑简单、模块边界清晰，非常适合用来检查你对 .NET 开发、数据库设计、HTTP 请求流程、Session 管理这些东西的掌握程度。

这个系统需要同时解决两类问题：普通读者要能够浏览图书、查询图书、加入购物车并下单；管理员要能够发布新书、调整库存、查看订单并处理。听起来并不复杂，但正因为不复杂，它才能在一个学期或一个设计周内真正完成，形成完整的工作量。

“智慧阅读”这个词在标题里显得比较高级，实际落地时，通常是在基础书城功能之上增加阅读排行、浏览记录、同类书籍推荐、按销量和热度排序这些“带推荐性质”的模块。它的意义主要是给系统找到差异化亮点，同时也方便在论文里写“系统拥有较好的用户体验和个性化推荐能力”这类总结性描述。

1.2 为什么 .Net 技术栈适合做课设，以及选型要注意什么

用 .Net 做课设的最大优势是环境系列化，一个人从数据库到服务端代码到页面展示全链路搞定，不需要额外搭前端服务、准备多个运行时。

在选型上，旧一些的校内参考案例多用 ASP.NET WebForms 或 ASP.NET MVC 5，数据库是 SQL Server；现在也有部分学校要求 ASP.NET Core，甚至自己指定 .NET 6/8。拿到别人源码时，第一个要做的事，不是立刻上网找资源，而是确认源码和本机环境是否兼容。启动时最常见的报错，比如视图编译不过、包还原失败、数据库连不上，多数都和版本错配有关。

我偏向于推荐你学习型的实现方式是这样的：

• 服务端技术：ASP.NET MVC 5 或 ASP.NET Core MVC，二者逻辑差不多，MVC 分层清晰，课程设计好讲解。
• 数据访问：EF（Entity Framework）的 Code First 或三层架构中的 ADO.NET 封装，两者能说出一套即可。EF 代码简洁、写数据库时不容易出错，ADO.NET 更便于理解 SQL 语句，但代码量稍大。
• 数据库：SQL Server，和 .Net 配合好，课程设计的报告普遍也会默认使用 SQL Server 截图。
• 前端：Bootstrap 加一些简单模板，不需要强行用 Element UI 或 Vue，除非你本来就熟练。

如果你手里只有一个 .NET Framework 4.x 源码，但老师要求 .NET Core 或 .NET 6 以上，那就不能指望直接改一两个字后能运行。真出现这种情况，最好的路径不是逐行翻译代码，而是把原来的页面和数据库拿过来，重新写一套 MVC 或 Razor Pages 项目，前端和 SQL 大体上能复用一半以上，这样反而省事。

1.3 我的功能模块是怎么拆分设计的

这个系统无论如何扩展，都会围绕两个角色工作：用户和管理员。按角色划分模块，论文里的系统功能结构和实际代码页面能一一对应，不容易出现“图里画了十个模块但代码里只有四个页面”的情况。

前台用户端，至少要包含下面这些功能点：

• 用户注册与登录、个人信息维护、密码修改。
• 图书首页展示：轮播图、新书推荐、热门排行。
• 分类检索：按一级/二级分类浏览指定类别的图书。
• 关键词搜索：支持按书名、作者模糊查询。
• 图书详情页：封面、简介、作者、定价、库存，以及加入购物车或直接购买。
• 购物车：对图书数量的增删改、选中结算。
• 订单：提交订单、模拟支付、查看历史订单、订单明细。
• 评论与收藏（可视情况加入），如果做“智慧”亮点，这部分非常有价值，比如基于图书的收藏和评论推荐同类书。

后台管理端，相对功能更“传统”，但不要省略：

• 管理员登录。
• 图书管理：列表、添加新书、修改信息、上下架、删除，并支持封面图片上传。
• 分类管理：一级分类、二级分类维护。
• 订单管理：查看所有订单，调整订单状态，比如待付款、已付款、已发货、已完成。
• 用户管理：查看注册用户、启用或禁用账号。
• 数据统计：销售报表、图书热度排行，这是区别于普通书城的一个加分项。

你会发现，上面的模块之间耦合性很低，每部分都能在报告里独立成节，也能在答辩时被单独提问。这个特点对“讲清楚项目”是很有帮助的。

2. 数据库不是随便建几张表，而是一个业务逻辑的翻译

如果把 Web 系统比作一个人，数据库就是它记忆事情的那部分。书城系统的后台代码可能很灵巧，页面也可能很漂亮，但只要涉及下单、存书、查历史，最终都要落到数据库里。

在我第一次做类似课设的时候，为了省事把所有数据塞进一两张宽表里，结果写着写着发现排序、分页、推荐全被一张结构不清晰的表绊住了。后来老老实实拆表才顺畅。这也说明，建表这一步偷懒，后面一定会加倍还回来。

2.1 核心表，其实就八张左右

正常情况下，书城系统的表不需要超过十张，把表拆出二十多个反而容易被评委质询“存在明显的过度设计”。我认为最少且合理的主表设计如下：

• 用户表 Users。字段：UserId 自增主键，Username 用户名（唯一），Password 密码哈希，NickName 昵称，Gender，Phone，Email，Address，UserType 标志用户还是管理员，CreateTime。
• 图书表 Books。字段：BookId 主键，CategoryId 关联分类，BookName，Author，Publisher，PublishDate，ISBN，Price，DiscountPrice 或 SalePrice 实际售价，Stock 库存，Cover 封面图片路径，Description 描述，Sales 销量，State 上架/下架，CreateTime。
• 分类表 Categories。字段：CategoryId，CategoryName，ParentId。ParentId 为 0 时是一级分类，非 0 时表示它是某一个一级分类下的二级分类。用 ParentId 做自关联，比设计两张一级分类表和二级分类表要方便。
• 购物车表 CartItems。字段：CartItemId，UserId，BookId，Quantity，AddTime。用 UserId 和 BookId 联合查询。
• 订单表 Orders。字段：OrderId（可用带日期的时间戳主键或自增主键），OrderNo 给用户看的流水号，UserId，TotalAmount，Status（0 待付款，1 已付款待发货，2 已发货，3 已完成，4 已取消），ReceiverName，ReceiverPhone，ReceiverAddress，CreateTime，PayTime。
• 订单明细表 OrderItems。字段：OrderItemId，OrderId，BookId，BookName 快照，Price 购买时价格，Quantity，SubTotal。保存 BookName 快照是很好的习惯，因为如果后来修改了图书名称或价格，历史订单仍能正确显示。
• 评论表 Comments。字段：CommentId，BookId，UserId，Content，Score 评分，CreateTime。
• 公告或轮播图表 Banner/Notice。字段：Id，Title，ImageUrl，LinkUrl，Sort，Enable。如果整个页面的轮播内容想方便管理，可以做成表；不想管理的话，页面写死也能应付。

有一部分需求里还有收藏表 Favorites：FavoriteId，UserId，BookId，CreateTime，做“我的收藏”和个人推荐时会用上。

2.2 关键表的关联关系与外键使用注意

表与表之间的核心关系，可以梳理为：

• 用户 1 对 多 购物车项：一个用户可以往购物车加多条记录。
• 用户 1 对 多 订单：一个用户可以有多个订单。
• 订单 1 对 多 订单明细：一个订单包含多个图书。
• 图书多对多标签/分类，实际通常简化为 图书 N 对 1 分类，因为每本书在书城导航中会被放进一个最具体的二级分类。
• 评论表关联用户和图书，通常用 BookId + UserId 建立联合索引。

在设计外键时，课程设计要求需要体现“完整性”。但我建议，除非你用的是 EF Code First 自动生成带外键的库，否则不要为了建外键把所有表都加上级联删除。比如订单明细表关联图书，如果设有外键并且开启级联删除，那么后台一旦误删一本书，历史订单明细会一起丢失，这在电商场景里是严重事故。课程设计报告里，可以声明“外键关系由代码逻辑保证”，但页面要限制删除已产生订单的图书，比如改成下架，而不是物理删除。

2.3 初始化数据，怎样从零打造一个“看起来跑了很久”的书城

一个刚跑起来的空书城，页面不会好看，答辩时老师一进去看到“暂无图书”，体验极差。最好的办法是导数据的 SQL 脚本里自带若干条数据：

• 至少 30 本图书。书名、封面、作者、简介尽量贴近市面真实书籍，但不要用盗版封面或受版权限制的图片。如果找不到图片，可以自己用占位图并配纯色封面，或直接从出版社官方素材页找允许引用的图书资料。
• 用户至少两个角色各一个：admin 管理员、test 普通用户。
• 1~2 条已支付、已完成流程的示例订单。
• 几条评论和评分，评分最好让数据有梯度，方便做推荐逻辑演示。
• 轮播图数据 3 条。

分类数据的组织建议用“一级大类 + 二级细分类”结合方式。一级分类如文学、历史、科技、少儿；二级分类如“文学——小说”“文学——散文”“历史——中国史”“科技——编程”。这样的设计也便于写“点击分类后递归展示下级分类”的功能，虽然实际需求只到二级就足够了。

3. 核心业务功能，别只会套页面模板

很多同学拿到一份能运行的源码后，第一步就是注册账号、下单跑一遍，然后以为大功告成。但答辩老师基本不会只要求你演示流程，他们更在意你会不会解释业务背后的设计决策。这里挑几个重点模块，讲一讲实现思路。

3.1 登录、注册与权限拦截：整个系统的门禁

登录模块看着简单，但如果处理不当，把页面放在登录校验之外，用户不需要登录也能打开后台地址，那就是严重安全漏洞。所以代码里至少要有这样一个逻辑层次：

所有请求先进拦截器/过滤器；判断请求路径是否需要登录；如果需要，再看 Session 里有没有用户信息；如果没有，就跳回登录页。传统 ASP.NET Core 里也可以用中间件，或者给 Controller 打 [Authorize] 特性。

给管理员单独做一套 Controller 或 Area 是一个比较好的习惯。后台 Area 强制要求管理员角色：当 Session 不是管理员时，直接拒绝，不能仅靠前端隐藏“后台管理”入口就认为安全。

另一个细节是密码存储。凡是教材级别做这类课设，示例代码经常用明文或者 MD5 加密。真实项目推荐这样做：

• 不要存储明文密码，也不要只做普通 MD5，常见说法是加盐。
• 简单可靠的选择：可以用 SHA256，将 用户名+密码+固定盐 组合后哈希，或者用 BCrypt。课设如果担心环境装依赖不好解释，至少也要做一个“密码字符串 + 随机盐后取多次哈希”的工具方法。

注意：很多课程设计对密码加密不会深究，你完全可以选简单方案；但答辩时如果有人问“密码存的是明文吗”，你如果说“是明文，没做处理”，容易让评委对你的系统安全性印象分大减。所以哪怕实现时用了 MD5，也要说明“自己清楚它不等于真正安全”。

3.2 图书展示、分类和搜索，怎么提升“智慧感”

图书首页通常要包含：顶部推荐位、侧边分类导航、中间新书列表和热门书籍。

新书列表，最简单的做法是：按创建时间倒序，取前 8 条。

热门书籍排序可以用销量字段：按 Sales 倒序，再按评论数或综合评分排序。这些虽然是小逻辑，但让首页不再是一个静态“表格”，而是有算法感。

搜索方面，核心是“关键字匹配”。比较规范的 SQL 写法是：

sql复制SELECT * FROM Books 
WHERE State = 1 
  AND (BookName LIKE '%' + @keyword + '%' 
    OR Author LIKE '%' + @keyword + '%' 
    OR ISBN LIKE '%' + @keyword + '%')

如果是 EF Core，写成：

csharp复制var list = await context.Books
    .Where(b => b.State == 1 &&
        (b.BookName.Contains(keyword) ||
         b.Author.Contains(keyword) ||
         b.ISBN.Contains(keyword)))
    .OrderByDescending(b => b.Sales)
    .ToListAsync();

“智慧阅读”可以体现在哪里？我在设计方案时做了三个很轻量的点：

• 猜你喜欢：当用户查看某本书时，查询同一二级分类下、销量较高、且 BookId 不同的书，取前 4 条展示。
• 浏览记录：用户访问书籍详情页时，向一张 BrowsingHistory 表插入 ViewTime 记录。再次登录后首页可以读取该用户最近浏览过的分类标签，按频次排序后推荐同类书籍。
• 综合排序：在列表页提供“按销量”“按价格”“按上架时间”三个排序维度，比默认只有一列展示效果更好。

这三个功能听起来都不“高大上”，但本质上已经属于基于用户行为的个性化推荐雏形，应付课程设计绰绰有余，而且代码量并不大。

3.3 购物车、下单、扣库存，最考验“事务感”的流程

购物车部分，建议不要直接用前端 localStorage 存储，否则用户换个电脑车就丢了。适合用数据库表 CartItems，并在页面通过 AJAX 调用接口，传入 图书Id、数量、用户Id，实现增删改。

把图书加入购物车时，有一种边界情况很多人没处理：如果这本书已经加过了，正常操作应该把数量加一，而不是重新插入一条重复记录。实现时在接口里先：

csharp复制var cartItem = await context.CartItems
    .FirstOrDefaultAsync(c => c.UserId == userId && c.BookId == bookId);

if (cartItem == null)
{
    // 新增一条
}
else
{
    cartItem.Quantity += 1;
}

订单提交是整个系统真正需要认真设计的地方。用户点击“提交订单”后，至少要做四件事：

• 从购物车或选中项中读取本次下单的图书列表。
• 计算总金额。
• 写入 Orders 表，得到主键 OrderId。
• 循环写入 OrderItems 明细。
• 扣减 Books 表中对应图书的库存。
• 清空购物车中已下单的项。

这五步要保证原子性：如果用户在订单提交过程中直接关页面，结果库存减了但订单没生成，或者订单生成了却库存没扣，后面演示和开发会非常痛苦。

在 .NET Framework 阶段可以用 TransactionScope；在 .NET Core 里，EF Core 里的 context.Database.BeginTransactionAsync() 是更常用做法。页面里，用户点击了“提交订单”按钮之后，跳转到新的订单详情页，并生成一个 OrderNo。产生 OrderNo 的时候我习惯这么做：

csharp复制string orderNo = DateTime.Now.ToString("yyyyMMddHHmmssfff") + 
                 new Random().Next(100, 999).ToString();

现实中订单号会再加用户ID或分布式 ID，不过对于课程设计，这种带时间的随机号可以避免主键冲突，也让页面显示的订单号像那么回事。

支付模块不用对接真实微信/支付宝接口，基本做一个模拟界面：点击“模拟支付成功”，更新订单状态为“已支付”，把已支付时间写入 PayTime，同时给用户一个明显提示。这种模拟方式在论文里也很好写，因为你不会因为需要商户资质导致项目无法演示。

3.4 后台管理模块：图书管理要处理图片上传

后台的核心操作是书籍增删改查。删除时，如果坚持物理删除，会发现历史订单明细或购物车里关联的 BookId 会悬空，推荐系统也会混乱。所以后台的“删除图书”要格外谨慎。我建议：

如果图书的销售量为 0 且没有关联订单，可以物理删除；否则只做“下架处理”，也就是把 Books 表的 State 改为 0。这一条是让项目显得有完整“业务逻辑”的关键。

上传封面时，图片保存到项目的 Uploads/BookCover 文件夹，在数据库里只保存相对路径，比如 /Uploads/BookCover/20250412120110.jpg。不要用二进制形式把整张图片塞进数据库，课程设计看似酷炫，实际会导致数据库体积膨胀，查询加载变慢。文件路径存的磁盘文件，读取更快，展示时直接给 img 标签的 src 使用即可。

在 .NET Core 中，处理上传的典型代码片段是这样的：

csharp复制var uploadsFolder = Path.Combine(env.WebRootPath, "Uploads/BookCover");
var uniqueFileName = DateTime.Now.ToString("yyyyMMddHHmmss") + "_" + file.FileName;
var filePath = Path.Combine(uploadsFolder, uniqueFileName);
using (var fileStream = new FileStream(filePath, FileMode.Create))
{
    await file.CopyToAsync(fileStream);
}
string relativePath = "/Uploads/BookCover/" + uniqueFileName;

还要注意同名文件覆盖问题。用时间戳加上随机数重命名原始文件，能避免中文文件名、空格文件名的干扰，也避免用户上传同一个文件名后把彼此覆盖。

4. 一些容易被忽视、但很容易被拷问的细节实现

书城这种 CRUD 项目想拿高分，光“能跑”不够。很多细节实现是后续代码看得到、答辩时也问得到的地方，我自己在做这类项目时，把以下环节都当成重点内容去准备。

4.1 分页查询：什么时候用内存分页，什么时候用 SQL 分页

图书列表、订单列表、用户管理都涉及大量数据。直接不写分页、一次查询所有记录回传到前台，功能自然能演示，但效率低且看起来不够专业。

正确的做法是数据库层分页，即在 SQL 查询时就完成跳过和取数的动作。假设每页显示 10 条，取第 3 页数据，使用 SQL Server 的 ROW_NUMBER 或 OFFSET-FETCH，例如：

sql复制SELECT * FROM Books
WHERE State = 1
ORDER BY BookId DESC
OFFSET 20 ROWS FETCH NEXT 10 ROWS ONLY;

EF Core 的等效方法是：

csharp复制var pageList = await context.Books
    .Where(b => b.State == 1)
    .OrderByDescending(b => b.BookId)
    .Skip((pageIndex - 1) * pageSize)
    .Take(pageSize)
    .ToListAsync();
int totalCount = await context.Books.CountAsync(b => b.State == 1);

页面底部渲染一个分页组件，这比一次全量加载然后在前端 JS 里分页要正确得多。因为浏览器需要下载所有数据，对用户流量和服务端带宽都是不必要的浪费。做课设时可以很直接地回答这个问题：“我用的是 SQL 分段查询，不是把所有数据拉到内存再切分。”

4.2 图片路径与会话管理，别等部署时才踩坑

图书封面、轮播图、用户头像的路径经常出问题。路径写绝对路径比如 D:\\\\.... 会导致换机器或换目录后直接 404；正确的做法是服务器端生成网站相对路径。在页面中引用时，以 /Uploads/xxx.jpg 开头，让域名部分由浏览器或服务器自动补全。

另外，Session 管理在 ASP.NET Core 里默认不一定配置了。默认项目模板中，如果要用 Session，需要在 Program.cs 中显式调用 builder.Services.AddDistributedMemoryCache() 和 builder.Services.AddSession()，再调用 app.UseSession()。很多同学直接使用 HttpContext.Session.SetString 发现 null，都是因为没配置这些步骤。用户登录后，把 用户ID、用户名、角色 放进 Session，之后所有需要权限判断的地方从 Session 中取，而不是每页重新查数据库。

4.3 用户输入校验和防 SQL 注入

这是答辩高频安全点。在 ADO.NET 时期，没有参数化查询、直接拼接 SQL 字符串是课程设计里最常见的问题。一旦老师输入一个包含单引号的搜索词，系统直接报错，体验很差；更严重的是还可能被绕过认证。

解决方法从根源上也很简单：任何 SQL 语句都用参数化查询，不要拼接：

csharp复制using (SqlCommand cmd = new SqlCommand(
    "SELECT * FROM Users WHERE Username=@u AND Password=@p", conn))
{
    cmd.Parameters.AddWithValue("@u", username);
    cmd.Parameters.AddWithValue("@p", encryptedPassword);
}

EF Core 里使用 LINQ 的时候，字符串值会被默认转成 SQL 参数，已经能挡住大多数情况。但是搜索条件如果用了 FromSqlRaw，要额外小心。页面端还可以做一个简单的双保险：对长度做限制，并对书名、评论等输入字段的字符串长度做范围校验。

同样需要把关的是“权限管理”。后台管理得写一个公共方法或过滤器，确保所有后台请求都先判断是否为管理员，再提供功能。不要只靠菜单隐藏，否则别人直接访问 /Admin/Book/Add 地址也能进入，就是很大的安全漏洞。

5. 我踩过的坑与答辩前最值得准备的几个问题

开发类课设的一大共同点是：时间安排永远不合理，总在交付前一周才集中写代码。这导致很多错误是临阵阶段集中爆发的。我把踩过的典型问题整理出来，希望对你有直接帮助。

5.1 常见问题排查速查表

课程设计期间的问题通常不会是“算法难”，更多的是环境、版本、配置和数据库层面的问题，排查方法相对固定，下面这张表可以帮你快速定位。

5.2 答辩环节，老师最爱追着问以下几个点

课程设计的答辩时间通常只有十分钟左右，但提问往往能直击要害。提前准备好这些高频问题，比临场自由发挥要稳。

• 为什么选这个课题？技术选型是怎么决定的？
  可以按“项目本身是一个典型的管理系统，功能复杂度适中；.Net 技术栈在 Windows 环境里配置方便；同时 MVC 分层结构清晰，方便维护”来讲。

• 数据库表之间有什么关系？
  不用背出全部字段，只需用自己的话说：用户和订单是一对多关系，订单和订单明细是一对多关系，图书和分类是多对一关系，图书与订单明细是多对一但订单明细里会做价格快照。

• 购物车存内存还是数据库？为什么？
  说明存数据库，可以跨设备保存，能持久化；如果在内存 Session 中存放，浏览器关闭或服务器不稳会丢失。

• 订单模块并发时怎么处理？
  往“乐观”的思路讲比较容易：在数据库增加一个库存校验条件，执行 Update Books set Stock=Stock-1 where BookId=@id and Stock>=@quantity；如果受影响行数为 0，说明库存不足，订单回滚。

• 这个项目有什么亮点？
  不要泛泛说“我用了 MVC”。最推荐的回答方式是：“系统除了基础购物功能外，实现了用户浏览记录分析和基于分类的推荐展示；在事务上，下单扣库存用事务保证一致性；在权限上，管理员功能和用户功能通过 Session 角色区分并做了过滤器校验。”

把这三个小点说出来，答辩老师通常会认为你确实动手做的，不是只会拿代码跑一遍。

5.3 从“能跑”到“真属于自己”：代码本地化改造的三个方向

很多同学是参考开源源码做的，这不是问题。怕的是原样照抄，然后被反复追问细节。推荐的改造方向有三个：

第一，把静态数据换成自己的初始化 SQL。把书籍名称改成自己熟悉的教材或喜欢的图书，封面换过，肉眼可见是你自己调过的。

第二，给页面加上不同样式。通过 Bootstrap 改一个配色、调整首页卡片信息块、在导航栏加一个“阅读排行榜”。这些小改不破坏核心代码，还能让项目外观不同。

第三，新增一个小的特色功能。比如我建议加“历史浏览记录”或“图书评分”，它们不改变主流程，但增加“智慧阅读”的贴合度，也给自己增加一两个能讲的新模块。新增功能时，把 Controller、View、数据库表都补齐，流程会与你做整个项目时的开发流程完全一致。

课程设计源码本身只是起点，关键在于你要能在笔记本上和答辩现场把它讲成一条完整逻辑链：用户从首页看到一本书，进入详情，加入购物车，提交订单，模拟支付，管理员后台能查到订单并修改状态。把这条链路亲自走通并解释清楚，你已经不是在交一份代码，而是在交一个完整项目了。

6. 最后想说的几句实在话

这个系统值不值得选、能不能做好，很大程度取决于你对业务闭环的把握，而不是你会不会用高深的框架。在我做完这个项目之后，最大的收获不是“会写分页查询”，而是真正理解了：一个系统的核心并不在某个炫技组件，而在于把用户、订单、库存、权限这些业务模型串成一套完整规则。

如果你现在还在犹豫是改造现有源码还是从零写，我个人的建议是：如果你的时间只剩两三天，就基于现成源码改，优先改数据库初始数据和页面样式，再把重要流程全部调试到可演示；如果你还有两周以上，可以尽量从零搭一个 MVC 项目，然后把核心模块一个个加上去，这个过程的成长价值远超过最后提交的那份代码。

前期在数据库设计上多花一小时，后面可以少熬夜三天。先做表结构设计，再写业务代码，最后补页面和文档，这个顺序真的建议遵守。另外，多花点时间把系统的启动说明和数据库初始脚本写好，不仅方便老师运行查看，也会在很多关键时刻救自己一命。