精华版ASP销售管理系统：数据库设计、核心代码与IIS部署实战-编程实验室

简介：一套完整的ASP销售管理系统源代码，面向中小型企业、在线商店及ASP开发初学者，用于实现商品销售、订单处理、库存管理等业务数字化管理。系统覆盖客户管理、商品管理、订单管理、库存管理和报表分析等核心模块，配套Access或SQL Server数据库设计，便于理解表结构和业务逻辑。资源包共230个文件、大小676KB，主要包含167个asp页面作为功能实现主体，另有gif/jpg图片、htm静态页、js脚本、sql数据库脚本及css样式等，涵盖界面展示、前端交互、数据库初始化与后台逻辑等层次，目录结构清晰，适合直接定位与二次开发。目前已有228人学习下载。借助开放源码，可深入研读前台与后台交互流程，在此基础上扩展会员积分、促销活动或安全加固等个性化功能，也适合作为技术培训、毕业设计或企业快速搭建销售管理系统的蓝本参考。

1. 为什么一个十几年前的ASP系统还在被反复翻出来

我最早接触ASP做销售管理系统，是在帮一家小型商贸公司维护老系统的活儿里。那家公司从2010年左右就在用一套用VBScript写的ASP进销存，后来换过几次外包团队，系统缝缝补补一直撑到今天。这两年陆续有不少读者私信问我：手上接到一个ASP销售管理系统的二次开发需求，客户还要求附带完整源代码，这东西还值不值得接？我的回答一般是：值不值得接取决于你怎么用它，但ASP这套老技术栈至今仍有一批存量系统在跑，维护和改造的市场一直没断过。

一个"精华版ASP销售管理系统"，通常意味着它在功能上不追求大而全，而是把销售业务闭环里最核心的几件事做扎实：商品资料管理、客户资料管理、销售开单、库存扣减、销售统计和基础权限控制。相比现在动辄微服务、前后端分离、容器化部署的方案，它只是一组ASP页面配合一个Access数据库，跑在Windows的IIS上，听起来确实"复古"，但对不少中小型批发零售商户来说，这套东西够用、好用、改起来也不费劲。

适合看这篇文章的人，我大致分三类。第一类是刚入行或正在学ASP的开发者，想找一份结构清晰、能跑通的完整源代码当学习标本；第二类是接私活或做外包的技术人员，手里正好有个ASP老系统要维护或二次开发，需要快速搞懂它的代码组织和坑点；第三类是自己开公司、想低成本搭一套内部销售管理工具的老板或IT负责人，想知道这类系统到底能干什么、不能干什么。

我后面所有内容都围绕一份典型的"精华版ASP销售管理系统"展开，从功能拆解、数据库设计、核心页面代码逻辑，到部署配置、常见故障排查，再到源代码的维护与交付注意事项，一次讲透。文章里涉及的代码片段都是这类系统里最常见、最通用的写法，你可以直接对照自己的项目往下看。

2. 先弄清楚这套系统解决了什么业务问题

2.1 中小商户的销售管理痛点

批发零售行业的小商户，日常经营里最头疼的几件事，我列一下你感受感受。商品几百上千种，哪些卖得好、哪些积压得厉害，凭脑子根本记不住；客户拿货可能月结、可能现结，账期和欠款一笔笔记在本子上，一到月底对账就乱套；每天开了多少单、毛利多少，老板问起来，店员半天给不出一个数。这些问题听着不大，但它直接影响现金流和库存周转效率。

精华版ASP销售管理系统解决的就是这一层问题。它把"商品档案—客户档案—销售开单—库存变化—销售统计"串成一条完整的业务链路：开单的时候自动扣库存，保存之后自动生成销售记录，月底查统计报表直接按时间范围汇总数量和金额。数据进出有依据，经营状况一目了然。

2.2 功能清单：精华版到底包含哪些模块

我见过不少叫"精华版"的ASP系统，功能模块大同小异，核心通常是这几块：

系统登录与操作员管理：区分管理员和普通操作员，管理员可以维护操作员账号和权限。
商品管理：商品编号、名称、规格、单位、进货价、销售价、库存数量、预警下限的增删改查。
客户管理：客户编号、名称、联系人、电话、地址、欠款金额等信息的维护。
销售开单：选择客户、选择商品、录入数量，自动带出销售价并计算金额，保存后更新库存。
进货入库：采购入库操作，增加库存数量，同时可以维护进货价格。
销售查询与统计：按时间、商品、客户等维度过滤销售记录，汇总数量、销售额、毛利。
系统设置：经销商/公司名称、电话、地址等基础信息的维护。

