简介：网络商品销售管理系统是一套面向电子商务学习与课程设计场景的ASP.NET源码示例，围绕商品维护、分类管理、库存与订单处理等常见业务展开，适合计算机专业学生、初级开发者及需要了解三层架构的读者参考。压缩包共55个文件，约88KB，包含13个cs源码文件、15个dll程序集、3个aspx页面、3个csproj项目文件、1个sln解决方案及1个sql脚本，另有pdb调试符号、config配置与txt说明等，能较完整呈现Web层、业务逻辑层和数据访问层的工程组织。已有156人学习，说明其对入门与参考资料有一定适用性。读者可从中了解Product、Categry等实体及管理类的分层写法，参考Default、AddDefault等页面与数据库脚本的配合方式，并借助解决方案结构梳理商品查询、录入、图片展示等模块的实现思路，为课程设计、源码阅读或小型电商功能二次开发提供可复用的结构参考。

1. 先把“商品维护”跑通：这套网络商品销售管理系统适合谁

很多人拿到网络商品销售管理系统源码，第一反应是找下单按钮，结果真正拖慢交付的往往是商品维护：商品编号重复、价格改完历史订单跟着变、下架商品还能被加入购物车。这套资源的核心价值不在页面多花哨，而在把商品资料、分类、库存、上下架状态和销售订单串成一条能自洽的链路。它适合做课程设计、毕业设计原型，也适合中小商家后台二次开发；新手能照着建表和接口顺序跑通闭环，熟手更该关注库存扣减、价格快照和软删除这些边界。下面按“拆表—接单—部署—排错—对账”的顺序拆，能直接复现。

2. 拆开资源看骨架：商品、库存、订单三张表怎么落

商品维护看起来只是增删改查，真正决定系统能不能用的，是表结构有没有给销售链路留位置。常见做法是把商品主表、分类表、库存流水、订单主表、订单明细分开，而不是把所有字段塞进一张商品表。这样做的原因很直接：商品价格会变，订单价格不能跟着变；库存会动，必须留下可追溯的流水；分类会删，商品不能变成孤儿数据。下面先反推数据模型，再给一份能直接执行的 SQL 骨架，最后落到商品维护的四个动作。

2.1 从商品维护反推数据模型：主表、分类表、库存流水

商品维护的第一层不是“商品名称、价格、库存”三个字段，而是“商品身份”和“商品状态”。商品身份通常由商品编号product_no承担，它要唯一、可检索、不随价格变化；商品状态用status表示草稿、上架、下架、删除。库存不要只放一个stock字段，至少要有stock和locked_stock，前者是可售库存，后者是下单未支付时锁定的数量。常见做法是下单时先锁库存，支付成功后扣减可售库存并释放锁定，取消订单则反向释放。这样比“下单直接减库存”多一张流水表，但后面排查超卖会轻松很多。

分类表要支持父子层级，至少保留parent_id、sort_no、status。商品表用category_id关联分类，但不要加级联删除。分类删除时先检查该分类下是否有未删除商品，有就拒绝；没有商品但有子分类，也拒绝。这个校验放在服务层还是数据库外键都行，关键是不要图省事直接DELETE。商品主表还要保留version字段做乐观锁，编辑商品时带上版本号，避免两个人同时改价格把后一次覆盖前一次。金额统一用decimal(10,2)，不要用浮点；库存用整数，并在应用层做非负校验。

库存流水表不是装饰。每次入库、销售出库、退货入库、手工调整都写一条，字段包括商品 ID、变更类型、变更数量、变更前库存、变更后库存、业务单号、操作人、创建时间。商品维护页面上的“调整库存”必须写流水，否则月底对账就是黑匣子。订单明细表要存商品名称、销售单价、成本价快照，不要只存product_id。原因很简单：商品改名、改价、下架之后，历史订单还要能还原当时的交易内容。

2.2 建库建表：一份能直接执行的 SQL 骨架

下面这份 SQL 是通用关系库写法，字段名可以按实际源码包调整，但约束和索引建议保留。执行顺序按“分类—商品—库存流水—订单—订单明细”来，避免外键依赖报错。如果实际资源包用的是别的数据库，把自增主键和日期类型换成对应写法即可，业务字段不要省。

