简介：这是一份面向Web开发初学者与课程实践者的ASP.NET电子商务网站示例项目，适合课程设计、期末作业参考或框架入门练手。项目围绕商品展示、用户注册登录、购物车与订单处理等典型电商流程展开，涵盖母版页布局、身份验证与角色授权、ADO.NET数据访问、Session状态管理等常见技术点，可帮助读者理解中小型电商站点的基本架构与代码组织方式。压缩包共59个文件，约400KB，以12个cs后台代码、7个aspx页面、4个ascx用户控件和4个mdb数据库为主，另有css样式表、gif与jpg图片素材以及站点地图、Web.config等配置文件，分层结构与静态资源较为清晰。已有143人浏览学习。对需要动手搭建第一个动态网站的读者，这份源码可作为可运行骨架，便于对照页面、控件与数据表理解前后端协作，也便于在此基础上改造样式、扩展功能。

1. 拿到一份 ASP.NET 电子商务网站源码：先判断它能不能直接跑起来

压缩包解开的第一个小时，最容易误判的地方是把「首页能打开」当成「项目能跑」。有位读者发来一份 ASP.NET 电子商务网站源码，说前台商品列表和详情页都正常，一点「去结算」就返回 500。翻到 Web.config，连接字符串还写着作者本机的数据库实例名，支付配置节点整段是空的——它不是坏了，是还没接上你的环境。

这类包的真实性质是一套可二次开发的电商站点骨架：前台商品浏览、会员登录注册、购物车、下单、后台商品与订单管理，业务闭环基本完整；缺的是环境适配和你自己的业务规则。适合手里有 Windows 服务器、想快速搭一个可运营商城后台的开发者，也适合拿它当分层架构的阅读样本；不适合指望解压即用、零配置上线的人。

2. 环境与数据库落地：把源码从压缩包跑成能下单的站点

2.1 三个版本号先对齐，再谈编译

ASP.NET 站点跑不起来，八成不是代码问题，是版本号错位。要对的就三个：Web.config 里compilation节点的targetFramework、服务器上实际安装的 .NET Framework 版本、IIS 应用程序池的 CLR 版本。前者大于后者，站点一启动就报「配置错误」，页面连黄页都出不来。

判断项目类型也有讲究，别急着改代码：

看清类型再决定怎么调，WebForms 的坑多在 ViewState 和控件事件顺序，MVC 的坑多在路由和模型绑定。应用程序池统一按「.NET CLR 版本 v4.0 + 集成模式」建，除非源码里引用了老式 32 位组件（比如某些老版本导出库），那才需要在池的高级设置里把「启用 32 位应用程序」打开。改完池设置记得回收，否则改动不生效——这一步很多人漏掉，然后对着同一个错误反复重启站点。

部署前先把目录权限过一遍：站点根目录给IIS_IUSRS读权限，uploads、log、cache这类运行期写入的目录给「修改」权限。少了这一步，后台传图必定 500，而且错误日志里写的是「未将对象引用设置到对象的实例」，误导性极强。

2.2 还原数据库与改写连接字符串

先还原备份，别用「附加 mdf」那种土办法，日志文件路径容易对不上：

-- 还原前先看一眼备份文件里的逻辑文件名，MOVE 要跟它一字不差 RESTORE FILELISTONLY FROM DISK = 'D:\bak\shopdb.bak'; RESTORE DATABASE ShopDb FROM DISK = 'D:\bak\shopdb.bak' WITH MOVE 'ShopDb' TO 'D:\data\ShopDb.mdf', MOVE 'ShopDb_log' TO 'D:\data\ShopDb_log.ldf', REPLACE, STATS = 10;

RESTORE FILELISTONLY这一步别省。备份来自别人的机器时，逻辑文件名可能叫ShopDb_OLD或带实例前缀，直接写ShopDb会报「无法覆盖文件」。REPLACE是允许覆盖同名库，测试环境用得上，生产环境慎用。

连接字符串改三处：服务器地址、库名、账号。别图省事用sa，给站点单独建一个只有db_datareader、db_datawriter加存储过程执行权限的账号，出事时影响面小得多。

