企业官网建设流程全解析

简介：面向五金行业的B2B电子商务系统源码，基于.NET技术开发，适合.NET开发者或希望在垂直行业搭建在线交易平台的技术人员参考。资源以rar压缩包提供，大小约2.68MB，目前已有268人学习。系统覆盖B2B交易核心链路：用户注册登录与角色权限管理、商家商品发布与分类、购物车及订单流程、库存实时更新、支付接口对接、物流查询、客服售后、销售报表与SEO优化等，并支持多语言界面。开发者可通过阅读源码，快速理解B2B电商平台在.NET体系下的架构分层、数据库设计及后台管理逻辑，同时参考完整的权限控制与接口对接实现；也可针对五金行业特有的商品规格、询报价等需求进行二次开发，直接用于搭建或改造成自有平台，能有效节省前期研发成本，加速企业数字化进程。

1. 五金在线B2B网站源码_dotnet电子商务系统源代码.rar：这套老代码为什么还能打

拿到“五金在线B2B网站源码_dotnet电子商务系统源代码.rar”这个压缩包的人，多半是两种情况：要么是刚接手一家五金贸易公司的信息化改造，要么是想在垂直行业电商里快速起个盘。先说结论——这类基于 dotnet 的电子商务系统源码，虽然界面和架构停留在十年前，但五金 B2B 的核心交易逻辑从来没有变过：阶梯价、客户等级、账期、询价转订单。把这些业务规则吃透，比追逐一套微服务架构有用得多。dotnet（.NET Framework 或 .NET Core）栈在私有化交付、内网部署、对接用友和金蝶这类老财务系统时，依然是成本最低的选择。这篇文章会从业务模型拆起，给你一条从解压源码到二次开发、再到上线避坑的完整路径。

2. 先看懂业务再碰代码：五金B2B和普通商城的四点本质区别

很多开发者拿到源码第一反应是打开 Visual Studio 按 F5，结果跑起来发现满屏的“订单审批”“客户等级价”“开票信息”不知道往哪填。这不是代码坏了，是业务模型没对齐。五金 B2B 和面向 C 端的电商商城，看起来都是“商品-购物车-订单”，实际底层逻辑完全不同。

2.1 交易链路不一样：B2B 是询价、议价、审批、账期、开票五件事

C 端商城是“看价-下单-支付-发货”，价格公开、支付即时、不需要开票流程。五金 B2B 的真实链路通常是这样：采购方先向销售询价，销售在后台维护一个针对该客户的专属价格，客户确认后转为正式订单，金额大的还需要内部审批，付款方式可能是“月结 30 天”而不是在线支付，最后还要按订单开增值税发票。这套链路里，价格不是商品属性，而是客户与商品之间的关系。这也是为什么这类源码里一定会有 customer_price、price_level、price_policy 这类表——没有它们，B2B 根本跑不起来。

我一般拿到源码后会先去数据库关系图里找三张表：客户表、商品表、价格表。如果价格表里没有客户等级字段和有效期字段，那这个系统的 B2B 属性就要打个问号。做二次开发时，优先把“客户-商品-价格”这条链路理顺，其他都是后续问题。

2.2 商品模型不一样：五金货品的规格、材质、单位换算是三座山

五金件不像图书或数码产品，一个 ISBN 或一个型号就能锁定商品。一颗螺丝可能有材质（304/316/碳钢）、表面处理（镀锌/发黑/达克罗）、规格（M6×20 vs M8×30）、强度等级（4.8/8.8/10.9）多个维度。同一个商品编码下挂着十几个规格，每个规格的库存和价格可能完全不同。更麻烦的是单位换算——按“千件”采购还是按“盒”采购，计价单位不同，库存单位可能又是“公斤”。

这类 dotnet 电子商务系统源码最常见的商品表设计是：product 主表 + product_sku 子表，SKU 通过一串规格属性组合键来区分。差的实现是把所有规格塞进一个文本字段，查询靠 LIKE，跑起来慢不说，库存和价格根本对不齐。拿到源码先看商品表有没有独立的 SKU 表，没有的话，二次开发第一件事就是把它拆出来。