-- 商品分类：支持父子层级，status=1 启用，0 停用 CREATE TABLE product_category ( id BIGINT PRIMARY KEY AUTO_INCREMENT, parent_id BIGINT NOT NULL DEFAULT 0, category_name VARCHAR(64) NOT NULL, sort_no INT NOT NULL DEFAULT 0, status TINYINT NOT NULL DEFAULT 1, created_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, updated_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, KEY idx_parent (parent_id) ); -- 商品主表：product_no 唯一，status=0 草稿 1 上架 2 下架 3 删除 CREATE TABLE product ( id BIGINT PRIMARY KEY AUTO_INCREMENT, category_id BIGINT NOT NULL, product_no VARCHAR(32) NOT NULL, product_name VARCHAR(128) NOT NULL, sale_price DECIMAL(10,2) NOT NULL DEFAULT 0.00, market_price DECIMAL(10,2) NOT NULL DEFAULT 0.00, cost_price DECIMAL(10,2) NOT NULL DEFAULT 0.00, stock INT NOT NULL DEFAULT 0, locked_stock INT NOT NULL DEFAULT 0, status TINYINT NOT NULL DEFAULT 0, version INT NOT NULL DEFAULT 0, created_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, updated_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, UNIQUE KEY uk_product_no (product_no), KEY idx_category_status (category_id, status) ); -- 库存流水：每次库存变化都留痕，biz_no 记录订单号或调整单号 CREATE TABLE inventory_log ( id BIGINT PRIMARY KEY AUTO_INCREMENT, product_id BIGINT NOT NULL, change_type VARCHAR(16) NOT NULL, -- INIT/SALE/RETURN/ADJUST change_qty INT NOT NULL, before_stock INT NOT NULL, after_stock INT NOT NULL, biz_no VARCHAR(64) NOT NULL DEFAULT '', operator_id BIGINT NOT NULL DEFAULT 0, created_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, KEY idx_product_time (product_id, created_at), KEY idx_biz_no (biz_no) ); -- 订单主表：状态 0 待支付 1 已支付 2 已取消 3 已完成 4 已退款 CREATE TABLE sales_order ( id BIGINT PRIMARY KEY AUTO_INCREMENT, order_no VARCHAR(40) NOT NULL, buyer_id BIGINT NOT NULL, total_amount DECIMAL(10,2) NOT NULL DEFAULT 0.00, pay_amount DECIMAL(10,2) NOT NULL DEFAULT 0.00, status TINYINT NOT NULL DEFAULT 0, created_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, paid_at DATETIME NULL, UNIQUE KEY uk_order_no (order_no), KEY idx_buyer_time (buyer_id, created_at) ); -- 订单明细：只存快照，不依赖商品表当前值 CREATE TABLE sales_order_item ( id BIGINT PRIMARY KEY AUTO_INCREMENT, order_id BIGINT NOT NULL, product_id BIGINT NOT NULL, product_no VARCHAR(32) NOT NULL, product_name VARCHAR(128) NOT NULL, sale_price DECIMAL(10,2) NOT NULL, cost_price DECIMAL(10,2) NOT NULL DEFAULT 0.00, buy_qty INT NOT NULL, KEY idx_order_id (order_id), KEY idx_product_id (product_id) );

这段 SQL 的关键不是字段多，而是三个约束：uk_product_no防重复编号，idx_category_status让后台列表按分类和状态筛选时不至于全表扫，sales_order_item里的sale_price、cost_price和product_name做快照。inventory_log.change_qty用正负号表示方向，比如销售出库写-2，退货入库写2，对账时直接按商品聚合。product.version给编辑操作做乐观锁。status=3表示软删除，真实删除只在对账确认无订单引用后手工处理，不要在后台页面直接物理删除。

2.3 商品维护的四个核心动作：新增、编辑、上下架、软删除

商品维护页面通常有四个动作，每个动作对应不同的校验。新增商品时先校验product_no唯一、分类存在且启用、销售价不低于 0、库存不小于 0；如果资源包要求上架才能卖，新增默认状态应为草稿或下架，不要一保存就上架。编辑商品时把version带上，SQL 更新条件加version = ?，影响行数为 0 就提示“数据已被其他人修改，请刷新后重试”。这不是玄学，是多人后台最常见的并发问题。