有些版本会再做一层库存预警和简单的进销存报表，但"精华版"的定位一般不会塞太多花哨功能。功能少不是缺点，反而是优点——对于学习ASP的人来说，代码量适中、结构清楚，看得懂、跑得动；对使用方来说，业务逻辑直接，不会因为功能复杂导致操作门槛高。

2.3 经典ASP在这里的优势和局限

为什么不用PHP、不用ASP.NET而要选ASP？其实不是"选"，而是历史遗留。这套技术栈诞生的年代，Windows + IIS + Access是小型Web系统很廉价的组合，开发门槛低、部署简单，一个服务器能挂一堆小网站。即使放在今天，一个活动目录、一段VBScript、一个几十MB的Access文件，就能支撑一个小型公司的内部管理系统，维护成本接近零。

但它的局限也很明显。Access数据库在并发访问上很弱，十几二十个操作员同时开单就会偶发锁库；VBScript没有强类型约束，代码一多容易越改越乱；IIS在默认配置下的安全性，也需要专门加固。因此它更适合数据量不大、并发不高、内网使用或少量外网访问的场景。超过这个体量，就建议往SQL Server和ASP.NET平移了。

3. 数据库设计：进销存闭环的核心逻辑

3.1 表结构与字段设计

一份能正常跑起来的ASP销售系统，数据库里通常会建这几张核心表：操作员表（Admin）、商品表（Products）、客户表（Customers）、销售单主表（SaleMain）、销售单明细表（SaleDetail）、进货单主表（PurchaseMain）、进货单明细表（PurchaseDetail）。主表和明细表分开，是这类系统的标准设计，目的就是规范保存"一张单对应多条商品记录"的数据关系。

我在做系统改造时整理过一份标准的字段清单，直接列出来供你参考。商品表至少要有：ProductID、ProductCode（商品编号）、ProductName、Specification（规格）、Unit（单位）、PurchasePrice（进货价）、SalePrice（销售价）、StockQty（库存）、MinStockQty（库存预警下限）。销售单主表要有：SaleID、SaleNo（单号）、CustomerID、SaleDate、TotalAmount、OperatorID。销售明细表要有：DetailID、SaleID、ProductID、Quantity、Price、Amount。客户表里一定要放DebtAmount（欠款）字段，方便统计客户账期。

3.2 Access数据库中表关系的建立

在Access里建立表间关系，一个重要原则是：主表和明细表通过外键关联，不要在明细表里反复存储冗余信息。比如销售单明细表只需要存ProductID、Quantity、Price、Amount，商品名称和规格统一从商品表查询出来。这样改一个商品名称，所有历史单据都会自动跟随变化，不会出现同一商品在不同单据里显示不同名称的脏数据。

对于还不太熟悉关系型数据库的读者，我做一个简化类比：销售单主表相当于一张购物小票的抬头（日期、客户、总金额），明细表相当于小票上细列的商品行（每件商品叫什么、几件、多少钱）。一张主表可以对应多张明细行，它们通过SaleID这一个公共编号串起来。系统统计销售额时，对明细表做SUM汇总；统计客户欠款时，则对主表按客户ID做GROUP BY。

3.3 关键的库存与金额计算逻辑

进销存系统最容易出错的地方，就是库存和金额的更新时机。正确的做法是：销售开单保存时，在主表写入一条记录获得SaleID，然后逐条往明细表写商品数据，同时执行UPDATE Products SET StockQty = StockQty - 数量。进货入库正好相反，是加库存。

金额计算时要注意单位和精度的坑。单价和数量通常用数字类型，金额如果是通过单价乘以数量算出来的，建议直接在代码层算好再写入，不要在SQL中反复ROUND，否则浮点误差会在统计时越积越明显。对账时如果发现汇总金额和单据金额差一两分钱，十有八九是精度处理不一致。

