简介本资源是一份面向.NET初学者与Web服务开发入门者的ASP.NET WebService实战示例包聚焦跨平台数据交互场景解决SOAP协议下Web服务创建、发布与基础调用的核心实践问题。压缩包共49个文件总大小357KB涵盖18个C#服务端逻辑文件含WebService.asmx.cs、StudentInfo.cs等、6个ASPX页面Default.aspx、About.aspx等、4个配置文件Web.config及Debug/Release变体、4张操作界面截图t0001.jpg等以及CSProj/Sln工程文件、JS/CSS前端脚本和DLL/PDB编译产物完整呈现从项目结构、服务定义到页面集成的全流程。已有244人学习下载。读者可直接导入Visual Studio运行调试掌握[WebMethod]标记方法、ASMX服务部署、IIS发布要点及客户端调用验证方式尤其适合理解传统ASP.NET WebService与现代Web API的演进差异。1. ASP.NET 发布 WebService别急着点“发布”先搞清你用的是 .NET Framework 还是 .NET Core/.NET 5刚接手一个老系统维护某导师甩来一个.asmx文件让我“快速部署成 WebService”我二话没说建了个新 ASP.NET Web Forms 项目加了WebService.asmxF5 一跑本地能通兴冲冲右键“发布”——结果 IIS 上死活返回 404浏览器连.asmx?wsdl都打不开。折腾三小时才发现这项目默认是 .NET Framework 4.7.2而服务器上只装了 .NET Core Runtime压根不认.asmx这套老古董。更玄学的是同一台机器上装了 .NET 6 SDK但 IIS 模块没注册aspnet_regiis.exe又早被微软弃用了……这种“本地能跑、线上翻车”的 WebService 发布场景几乎每个接触过遗留系统的开发者都踩过。它不是功能问题而是环境链断裂从开发时的框架选型、Web.config 配置粒度、IIS 的模块注册、到 Windows Server 的角色服务启用漏掉任何一环.asmx就是个黑匣子。本文专治这类“发布即失联”的 WebService 环境覆盖 .NET Framework经典 ASP.NET和 .NET Core/5WCF-HTTP 或轻量 REST 替代方案两条路径不讲 SOAP 协议原理只告诉你命令敲哪、配置改哪、报错看哪。适合正在迁移老系统、接手外包项目、或被甲方临时要求“把接口暴露成标准 WebService”的一线开发者。2. 明确技术栈区分 .NET Framework WebService.asmx与 .NET Core/5 的替代实现WebService 在 ASP.NET 生态里从来就不是单一技术。它像一个被时代分叉的路口一边是上世纪末诞生、基于.asmx文件和System.Web.Services命名空间的经典模式另一边是现代 .NET 中被重构、解耦甚至部分淘汰的通信方式。装错起点后面全是徒劳。下面直接划清边界不绕弯。2.1 经典 ASP.NET WebService.asmx仅限 .NET FrameworkWindows IIS 是刚需这是标题“ASP.NET 发布 WebService”最可能指向的原始形态。它的核心特征非常鲜明文件后缀.asmx如Calculator.asmx本质是一个 HTTP 处理程序HTTP Handler由System.Web.Services.Protocols.WebServiceHandlerFactory负责解析。框架依赖严格绑定 .NET Framework2.0 至 4.8.x无法在 .NET Core 或 .NET 5 上原生运行。微软官方文档明确标注其为“legacy technology”。宿主环境必须部署在IISInternet Information Services上且需启用“ASP.NET” 和 “HTTP 激活”Windows 功能。Kestrel.NET Core 默认 Web 服务器完全不支持.asmx。配置中心所有行为控制都在web.config的system.web节点下例如compilation控制编译选项httpHandlers注册处理程序webServices配置 SOAP 版本等。提示如果你的项目属性中“目标框架”显示为.NET Framework 4.x且解决方案里有.asmx文件那你走的就是这条路。别试图用dotnet publish命令去发布它——那只会生成一堆 DLLIIS 根本不认识。2.2 .NET Core/5 中的 WebService 替代方案没有原生 .asmx但有务实出路.NET Core 自诞生起就移除了对.asmx的支持。这不是疏忽而是架构演进的必然。但现实业务不会等你重写整个通信层。所以开发者实际有三条路可走按推荐度排序方案技术基础适用场景关键限制WCF HTTP 服务.NET 5System.ServiceModel.HttpNuGet 包需要保持 SOAP 协议兼容性客户端无法修改如对接老 Java Axis 系统仅支持 BasicHttpBinding不支持 WS-* 安全协议需手动配置路由和序列化ASP.NET Core Web APIRESTfulMicrosoft.AspNetCore.Mvc新建项目、或客户端可接受 JSON/XML 的轻量交互不是 WebService无 WSDL但语义上常被当作“现代 WebService”使用第三方库如 SoapCoreSoapCoreNuGet 包强烈需要 WSDL SOAP 1.1/1.2且不愿用 WCF社区维护版本更新节奏依赖作者需自行处理跨域、认证等中间件注意本文后续章节将并行展开这两条主线——第 3 章专注.asmx的 IIS 部署全流程第 4 章则聚焦如何在 .NET 6/7/8 项目中用SoapCore快速搭建一个能生成 WSDL、支持 SOAP 请求的“类 WebService”服务。二者代码结构、配置方式、验证手段完全不同切勿混用。2.3 如何一眼判断你的项目属于哪一类别猜用三个命令直接定位# 1. 查看项目文件.csproj找 TargetFramework 标签 cat YourProject.csproj | findstr TargetFramework # 输出示例 # TargetFrameworknet472/TargetFramework → 经典 .asmx 路线 # TargetFrameworknet6.0/TargetFramework → .NET Core/5 路线 # 2. 检查解决方案中是否存在 .asmx 文件Windows 命令 dir /s *.asmx # 如果存在且项目是 net4xx则锁定为经典路线 # 3. 检查引用的命名空间打开任意 .asmx.cs 或 Controller.cs # 经典路线必有using System.Web.Services; # .NET Core 路线绝不会有此引用常见的是using Microsoft.AspNetCore.Mvc;这三个命令执行完你的技术栈就毫无悬念了。很多翻车案例根源就是开发者凭经验以为“ASP.NET .asmx”却没意识到自己新建的是 .NET 6 Web API 项目——然后对着Startup.cs疯狂找web.config这当然找不到。3. 经典路线.NET Framework WebService.asmx在 IIS 上的完整部署确认走.asmx路线后发布就不再是 Visual Studio 里点几下鼠标的事。它是一套 Windows Server IIS .NET Framework 的协同工程。下面步骤全部基于Windows Server 2019 / 2022 IIS 10本地开发机Windows 10/11同理只是角色启用方式略有差异。3.1 前置检查确保 Windows 角色与功能已启用IIS 不是装上就能跑.asmx的。它依赖底层 Windows 组件。缺一个.asmx就是 500.19 错误。# 以管理员身份运行 PowerShell逐条执行检查 # 1. 检查 IIS 是否已安装 Get-WindowsFeature Web-Server # 2. 检查 ASP.NET Framework 支持关键针对 .NET 4.x Get-WindowsFeature Web-Asp-Net45 # 3. 检查 HTTP 激活WAS 服务所需 Get-WindowsFeature NET-WCF-HTTP-Activation45 # 4. 检查 Windows Process Activation ServiceWAS Get-WindowsFeature WAS-Process-Model Get-WindowsFeature WAS-Config-APIs如果任一命令返回InstallState : Removed或InstallState : Available说明未启用需立即安装# 启用所有必需功能一行搞定 Install-WindowsFeature Web-Server, Web-Asp-Net45, NET-WCF-HTTP-Activation45, WAS-Process-Model, WAS-Config-APIs -IncludeAllSubFeature -IncludeManagementTools逻辑说明Web-Asp-Net45并非只支持 .NET 4.5它是 .NET Framework 4.x 全系列的 IIS 集成开关NET-WCF-HTTP-Activation45则让 WASWindows Process Activation Service能监听 HTTP 请求并转发给 ASP.NET 处理程序——.asmx正是靠它活下来的。3.2 Visual Studio 中的正确发布配置很多人卡在第一步VS 里的“发布”向导选错了目标。.asmx项目不能选“文件系统”发布到任意文件夹因为 IIS 需要识别这是一个 Web 应用程序而非静态文件。步骤清单右键项目 → “发布…” → 点击“创建新配置文件”发布目标选择“IIS、FTP、FTPS”不是“文件夹”目标位置填\\localhost\c$\inetpub\wwwroot\MyWebService或你规划的物理路径配置文件名设为IIS-Publish-Profile.pubxml保存在“设置”选项卡中关键三处必须勾选✅ “删除目标位置中不存在的文件”避免旧 DLL 残留✅ “预编译期间排除 App_Code 文件夹中的文件”防止动态编译冲突✅ “启用 MSDeploy 包”生成 .zip 包便于离线部署为什么不用“文件夹发布”因为.asmx依赖App_Code、Bin、web.config的严格目录结构。文件夹发布会把.asmx.cs编译进Bin但.asmx文件本身仍需放在网站根目录供 IIS 解析。而 IIS 发布模式会自动处理.asmx文件的复制、web.config的合并、以及Bin目录的清理保证结构纯净。3.3 IIS 站点创建与应用程序池配置发布只是拷贝文件真正的“激活”在 IIS 管理器里。创建应用程序池Application Pool打开 IIS 管理器 → 左侧“应用程序池” → 右键“添加应用程序池”名称MyWebService-Pool.NET Framework 版本选择“.NET Framework v4.0.30319”注意不是“无托管代码”也不是“.NET CLR 版本 v2.0”托管管道模式“集成”经典模式已过时且不支持部分新特性启动模式“始终运行”避免首次请求时冷启动延迟。参数说明.NET Framework v4.0.30319是 .NET 4.x 的统一 CLR 版本号无论你项目是 4.5、4.7.2 还是 4.8这里都填这个。填错会导致 500.22 错误“HTTP 错误 500.22 - Internal Server Error”。创建网站或应用程序方法一独立网站右键“网站” → “添加网站”物理路径指向你发布的wwwroot\MyWebService绑定端口如 8080应用程序池选刚建的MyWebService-Pool方法二子应用程序右键现有网站 → “添加应用程序”别名填webservice物理路径同上应用程序池同上。权限设置极易忽略IIS 工作进程通常是IIS APPPOOL\MyWebService-Pool必须对发布目录有读取执行权限# PowerShell 命令行管理员 icacls C:\inetpub\wwwroot\MyWebService /grant IIS APPPOOL\MyWebService-Pool:(OI)(CI)RXRX表示读取执行(OI)对象继承、(CI)容器继承确保子目录和文件也获得权限。缺权限会报 401.3 或 403.14。3.4 web.config 的关键配置项详解.asmx的行为几乎全由web.config控制。一个典型、安全、可调试的配置如下删减版仅保留核心?xml version1.0? configuration system.web !-- 1. 编译设置允许调试禁用页面缓冲 -- compilation debugtrue targetFramework4.7.2 / httpRuntime maxRequestLength102400 executionTimeout300 / !-- 2. WebService 配置启用 WSDL 生成允许 GET 请求 -- webServices protocols add nameHttpGet/ add nameHttpPost/ add nameHttpSoap/ /protocols /webServices !-- 3. 安全关闭不必要的功能防信息泄露 -- customErrors modeOff/ !-- 开发期开启上线务必改为 On -- trace enabledfalse/ !-- 禁用跟踪防敏感信息外泄 -- /system.web !-- 4. 系统级配置启用 CORS如需跨域调用 -- system.webServer httpProtocol customHeaders add nameAccess-Control-Allow-Origin value* / add nameAccess-Control-Allow-Methods valueGET, POST, OPTIONS / /customHeaders /httpProtocol /system.webServer /configuration参数逐条解释compilation debugtrue开发期必须为true否则断点不生效、错误信息不详细上线前必须改为false否则性能暴跌且暴露源码路径。protocols下的三个addHttpGet和HttpPost允许浏览器直接访问?wsdl和表单提交HttpSoap启用 SOAP 1.1 协议。缺HttpSoapSOAP 客户端会连接失败。customErrors modeOff仅限测试环境。生产环境设为On并配defaultRedirect避免堆栈信息泄露。httpRuntime maxRequestLength102400单位 KB即 100MB用于支持大附件上传。默认 40964MB太小会报 400 错误。4. 现代路线在 .NET 6/7/8 中用 SoapCore 实现兼容 WebService 的 SOAP 服务如果你的项目是.NET 6.0或更高版本又必须提供.asmx那样的 WSDL 和 SOAP 接口比如对接老系统那么SoapCore是目前最成熟、社区最活跃的开源方案。它不是微软官方但已被大量企业级项目验证。4.1 创建 .NET 6 Web API 项目并集成 SoapCore从零开始拒绝魔改旧项目# 1. 创建新项目 dotnet new webapi -n SoapWebServiceDemo -f net6.0 # 2. 添加 SoapCore NuGet 包注意版本 cd SoapWebServiceDemo dotnet add package SoapCore --version 1.1.0.12 # 当前2024稳定版是 1.1.0.12不要用 2.xAPI 不兼容Program.cs 配置.NET 6 Minimal Hosting Modelusing Microsoft.AspNetCore.Builder; using Microsoft.Extensions.DependencyInjection; using Microsoft.Extensions.Hosting; using SoapCore; var builder WebApplication.CreateBuilder(args); // 添加 SoapCore 服务 builder.Services.AddSoapCore(); // 注册你的 WebService 类必须实现接口 builder.Services.AddScopedICalculatorService, CalculatorService(); var app builder.Build(); // 配置 SOAP 端点关键 app.UseRouting(); app.UseEndpoints(endpoints { // 暴露 SOAP 服务在 /soap 路径 endpoints.UseSoapEndpointICalculatorService(/soap, new SoapEncoderOptions(), SoapSerializer.XmlSerializer); // 同时保留默认 API 控制器可选 endpoints.MapControllers(); }); app.Run();逻辑说明UseSoapEndpoint是核心它告诉 Kestrel“当请求/soap时请交给 SoapCore 处理”。SoapSerializer.XmlSerializer确保生成标准 WSDL兼容老客户端若用DataContractSerializerWSDL 结构会不同老 Java Axis 可能解析失败。4.2 定义服务契约Interface与实现ClassSOAP 的灵魂是契约先行。必须定义接口并用[ServiceContract]标记// Models/ICalculatorService.cs using System.ServiceModel; [ServiceContract] public interface ICalculatorService { [OperationContract] int Add(int a, int b); [OperationContract] string GetVersion(); } // Services/CalculatorService.cs public class CalculatorService : ICalculatorService { public int Add(int a, int b) a b; public string GetVersion() $SoapCore v{typeof(SoapCore.SoapEndpointMiddleware).Assembly.GetName().Version}; }为什么必须用接口SoapCore 通过接口生成 WSDL 的portType和binding。如果直接实现类WSDL 会丢失操作契约客户端无法生成代理类。4.3 发布与部署.NET Core 的标准流程.NET Core项目发布极其简单但要注意路径和端口# 1. 发布为自包含推荐免服务器装 Runtime dotnet publish -c Release -r win-x64 --self-contained true -o ./publish # 2. 复制 publish 文件夹到服务器如 C:\MySoapService # 3. 启动服务Windows 服务或后台进程 # PowerShell 中执行 Start-Process -FilePath C:\MySoapService\SoapWebServiceDemo.exe -WindowStyle Hidden参数说明-r win-x64指定运行时标识符RID确保生成 Windows x64 可执行文件--self-contained true打包所有依赖服务器无需安装 .NET Runtime。若选false则服务器必须装对应版本的 .NET Runtime。4.4 验证端点与 WSDL用 curl 和浏览器双重确认部署后立刻验证两个关键 URLURL用途预期响应http://localhost:5000/soap?wsdl获取 WSDL 文档XML 格式含definitions根节点service和porthttp://localhost:5000/soapSOAP 服务入口返回405 Method Not Allowed正常说明端点存在只是不允许 GET# 用 curl 获取 WSDL 并检查是否有效 curl -s http://localhost:5000/soap?wsdl | head -20 # 应看到类似definitions xmlnshttp://schemas.xmlsoap.org/wsdl/ ... # 模拟一个 SOAP POST 请求验证服务可用 curl -X POST http://localhost:5000/soap \ -H Content-Type: text/xml; charsetutf-8 \ -H SOAPAction: \http://tempuri.org/Add\ \ -d ?xml version\1.0\ encoding\utf-8\?soap:Envelope xmlns:xsi\http://www.w3.org/2001/XMLSchema-instance\ xmlns:xsd\http://www.w3.org/2001/XMLSchema\ xmlns:soap\http://schemas.xmlsoap.org/soap/envelope/\soap:BodyAdd xmlns\http://tempuri.org/\a2/ab3/b/Add/soap:Body/soap:Envelope如果 WSDL 返回 404检查UseSoapEndpoint路径是否与 URL 一致如果 SOAP POST 返回 500检查Program.cs中AddSoapCore()是否遗漏或CalculatorService是否注册为 Scoped/Singleton。5. 避坑指南WebService 发布中最常见的 5 个血泪问题与解法再完美的流程也挡不住现实世界的千奇百怪。以下是我在多个模拟项目 X 和某跨平台系统迁移中反复遇到、且文档极少提及的硬核坑。每一条都附带真实现象、根因分析和可立即执行的解决命令。5.1 现象IIS 上访问xxx.asmx?wsdl返回 404但xxx.asmx本身能打开原因IIS 的 MIME 类型映射缺失或web.config中protocols未启用HttpGet。.asmx?wsdl是一个特殊的 HTTP GET 请求IIS 需要明确知道.asmx文件支持?wsdl查询字符串。解决# 在 IIS 管理器中选中你的网站 → “MIME 类型” → 右键“添加” # 扩展名.asmxMIME 类型application/octet-stream # 或用命令行管理员 cmd /c echo y | %windir%\Microsoft.NET\Framework\v4.0.30319\aspnet_regiis.exe -i # 重新注册 ASP.NET强制刷新 MIME 映射5.2 现象SOAP 客户端调用返回The remote server returned an error: (400) Bad Request原因SOAP 请求的SOAPActionHeader 缺失或值错误。.asmx严格校验此 Header而很多工具如 Postman默认不发送。解决在 Postman 中Headers 标签页手动添加SOAPAction: http://tempuri.org/Add Content-Type: text/xml; charsetutf-8SOAPAction的值必须与 WSDL 中operation soapAction...的值完全一致包括引号。用浏览器打开?wsdl搜索soapAction即可找到。5.3 现象.NET Core SoapCore 服务启动后/soap?wsdl返回 404原因UseSoapEndpoint调用顺序错误。它必须在UseRouting()之后、UseEndpoints()内部调用且不能放在MapControllers()之后。解决严格按以下顺序写Program.csapp.UseRouting(); // 必须第一 app.UseEndpoints(endpoints { endpoints.UseSoapEndpointIService(/soap, ...); // 必须在此处 endpoints.MapControllers(); // 必须在此之后 });若顺序颠倒Kestrel 的中间件管道会跳过 SoapCore。5.4 现象IIS 上.asmx服务返回 500.22 错误事件查看器提示“HTTP 错误 500.22 - Internal Server Error”原因应用程序池的 .NET Framework 版本选错或web.config中system.webServer节点被错误修改如删掉了modules runAllManagedModulesForAllRequeststrue /。解决!-- 在 web.config 的 system.webServer 下确保有这一行 -- modules runAllManagedModulesForAllRequeststrue /并再次确认应用程序池的“.NET Framework 版本”是v4.0.30319不是v2.0.50727或空。5.5 现象SoapCore 服务在 Linux 服务器Nginx 反向代理下 WSDL 中的地址是http://localhost:5000/soap而非公网域名原因SoapCore 生成 WSDL 时从HttpContext.Request中提取 Host而 Nginx 默认不透传 Host 头。解决在 Nginx 配置中添加location /soap { proxy_pass http://localhost:5000; proxy_http_version 1.1; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection keep-alive; proxy_set_header Host $host; # 关键透传 Host proxy_set_header X-Real-IP $remote_addr; proxy_cache_bypass $http_upgrade; }同时在Program.cs中启用ForwardedHeadersbuilder.Services.ConfigureForwardedHeadersOptions(options { options.ForwardedHeaders ForwardedHeaders.XForwardedFor | ForwardedHeaders.XForwardedProto; options.KnownNetworks.Clear(); options.KnownProxies.Clear(); });6. 验证跑通用三种方式交叉验证 WebService 是否真正可用装完不是终点验证才是。我从不信任单一测试手段。下面这套组合拳能在 5 分钟内揪出 95% 的隐藏问题。它不追求花哨只求每一行命令都有明确预期和失败反馈。6.1 第一关WSDL 可访问性与结构验证这是最基础的“心跳检测”。WSDL 文件必须能下载且结构合法。# 1. 下载 WSDL 到本地 curl -o wsdl.xml http://your-server/MyWebService/Calculator.asmx?wsdl # 2. 检查是否为有效 XML非 HTML 错误页 xmllint --noout wsdl.xml 21 | grep -q valid echo ✅ WSDL 是有效 XML || echo ❌ WSDL 格式错误 # 3. 检查是否包含关键 SOAP 元素证明不是 404 伪装的 HTML grep -q soap:address wsdl.xml echo ✅ 包含 soap:address || echo ❌ 缺少 soap:address grep -q http://schemas.xmlsoap.org/wsdl/ wsdl.xml echo ✅ WSDL 命名空间正确 || echo ❌ 命名空间异常为什么用xmllint因为它比curl -I更深入一层curl -I只看 HTTP 状态码而xmllint真正解析 XML 结构。曾有个案例IIS 返回 200但内容是“HTTP 错误 404.3 - Not Found”的 HTML 页面xmllint会直接报错而curl -I会误判为成功。6.2 第二关SOAP 协议级连通性测试不依赖客户端生成用最原始的curl模拟一次完整的 SOAP 请求-响应循环绕过所有 SDK 封装。# 构造一个最小化 Add 请求替换 your-server 和端口 SOAP_REQUEST ?xml version1.0 encodingutf-8? soap:Envelope xmlns:xsihttp://www.w3.org/2001/XMLSchema-instance xmlns:xsdhttp://www.w3.org/2001/XMLSchema xmlns:soaphttp://schemas.xmlsoap.org/soap/envelope/ soap:Body Add xmlnshttp://tempuri.org/ a10/a b20/b /Add /soap:Body /soap:Envelope # 发送并提取响应中的结果用 sed 粗暴但有效 curl -s -X POST http://your-server/MyWebService/Calculator.asmx \ -H Content-Type: text/xml; charsetutf-8 \ -H SOAPAction: \http://tempuri.org/Add\ \ -d $SOAP_REQUEST \ | sed -n s/.*AddResult\(.*\)\/AddResult.*/\1/p \ | grep -q 30 echo ✅ SOAP Add 调用成功返回 30 || echo ❌ SOAP 调用失败或返回值错误关键点说明SOAPActionHeader 必须用双引号包裹且值与 WSDL 中完全一致sed命令精准提取AddResult标签内的数字避免匹配到其他 XML 内容这个测试直接验证了网络层、IIS/ASP.NET 处理层、以及 WebService 业务逻辑层三者全部打通。6.3 第三关客户端代理生成与调用终极实战最后一步用标准工具生成客户端代码再调用。这是对 WSDL 完整性和服务契约的终极考验。使用dotnet-svcutil.NET Core 官方工具# 1. 安装工具一次 dotnet tool install --global dotnet-svcutil # 2. 根据 WSDL 生成 C# 客户端类 dotnet-svcutil http://your-server/MyWebService/Calculator.asmx?wsdl --outputDir ./Client --namespace MyClient # 3. 编译并运行一个测试程序test.cs cat test.cs EOF using System; using MyClient; class Program { static void Main() { var client new CalculatorSoapClient(CalculatorSoapClient.EndpointConfiguration.CalculatorSoap); try { var result client.AddAsync(5, 7).Result; Console.WriteLine($✅ 客户端调用成功5 7 {result}); } catch (Exception ex) { Console.WriteLine($❌ 客户端调用失败{ex.Message}); } finally { client.Close(); } } } EOF # 4. 编译并运行 dotnet new console -n TestClient -o ./TestClient cp test.cs ./TestClient/ cd ./TestClient dotnet add reference ../Client/Reference.cs dotnet run如果这一步成功恭喜你你的 WebService 已经通过了从协议层到应用层的全栈验证。它不再是一个“能打开的网页”而是一个可被任何标准 SOAP 客户端消费的、可靠的远程服务。从那以后我每次部署 WebService都强制走一遍这三关WSDL 下载 → curl SOAP 请求 →dotnet-svcutil生成调用。少一关心里就发虚。因为.asmx和SoapCore都不是黑盒它们的契约WSDL就是最权威的说明书。只要 WSDL 能生成、能解析、能调用服务就立得住。希望帮到你。本文还有配套的精品资源点击获取