简介针对数据库课程设计、毕业设计或需要完成同类管理系统的学生与开发者这份文档给出通讯录管理系统数据库从需求到落地的完整设计与实现。内容覆盖需求简介、数据字典、数据结构、E-R图、关系模型转换、数据库模式、用户子模式、物理结构设计及实施SQL语句可直接用于撰写设计报告或作为数据库建表参考同时明确了各数据项的编号、类型、含义并对主外键与完整性约束做了标注。包体仅含1个doc文档压缩包大小422KB结构精简便于查阅与复制使用。目前已有998人学习下载。文档重点展示了用户、联系人、分组、拥有四类表的字段定义、主外键设置与完整性约束并附有create database、create table等核心SQL示例帮助读者理清从需求分析到数据库实施的全过程。1. 通讯录管理系统数据库设计这份doc为什么值得照着敲一遍如果你的课程设计题目恰好落在“信息管理系统”这类范围里这份《通讯录管理系统数据库设计与实现.doc》基本就是一份能直接照着改的标准答案。它不像网上那些只丢几个建表SQL的零散脚本而是从需求分析、数据字典、E-R图、关系模型转换一路写到物理存储规划、子模式视图和增删改查SQL的完整闭环。四张表覆盖用户、联系人、分组和归属关系十八个数据项把每个字段的类型和边界都提前定好了连create database的数据文件和日志文件分开存放这种细节都给了。适合两类人一是正在做数据库课设、想找个规范模板快速改写成自己题目比如图书管理、商品管理的学生二是想快速过一遍SQL Server建模流程的从业者。但先说句实在话——文档里埋着好几处前后不一致的坑主键选Name还是L_number、字段长度为什么一会儿CHAR(10)一会儿CHAR(100)这些我放到第五章逐个点破。2. 数据字典与关系模型十八个字段怎么落成四张表拿到这份doc最先能直接抄的资产就是数据字典。它把整个系统涉及的数据项全列出来了编号从TXL-1到TXL-18每个字段都规定好了类型和长度。这一章做的事就是把这些散装字段归拢到四张表里说清楚它们之间的依赖关系。2.1 十八个数据项字段、类型和命名边界原文档的数据字典整理一下大致是这样的结构编号数据项名类型所属表作用TXL-1G_numberCHAR(10)Grouping / Own分组号Grouping主键TXL-2G_nameCHAR(20)Grouping分组名非空TXL-3IDCHAR(10)Worker / Own账号充当用户IDTXL-4IDCHAR(10)Worker账号主键TXL-5NicknameCHAR(20)Worker昵称TXL-6PasswordCHAR(20)Worker密码TXL-7QianmingCHAR(50)Worker个性签名TXL-8L_numberCHAR(100)Linkman / Own联系人号TXL-9NameCHAR(20)Linkman联系人姓名TXL-10SexCHAR(2)Linkman性别TXL-11ConcernCHAR(10)Linkman与联系人的关系TXL-12PhoneCHAR(11)Linkman手机号TXL-13LandlineCHAR(10)Linkman座机号TXL-14QQCHAR(10)LinkmanQQ号TXL-15EmailCHAR(20)Linkman邮箱TXL-16WorkCHAR(30)Linkman工作单位TXL-17AddressCHAR(30)Linkman地址TXL-18BirthdayDateLinkman生日注意一个细节全表清一色CHAR定长类型。课程设计里这么写没问题但放到实际生产环境我更建议把姓名、地址、个性签名这种长度不稳定的字段换成VARCHAR否则每个联系人姓名都固定占20字节存一万条记录就是20万字节的固定开销。原文档这么设计可能是为了体现“数据类型设计”这个知识点你抄的时候可以保留这个说辞也可以顺手改成VARCHAR写进报告里两种做法都说得通。另外命名上直接用了拼音Qianming、L_number这在课设报告里很常见。如果你想让它看起来更规范可以改成sgnature或motto但需要全局同步我一般建议保持原样避免改一半出问题。2.2 四张表的数据结构E-R图怎么落成关系模型原文档定义了四个数据结构DS-1 Grouping分组、DS-2 Worker用户、DS-3 Linkman联系人、DS-4 Own拥有。这四张表分别对应E-R图里的两个实体和一个联系用户Worker与分组Grouping之间是“管理”关系一个用户能建多个分组分组Grouping与联系人Linkman之间是“拥有”关系一个分组里能挂多个联系人Own表把这两层关系合并成一个三元联系用户ID 分组号 联系人号。这个设计是合理的因为联系人必须归属于某个用户和某个分组单纯用一对多关系表达会丢信息。把“拥有”独立成表是数据库设计中处理多对多关系的标准做法。尤其要注意Own表的主键设计——(ID, G_number, L_number)三列联合主键这保证了同一个联系人不会重复挂到同一用户下的同一分组里。关系模型转换的规则也很清晰实体变成表实体属性变成列多对多联系单独成表主键从实体标识属性里选。对照原文档3.1节的描述UserID, Nickname, Password, Qianming GroupingG_number, G_name, ID LinkmanName, Sex, Concern, QQ, Phone, Landline, Email, Work, Address, Birthday OwnID, G_number, L_number这里有一个值得注意的矛盾我先埋个伏笔后面展开关系模型里Grouping带了一个ID字段表达“这个分组属于哪个用户”但建表SQL里却没有这一列Linkman在关系模型里没有列L_number可建表和插入数据时又处处用到它。这种不一致在课设模板里很常见属于“报告写了A脚本写了B”的典型翻车现场。2.3 用户子模式设计九个功能点对应的视图思路原文档3.3节列了九个“子模式”编号从001到009用户分组显示、联系人查询、用户账号管理、联系人的增删改、分组的增删改。这其实就是数据库里的“视图”概念——为不同角色屏蔽底层表的细节只暴露业务需要的列。比如“用户账号管理”这个子模式对应到SQL就是-- 只暴露昵称、密码、签名不暴露账号ID之外的敏感列 CREATE VIEW v_worker_account AS SELECT ID, Nickname, Password, Qianming FROM Worker;“联系人查询”子模式则可以做成只允许查姓名、手机号、分组名的视图不让用户直接摸到整张Linkman表。视图的作用在原文档里写得很明确提供数据保密和安全保护机制。做课设答辩时这一条很适合拿来回答“你的系统安全性怎么体现”这类问题。3. 建库建表脚本拆解数据文件、主外键和CHECK约束逐行讲这一章是整份doc里最值得直接抄的部分。原文档从建库到建表给了完整的SQL Server脚本我按顺序拆开讲。你照着敲一遍就能得到一个能跑的数据库骨架。3.1 建库语句数据文件和日志分开放的逻辑原文档5.1节的建库脚本是这样的CREATE DATABASE TXL ON ( NAME TXL, FILENAME D:\通讯录数据库\TXL.mdf, SIZE 100MB, MAXSIZE UNLIMITED, FILEGROWTH 50MB ) LOG ON ( NAME TXL_log, FILENAME E:\通讯录数据库\TXL_log.ldf, SIZE 3MB, MAXSIZE 50MB, FILEGROWTH 2MB );这段脚本的参数含义SIZE 100MB主数据文件初始大小课设数据量远用不到但设大点能避免频繁自动增长MAXSIZE UNLIMITED数据文件不设上限。注意这个配置要配合磁盘空间看磁盘满了就会出错生产环境一般会设一个具体上限课设无所谓FILEGROWTH 50MB空间不足时每次自动增50MB。增量太大可能造成磁盘碎片太小则频繁增长影响性能LOG ON日志文件单独定义放在不同盘符E:数据文件在D:。这个做法叫“读写分离”的物理基础把日志IO和数据IO分散到不同磁盘能明显降低磁盘竞争日志文件初始SIZE 3缺少单位。SQL Server默认按MB算但这么小的初始日志对生产环境不够用课设场景则无所谓建库能成功就行。我把路径的盘符换一下就能在你自己机器上跑。如果路径目录不存在SQL Server会报错所以要先创建D:\通讯录数据库和E:\通讯录数据库这两个文件夹。3.2 四张表的建表脚本主键、外键与CHECK约束原文档5.2节给了四张表的建表SQL我完整抄一遍再把每张表的约束讲清楚。-- (1) 创建用户表 Worker CREATE TABLE Worker ( ID CHAR(10) PRIMARY KEY, -- 账号主键 Nickname CHAR(20) NOT NULL, -- 昵称不允许空 Password CHAR(20) NOT NULL, -- 密码不允许空 Qianming CHAR(50) -- 个性签名允许为空 );-- (2) 创建分组表 Grouping CREATE TABLE Grouping ( G_number CHAR(10) PRIMARY KEY, -- 分组号主键 G_Name CHAR(20) NOT NULL -- 分组名不允许空 );-- (3) 创建联系人表 Linkman原文档版本 CREATE TABLE Linkman ( Name CHAR(20) PRIMARY KEY, -- 姓名被设为主键注意问题 Sex CHAR(2) CHECK (Sex 男 OR Sex 女) DEFAULT NULL, Concern CHAR(10) DEFAULT NULL, -- 关系 Phone CHAR(11) DEFAULT NULL, -- 手机号 Landline CHAR(10) DEFAULT NULL, -- 座机号 QQ CHAR(11) DEFAULT NULL, -- QQ号文档里写成CHAR(10)和CHAR(11)不一致 E_mail CHAR(30) DEFAULT NULL, -- 邮箱 Work CHAR(20) DEFAULT NULL, -- 工作单位 Address CHAR(30) DEFAULT NULL, -- 地址 Birthday DATE DEFAULT NULL -- 生日 );-- (4) 创建拥有表 Own原文档版本 CREATE TABLE Own ( ID CHAR(10), -- 用户ID G_number CHAR(10), -- 分组号 Name CHAR(20), -- 联系人姓名 PRIMARY KEY (ID, G_number, Name), FOREIGN KEY (ID) REFERENCES Worker(ID), FOREIGN KEY (G_number) REFERENCES Grouping(G_number), FOREIGN KEY (Name) REFERENCES Linkman(Name) );这里有几个明显的设计问题我直接指出来第一Linkman表把Name设为主键可联系人姓名是会重复的——通讯录里出现两个“张伟”太正常了。原文档的数据字典里明明定义了L_number联系人号但建表时却没建这一列。更矛盾的是后面插入联系人数据的SQL里又写了Insert into Linkman(L_number, Name, ...)。也就是说文档的建表脚本和业务SQL根本没对齐照着敲必报“列名无效”。第二Own表的外键用的是Name指向Linkman(Name)但6.6节插入Own表时用的却是L_number。这意味着你必须先给Linkman补上L_number主键再把Own表外键改成指向L_number整个外键链才能走通。第三Grouping表在关系模型里是有ID字段的功能上表达“这个分组是哪个用户建的”。但建表脚本里没有这个字段也没有到Worker表的外键。结果就是分组和用户之间在物理表上完全断开只剩Own表间接关联。严格来说这会导致一个用户能修改另一个用户的分组名——逻辑漏洞。3.3 把原文档脚本改到能跑一版修正后的完整建库脚本为了让这份资源真正能落地我给出修正后的完整脚本。改动的核心思路让L_number成为联系人的主键把Own表的外键关系对齐到Linkman(L_number)并给Grouping表补上ID字段和相关外键。-- 修正1Linkman表使用L_number作为主键 CREATE TABLE Linkman ( L_number CHAR(10) PRIMARY KEY, -- 联系人号主键 Name CHAR(20) NOT NULL, -- 姓名不再作为主键 Sex CHAR(2) CHECK (Sex 男 OR Sex 女) DEFAULT NULL, Concern CHAR(10) DEFAULT NULL, Phone CHAR(11) DEFAULT NULL, Landline CHAR(10) DEFAULT NULL, QQ CHAR(11) DEFAULT NULL, E_mail CHAR(30) DEFAULT NULL, Work CHAR(20) DEFAULT NULL, Address CHAR(30) DEFAULT NULL, Birthday DATE DEFAULT NULL );-- 修正2Grouping表补充所属用户ID和外键 CREATE TABLE Grouping ( G_number CHAR(10) PRIMARY KEY, G_Name CHAR(20) NOT NULL, ID CHAR(10), -- 补充所属用户 FOREIGN KEY (ID) REFERENCES Worker(ID) );-- 修正3Own表外键指向 L_number CREATE TABLE Own ( ID CHAR(10), G_number CHAR(10), L_number CHAR(10), PRIMARY KEY (ID, G_number, L_number), FOREIGN KEY (ID) REFERENCES Worker(ID), FOREIGN KEY (G_number) REFERENCES Grouping(G_number), FOREIGN KEY (L_number) REFERENCES Linkman(L_number) );改完这三处后面原文档6.5节以后的所有插入、修改、删除语句就都能原样执行了不需要再动。这张修正表也建议直接写进你的课设报告答辩老师问“你的表结构怎么优化的”时这就是现成的回答。4. 业务SQL与视图注册、分组、联系人增删改查九连击原文档第六章给出的业务SQL覆盖了从注册到条件查询的完整路径。我按功能模块拆开讲每段SQL后面跟着说明它是怎么和前面的表结构对应的。4.1 注册、修改资料和分组维护六个基础SQL操作注册用户是系统入口原文档6.1节给的是这样的INSERT INTO Worker(ID, Nickname, Password, Qianming) VALUES (00000, 用户1, 00000, 我的联系人我做主);这条SQL把ID当成了唯一标识ID即账号。注意原文档后续所有业务都围绕ID00000这个用户展开相当于一个默认测试账号。修改用户资料的SQL也很直白UPDATE Worker SET Nickname 超级用户, Password 11111, Qianming 常联系 WHERE ID 00000;WHERE条件一定要带ID否则会把整张表所有用户的昵称全改成“超级用户”。分组维护的三条SQL分别是创建、改名、删除INSERT INTO Grouping(G_number, G_name) VALUES (0000000000, friends); INSERT INTO Grouping(G_number, G_name) VALUES (0000000001, family);UPDATE Grouping SET G_name my friends WHERE G_number 0000000000;DELETE FROM Grouping WHERE G_number 0000000001;分组删除有一点容易踩如果这个分组下面还挂着联系人那么Own表里仍有指向该分组的记录外键约束会拦住DELETE。所以业务上正确的顺序是先把该分组下的联系人解绑再删分组。原文档的示例里是先插了7个联系人并挂到了G_number0000000000下然后直接删的是0000000001这个空分组所以没触发约束问题。4.2 联系人增删改查先插Linkman还是先插Own添加联系人是整份文档里最有代表性的操作。原文档6.5节一口气插了7个联系人我截前两条看INSERT INTO Linkman(L_number, Name, Sex, Concern, QQ, Phone, Landline, E_mail, Work, Address, Birthday) VALUES (0000000001, 刘江涛, 男, NULL, 1234567891, 12345678901, NULL, NULL, NULL, NULL, NULL); INSERT INTO Linkman(L_number, Name, Sex, Concern, QQ, Phone, Landline, E_mail, Work, Address, Birthday) VALUES (0000000002, 查孟博, 男, NULL, 1234567892, 12345678902, NULL, NULL, NULL, NULL, NULL);注意这里我用的表结构是修正过的版本——Linkman表第一列是L_number原来doc里的原版建表脚本没有这个列直接跑这段SQL会报错。插入时UNLL的位置对应的是“关系、座机、邮箱、工作单位、地址、生日”这些选填字段SQL Server会用建表时的DEFAULT NULL兜底。插入联系人之后原文档6.6节执行联系人归属操作INSERT INTO Own(ID, G_number, L_number) VALUES (00000, 0000000000, 0000000001);这条SQL建立了“用户00000 → 分组friends → 联系人刘江涛”的归属链。多对多关系表Own必须等Linkman里的记录存在后才能插入否则外键约束直接报错。正确的插入顺序永远是先Linkman后Own。修改和删除联系人也遵循同样的顺序逻辑UPDATE Linkman SET Name 侯启瑞 WHERE L_number 0000000004;DELETE FROM Own WHERE L_number 0000000004; DELETE FROM Linkman WHERE L_number 0000000004;删除时必须先删Own里的关联记录再删Linkman里的联系人。如果顺序反了外键会拦住最后一条SQL。这是数据库完整性约束在工作不是系统出bug。4.3 关键字查询和条件查询两段SELECT的写法差异原文档6.9节按联系人号精确查询SELECT * FROM Linkman WHERE L_number 0000000001;这段SQL就是“关键字查询”。这里的“关键字”指的是主键等唯一标识实际项目中更常见的是按姓名模糊查找写法是WHERE Name LIKE %刘%。原文档6.10节给了一个三表联查SELECT L.Name, L.Phone FROM Linkman L, Own, Grouping G WHERE L.L_number Own.L_number AND Own.G_number G.G_number AND G.G_name my friends;这段SQL的意图是查“my friends”分组里所有联系人的姓名和手机号。它用隐式连接写法把Linkman和Own通过L_number关联把Own和Grouping通过G_number关联再用G_name过滤。功能没问题但我自己在写的时候会更偏好显式INNER JOINSELECT L.Name, L.Phone FROM Linkman L INNER JOIN Own O ON L.L_number O.L_number INNER JOIN Grouping G ON O.G_number G.G_number WHERE G.G_name my friends;两种写法结果一样但显式JOIN可读性更好也方便后边加条件。报告中用原文档的写法可以因为那是教学场景里的经典老式写法答辩时老师不会扣分。5. 复现避坑Linkman主键、L_number长度与外键顺序的五个坑这一章我把这份doc里最容易让复现翻车的地方集中列出来。每条都按“现象 → 原因 → 解决”来写你可以把这几条直接搬进课设报告的“问题与解决”小节老师问起来也解释得通。5.1 现象一Linkman表根本没有L_number列插入却报“列名无效”现象按原文档6.5节的INSERT INTO Linkman(L_number, ...)执行SQL Server直接报错“列名 L_number 无效”。原因5.2节建表SQL里Linkman压根没有定义L_number列。数据字典里写了TXL-8 L_number CHAR(100)可建表脚本只建了Name、Sex、Phone这些列。文档写了两套结构一套是字典和关系模型一套是建表脚本两边没对齐。这大概率是生成文档时复制遗漏了。解决建表时补上L_number CHAR(10) PRIMARY KEY放在第一列。注意类型长度和数据字典保持一致后面第5.3条会讲长度的问题。我给出的修正版脚本已经处理好了。5.2 现象二主键到底选Name还是L_number直接决定删改SQL能不能跑现象删除联系人时原文档6.8节写的是DELETE FROM Linkman WHERE L_number 0000000004但按原建表脚本Linkman没有L_number列只能用Name定位可Name又允许重复删一次可能误删多个同名联系人。原因关系模型和业务SQL都默认L_number是联系人的唯一定位标识唯独建表脚本把主键放在了Name上。主键选错等于整个删改操作失去了可靠条件。解决用L_number做主键。Name可以加一个唯一索引也可以不加——真实通讯录里重名很正常但课程设计里加一个UNIQUE约束报告里可以写“保证联系人姓名唯一”也算合理设计。5.3 现象三L_number长度对不上CHAR(100)和CHAR(10)到底听谁的现象数据字典把L_number定义为CHAR(100)建表脚本和插入数据用的却是形如0000000001的10位字符串。原因原文档对“联系人号”的定位摇摆不定。如果是全局唯一编号10位足够表达百亿条记录如果想把分组号嵌进联系人号里做组合编码比如前4位是分组号后6位是联系人序号那CHAR(10)也够用。CHAR(100)应该是早期设计时预留了冗余后来没同步。解决统一用CHAR(10)。课程设计数据量小10位绰绰有余。真用CHAR(100)每次索引扫描和比较的开销都会成倍增加属于没有道理的浪费。如果非要体现“可扩展”可以在报告里写“本设计预留分组前缀编码空间联系人号前4位保留给分组号”既解释了为什么10位又展示了设计思路。5.4 现象四删除联系人被外键拦住报“DELETE 语句与 REFERENCE 约束冲突”现象执行原文档6.8节的DELETE FROM Linkman WHERE L_number0000000004SQL Server报冲突错误记录删不掉。原因Own表里还有L_number0000000004的关联记录。外键约束要求父表记录被删前子表不能有引用它的记录。解决先删Own再删Linkman这是标准的外键依赖顺序。用事务包起来更稳妥BEGIN TRANSACTION; DELETE FROM Own WHERE L_number 0000000004; DELETE FROM Linkman WHERE L_number 0000000004; COMMIT;5.5 现象五Grouping表缺了ID字段分组归不到用户头上现象3.1节关系模型里明确写了Grouping(G_number, G_name, ID)但建表SQL里只建了G_number和G_name。结果就是任何用户都能修改任何分组名分组和用户之间没有物理约束。原因关系模型到表结构的转换环节漏掉了ID字段属于“报告写的是设计脚本写的是敷衍”。解决给Grouping补上ID CHAR(10)并加外键指向Worker(ID)。修正后的建表脚本已经在3.3节给出了。如果把这一步省掉你的课设答辩可能会被老师揪住问“分组的所有权怎么保证”6. 验证与改造把模板变成自己课设的进阶玩法6.1 用系统视图和约束检查验证库结构按修正版脚本建完库之后我先教你怎么验证它真的建对了。SQL Server提供了几个系统视图可以一次性看到所有表、约束和索引-- 查看当前库所有表及类型 SELECT name, type_desc FROM sys.tables; -- 查看Linkman表上的主键和约束 SELECT kc.name AS constraint_name, kc.type_desc FROM sys.key_constraints kc WHERE kc.parent_object_id OBJECT_ID(Linkman); -- 查看所有外键关系 SELECT fk.name AS fk_name, tp.name AS parent_table, cp.name AS parent_column, tr.name AS referenced_table, cr.name AS referenced_column FROM sys.foreign_keys fk JOIN sys.foreign_key_columns fkc ON fk.object_id fkc.constraint_object_id JOIN sys.tables tp ON fkc.parent_object_id tp.object_id JOIN sys.columns cp ON fkc.parent_object_id cp.object_id AND fkc.parent_column_id cp.column_id JOIN sys.tables tr ON fkc.referenced_object_id tr.object_id JOIN sys.columns cr ON fkc.referenced_object_id cr.object_id AND fkc.referenced_column_id cr.column_id;执行完你至少要能看到三张业务表Worker、Grouping、Linkman和一张关系表Own并且Own上有三条外键分别指向前三张表。看不到外键就要回查是不是漏建了。再做一个破坏性测试验证外键真的在工作-- 尝试删除一个已经挂在分组下的联系人验证是否被外键拦截 DELETE FROM Linkman WHERE L_number 0000000001;执行后应该报“冲突”错误。这时你就能在报告里写“本人通过破坏性测试验证了外键完整性约束有效”这是课设报告里很加分的实证。6.2 三个值得加的扩展登录日志、分页、联系人标签原文档的功能已经能撑起一份课设了但如果你想让它看起来比别人多做了点事我建议加一个登录日志表CREATE TABLE LoginLog ( LogID INT IDENTITY(1,1) PRIMARY KEY, ID CHAR(10) NOT NULL, LoginTime DATETIME DEFAULT GETDATE(), FOREIGN KEY (ID) REFERENCES Worker(ID) );有了这张表每次登录往里面插一条记录就能展示“最近登录时间”。这个功能在答辩时比多写两个查询更有说服力因为它涉及了新的表设计、时间函数和ID自增三个知识点。分页扩展的话SQL Server用OFFSET FETCHSELECT Name, Phone FROM Linkman ORDER BY L_number OFFSET 0 ROWS FETCH NEXT 5 ROWS ONLY;这段代码让联系人列表支持“每页5条”的翻页真实管理系统里必不可少顺手写进报告里很提气。联系人标签功能给Linkman加一列Tag比如“同学”“同事”“家人”查询时用它做二次筛选是对原设计的低成本功能增量。6.3 从模板到自己的课设改表名、改字段、补文档拿到这份doc之后最值钱的动作是“替换”。如果老师的题目不是通讯录而是图书管理系统或员工管理系统你只需要做三件事。第一全局替换实体名把Linkman换成Book或Employee把Name换成BookName或EmpNamePhone换成ISBN或EmpPhone。替换完所有SQL语句里的列名同步跟进。第二调整字段边界图书题目里不需要“关系”和“生日”换成Press出版社、Price价格员工题目里加上Department部门、Salary工资。数据字典、表结构、插入语句三处同步改别只改了建表脚本忘改字典。第三补齐文档叙述把需求简介里的功能描述改成你题目的场景把ER图重画一遍把子模式名称改成你系统的菜单名。技术骨架完全不用动因为它本来就是一套标准的信息管理系统设计流程换皮不换骨。我自己的习惯是拿到这种课设模板先强制做一遍“三表对齐”检查——把数据字典、建表脚本、业务SQL放着一起扫一遍任何一个数据项在三个地方出现但定义不一致就先用红笔标出来再动手。这套流程帮我避开了不少从命名到类型不统一的暗坑。希望帮到你照着敲完一遍这份doc里的SQL就真正变成你能讲清楚的东西了。本文还有配套的精品资源点击获取