还有一个我特别提醒的口径问题：客户欠款到底要不要随销售单自动累加。如果支持月结和欠款业务，销售单保存成功后，应该同时执行UPDATE Customers SET DebtAmount = DebtAmount + 总金额；收到回款时再手工登记并减少欠款。但要注意，如果一张销售单被删除了，必须同步回滚库存和客户欠款，否则账就平不了。

4. 核心页面的开发思路与代码片段拆解

4.1 为什么代码结构适合用"公共文件 + 业务页面"的方式组织

我建议任何ASP销售系统都从结构上把公共部分抽出来，而不是每个页面都重复写数据库连接和权限判断。精华版系统虽然代码量不大，但遵循这个原则会让后续维护省心非常多。通常我会建一个conn.asp（数据库连接文件）和一个check_login.asp（登录校验文件），在业务页面顶部用引入。

连接Access数据库的标准写法是使用ADODB.Connection，代码大致这样：

<% Dim conn, connStr, dbPath dbPath = Server.MapPath("data/db.mdb") connStr = "Provider=Microsoft.Jet.OLEDB.4.0;Data Source=" & dbPath Set conn = Server.CreateObject("ADODB.Connection") conn.Open connStr %>

数据库文件放在站点根目录里，用相对路径定位，这样整站拷贝到其他服务器时不用改绝对路径。这里有两个细节值得注意：一是数据库文件必须有读写权限，否则页面会报"操作必须使用一个可更新的查询"；二是数据库路径不要放在网站的脚本可访问目录下太长且难猜的路径里，这个后面讲安全的时候再展开。

4.2 登录模块与权限控制

登录页面的逻辑很直接：接收用户输入的操作员名和密码，去Admin表比对，认证成功后把操作员ID和姓名写入Session，并跳转到主页面。很多老系统用明文存密码，这在现在的安全标准下已经不能接受了，我在做改造时会把密码一律改成MD5后再存储。登录代码的骨架大致如下：

<% Dim username, password username = Trim(Request.Form("username")) password = Trim(Request.Form("password")) If username <> "" And password <> "" Then Dim rs, sql sql = "SELECT * FROM Admin WHERE UserName='" & Replace(username, "'", "''") & "' AND PassWord='" & MD5(password) & "'" Set rs = conn.Execute(sql) If Not rs.EOF Then Session("AdminID") = rs("AdminID") Session("AdminName") = rs("AdminName") Response.Redirect "main.asp" Else Response.Write "<script>alert('用户名或密码错误');history.back();</script>" End If rs.Close Set rs = Nothing End If %>

登录之后的每个业务页面，都要在开头做会话校验，防止未登录用户直接通过URL访问页面：

<% If Session("AdminID") = "" Then Response.Redirect "login.asp" End If %>

权限控制如果做得细一点，可以给Admin表加一个Role字段，区分管理员和普通操作员，普通操作员不能访问商品删除、系统设置这类管理页面。对"精华版"系统来说，做到这一层已经够用。

4.3 商品管理页：列表、新增、修改、删除

商品列表页的数据查询很基础，但有一个地方值得单独说：搜索和分页。ASP里没有内置的分页控件，通常用RecordSet的PageSize、AbsolutePage属性来实现。精华版系统通常直接用一个Repeater式的循环，把商品表的数据罗列出来，后面再加"编辑""删除"操作按钮。

新增和修改可以放在同一个product_edit.asp页面里，通过URL参数区分动作。例如product_edit.asp?id=5表示修改ID为5的商品，不带id参数表示新增。保存时判断一下Request.Form("ProductID")是否为空，不为空就走UPDATE，为空就走INSERT。这种"一个页面做两件事"的写法在ASP老系统里非常常见，也方便页面间跳转传参。

商品删除时要特别留意关联数据。如果某个商品已经产生了销售记录，直接删除商品表里的记录会导致明细表的ProductID变成空引用，统计报表和单据查询都会出问题。比较稳妥的做法是：删除前先查一下SaleDetail和PurchaseDetail里有没有该商品的历史记录，有的话就提示"该商品已有业务记录，不能删除"，改为把商品的Status字段置为停用。这个细节我在不少项目里踩过，属于典型的"业务逻辑比技术逻辑重要"的地方。

4.4 销售开单页：主表明细表一次保存

销售开单是整个系统里最核心也最容易写崩的页面。它的处理流程是这样的：