2.3 订单状态机更复杂：不是“已支付”就结束了

C 端订单的状态机一般是待付款→已付款→已发货→已签收。B2B 订单要高出一个量级：待审核→审核通过→已确认→已排产→部分发货→已完成→已对账→已开票。而且这些状态之间不是简单的线性流动，订单可能被拆分多次发货，部分退货要单独挂账，对账和开票更是独立于订单存在的环节。

这也是老源码值得参考的地方——它的表设计里会有 order_status_log 这类操作日志表，记录每一次状态变更的操作用户、变更时间和备注。很多新团队做 B2B 系统，把状态设计成订单表里的一个枚举字段，改状态直接 UPDATE，上线三个月后想追责“谁把价格改低了”根本无据可查。源码里带这种日志表的，说明原作者踩过坑。

2.4 dotnet 技术栈在 B2B 场景的选型理由：稳定压过一切

做五金 B2B 特别是传统行业数字化转型，IT 团队往往只有两三个人，老板要的是“别再出幺蛾子”。.NET Framework + SQL Server + IIS 的组合虽然被很多互联网团队诟病“老旧”，但它有实打实的优势：Windows 服务器和 SQL Server 在传统企业里几乎是标配，招聘维护成本低；Visual Studio 的调试体验对中小团队非常友好；大量现成的报表控件和第三方组件；SQL Server 的维护工具链成熟，DBA 好招。这些对于一年几十万订单量的垂直 B2B 来说完全够用。

相比之下，Java 系的微服务体系需要引入注册中心、配置中心、网关，运维复杂度指数级上升。做传统行业项目，技术债务往往不是来自代码质量，而是来自过度设计。dotnet 这套栈在“能跑、好维护、出问题有人会修”这个维度上，依然是最稳的选择之一。

3. 把源码包跑起来：从解压到IIS发布的最小步骤

这一步的目标只有一个：让网站在本地或一台 Windows 服务器上跑出登录页。不要想着第一次就理解全部代码，先把环境凑齐，能登录后台，再逐步对业务。

3.1 先看目录再动手：源码包常见结构与落盘规范

解压 rar 之后，先别急着双击 .sln。我一般会先在资源管理器里看顶层目录结构，判断这是 WebApplication 还是 Website 项目，区别很大：WebApplication 项目有 .csproj 文件，编译成 DLL 发布；Website 项目没有 .csproj，源码 .cs 文件直接放在 App_Code 目录下，运行时由 IIS 动态编译。两种方式部署策略完全不同，搞错了连编译都过不了。

/Web -> 网站根目录，放 aspx、ascx、web.config /Web/App_Code -> Website 模式下的 C# 源码（如果有） /Web/bin -> 编译后的 DLL（WebApplication 模式） /Database -> SQL 脚本或 MDF 备份文件 /Document -> 部署说明、接口文档

典型 dotnet 电商源码解压后的目录结构

先确认三件事：数据库脚本在不在 Database 目录；web.config 里的连接字符串指向哪台服务器；有没有 PDF 或 txt 版部署文档。这三样缺一样，后面的坑会成倍增加。没有文档的源码包，只能靠读 web.config 反推数据库地址，再不行就全局搜“server=”或“Data Source”。

3.2 数据库初始化：附加 MDF 与执行 SQL 脚本两条路径

大多数这类源码会附带 .bak 备份文件或 .sql 脚本。.bak 文件用 SQL Server Management Studio 还原就行，唯一要注意的是还原后的数据库文件路径。.sql 脚本则要在 SSMS 里对目标数据库逐段执行。我遇到过脚本里包含 GO 批处理语句，在 .NET 的 SqlCommand 里直接执行会报语法错误，只能在 SSMS 里跑。