上下架动作只改状态，但要加前置校验：上架前检查库存是否大于 0、价格是否已设置、分类是否启用；下架前检查是否有未支付订单锁定了该商品，有就提示先处理订单。软删除把status改为 3，同时把商品从推荐位、购物车缓存里清掉。下面是一段更新示例，重点看条件。

-- 编辑商品：version 参与条件，防止覆盖他人修改 UPDATE product SET product_name = ?, sale_price = ?, category_id = ?, version = version + 1, updated_at = CURRENT_TIMESTAMP WHERE id = ? AND version = ? AND status <> 3; -- 上架：库存和价格必须合法 UPDATE product SET status = 1, updated_at = CURRENT_TIMESTAMP WHERE id = ? AND status = 2 AND stock > 0 AND sale_price > 0; -- 软删除：保留行，后续订单仍能关联到商品 ID UPDATE product SET status = 3, updated_at = CURRENT_TIMESTAMP WHERE id = ? AND status <> 1;

更新语句执行后要检查影响行数。编辑影响 0 行，优先怀疑版本号过期或商品已被删除；上架影响 0 行，查库存、价格、当前状态；软删除影响 0 行，查商品是否仍在上架。后台列表查询默认过滤status <> 3，但订单明细回显时不能过滤，否则历史订单会显示“商品不存在”。商品维护的“删除”按钮做成二次确认不够，还要在服务层拦截上架商品直接删除。血泪经验是：后台页面做得再漂亮，删除不校验订单引用，后面订单详情一定翻车。

3. 把商品维护接到销售链路：订单扣库存与价格快照

商品维护不是孤立模块，它最终要服务销售。很多课程设计把商品表和订单表直接关联，下单时读商品现价，支付时再读一次库存，结果测试没问题，一并发就超卖，一改价历史订单金额就变。正确做法是下单时写订单明细快照、用条件更新扣库存、把库存流水和订单放在同一个事务里。下面按价格快照、下单事务、销售统计三个点拆。

3.1 为什么下单不能直接读商品现价

订单详情页展示的是“成交价”，不是“商品当前价”。商品维护里改一次促销价，历史订单如果还关联商品表读sale_price，金额就会跟着变，财务对账直接对不上。常见做法是在sales_order_item里存sale_price、cost_price、product_name、product_no，下单那一刻把商品信息复制进去。之后商品改名、改价、下架、软删除，订单明细都不受影响。这个设计会增加一点存储，但省掉的是无穷无尽的解释成本。

库存也是同理。商品主表上的stock是当前可售库存，不是历史库存。要回答“这个商品昨天卖了多少、退了多少、还剩多少”，只能查inventory_log和订单明细。商品维护页面上的库存调整必须写流水，调整原因填清楚，比如“盘点修正”“采购入库”。如果源码包里库存调整只改product.stock不写流水，建议先补这张表，不然后面做销售统计只能靠猜。

价格快照还要注意优惠分摊。如果订单有优惠券、满减、运费，sales_order_item.sale_price存原成交单价，订单主表存total_amount和pay_amount，优惠明细单独存。不要在商品维护里改价格去“修正”历史订单，历史订单只能走退款或冲正。这个边界守住了，商品维护和销售统计才不会互相打架。

3.2 下单事务：锁库存、写快照、落订单

下单事务的常见顺序是：校验商品状态和库存、写订单主表、写订单明细快照、条件更新扣库存、写库存流水、提交事务。任何一步失败都回滚。库存扣减不要先查再减，要用UPDATE ... WHERE stock >= ?的条件更新，影响行数为 0 就说明库存不足。下面是一段 Java JDBC 示例，重点看事务边界和条件更新。实际资源包可能用别的 ORM，思路一样。