前端通过HTML表格让操作员选择客户、填写多行商品（每行一个商品编号和数量）。
点保存后，表单数据POST到sale_save.asp。
服务器端先插入SaleMain主表，取得新增的SaleID。
循环遍历表单中的商品行，逐行插入SaleDetail明细表，同时更新产品的库存。
最后按客户是否月结决定是否累加欠款。

批量保存的代码没有现成的框架，只靠VBScript的循环写法：

For i = 1 To Request.Form("ProductCode").Count productID = Request.Form("ProductID")(i) quantity = Request.Form("Quantity")(i) If IsNumeric(productID) And IsNumeric(quantity) And quantity > 0 Then sql = "INSERT INTO SaleDetail (SaleID, ProductID, Quantity, Price, Amount) VALUES (" sql = sql & saleID & "," & productID & "," & quantity & "," sql = sql & GetPrice(productID) & "," & (quantity * GetPrice(productID)) & ")" conn.Execute sql conn.Execute "UPDATE Products SET StockQty = StockQty - " & quantity & " WHERE ProductID=" & productID End If Next

在写这段代码时，我特别强调三件事。第一，前端每一行商品都必须在服务端做合法性校验，不能只依赖前端JavaScript，ASP页面直接收到伪造的POST是常见攻击入口。第二，如果某一行的数量不是数字或者是负数，跳过这一行，不要让整个提交因为一行垃圾数据而中断。第三，主表和明细表的写入要尽量放在同一个逻辑事务里，Access虽然事务能力弱，但还是支持BeginTrans/CommitTrans的，能加就加，避免主表成功了明细表却失败了一半。

4.5 统计报表：从销售额汇总到毛利分析

统计页面是老板最关心的地方。常见的有按日/按月销售汇总、按商品销售排行、按客户销售汇总。SQL写法通常是这样：

SELECT DATEVALUE(SaleDate) AS SaleDay, SUM(TotalAmount) AS DayTotal FROM SaleMain WHERE SaleDate BETWEEN #2024-01-01# AND #2024-01-31# GROUP BY DATEVALUE(SaleDate) ORDER BY SaleDay

Access的日期参数必须用#括起来，这是它和SQL Server语法上的区别，很多从其他数据库转过来的开发者在第一次用Access时在这里栽过跟头。统计销售额已经很简单，但要做到毛利分析的话，需要把商品当前PurchasePrice和销售单detail里Price做差，再乘以数量。注意这个毛利是静态的，如果某商品进货价历史上有过多次变动，用当前进货价算出来的毛利会和历史真实毛利有偏差，精华版系统一般不做追溯处理，这个在交付说明里跟客户讲清楚即可。

所有统计页面的数据输出后，都要考虑怎么导出。对于这种轻量系统，最实用的方案是生成CSV文件让用户下载，因为CSV不需要额外装任何组件，Excel可以直接打开。导出到Excel的COM组件方式在IIS环境里容易因为权限问题报错，我不太推荐。

5. 部署与运行环境：那些年我们踩过的IIS和Access的坑

5.1 Windows 10/11上跑ASP老项目的环境配置

ASP系统在Windows 10或Windows 11上运行，第一关是IIS功能没装全。很多人直接把项目扔进IIS后访问，页面变成纯文本或者直接报404，原因多半是"ASP"这一项就没启用。正确步骤是：控制面板—程序和功能—启用或关闭Windows功能，勾选"Internet Information Services"—"万维网服务"—"应用程序开发功能"里的ASP，再勾选"ISAPI扩展"。装完之后，打开IIS管理器，在站点对应的处理程序映射里确认ASP的路径是C:\Windows\System32\inetsrv\asp.dll。

目录权限是第二个高频坑。Access数据库文件所在的目录需要给IIS应用程序池身份（通常是IUSR或IIS_IUSRS）读写权限，否则系统登录没问题，但一到插入数据就报错。右键数据库目录—安全—编辑—添加IIS_IUSRS用户，勾选完全控制，这一步做完，绝大多数"无法更新数据库"的问题都解决了。

第三个容易忽略的是64位和32位的问题。IIS应用程序池默认启用32位应用程序为False，但Access的OLEDB驱动在老系统里经常是32位的，此时连接数据库会报"未找到提供程序"。在应用程序池的高级设置里把"启用32位应用程序"改成True，重试一下，往往就好了。

5.2 页面样式不生效：win10下ASP老系统的经典故障