<connectionStrings> <!-- Max Pool Size 默认 100，中小站点够用；Connect Timeout 别设太小，首屏冷启动会误判 --> <add name="ShopConn" connectionString="Data Source=10.0.0.12;Initial Catalog=ShopDb;User ID=shop_user;Password=***;Max Pool Size=200;Connect Timeout=15;" providerName="System.Data.SqlClient" /> </connectionStrings>

连接池参数是最常被忽略的一行。默认 100 个连接，遇到商品列表页一次查十几张表的写法，几十个并发就能把池子抽干，表现是页面卡住十几秒然后抛「超时时间已到」。把Max Pool Size提到 200 只能缓解，真正的解法是把循环里查库的代码改成批量查询——这个后面在排查章节还会遇到。

2.3 首次启动必须改的四处配置

数据库通了之后，先别急着点结算。站点的绝对路径、上传目录、回调地址、错误页这四项不改，前台看着正常，后台一操作就露馅。

<appSettings> <!-- 站点根地址：支付回调和邮件里的链接全靠它拼，写成 localhost 上线就废 --> <add key="SiteUrl" value="http://shop.example.local" /> <!-- 上传目录：相对路径在 IIS 虚拟目录下会解析错，建议写物理路径 --> <add key="UploadPath" value="D:\sites\shop\uploads" /> <add key="UploadAllowExt" value=".jpg,.jpeg,.png,.gif,.webp" /> <!-- 单笔订单最大金额，防止测试数据把报表搞乱 --> <add key="OrderMaxAmount" value="50000" /> </appSettings> <system.web> <!-- 上线前必改：debug 关掉，错误页给用户看统一的，详细堆栈只落日志 --> <compilation debug="false" targetFramework="4.7.2" /> <customErrors mode="RemoteOnly" defaultRedirect="/error.html" /> <httpRuntime targetFramework="4.7.2" maxRequestLength="20480" executionTimeout="120" /> </system.web>

maxRequestLength单位是 KB，20480 就是 20MB，后台上传大图超了会直接断连，浏览器只给你一个「连接被重置」，不看配置根本猜不到。executionTimeout是单个请求的执行上限，导出订单报表这类操作容易撞上，按业务调。

提示：customErrors设成RemoteOnly，本机调试还能看到黄页，远程访问只看到友好页；设成On会把本地调试也挡住，白折腾半小时。

3. 拆项目结构：分层目录里哪些文件决定业务走向

3.1 四层调用链：一次商品列表请求走过哪些文件

典型分层是Web/BLL/DAL/Model四个项目，解决方案里还有一层Common放工具类。别急着通读，按请求链路走一遍最快：

ProductList.aspx页面加载 →ProductBll.GetPagedList(categoryId, page, size)→ProductDal.GetPagedList(...)拼 SQL → 返回List<ProductInfo>→ 页面绑定 Repeater。

跟着这条链路，你只需要看四个文件就能判断代码质量。看到 DAL 里用字符串拼接 SQL、参数直接从Request.QueryString传进去，那这份包的安全基线就得自己补——SQL 注入在电商站是致命的，商品搜索框就是最典型的入口。

Model 层一般是纯属性类，没什么可看的，但要注意字段命名和数据库列的映射方式。有的包用SqlDataReader手工赋值，有的用反射自动映射；前者快但改字段要动两处，后者省事但字段改名后是运行时才报错。我自己接手陌生包时，会先在 Model 里挑一个字段，全局搜索它在哪几个文件出现，一分钟就能判断映射方式。

Common 层反而是重点，日志、缓存、加密、分页、图片处理都在这。加密相关的工具类要重点看：如果密码是 MD5 直接存，这份包必须先改密码策略再上线，加盐 + 慢哈希是底线。

3.2 商品、购物车、订单三张表的字段约定

表结构决定了业务能走多远。核心三张表的关系是：商品表存 SKU 和库存，购物车表（或会话）存临时选择，订单主表 + 明细表存成交快照。快照这点特别关键——订单明细里的商品名和单价必须是下单那一刻的值，不能关联商品表实时取，否则商品改价后历史订单全变。