-- 方法一：还原 bak 备份 RESTORE DATABASE [HardwareB2B] FROM DISK = N'D:\Backup\HardwareB2B.bak' WITH MOVE 'HardwareB2B_Data' TO N'D:\Data\HardwareB2B.mdf', MOVE 'HardwareB2B_Log' TO N'D:\Data\HardwareB2B.ldf', REPLACE, STATS = 10;

-- 方法二：直接执行脚本后，检查关键表是否创建成功 USE HardwareB2B; SELECT name FROM sys.tables WHERE name IN ('product','product_sku','customer','order_main','price_level') ORDER BY name;

还原数据库后先确认核心表存在，再进入下一步

执行完脚本，如果缺表，说明脚本不完整。此时翻 Database 目录找是否有单独的增量脚本。老源码经常拆成 base.sql 和 update1.sql、update2.sql 这种命名方式，漏跑一个后面程序就会报“列名无效”。

3.3 修改 web.config：连接字符串、验证模式、调试开关三个必改项

web.config 是整个网站的命门。打开后先定位<connectionStrings>，把 Data Source、Initial Catalog、User ID、Password 改成你本机的 SQL Server 实例。这里最容易翻车的是“Data Source=.”或者“Data Source=(local)”这类简写，在装了多个 SQL Server 实例的机器上经常解析不对。改用Data Source=localhost\SQLEXPRESS;或完整实例名最稳妥。

<configuration> <connectionStrings> <add name="B2BConnectionString" connectionString="Data Source=localhost\SQLEXPRESS;Initial Catalog=HardwareB2B;Persist Security Info=True;User ID=sa;Password=YourStrongPassword;MultipleActiveResultSets=True" providerName="System.Data.SqlClient" /> </connectionStrings> <appSettings> <!-- 伪静态开关，很多老站靠 URLRewriter 组件，关掉才能访问原始 aspx 页面 --> <add key="EnableUrlRewrite" value="false" /> </appSettings> <system.web> <!-- 关闭调试模式，减少首次访问的编译开销和错误信息暴露 --> <compilation debug="false" targetFramework="4.0" /> <!-- 表单验证超时时间，B2B 客户经常挂着页面聊天，超时太短会被踢出 --> <authentication mode="Forms"> <forms loginUrl="~/login.aspx" timeout="120" slidingExpiration="true" /> </authentication> </system.web> </configuration>

web.config 最小改动：连接串、伪静态开关、验证超时

MultipleActiveResultSets=True这个参数建议保留。老代码里经常出现一个 SqlConnection 上同时开着多个 DataReader 的情况，不加这个会报“已有打开的 DataReader 与此连接关联”，第一次跑就遇到会让人误以为代码有 bug。slidingExpiration="true"也很重要，采购员填半天下单信息才提交，Forms 票证过期直接给你跳回登录页，填的东西全丢。

3.4 发布到IIS：应用程序池、权限与默认文档

如果是 WebApplication 型源码，用 Visual Studio 的“发布”功能生成文件，再把输出拷到 IIS 站点目录。如果是 Website 型源码，直接把源码整个目录拷过去。然后按下面顺序配置 IIS：

# 以管理员身份运行 PowerShell，创建应用程序池和站点 Import-Module WebAdministration # 创建 .NET v4.0 经典模式应用程序池 New-Item IIS:\AppPools\HardwareB2BAppPool Set-ItemProperty IIS:\AppPools\HardwareB2BAppPool managedRuntimeVersion "v4.0" Set-ItemProperty IIS:\AppPools\HardwareB2BAppPool managedPipelineMode "Classic" # 创建站点并绑定到 8088 端口，避免与默认 80 冲突 New-Item IIS:\Sites\HardwareB2B -physicalPath D:\wwwroot\hardwareb2b -bindings @{protocol="http";bindingInformation="*:8088:"}

PowerShell 一键创建应用池与站点，注意经典模式是此类老代码的默认兼容项