我猜你会问为什么热词里有"win10 asp style 不生效"，因为这个问题真的太常见了。现象是ASP页面在Windows 10以上环境里打开，HTML结构正常，但CSS全部失效，页面看起来像是纯文本堆出来的。

排查思路我从根上讲。ASP页面输出的HTML里，CSS通常有两种引入方式：一种是通过<link>引用外部CSS文件，另一种是直接在页面内部用<style>标签写。对于外部CSS文件，问题多半出在IIS的静态文件映射上，解决方式是确认站点里有CSS的MIME类型映射（.css对应text/css），同时确认CSS文件的物理路径没有因为代码注释掉或者大小写不匹配而404。

对于内联样式失效的问题，有一个非常隐蔽的原因：ASP页面里如果出现了意外的空行或BOM字符，会导致整个页面输出时产生多余内容，浏览器解析时把样式规则顶坏了。解决办法是用UTF-8无BOM格式重新保存ASP文件，并且检查ASP脚本标签前后的输出顺序，不要用Response.Write输出无关的空行。还有一个经常遇到的情况是CSS里用了position: fixed或某些在IE里正常的属性，在Edge或Chrome里显示正常，但客户用的是老IE兼容模式导致错乱，这个让浏览器以Edge模式渲染即可：

<meta http-equiv="X-UA-Compatible" content="IE=edge">

5.3 Access数据库崩溃与并发问题处理

Access数据库在极端情况下会出现文件损坏，通常表现为打开表提示"不可识别的数据库格式"。如果是不重要的数据，直接删掉重建；但如果里面是生产数据，就需要用Access自带的"压缩和修复数据库"功能。在修复之前，千万记得先复制一份备份文件，因为修复过程本身有一定概率造成二次损坏。

并发问题的处理思路有两个方向。第一个是降低连接频率：在conn.asp里不要每次请求都打开和关闭连接，可以设置连接池，尽量复用同一个Connection对象。第二个是缩短事务时间：销售开单保存过程中，主表明细表和库存更新都是毫秒级操作，但如果有其他页面在统计大量数据时长时间占用数据库锁，就会阻塞开单。这种场景下可以把统计页改成非实时数据，比如凌晨生成缓存表，或者把Access换成SQL Server。但精华版通常不推荐改SQL Server，因为工作量等于重写数据访问层。

在实际项目中，我还见过一种因为磁盘空间不足导致的数据库"打不开"的情况，现象和损坏完全一样，所以遇到问题先检查C盘和目标数据库所在盘符的剩余空间，这个检查成本最低，别一上来就动数据库结构。

6. 源代码的维护、交付与二次开发注意事项

6.1 拿到一份ASP源代码，第一步该怎么看

很多读者拿到一份不认识的老系统源代码，第一反应是所有文件都打开看看，结果越看越晕。我建议按这个顺序来：

先看目录结构。典型ASP项目一般包含根目录的ASP文件、data（数据库）、admin（后台管理）、css、images等子目录。通过目录就能判断它是单层结构还是前后台分离的结构。
找到全局入口文件。要么是index.asp，要么是conn.asp，前者告诉你系统最基础的页面流程，后者告诉你所有数据来源。把conn.asp读懂，你就拥有了整个系统的"钥匙"。
根据业务模块分块读代码，不要按字母表顺序读所有文件。看销售模块就进sale相关的几个文件，看商品模块就进product相关文件。ASP老项目的命名通常比较直白，拼出来大概就能猜到用途。
用对比工具看同一类页面（新增和编辑）的差异，能快速理解数据流是INSERT还是UPDATE。

看代码的过程中，强烈建议顺手画一张页面跳转关系的小图，不需要工具，白纸手画就行：登录页—主页面—各个子模块—保存页—跳回列表页。对刚开始维护老系统的人来说，这张图比任何文档都管用。整个系统读了不到半天，基本就有把握接手做修改了。

6.2 交付项目时源码的整理与权限处理

做外包交付时，源代码的整理直接关系到客户后续能不能自己维护，也关系到你收不收得到尾款。提炼几条经验：

