简介这是面向软件开发人员、项目经理及计算机专业学生的软件概要设计说明书范本用于解决从需求分析到详细设计之间文档缺失、结构不规范、模块划分模糊等问题。整份文档以经典模板呈现涵盖引言、范围界定、软件系统结构设计、功能需求追溯、数据设计与系统维护设计等核心章节并针对学生、教师、管理员三类角色梳理了修改密码、重修审核、成绩录入、课表管理等具体功能模块同时给出学生信息表、教师信息表、成绩表、权限表等数据项定义与模块命名规则可直接作为编写类似文档的参考框架。文档中还包含软件程序结构图、数据字典复审说明以及系统维护设计要点能够帮助读者理解系统架构从宏观到细节的完整设计思路。资源包为1个doc文件约350KB内容排版规范、便于按需编辑。目前已有117人学习下载适合需要快速产出规范概要设计说明书或系统学习软件工程文档写作的读者。1. 软件概要设计说明书一份MIS系统设计文档的门道在哪软件概要设计说明书这类文档在课程设计和中小型项目里常被当成“交差材料”其实它是需求分析与详细设计之间的桥梁。这份《软件概要设计说明书.doc》对应的是一套学生体质测试结果统计分析系统学生查成绩、提重修申请教师导入成绩、看学生反馈管理员维护用户和体测项目业务链完整但不臃肿正好覆盖了 MIS 系统概要设计要处理的全部核心问题。它解决的是“概要设计说明书每一章该写什么、写到什么粒度”这个具体疑问适合正在做课程设计、毕业设计或第一次独立交付小型管理系统的开发者拿它当骨架逐节对照着填自己的需求。2. 需求到模块边界范围界定与功能拆分的三个动作概要设计的第一步不是画架构图而是把需求规格说明书里描述的业务重新翻译成模块边界。这份文档在第二章先写系统目标再列三类角色的功能需求最后才在第三章给出模块描述和结构图。这个顺序不是模板惯性而是因为模块划分的依据必须能从需求描述里直接找到。我见过不少团队跳过范围界定直接画结构图画出来的模块树和需求对不上评审追问“这个模块承接了哪条需求”答不上来根源就是把范围这一步省掉了。2.1 先把系统目标换算成功能点四个目标对应四条业务链文档里列出的系统目标有四条办公自动化、体质测试结果资料管理、统计分析质量管理、信息综合管理。光看表述会觉得有点虚但往下读就能发现每个目标都挂了对应的功能操作。办公自动化对应的是申请、审核、建议在网络上流转资料管理对应教师用 Excel 批量导入成绩和成绩的存储统计分析质量对应学生体测结果分析、报表查询信息综合管理对应学生与教师之间的数据共享和流通。这里有一个可以照搬的检查方法把系统目标逐条抄下来在旁边写出承接它的功能模块最后检查有没有目标没有任何模块承接。用表格列出来大概是这样系统目标承接模块办公自动化学生登录系统、重修申请、提出建议、管理员重修审核体质测试结果资料管理教师登录系统、成绩录入、成绩修改、学生查询成绩统计分析质量管理学生体测结果与分析、成绩管理子系统信息综合管理学生登录系统、教师登录系统、管理员登录系统这张表做完之后目标是不是空话就很好判断。比如“统计分析质量管理”如果只有成绩查询没有分析功能这条目标就是悬空的需要在详细设计之前跟需求方确认。我自己写概要设计的时候一定先把这张目标-模块映射表填完再开始画结构图因为它本质上就是在给整个系统画功能边界边界画清楚了后面分模块、分人开发才不会有灰色地带。2.2 三类角色的功能清单从用户视角划边界这套系统的用户分三类学生、教师、管理员功能需求也按角色分了三组。学生的操作集中在个人数据和个人申请修改密码、找回密码、对老师提建议、提出重修申请、查询自己的成绩、对系统提建议。教师操作集中在成绩类修改密码、Excel 录入成绩、成绩修改、查看单个学生成绩、查看学生建议。管理员集中在维护和审核重修审核、用户信息录入与维护、体测项目增删改、查看和修改学生权限申请。这个划分有一个值得注意的边界原则谁的数据由谁维护避免多人对同一份数据有写权限。学生只能提交申请和查看结果不能直接改成绩教师可以改成绩但不能管理用户账号管理员只维护基础数据和项目定义不干预具体成绩。三个角色的权限没有交叉权限表的设计因此变得很简单。如果出现“教师既能录成绩又能改项目定义”这类交叉权限设计和数据审计都会复杂不少所以划模块时值得多问一句这个操作的写权限真的应该给这个角色吗这份文档的整体结构也体现了这个原则。学生模块和教师模块都包含密码服务但不会是各自维护一套密码逻辑而是复用同一段逻辑再按角色区分管理员模块的重修审核和学生模块的重修申请分别放在 F0304 和 F0104业务上下游的关系通过编号前缀就能区分。这种角色优先的模块划分方式对后续做菜单权限和接口权限都非常友好权限表里存角色编码角色编码决定可访问的模块前缀一套方案走到底。2.3 功能编号规则FXXYY00 看似刻板编码阶段很省事文档在 3.1.2 定义了功能编号规则开头 F 代表功能Function后两位是子系统编号再两位是一级模块编号最后两位是二级及以下模块的流水编号。整套系统里编号能具体到 F0103 学生体测结果分析、F0202 成绩管理、F0304 重修安排这种粒度。第一眼看上去像形式主义真正写代码的时候才发现它是代码检索和评审沟通的锚点。我自己的习惯是让实现类名直接吞掉这个编号比如学生模块的密码服务对应的实现类叫 F0101ServiceImpl成绩管理模块叫 F0202ServiceImpl。这样无论是 IDE 里跳转还是排查问题时看日志里的类名都能一眼定位到概要设计文档里的对应模块不用再去翻命名映射表。方法名沿用“操作_对象”的约定用 Java 写出来就是 resetPassword、updateStudent、approveReapply 这种结构// F0202 成绩管理教师按 Excel 批量导入体测成绩 Service public class F0202ServiceImpl implements F0202Service { Override public ImportResult importScores(MultipartFile excelFile, String teacherNo) { // 读取 Excel 每一行按学号匹配学生写入成绩表 // 学号不存在时记录到失败列表继续处理下一行 } Override public void updateScore(String studentNo, String itemCode, Double newScore) { // 成绩修改先记录修改前后日志再更新学生成绩表 } }参数说明excelFile 对应需求里“教师利用电子表格直接导入”的成绩文件studentNo 是学号与数据表中的主键保持一致itemCode 代表体测项目编码。updateScore 只允许教师角色调用权限控制在进入 Service 之前完成。这种编码方式唯一的代价是类名不直观但只要团队约定好“编号映射表以概要设计文档为准”检索起来反而比自然命名的类更快。这套编号和权限体系的配合也很直接。学生子系统的 F01 前缀、教师子系统的 F02 前缀、管理员子系统的 F03 前缀可以沿用到前端菜单、后端接口路径和数据库菜单表。前端路由设计成 /student/f0103/analysis、/teacher/f0202/import后端 Controller 的 RequestMapping 也照抄这个编码那么从浏览器请求到日志里的类名再到概要设计书里的模块描述全链路都能对上。对课程设计或三五人协作的小项目来说这个一致性是成本最低的沟通机制比单独维护一份接口对照表省心得多。3. 结构设计与数据设计从程序结构图到核心数据表结构设计和数据设计是概要设计的两个重头。文档在第三章给出软件体系结构、模块命名规则、模块描述在第四章完成数据字典复审和数据项定义。这两个章节不是各写各的模块描述里的输入输出最终都要落成数据表所以我习惯把两章放在一起对照着检查每张表里的字段能不能支撑前面描述过的模块操作以及模块之间的数据流向是不是清晰。3.1 程序结构图三个登录入口定全局文档把程序结构图拆成了三张学生登录系统、教师登录系统、管理员登录系统。虽然图形在文档里占的篇幅不大但从模块编号可以还原出完整结构。学生子系统 F01 下面挂了 F0101 密码服务、F0102 学生个人基本信息、F0103 学生体测结果与分析、F0104 重修申请、F0105 提出建议五个一级模块教师子系统 F02 下是 F0201 教师个人基本信息、F0202 成绩管理、F0203 查看建议管理员子系统 F03 下是 F0301 到 F0305 五个模块。这种按角色拆子系统、角色下再挂业务模块的方式对 MIS 系统来说非常稳妥。好处是权限模型可以直接跟子系统编号对齐登录后进入哪个菜单体系由用户角色决定而不是由某个业务模块决定。反过来如果按业务域拆子系统比如分成“成绩子系统”“申请子系统”“审核子系统”同一个页面里就得不断切换角色上下文权限校验容易散落得到处都是。后一种方式更适合中后台系统但规模不大的 MIS 项目用角色拆开发和测试的理解成本都低很多。3.2 模块描述表输入、输出、运行环境怎么填文档在 3.1.3 给每个模块建了一张描述表包含标识、名称、输入说明、输出说明、功能说明、运行环境和调用关系。这里最容易写废的是输入输出栏。很多初版文档里这栏只写“用户的请求”和“处理结果”等于没说。正确的写法是把关键的数据对象描述出来让读文档的人能直接判断这个模块依赖什么数据、产出什么数据。以 F0304 重修安排为例文档写的输入是“学生提交的重修申请”输出是“查看老师上课信息后分配的重修结果”。虽然简短但它指出了重要的依赖重修安排的输出依赖教师课表查询所以 F0304 必然要调用课表相关模块或数据表。模块不是孤立的依赖关系已经隐含在输入输出描述里。填模块描述表时把输入输出写具体调用关系自然浮现这也是概要设计阶段检验模块划分是否合理的实操手段。这里再补充一个字段的填写口径。“运行环境”这一栏统一写 Eclipse、MySQL 就够但必须和项目实际技术栈一致。文档中 F0301 信息数据录入模块的运行环境写着“Lotes Notes 实现”而其他模块全是 Eclipse 加 MySQL一看就是旧文档复制过来的遗留信息评审时被指出来很尴尬。像这种运行环境字段写完以后值得在全文档范围搜索一遍关键词逐条核对不能只盯着当前章节检查。3.3 数据字典复审Student_Message 核心表与字段设计数据设计部分先是数据字典复审明确学生体测结果表是整个系统的分析基础然后给出了 Student_info、Teacher_info、StudentScore_info、Authority_info 四张表的数据项。文档提到这是多人的协作项目数据字典必须提前统一口径不然各人开发的模块之间数据接口对不上。核心表 Student_Message 的字段有姓名、学号、性别、800m、1000m、跳远、50m、视力、身高、体重、握力、肺活量、仰卧起坐。这里有个设计细节值得单独说男生和女生的体测项目不一样比如男生跑 1000m、女生跑 800m所以文档明确写了“没有该项目的体测结果允许为空”。这意味着建表时这些男女差异列在设计上必须允许 NULL不能因为“成绩是必填项”就把所有列都设为 NOT NULL。对应到 SQL 就是CREATE TABLE student_message ( id BIGINT PRIMARY KEY AUTO_INCREMENT COMMENT 自增主键, student_no VARCHAR(20) NOT NULL UNIQUE COMMENT 学号, student_name VARCHAR(50) NOT NULL COMMENT 姓名, student_sex CHAR(1) COMMENT 性别: 0-未知 1-男 2-女, student_800 DECIMAL(5,2) COMMENT 800m成绩(秒), 仅女生, student_1000 DECIMAL(5,2) COMMENT 1000m成绩(秒), 仅男生, student_jump DECIMAL(5,2) COMMENT 跳远成绩(厘米), student_50 DECIMAL(5,2) COMMENT 50m成绩(秒), student_eyesight DECIMAL(4,2) COMMENT 视力, student_height DECIMAL(5,2) COMMENT 身高(cm), student_weight DECIMAL(5,2) COMMENT 体重(kg), student_grip DECIMAL(5,2) COMMENT 握力(kg), student_lungs DECIMAL(6,2) COMMENT 肺活量(ml), student_situp INT COMMENT 仰卧起坐(个), create_time DATETIME DEFAULT CURRENT_TIMESTAMP COMMENT 创建时间 ) COMMENT 学生体测结果表;逻辑说明student_no 建唯一约束是为了满足“一个学生只能有一个 ID”的需求student_sex 用 CHAR(1) 而不是数字类型便于数据展示和接口对接允许为空的列都是男女项目差异列这是文档特别说明过的设计决策。主键用自增 id 而不是学号是因为学号属于业务键一旦出现学号调整或者学生转学直接用学号做主键会让所有关联表都很被动。业务上还有个容易忽略的校验点性别和体测项目的关联在写入和统计时需要放在同一处校验否则可能出现女生填了 1000m 成绩的脏数据。常见做法是在 Service 层维护一个性别-项目映射表写成绩前先判断项目是否适用于该性别。这种校验如果只在页面端做绕过前端直接调接口就会出现脏数据到时候统计报表里出现不该有的数据排查起来比多做一次校验麻烦得多。3.4 四张辅助表的角色定位与冗余取舍Student_info 存学生基础信息Teacher_info 存教师基础信息StudentScore_info 存成绩数据Authority_info 存权限。这里有一个数据冗余的取舍Student_Message 里既有学生姓名又有体测结果实际实现时最好让 Student_info 作为学生基础信息的唯一来源Student_Message 只存学号和体测结果姓名等其他信息通过学号关联查询。否则两处都维护姓名教师改完一个模块另一个模块不同步数据对不上又是一轮排查。权限表 Authority_info 建议把角色编码和模块编号关联起来比如角色 STUDENT 可访问 F01 前缀的所有模块TEACHER 可访问 F02ADMIN 可访问 F03这样接口鉴权时只需要比对前缀不需要为每个接口单独配置权限码。这种设计在课程设计和中小型项目里足够用如果权限粒度需要细化到单个操作再在模块编号末尾追加流水位就行前面说的 F010101 这种扩展方式能直接接上。4. 从文档到代码EclipseMySQL 环境下的落地路径概要设计文档最终要喂给详细设计和编码。以这份系统为例技术栈是 Eclipse 加 MySQL典型的小型 Java Web 项目。从文档到代码最值得优先做的是三件事把模块标识映射成接口路径把默认密码规则落进初始化代码把 Excel 导入的边界条件想清楚。这三件事做完文档的价值就从纸面变成了代码骨架后面接详细设计的人不至于对着文档还要猜接口怎么定。4.1 从模块标识到 REST Controller 的映射每个功能编号都可以映射成一个接口组。以 F0103 学生体测结果与分析为例接口路径设计成 /student/f0103/analysisController 的 RequestMapping 直接拿模块编号当路径前缀既省去单独维护接口字典又能在出问题时顺着路径找到对应模块。代码大概是RestController RequestMapping(/student/f0103) public class StudentBodyResultController { GetMapping(/analysis) public ResultAnalysisVO analysis(RequestParam String studentNo) { // 查询学生某次体测的成绩、项目得分与趋势分析 } }逻辑说明/student/f0103 中的 f0103 就是概要设计文档里的模块标识analysis 对应文档中的分析功能studentNo 是学号参数。这样拿着概要设计书就能在代码里逐项找到对应实现。唯一的坑是如果项目里同时存在旧接口和新接口的迁移编号前缀尽量保持稳定不要换了模块编号却忘了改路由导致文档和代码对不上。这种映射方式对多人协作特别友好。A 同学做 F01 学生模块B 同学做 F02 教师模块接口文档上写“F0202 成绩管理”两人都知道该去哪个目录找代码。评审的时候拿着一份设计文档就能点对点核对实现不用再让程序员口头解释这个类对应那个需求沟通效率会明显不一样。4.2 登录流程与默认密码的落点文档里写得很清楚学生第一次登录默认密码同学号教师默认密码同工号建议登录后修改忘记密码走邮箱验证找回。落地时最应该注意的是“默认密码同学号”不是把明文存进数据库而是用统一的哈希算法处理后再入库校验时用匹配接口比对。很多课程设计项目在这里翻车把默认密码明文放在数据库里一旦被抽查到安全问题整改起来又是半天时间。我一般会在初始化用户数据的脚本里统一处理默认密码加密逻辑写进一次性初始化工具类不在运行时反复判断“密码是不是学号初始密码”。这样登录逻辑只有一套默认密码只是数据初始化时的一次性状态。邮箱找回密码的功能至少要预留两步生成带令牌的重置链接以及重置后让旧密码立即失效否则找回接口容易成为账户被篡改的入口这一点在概要设计阶段可能看不出问题编码时一定要守住。4.3 Excel 导入成绩的解析边界教师模块用电子表格导入成绩这个需求看起来简单真正的复杂度都在边界里。字段顺序、表头命名、学号不存在、成绩超界、重复导入这些情况都要在解析层处理掉。概要设计文档没有展开这些异常但编码时必须有。我一般让 Excel 模板的列名与 Student_Message 的字段名保持一致解析时逐列校验并把错误逐行返回给前端import re field_map { 学号: student_no, 800m: student_800, 1000m: student_1000, 跳远: student_jump, 50m: student_50 } def validate_row(row): errors [] student_no str(row.get(学号, )).strip() if not re.fullmatch(r\d{8,12}, student_no): errors.append(学号格式非法: %s % student_no) for cn_name, field in field_map.items(): val row.get(cn_name) if val not in (None, ): try: float(val) except ValueError: errors.append(%s 不是数字: %s % (cn_name, val)) return errors逻辑说明函数接收 Excel 解析后的一行数据先校验学号是否满足 8 到 12 位数字再逐列尝试转成浮点数任何一步失败都把错误原因收集起来。接口返回时把这些错误逐行反馈给教师而不是导入完只说一句“部分失败”。有几百条数据的 Excel 导入失败原因必须对应到行教师才能回原表定位修改否则就是让用户对着空白错误提示干瞪眼。参数说明row 是 Excel 表头映射后的字典field_map 是中文表头到数据库字段名的对照表。表头不是固定的不同年份的体测表头可能带空格或年份后缀解析前先做表头清洗再走校验。导出的错误列表建议带上 Excel 行号方便老师直接跳到对应行修改这是那些专业导入工具都在做的事情没必要在这个环节偷懒。4.4 事务与幂等的边界成绩录入和修改类操作要考虑事务边界。批量导入成绩时如果第 50 行失败而前面 49 行已经写库那到底是部分成功还是全部回滚需要和业务方提前确认。文档没有写但这类问题在编码前不定好测试阶段就会出现“我明明导入成功了两行为什么另外一行不见了”的争议。常规做法是 Excel 导入采用全量校验、分批写入的模式先校验所有行返回错误清单用户修正后再导入这样写入阶段就很少出现半截失败。如果把校验和写入混在一次循环里做一旦中间抛异常事务一回滚用户就得从头再来。5. 概要设计避坑实录五处翻车现场与排查方法这一章把文档里那些容易被忽略的问题逐个过一遍。都是实际出现过的现象每条按要说的现象、原因、解决三步拆开方便你对照自己的文档做检查。很多问题看起来都是小错但评审时被指出来整个文档的专业度会大打折扣。5.1 管理员模块编号错位整章小标题全部串号现象文档里管理员模块下面出现“2.2.2.1 重修审核”按层级关系管理员模块是 2.2.3它的子模块编号应该是 2.2.3.1而不是 2.2.2.1。目录里这段结构整体是串着的。原因多半是从教师模块段落复制过来后只改了标题文字忘了改编号。Word 文档在结构修改后没有同步更新标题编号最容易出现这种问题尤其是整节复制粘贴再做局部修改的场景。解决交稿前先更新目录域再手工抽查每个一级章节下的子标题编号是否连续。更稳妥的办法是用 Word 的导航窗格按标题层级走一遍看到同一级下出现两个同层编号基本就能定位这种问题。编码阶段如果发现设计文档编号和实际模块对不上也值得回头改文档不要将错就错。5.2 模块表 Lotes Notes 乱入运行环境前后矛盾现象F0301 信息数据录入模块的运行环境写着“用 Lotes Notes 实现”其他所有模块都是 Eclipse 和 MySQL前后技术栈完全不搭。原因这是从旧文档直接复制模块描述表留下的痕迹最容易被忽略的就是运行环境这一栏。复制表格时其他栏目都改了只有运行环境没改这种错误在多人协作文档里特别常见。解决全局搜索“运行环境”“Lotes”“Eclipse”关键词把模块表里的技术栈和项目实际选型逐一核对。这类错误本身不难改难的是愿意回头逐张表检查建议在进入详细设计前做一次统一排查而不是等编码时被测试人员问“这个模块到底用什么技术实现”。5.3 数据字典只有字段名没有类型和约束现象4.1 数据字典复审里列出了 Student_Message 的字段清单但整份文档没有字段类型、长度和空值约束详细设计阶段还得回头补。原因概要设计阶段常只梳理字段清单把类型定义推迟到详细设计。但如果连类型都不提模块间的数据接口就无法确认两个人各写一个模块同一个“身高”字段一个人存厘米一个人存米最后数据对不上又是血泪教训。解决至少把主键、唯一键、允许空值的字段标记出来类型可以后补但约束语义必须先定。我给数据字典加一列“约束说明”哪怕只写“唯一”“允许空”“0-未知 1-男 2-女”这种简短描述也比什么都没有强。如果嫌表格太宽把约束说明单独合并成一段跟在字段表后面也行。5.4 功能编号规则停在模块级二级流水号悬空现象编号规则写的是 F 加两位子系统加两位模块加两位流水但文档中实际出现的 F0101、F0202 都只到模块级没有二级模块的编号示例。如果后续要拆分“修改密码”和“找回密码”两个子功能编号就断档了后面的人不知道怎么往下编。原因规则只定义了格式没有定义扩展时的追加方式。文档的编写者当时可能只想到了模块级没考虑到二级子功能也要编号。解决约定二级模块在末尾追加两位数字F010101 表示 F0101 下的修改密码F010102 表示找回密码。编码阶段按这个扩展规则往下走整套系统就不需要第二套编号前端菜单和后端接口也能直接沿用。5.5 追溯矩阵只有单向模块到需求是断开的现象3.2 功能需求追溯矩阵里三条系统级需求对模块的勾选还算完整但没有反过来做“每个模块对应哪条需求”的映射评审时很难快速确认某个模块是不是多余的。原因文档在概要设计阶段只做了正向覆盖忽略了反向验证。正向矩阵能回答“需求有没有被覆盖”回答不了“每个模块是不是都有需求依据”后一个问题恰恰容易暴露拍脑袋加出来的功能。解决用代码差集会非常快。把需求清单和模块清单分别提取出来做双向差集缺失项一目了然。具体做法下一章展开几分钟就能跑一遍比人工翻文档靠谱得多。6. 用追溯矩阵反向校验一个脚本找出漏掉的模块前面讲到功能需求追溯矩阵很容易只画了正向覆盖。我从某个项目之后养成了一个习惯拿到任何一份概要设计先写十几行脚本做差集检查。思路很简单从文档全文里用正则把 F0 开头的模块标识都提出来再对照人工整理的需求-模块映射表找出那些“需求里写了、文档里却找不到模块编号”的空洞。6.1 模块编号差集检查脚本以这份学生体质测试系统为例需求清单里有三条核心需求学生登录、教师成绩管理、管理员重修审核。手动把它们和模块编号对应起来后跑下面这个脚本import re # 需求编号 - 应覆盖的模块编号 req_module_map { REQ-STU-LOGIN: [F0101, F0102, F0103, F0104, F0105], REQ-TEA-SCORE: [F0201, F0202, F0203], REQ-ADM-REVIEW: [F0301, F0304], } doc_text open(design.txt, encodingutf-8).read() existing set(re.findall(rF0\d{3}, doc_text)) for req, expect_list in req_module_map.items(): missing [m for m in expect_list if m not in existing] if missing: print(f[缺失] {req} 未出现的模块: {missing}) else: print(f[OK] {req} 所有模块已出现)逻辑说明design.txt 是 .doc 转纯文本后的文件正则 rF0\d{3} 会匹配 F0101、F0202 这类编号。把期望清单和实际出现的编号集合取差集缺失项一般对应章节没写完、模块表漏掉或者编号改过但标识没同步。这个检查很适合做评审前的自动巡检比肉眼翻目录快得多。参数说明req_module_map 的键是需求编号值是应覆盖的模块编号列表正则限定为 F0 开头避免误匹配需求文档里偶然出现的相似字符串。如果你系统的编号前缀不同改成对应前缀即可比如换成 M01、M02 就把正则改成 M0\d{3}。6.2 顺带检查接口路径一致性这个脚本稍作扩展还能用来检查接口路径。接口文档里出现 /student/f0103说明对应 Controller 已经写了设计文档里有 F0103 但代码里搜不到 /f0103要么是新模块没开工要么是有人改了路径没同步设计文档。从那以后我每次评审概要设计都会强制走一遍这个差集脚本再决定要不要往下看细节。很多时候以为文档缺了章节其实是某张模块表的标识和规则没对齐脚本一跑就水落石出。希望这个习惯也帮到你。本文还有配套的精品资源点击获取