应用程序池的托管管道模式第一选择是“经典模式”。老代码里的 URLRewriter、HttpModule 大多基于经典模式编写，切到集成模式会冒出一堆 500 错误。当然新版 IIS 默认是集成模式，创建完应用池记得手动切换。

接下来是权限。在 IIS 管理器里右键站点，编辑“编辑权限”，给 IIS_IUSRS 用户分配“完全控制”权限，否则网站运行时没有权限写日志、上传附件。这个权限问题比代码本身更常见，尤其遇到“上传图片成功但目录里没文件”这种怪问题时，十有八九是目录权限丢了。最后设置默认文档，把 index.aspx 或 default.aspx 加进列表，再浏览站点。看到登录页面，这就算跑通了。

4. 二次开发核心逻辑：把通用电商改成能落地的五金B2B

跑通只是开始。让客户愿意把生意放上来，必须把“通用电商”改成“能谈生意的 B2B”。下面是三个最常见的改造点，每个都给出代码层级的落地思路。

4.1 价格体系改造：客户等级、阶梯价与生效时间

五金 B2B 的价格是谈出来的，不是定出来的。同一个客户买不同规格的螺丝，谈下来的价格可能完全不同；同一个商品卖给 A 公司和 B 公司，价格也可能差 15%。这类源码里常见有两种价格：客户等级价和下单数量阶梯价。等级价解决“因人而异”，阶梯价解决“量大多优惠”。

改造思路：在商品 SKU 表之外，新建三张表——customer_price（针对客户的价格）、level_price（按客户等级统一定价）、tier_price（按量阶梯价）。取价顺序是：有客户专享价就用客户专享价；没有，再看客户等级价；等级价也没有，回到销售基准价。整个逻辑封装在一个 PricingService 里。

/// <summary>根据客户、商品、数量计算最终单价</summary> public decimal ResolvePrice(int customerId, int skuId, int quantity, DateTime now) { // 1. 客户专享价优先，条件：未过期、商品匹配 var custom = _db.CustomerPrices .FirstOrDefault(p => p.CustomerId == customerId && p.SkuId == skuId && p.ValidFrom <= now && p.ValidTo >= now); if (custom != null) return custom.Price; // 2. 客户等级价其次，条件是客户所在的等级组 var levelId = _db.Customers.Find(customerId).LevelId; var levelPrice = _db.LevelPrices .FirstOrDefault(p => p.LevelId == levelId && p.SkuId == skuId); if (levelPrice != null) return levelPrice.Price; // 3. 兜底用基准价，这里体现“阶梯”：数量越大折扣越高 var basePrice = _db.Skus.Find(skuId).BasePrice; var tier = _db.TierPrices .Where(t => t.SkuId == skuId && t.MinQty <= quantity) .OrderByDescending(t => t.MinQty) .FirstOrDefault(); return tier != null ? basePrice * tier.DiscountRate : basePrice; }

取价顺序：客户专享价 → 等级价 → 基准价 × 阶梯折扣

参数上要注意三个点。一是ValidFrom/ValidTo用 datetime 类型，很多五金行业的价格有效期精确到小时级别，业务上有“月初调价”惯例；二是阶梯价的 MinQty 建议用 int 而不是 decimal，五金件按千件采购很常见，用 decimal 会给自己找麻烦；三是整个方法要加缓存但必须在后台改价时主动清缓存，否则客户看到的价格永远是旧价。缓存键建议包含 customerId 和 skuId 两个维度，清缓存时按客户维度批量删除。

4.2 订单流程重排：询价转订单、审批流与订单日志

B2B 订单不是“点了就成功”。典型流程是：客户在前台提交询价单，销售在后台把询价单转成正式订单并填入最终折扣，订单超过一定金额要触发上级审批，审批通过后仓库才能看到订单开始拣货。这套逻辑源码里未必完整，但订单状态日志表通常已经存在，改造时把它利用起来。