清理开发残留：把测试用的临时ASP文件（比如test.asp、temp.asp）、调试日志、上传的临时图片清干净，避免客户在根目录看到一堆莫名其妙的文件。
数据库文件单独放：Access数据库是整个系统里最敏感的文件，提供一份初始密码文档和一份带测试数据的备份，特别是演示用的数据库，一定要把里面的真实客户信息删掉，换成示例数据。
提供部署说明文档：别假设客户会配置IIS，一个详细的doc文档，把启用ASP功能、数据库权限、目录权限、数据库连接信息改哪里写清楚。这是外包验收时最容易体现专业度的环节。
源代码加密与防拷问题：如果你的客户担心自己花钱开发的系统被随意拷贝，可以提示他使用IIS的URL授权、数据库密码或代码混淆。ASP的源码本质上很难完全防拷，因为服务器端VBScript需要能被IIS解释执行，真正能加密的手段有限，常见的做法是注册COM组件把核心逻辑编成DLL。但说实话，对中小商户内网使用的场景，这个投入产出比不高，客户端和服务器都在自己手里，做基本的数据库密码保护和目录权限限制就足够了。

6.3 二次开发怎么在不破坏原结构的前提下加功能

加新功能的时候最怕把老代码改崩。我在ASP项目上养成的习惯是：新增功能尽量新增文件，不改老文件。比如客户需要一个"退货单"功能，我不会去改sale开单相关的页面，而是新建return_main.asp、return_save.asp、return_list.asp，在菜单里加一个入口。这样做的好处是，老代码出问题时有明确的责任边界，回滚也容易。

数据库层面的扩展，优先考虑增加新表，不要贸然改老表结构。比如要记录每个操作员的登录日志，新建一张AdminLoginLog表即可，完全不动Admin表。确实必须加字段的时候，Access的表结构修改在企业管理器里直接操作风险不小，建议先做数据库备份，改完立刻做一次压缩修复。

所有二次开发，我坚持先搭建完整的本地测试环境，拿副本数据库测试通过后再上生产。ASP这种解释型脚本，改完立即生效，没有编译期拦截，一个拼写错误就能让整页白屏。生产环境上直接改代码、踩到线上故障的案例，我碰到过不止一次。

6.4 老ASP系统的安全加固清单

如果你负责维护的ASP系统还需要长期运行，有几项安全加固建议值得提。虽然ASP技术已经老旧，但很多生产系统仍承载着真实业务数据，不能掉以轻心。

数据库文件改名并移出Web根目录：比如默认的data.mdb改成一段无规律的名称，放到站点之外的物理目录里，通过连接字符串里的绝对路径读取。这样即使攻击者扫到了数据库文件路径，URL也直接下载不到文件。
SQL注入过滤：所有接收用户输入的参数，都要过滤单引号等危险字符。ASP里可以写一个通用的参数清洗函数，所有取参都走这个函数。老系统最常见的漏洞就是登录框直接拼SQL字符串。
登录尝试次数限制：在AdminLoginLog表里记录连续失败的登录请求，超过5次锁定账号一段时间。这个功能不难实现，但对防暴力破解很有效。
过期的IIS安全配置：关闭目录浏览，删除不必要的虚拟目录和ISAPI扩展，设定应用池的回收时间和限制。这些都属于运维层面的防护，成本不高但收益明显。

7. 我在这类项目里积累的一点选型心得

做了这些年老系统维护和新项目开发，我对ASP销售管理系统的整体判断是：它不会是你职业生涯里最高大上的项目，但一定是最"练手"的项目之一。因为它麻雀虽小、五脏俱全，业务闭环完整，你可以在里面锻炼数据库设计思维、服务端脚本逻辑、权限控制、部署排错等基本功。这些能力，放到任何现代技术栈里都依然通用。

如果你是想拿这套源代码练手，我的建议是先把代码完整跑起来，然后按自己的理解去改（比如把Access换成SQL Server、把VBScript重构成Class封装、加一个导出Excel功能），这种"破坏式重构"的学习效果，比单纯读代码强十倍。如果你是在做真项目交付，那记住我自己反复踩坑后的核心教训：环境配置问题占一半，数据库数据一致性占三成，业务逻辑设计占两成。把这几个方面都提前计划好，ASP项目反而是最不容易出幺蛾子的。最后再说一个实际经验：这种系统的数据库一定要养成定期备份的习惯，写个批处理脚本每天把mdb文件复制到另一个目录，成本极低，可一旦数据库损坏，这就是唯一的救命稻草。

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