public void createOrder(long buyerId, long productId, int buyQty) throws Exception { if (buyQty <= 0) throw new IllegalArgumentException("购买数量必须大于0"); Connection conn = dataSource.getConnection(); try { conn.setAutoCommit(false); // 1. 锁定商品行，校验状态；实际项目按 productId 排序加锁，降低死锁概率 Product p = queryForUpdate(conn, productId); if (p == null || p.status != 1) throw new RuntimeException("商品未上架"); if (p.stock < buyQty) throw new RuntimeException("库存不足"); // 2. 写订单主表和明细快照 long orderId = insertOrder(conn, buyerId, p.salePrice.multiply(new BigDecimal(buyQty))); insertOrderItem(conn, orderId, p, buyQty); // 3. 条件更新扣库存，防止并发下扣成负数 int affected = updateStock(conn, productId, buyQty); if (affected == 0) throw new RuntimeException("库存扣减失败，可能已被抢完"); // 4. 写库存流水，biz_no 用订单号关联 insertInventoryLog(conn, productId, "SALE", -buyQty, p.stock, p.stock - buyQty, "ORDER-" + orderId); conn.commit(); } catch (Exception e) { conn.rollback(); throw e; } finally { conn.setAutoCommit(true); conn.close(); } }

这段代码里，queryForUpdate对应SELECT ... FOR UPDATE，用来锁住商品行；updateStock对应UPDATE product SET stock = stock - ? WHERE id = ? AND stock >= ? AND status = 1。参数buyQty是购买数量，必须大于 0；biz_no用于把库存流水和订单关联起来。事务里不要做远程调用、发短信、写日志文件这类耗时操作，否则锁持有时间变长，并发一高就排队。支付回调里再做“已支付”状态流转和锁定库存释放，不要在下单事务里把支付也塞进去。

3.3 销售统计与商品维护的联动

销售统计要围绕订单明细做，不要围绕商品表做。按商品统计销量时，过滤订单状态为已支付、已完成，排除已取消和已退款；按分类统计时，订单明细关联商品分类，但分类可能被改名，所以统计口径要写清楚是“按当前分类”还是“按下单时分类”。常见做法是订单明细里再存一个category_id快照，避免分类调整后历史报表漂移。如果资源包没这个字段，至少要在报表页标注“按当前商品分类归集”。

商品维护页面的“销量”字段不要直接冗余在商品表里手工改。销量应该由订单明细聚合出来，或者用定时任务汇总到统计表。库存和销量分开看：库存是可售数量，销量是成交数量，退货要冲减销量。下面这条统计 SQL 可以作为后台仪表盘的基础。

-- 按商品统计有效销售额和销量，排除取消、退款订单 SELECT i.product_id, i.product_no, i.product_name, SUM(i.buy_qty) AS sale_qty, SUM(i.sale_price * i.buy_qty) AS sale_amount, SUM((i.sale_price - i.cost_price) * i.buy_qty) AS gross_profit FROM sales_order_item i JOIN sales_order o ON o.id = i.order_id WHERE o.status IN (1, 3) GROUP BY i.product_id, i.product_no, i.product_name ORDER BY sale_amount DESC;

status IN (1,3)表示已支付和已完成，实际项目按订单状态字典调整；gross_profit用销售价减成本价，成本价来自订单明细快照。这个查询在订单量不大时够用，数据量上来后要加日期范围和索引。商品维护改动价格后，不要期望历史统计跟着变，统计看的是订单快照。把这条边界写进后台说明，后面少很多争论。

4. 部署与联调：从空库到能登录后台的最小闭环

拿到源码包后不要先点启动，先确认三件事：数据库脚本是否完整、配置文件里的连接参数是否对、后台管理员是否初始化。很多启动失败不是代码问题，是空库缺表、缺管理员、端口冲突。下面按环境假设、初始化数据、接口联调顺序走一遍。实际资源包的技术栈可能不同，命令按项目说明替换，但检查顺序可以照搬。

4.1 运行环境与目录假设

这类系统常见做法是 Java Web 加关系型数据库，源码目录通常分后端代码、前端静态资源、数据库脚本。我一般先找sql或db目录，确认有没有初始化脚本；再找配置文件里的数据库连接、端口、文件上传路径；最后看登录账号是脚本初始化还是首次启动生成。环境上先用项目说明要求的版本，没有说明就用稳定组合验证，不要一上来堆最新版本。数据库字符集统一utf8mb4，金额字段用decimal，时间字段统一时区。

上表不是让你逐行背，而是启动前过一遍。建库脚本执行时注意外键顺序，先分类后商品；如果脚本里有DROP TABLE，生产库不要直接跑。配置文件里的数据库密码不要提交到公开仓库，课程设计也一样，养成用环境变量或本地配置覆盖的习惯。

4.2 初始化管理员与基础字典

后台登录要有管理员表，密码不要明文。常见做法是存 BCrypt 哈希，首次登录强制改密。初始化 SQL 里可以插入账号，但密码哈希由后端工具生成后替换，不要抄网上固定哈希。下面给的是占位写法，password_hash必须替换成实际生成的哈希值。

-- 管理员初始化示例：password_hash 需由后端密码工具生成后替换 INSERT INTO sys_admin (username, password_hash, real_name, status, created_at) VALUES ('admin', 'REPLACE_WITH_BCRYPT_HASH', '系统管理员', 1, CURRENT_TIMESTAMP); -- 基础字典：商品状态、订单状态，后台下拉框从这里取 INSERT INTO sys_dict (dict_type, dict_code, dict_label, sort_no, status) VALUES ('product_status', '0', '草稿', 1, 1), ('product_status', '1', '上架', 2, 1), ('product_status', '2', '下架', 3, 1), ('product_status', '3', '删除', 4, 1), ('order_status', '0', '待支付', 1, 1), ('order_status', '1', '已支付', 2, 1), ('order_status', '2', '已取消', 3, 1), ('order_status', '3', '已完成', 4, 1), ('order_status', '4', '已退款', 5, 1);

username唯一索引要加，status=1表示启用。字典表的作用是避免后台写死中文，后面加“待发货”“已发货”不用改代码。初始化分类时至少建一个“默认分类”，否则新增商品没有分类可选。分类状态停用后，商品维护页面不应再允许选择该分类，但历史商品仍可展示分类名称。

4.3 接口联调顺序：商品列表→编辑→上下架→下单

联调不要从首页开始，从商品维护接口开始。顺序是：登录拿会话或令牌、查商品列表、新增商品、编辑商品、上下架、下单、查订单。每一步用固定参数，方便回放。下面用 curl 示例，路径和字段按实际项目调整，重点是观察返回码和数据库变化。

# 1. 查询商品列表，确认分页和状态过滤 curl -s "http://127.0.0.1:8080/api/admin/product?page=1&size=10&status=1" \ -H "Authorization: Bearer <token>" # 2. 新增商品，productNo 必须唯一 curl -s -X POST "http://127.0.0.1:8080/api/admin/product" \ -H "Content-Type: application/json" \ -H "Authorization: Bearer <token>" \ -d '{"categoryId":1,"productNo":"P1001","productName":"测试商品","salePrice":99.00,"costPrice":60.00,"stock":20,"status":2}' # 3. 编辑商品，带上 version 防覆盖 curl -s -X PUT "http://127.0.0.1:8080/api/admin/product/1" \ -H "Content-Type: application/json" \ -H "Authorization: Bearer <token>" \ -d '{"productName":"测试商品改","salePrice":88.00,"categoryId":1,"version":0}' # 4. 上架，再下单，观察库存和订单明细 curl -s -X PATCH "http://127.0.0.1:8080/api/admin/product/1/status" \ -H "Content-Type: application/json" \ -H "Authorization: Bearer <token>" \ -d '{"status":1}' curl -s -X POST "http://127.0.0.1:8080/api/order" \ -H "Content-Type: application/json" \ -H "Authorization: Bearer <token>" \ -d '{"productId":1,"buyQty":2}'

Authorization换成实际登录返回的令牌或会话；status按字典值传；编辑接口的version必须用查询结果里的当前版本。每调一次就查一次数据库：新增后查product，编辑后看version是否加 1，上架后看status，下单后看sales_order_item快照和inventory_log。如果返回成功但数据库没变，先查事务是否提交、ORM 是否开了批量延迟、接口是否走了缓存。联调顺序固定下来，后面换人接手也能复现。

5. 避坑与排查：商品维护最容易翻车的 5 个点

商品维护的坑大多不在页面上，而在数据边界。下面 5 条按“现象—原因—解决”写，都是这类系统里高频出现的。看的时候对照自己的库，别等演示当天才发现。

5.1 价格改了历史订单跟着变

现象：后台把商品销售价从 99 改成 88，之前订单详情里的单价也变成 88，财务金额对不上。原因：订单明细只存了product_id，详情页实时关联商品表读sale_price。解决：订单明细落价格快照，详情页只读快照；历史数据用订单创建时间回填，回填前先备份。商品维护页面的改价只影响新订单，这个规则要写进操作提示。

5.2 并发下单把库存扣成负数

现象：库存 1 件，两个请求同时下单都成功，库存变成 -1。原因：先查库存再更新，两个请求都查到 1，都执行了扣减。解决：用UPDATE product SET stock = stock - ? WHERE id = ? AND stock >= ?条件更新，影响行数为 0 就回滚；下单事务里锁商品行，库存流水同事务写入。测试时用两个并发请求打同一商品，别只点一次按钮。

5.3 商品上下架与购物车缓存不一致

现象：商品已下架，购物车还能结算；或者刚上架，前台搜不到。原因：商品状态改了数据库，但缓存、搜索索引、购物车校验没同步。解决：上下架接口更新数据库后主动删缓存或发状态变更消息；结算时二次校验商品状态和库存，不能只信购物车里的快照。课程设计没有消息队列，至少在结算接口实时查一次商品状态。

5.4 分类删除导致商品变孤儿

现象：删除分类后，商品列表按分类筛选查不到商品，编辑商品报分类不存在。原因：分类物理删除，商品表还留着category_id。解决：分类删除前检查商品和子分类，有引用就拒绝；商品表不要级联删除；确实要停用就改status。已有孤儿数据先归到“未分类”，再修分类关系。

5.5 后台权限没拦住直接调接口

现象：普通运营账号能调管理员接口改价格、删商品。原因：只在页面隐藏按钮，后端接口没做角色校验。解决：商品新增、编辑、删除、上下架按角色授权，接口层统一拦截；删除和改价留操作日志，记录操作人、前后值、时间。权限校验不要写在每个方法里复制粘贴，用统一拦截器或注解。

6. 最后一个可落地技巧：用对账 SQL 验证商品维护是否真的闭环

功能能点通不等于数据闭环。我习惯在演示前跑三条对账 SQL：库存是否出现负数、订单销售额和明细是否一致、是否存在孤儿商品。第一条查product.stock < 0或locked_stock < 0，有就说明扣减逻辑或并发控制有问题。第二条按订单汇总明细金额，和订单主表total_amount对比，差异不为 0 就查快照和优惠分摊。第三条查商品分类是否存在，LEFT JOIN后分类为空的就是孤儿数据。

-- 1. 负库存检查：正常应返回 0 行 SELECT id, product_no, product_name, stock, locked_stock FROM product WHERE stock < 0 OR locked_stock < 0; -- 2. 订单金额对账：主表金额与明细汇总不一致的订单 SELECT o.id, o.order_no, o.total_amount, SUM(i.sale_price * i.buy_qty) AS item_amount FROM sales_order o JOIN sales_order_item i ON i.order_id = o.id GROUP BY o.id, o.order_no, o.total_amount HAVING ABS(o.total_amount - SUM(i.sale_price * i.buy_qty)) > 0.01; -- 3. 孤儿商品检查：分类不存在或已删除的商品 SELECT p.id, p.product_no, p.product_name, p.category_id FROM product p LEFT JOIN product_category c ON c.id = p.category_id WHERE c.id IS NULL AND p.status <> 3;

跑完这三条，再把商品维护的四个动作走一遍：新增一个测试商品、改价、上架、下单、退款、下架、软删除，观察库存流水和订单快照是否对得上。对账 SQL 不追求复杂，追求每次改完都能重复跑。从那以后我每次拿到这类网络销售管理系统，都先跑一遍对账再谈页面演示；没有对账的库存就是黑匣子，早晚要交后悔药。希望帮到你。

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