Status字段用整型枚举比字符串好，0 待支付 / 1 已支付 / 2 已发货 / 3 已完成 / 4 已取消，迁移和索引都省事。见过用中文存的，改状态时全靠字符串匹配，错一个字就卡单。

3.3 后台入口与权限校验的位置

后台一般在/admin/目录下。有些包只在每个页面的Page_Load里写一句if (Session["admin"] == null) Response.Redirect(...)，这种写法漏一个页面就是一个洞。合格的做法是抽一个AdminBasePage继承System.Web.UI.Page，在OnInit里统一校验，所有后台页面继承它。

public class AdminBasePage : System.Web.UI.Page { protected override void OnInit(EventArgs e) { base.OnInit(e); var admin = Session["admin"] as AdminInfo; if (admin == null) { // 带上原始地址，登录后跳回来，后台操作体验会好很多 Response.Redirect("/admin/login.aspx?back=" + Server.UrlEncode(Request.RawUrl)); return; } CurrentAdmin = admin; } protected AdminInfo CurrentAdmin { get; private set; } }

除了页面级校验，/admin/web.config里再加一层授权兜底，双保险：

<configuration> <system.web> <authorization> <deny users="?" /> </authorization> </system.web> </configuration>

?表示匿名用户。这层是 IIS 级别的，即使某个页面忘了继承基类，未登录也进不去。接手陌生包时，我会先翻/admin/下有没有这个文件，没有就自己加一个，成本一分钟。

4. 核心链路动手改：购物车、订单号与库存扣减

4.1 购物车存 Session 还是 Cookie：判断标准与写法

源码里两种写法都常见。判断标准很简单：数据量大、要求实时准确、含价格计算 → Session；只要记录商品 Id 和数量、希望未登录也能留存 → Cookie。多数电商包采用的是「未登录用 Cookie 存 Id 列表，登录后合并进数据库购物车」的混合方案。

Session 版的写法要防一个坑：Session 里存的是引用类型，取出后直接改属性会污染会话数据，页面上表现为「数量莫名其妙翻倍」。

// 购物车操作：先取出副本，改完再放回去，避免直接修改 Session 里的对象引用 public static void Update(int productId, int qty) { var cart = HttpContext.Current.Session["cart"] as List<CartItem> ?? new List<CartItem>(); var item = cart.FirstOrDefault(x => x.ProductId == productId); if (item == null) { cart.Add(new CartItem { ProductId = productId, Qty = qty }); } else { item.Qty = qty; // qty <= 0 时建议整项移除，而不是留个 0 } HttpContext.Current.Session["cart"] = cart; // 显式回写，StateServer 模式下必须 }

在 InProc 会话模式下，Session["cart"] = cart可有可无，因为拿到的就是同一个对象；一旦切到 StateServer 或 SQLServer 模式，对象是序列化传输的，不回写就等于没改。这类「本地好好的、部署后购物车不更新」的问题，血泪经验全是这么来的。

Cookie 版则要注意大小上限，浏览器一般 4KB，存几十个商品 Id 就满了。存之前把 Id 压成id:qty|id:qty的字符串，别塞 JSON 全字段。

4.2 订单号生成：时间戳方案在并发下怎么补

yyyyMMddHHmmss + 随机数是最常见的订单号方案，问题是秒级并发时随机数撞车概率不低，撞了就报唯一索引冲突，用户看到下单失败。

// 订单号：14 位时间 + 4 位用户尾号 + 4 位随机；落库必须配唯一索引兜底 public static string BuildOrderNo(int userId) { var seed = userId % 10000; // 用 Guid 的哈希做种子，避免同一秒内多个线程 new Random() 拿到相同序列 var rnd = new Random(Guid.NewGuid().GetHashCode()).Next(1000, 9999); return DateTime.Now.ToString("yyyyMMddHHmmss") + seed.ToString("D4") + rnd; }

两个细节：new Random()不带种子时，同一毫秒内创建多个实例会得到相同序列，这是老问题；订单号里带用户尾号，排查问题时能直接从单号定位到下单人。真要高并发，用「日期 + 当日自增序列」更稳，序列由数据库的SEQUENCE或一张计数表生成，代价是多一次写。

唯一索引不能省。代码层的判重有竞态窗口，数据库的唯一约束是最后一道闸，插入失败就重试一次，比出重复单强得多。

4.3 库存扣减的事务边界与防超卖

超卖的根因永远是「先查后改」：SELECT Stock得到 10，程序判断够，再UPDATE Stock = 10 - 1，两个请求同时进来就都成功了。正确做法是把判断塞进WHERE：

-- 扣库存：判断与更新合成一条语句，靠受影响行数判断是否成功 UPDATE T_Product SET Stock = Stock - @Qty, UpdateTime = GETDATE() WHERE Id = @ProductId AND Stock >= @Qty; SELECT @@ROWCOUNT AS Affected; -- 0 表示库存不足，直接回滚

配套的事务边界要卡准：扣库存、写订单主表、写订单明细、清购物车，这四步一个事务；发短信、发邮件、调支付网关这类外部调用一律放在事务提交之后，否则外部接口超时会把数据库连接一起拖死。

using (var conn = new SqlConnection(connStr)) { conn.Open(); using (var tx = conn.BeginTransaction()) { try { // 1. 扣库存，受影响行数为 0 立即抛异常回滚，绝不能继续往下写 // 2. 写订单主表 + 明细（明细里的商品名、单价来自下单时的快照） // 3. 清空该用户的购物车 tx.Commit(); } catch { tx.Rollback(); throw; } } } // 事务外：发通知、调支付、写日志

隔离级别用默认的ReadCommitted就够，别随手上Serializable，锁范围一大，商品列表页先卡死。真遇到热点商品抢购，加一层应用级排队或 Redis 预扣更实际，但那已经超出这份源码的范畴了。

5. 避坑与排查：上线前必过的五个坎

5.1 后台上传图片报 500，日志里却是空引用

现象：后台上传商品图，浏览器返回 500，站点日志只有一行「未将对象引用设置到对象的实例」，看不出所以然。

原因：uploads目录没给IIS_IUSRS写权限，File.SaveAs抛UnauthorizedAccessException，被上层 catch 后包装成了空引用。有的包 catch 块里只写Response.Write("上传失败")，堆栈全丢了。

解决：给上传目录加「修改」权限，同时检查UploadPath配的是物理路径还是相对路径。相对路径在Server.MapPath下能拼对，但只要站点被部署成虚拟目录，拼出来的路径就会多一层或少一层，最后落到一个不存在的目录上，同样是空引用。

5.2 用户登录一会儿就掉线

现象：管理员在后台编辑商品，十分钟没操作，再点保存就跳回登录页。

原因：IIS 应用程序池默认闲置 20 分钟回收，InProc 会话跟着一起没了。开发机上不停有人访问，永远碰不到这个坑。

解决：会话改成StateServer或SQLServer模式，把会话从进程里挪出去；同时把应用程序池的「闲置超时」调到 1740 分钟、「回收」设为固定时间间隔并挑低峰期。

<system.web> <!-- 会话外置，进程回收不再丢登录态；stateConnectionString 指向本机或独立服务 --> <sessionState mode="StateServer" stateConnectionString="tcpip=127.0.0.1:42424" timeout="120" cookieless="false" /> </system.web>

改完记得启动对应的状态服务，否则站点会报「无法连接到状态服务器」——这个报错比掉线更直白，反而好排查。

5.3 支付回调重复触发，同一单发两次货

现象：用户付一次款，后台出现两条发货记录，订单状态被改了两遍。

原因：第三方支付网关在没收到成功响应时会重发通知，间隔从几十秒到十几分钟不等。源码里的回调页面只判断了「签名正确」，没判断「这单是不是已经处理过」。

解决：回调处理做成幂等。用交易流水号建唯一索引，或者先UPDATE T_Order SET Status = 1 WHERE OrderNo = @no AND Status = 0，受影响行数为 0 就直接返回成功响应、不再处理后续逻辑。状态机只能单向流转，已支付的单不许再回到待支付。

5.4 伪静态规则一加，后台样式全丢

现象：为了 SEO 加了 URL 重写，商品详情页能访问了，但后台页面样式全乱、图片 404。

原因：重写规则写成了.*全匹配，静态资源请求也被改写到了.aspx处理器上，CSS 和 JS 返回的是 HTML 内容，浏览器按 MIME 拒绝执行。

解决：规则里加condition排除真实存在的文件和目录，只对不以扩展名结尾的路径做重写。

<system.webServer> <rewrite> <rules> <rule name="product-detail" stopProcessing="true"> <match url="^product/([0-9]+)\.html$" /> <!-- 只处理数字 Id，避免把 /admin/ 和静态目录一起卷进来 --> <action type="Rewrite" url="/ProductDetail.aspx?id={R:1}" /> </rule> </rules> </rewrite> </system.webServer>

规则写死具体模式，比一条大而全的正则安全得多。改完用失败的请求跟踪看一遍实际重写链路，比猜快。

5.5 首页打开越来越慢，最后直接超时

现象：上午还正常，下午开始首页转圈十秒以上，最后报「超时时间已到，超时时间已到在从池中获取连接之前」。

原因：某个页面在循环里查库，每个商品查一次分类名，一页 40 个商品就是 40 次连接。并发一上来连接池被占满，后续请求全在排队。

解决：先看数据库侧的当前连接数，确认是池子耗尽而不是慢查询。然后把循环内查询改成一次IN查询或JOIN，把结果在内存里做字典匹配。连接字符串里的Max Pool Size是缓解手段，不是解法——池子调大只是把崩溃时间往后推。

// 反例：循环里查库，40 次往返 foreach (var p in list) { p.CategoryName = dal.GetCategoryName(p.CategoryId); } // 正例：一次查出所有分类，内存里匹配 var ids = list.Select(p => p.CategoryId).Distinct().ToArray(); var map = dal.GetCategoryNames(ids).ToDictionary(x => x.Id, x => x.Name); foreach (var p in list) { p.CategoryName = map.TryGetValue(p.CategoryId, out var n) ? n : ""; }

6. 上线前的完整走查：用一份并发脚本验证不超卖

功能点一个个点过去，永远发现不了并发问题。我的习惯是在交付前跑一遍固定走查，再用脚本压一轮下单接口。

走查表按业务闭环排，每项都要有明确的通过标准：

并发验证重点看库存，脚本要绕过会话锁这个障碍：

import concurrent.futures, requests URL = "http://127.0.0.1/api/order/create" # 关键：每个线程用不同账号的 Cookie。同一 SessionId 会被 ASP.NET 会话锁串行化， # 用一个会话压出来的「不超卖」是假的，压力根本没到数据库 COOKIES = ["ASP.NET_SessionId=aaa...", "ASP.NET_SessionId=bbb...", "ASP.NET_SessionId=ccc..."] def buy(i): headers = {"Cookie": COOKIES[i % len(COOKIES)]} r = requests.post(URL, json={"productId": 1001, "qty": 1}, headers=headers, timeout=15) return r.status_code, r.text[:60] with concurrent.futures.ThreadPoolExecutor(max_workers=30) as pool: results = list(pool.map(buy, range(120))) ok = sum(1 for s, _ in results if s == 200) print("成功下单:", ok, "初始库存应为:", 120 - ok)

库存设 100，发 120 个请求，成功的必须正好 100，剩下 20 个返回库存不足。如果成功数超过 100，回到 4.3 检查WHERE Stock >= @Qty是不是被改成了先查后改；如果成功数远小于 100，多半是唯一索引冲突后没重试，或者事务范围把外部调用也圈了进去导致锁等待超时。

这个脚本我第一次写的时候踩了个大坑：图省事全用同一个会话，压出来一个失败都没有，还以为代码写得真好。后来换成多账号才发现库存扣成了负数——@Qty参数在拼接 SQL 时被当成了字符串，Stock >= '1'恒真，判断形同虚设。从那以后我每次改完订单相关代码，都会强制走一遍「多会话 + 边界库存」的压测，不看结果不提交。希望帮到你。

本文还有配套的精品资源，点击获取