public void ConvertInquiryToOrder(int inquiryId, int operatorId, decimal finalDiscount) { var inquiry = _db.Inquiries.Find(inquiryId); using (var tx = _db.Database.BeginTransaction()) { // 1. 创建主订单，状态设置为“待审批” var order = new OrderMain { CustomerId = inquiry.CustomerId, OrderNo = GenerateOrderNo("PO"), // 业务编号规则：PO + 年月日 + 序列 TotalAmount = inquiry.TotalAmount * finalDiscount, Status = OrderStatus.PendingApproval, CreatedBy = operatorId, CreatedAt = DateTime.Now }; _db.Orders.Add(order); _db.SaveChanges(); // 2. 明细行复制过来，保留原始报价供审批人对照 foreach (var line in inquiry.Lines) { _db.OrderLines.Add(new OrderLine { OrderId = order.Id, SkuId = line.SkuId, Quantity = line.Quantity, OriginalPrice = line.OfferPrice, FinalPrice = line.OfferPrice * finalDiscount }); } // 3. 写操作日志，后面追责全靠这张表 _db.OrderStatusLogs.Add(new OrderStatusLog { OrderId = order.Id, FromStatus = null, ToStatus = OrderStatus.PendingApproval, OperatorId = operatorId, Remark = $"询价单 {inquiry.InquiryNo} 转订单，折扣 {finalDiscount:P0}" }); // 4. 业务上要求：询价单和订单必须同时改状态，缺一不可 inquiry.Status = InquiryStatus.Converted; _db.SaveChanges(); tx.Commit(); } }

询价转订单必须放在一个事务里，防止出现“订单建了询价单还是待处理”的中间状态

这段代码体现的核心理念是：状态变更不靠直接改字段，要靠“日志表 + 事务”。日志表的价值平时看不出来，一旦客户打电话来质疑“这个订单是谁改的价格”，查一下 OrderStatusLogs 就清楚了。很多新写的系统根本没有这个概念，出了事只能看数据库的 modified_time，根本没法定位操作人。

审批流的实现也建议用状态驱动而不是硬编码：订单状态为 PendingApproval 时，只有具备审批权限的角色能调用 Approve 方法；审批通过后状态变成 PendingDispatch；超过设定金额阈值的订单，自动加一条“需总经理审批”的日志。不要在这类老系统里堆 Workflow 引擎，一张状态机表 + 角色权限就够用。

4.3 商品SKU动态化：让“规格”不再死板

五金商品规格维度多、变化快，今天客户要 M6×20 镀锌，明天要 M8×30 发黑，硬编码规格列根本不是办法。做动态 SKU，核心是把规格做成键值对。

老系统的做法是在商品表里放一个 spec_text 字段，例如“材质=304,表面=镀锌,长度=20mm”，前端解析字符串拼规格名。这套做法的问题很直接：无法做库存维度查询。客户问“304 材质的有多少库存”，SQL 只能 LIKE，查询一大性能就恶化，而且写错一个标点就查不出数据。正确做法是把规格拆到独立表和 SKU 记录一一对应。

-- SKU 主表，每个 SKU 是商品的一个具体规格组合 CREATE TABLE product_sku ( sku_id INT PRIMARY KEY IDENTITY(1,1), product_id INT NOT NULL, -- 关联商品主表 sku_code VARCHAR(50) NOT NULL, -- 对外编码，例如 FX-304-DX-M6X20 sale_price DECIMAL(18,2) NOT NULL, stock_qty INT NOT NULL DEFAULT 0, status TINYINT NOT NULL DEFAULT 1, -- 1 上架，0 下架 UNIQUE (sku_code) ); -- SKU 规格属性表，采用 EAV 模型尽量扁平 CREATE TABLE product_sku_spec ( spec_id INT PRIMARY KEY IDENTITY(1,1), sku_id INT NOT NULL REFERENCES product_sku(sku_id), spec_name NVARCHAR(50) NOT NULL, -- 规格名：材质/表面/长度 spec_value NVARCHAR(100) NOT NULL, -- 规格值：304/镀锌/20mm UNIQUE (sku_id, spec_name) ); -- 按规格值精确查库存，替代 LIKE 查询 SELECT s.sku_code, s.stock_qty FROM product_sku s JOIN product_sku_spec sp ON sp.sku_id = s.sku_id WHERE sp.spec_name = N'材质' AND sp.spec_value = N'304' AND s.status = 1;

SKU 规格拆成键值对后，才能支持多条件精确筛选库存

这个改造执行时要特别注意：规格名要用 NVARCHAR 而不是 VARCHAR，不然中文“材质”写入会乱码；每个 SKU 的规格属性数量尽量固定在一个范围内（建议 3~6 个），查询时用 GROUP BY + HAVING COUNT 来匹配多条件筛选；老数据迁移时，把原先 spec_text 按分隔符解析出来的逻辑要写好后先跑一遍样本数据对账，不要直接全量执行——常见的情况是旧数据里格式不统一，有的用逗号、有的用顿号。这类数据清洗最耗时间，但值得做。

5. 五金B2B系统从源码到上线的避坑手册：五个常见坎

5.1 页面中文乱码，尤其是后台管理页

现象：登录后后台菜单全是“???”或者“锟斤拷”，但是前台部分页面正常。

原因：老源码的页面文件可能是 GB2312 编码保存的，但 web.config 里声明的响应编码是 UTF-8。浏览器拿到 UTF-8 的响应头，再去按 UTF-8 解释 GB2312 的字节流，自然就乱码了。

解决：用 Notepad++ 打开乱码页面的 .aspx 或 .ascx 文件，把编码从 ANSI 转为 UTF-8 保存。如果是全站性问题，在 web.config 里统一设置<globalization fileEncoding="utf-8" requestEncoding="utf-8" responseEncoding="utf-8" culture="zh-CN" uiCulture="zh-CN" />，同时把代码文件批量转码。批量转换别手动点，用 PowerShell 脚本遍历目录转换，几百个文件几分钟搞定。

5.2 订单金额对不上，差了 0.01 或是几块钱

现象：订单明细加总金额与订单主表金额不一致，对账时经常差几分钱。

原因：float/double 类型做浮点累加丢失精度。老代码里有些金额字段定义成了 float，添加商品后计算order.TotalAmount += item.Price * item.Quantity，浮点数乘加误差逐级放大，最终和数据库里单独计算的值对不上。

解决：数据库层面把所有金额字段统一改成DECIMAL(18,2)，代码里面金额变量统一使用decimal类型。decimal在 C# 中是 128 位高精度十进制数，专门用于货币计算。另外把金额计算的逻辑收敛到一个公共方法里，禁止业务代码里到处散写乘法。如果历史订单已经出现金额不一致，写一个 SQL 脚本按订单号汇总明细行，把差额列出来，逐笔修正或手工调账，不要指望自动修复——每笔差额的产生原因可能不同。

5.3 客户登录后看不到专属价格，看到的是基准价

现象：客户 A 登录后台管理自己的价格，价格没变；刷新浏览器又对了；过一会儿又不对。

原因：价格查询被缓存了，缓存键没有包含 customerId。所有客户访问同一个商品时命中的是同一份缓存数据，后登录的客户拿到的是前一个客户看到的价格。

解决：缓存键必须包含 customer_id 和 sku_id。后台“修改客户价格”保存成功后，主动删除该客户的全部价格缓存，而不能等缓存自然过期。常见的做法是维护一个“客户价格版本号”：每个客户有一个 price_version 字段，改价时版本号加一，查询缓存时把版本号拼进缓存键，旧缓存自然失效，不用显式一处处清除。这套做法对老系统侵入最小。

5.4 并发下单把库存卖成负数

现象：两个客户同时下单购买同一 SKU，库存显示还有 10 件，两单各卖 8 件，最终库存变成 -6。

原因：库存扣减用的是“先查库存、再看是否充足、最后 UPDATE”三步，没有加锁。两个请求同时通过第一步，都认为库存足够，然后各自执行扣减。

解决：把扣减语句写成一条原子 SQL。UPDATE product_sku SET stock_qty = stock_qty - @qty WHERE sku_id = @id AND stock_qty >= @qty。受影响行数为 1 表示扣减成功，为 0 表示库存不足。不要再做“SELECT 判断再 UPDATE”的两步操作。事务隔离级别再低，单条 UPDATE 语句的原子性是可以保证的。如果老代码里已经有用 Application Lock 或者表锁解决这个问题的，不要轻易拆掉——运行稳定就先留着。

5.5 经典dotnet项目在WinServer 2022上跑起来报500

现象：部署到 Windows Server 2022 + IIS 10 上，页面全部 500.19 或 500.21，但在本机 Windows 10 上跑得好好的。

原因：老工程的目标框架如果是 .NET Framework 2.0/3.5，而服务器上 IIS 应用池默认运行 .NET CLR v4.0，不兼容。更常见的是 IIS 10 默认不启用旧版 ASP.NET 的某些模块（如 URLRewriter 依赖的 ISAPI 筛选器）。

解决：先在“服务器管理器 - 角色和功能”里确认装了“.NET Framework 3.5 功能”。再检查应用池的“托管管道模式”切到经典模式，.NET CLR 版本选 v2.0（如果目标是 3.5）。如果代码用了 URLRewriter 这类组件，确认它在 IIS 中注册了对应的 ISAPI 筛选器或处理程序映射映射，最简单的方式是在 web.config 里写成 HttpModule 而不是依赖 IIS 界面配置。遇到 500.19 先看错误代码前两位，多数是配置语法问题，拿 XML 格式化工具检查 web.config 的闭合标签。

6. 上线前我必做的两个验证动作与一个自检习惯

系统开发完，不要急着让销售开始录客户。我上线前必做两件事：第一，把核心链路用 SQL 脚本做一次数据一致性快照对比——订单金额、库存数量、价格有效期，都通过脚本从数据库侧独立算一遍，和程序里展示的数值对一遍，很多动态计算问题在这个环节现出原形；第二，用两个浏览器同时登录不同客户账号测试价格和订单，专门查缓存串号和并发扣减。

-- 验证各客户的价格是否在有效期内，且不存在两条重叠的专享价 SELECT c.customer_name, s.sku_code, cp.valid_from, cp.valid_to, cp.price FROM customer_price cp JOIN customer c ON c.customer_id = cp.customer_id JOIN product_sku s ON s.sku_id = cp.sku_id WHERE cp.valid_to < GETDATE() OR EXISTS ( SELECT 1 FROM customer_price cp2 WHERE cp2.customer_id = cp.customer_id AND cp2.sku_id = cp.sku_id AND cp2.valid_from < cp.valid_to AND cp.valid_from < cp2.valid_to ) ORDER BY c.customer_name, s.sku_code

上线前检查过期价格与重叠价格区间

这个脚本查出来的数据，每条都要人工确认——过期价意味着客户可能在用旧价下单，重叠价意味着系统取价时可能随机选中一个。B2B 价格体系一旦乱了，客户信任直接崩塌。

我的自检习惯是：每个后端接口和页面查询都保留统一的访问日志，日志里带上 customer_id、sku_id、action、result。上线初期不要省这个功夫，出问题先翻日志而不是先翻代码。这套日志在排查价格不刷新、库存超卖、权限错乱时都帮了大忙，也让我养成了“先看数据再说”的习惯。日志表的写入要放在事务里或者用独立的消息队列，不能因为写日志影响主流程性能。

希望这套思路能帮你少走弯路。老源码不可怕，可怕的是动手前没有把业务链路理清楚。你手头这套 dotnet 电商源码里已经沉淀了很多五金行业的业务细节，把它们挖出来、改对、运行稳定，比推倒重来划算得多。

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