企业官网建设流程全解析

简介：面向软件项目需求分析与文档编写的SRS模板，适合产品经理、需求分析师、项目经理及计算机专业学生参考，用于解决需求文档章节不统一、描述粒度模糊、评审签署流程缺失等问题。压缩包内仅1个doc文件，约1.34MB，是一份26页的Word版需求规格说明书范本，替换项目名称与单位信息即可套用。目录结构完整，依次覆盖引言（编写目的、需求分析理论、分析目标、参考文献）、需求概述（项目背景、条件与限制、系统结构与网络拓扑图）、系统功能需求、软硬件及外部系统接口需求等章节，并附版本更新记录表与项目负责人审核确认签字栏。已有1125人学习下载。读者可获得可直接复用的章节框架，学习移动办公、车辆管理、电子公文预览等模块的功能拆分方式，参考界面元素、审批流程的需求描述粒度，并借鉴版本管理与评审确认的组织方法，减少从零起草文档的时间。

1. 从一句「需求文档在哪」说起：26 页 SRS 模板要挡掉的三类返工

互联网团队做移动办公、车辆管理这类系统，最常见的开场不是画架构图，而是被追问一句「需求文档在哪」。这份 26 页的软件需求规格说明书模板，把引言、需求概述、系统功能需求、接口需求、非功能需求五章定成固定骨架，每个小节都留了可填的占位和写法示例——从移动办公的待办公文列表，到车辆管理的「一车一档」，再到电子公文预览的中间层组件。它要解决的核心问题是“写出来没法验收”：界面元素漏一项、附件阈值差一个数量级、接口需求整章留空，后面就是成片的返工。准备写毕设需求章节、交课程设计文档，或者第一次独立承担需求评审的人，都可以拿它当底稿。

2. 文档骨架设计：五章结构、三张管理表与可复用的占位符

2.1 五章骨架各自要交付什么

很多人拿到 SRS 模板，第一反应是逐条填字，结果填出来的文档像教科书摘抄。要避免这件事，先要弄清每章在项目里承担什么职责，而不是它写了什么标题。

引言这一章看起来最“虚”，实际是给评审人一个判断依据。编写目的通常就三句话：明确软件需求、安排项目规划与进度、组织软件开发与测试。软件需求分析理论和分析目标这两节的意义在于为后面的变更流程做铺垫——需求分析错误导致的缺陷占比极高，而且往往演变成根本性的功能问题，所以后面任何需求变更都必须走版本记录。参考文献一节列 8 条左右，覆盖软件工程基础、需求工程方法、电子政务系统规划与建设三类即可，作用是把文档的判断依据指向可查资料，而不是个人经验。

需求概述章要交付的是范围。项目背景、需求概述、条件与限制、系统结构、网络拓扑图五节，前者回答“为什么做”，后者回答“做到哪、被什么卡住”。这一章写不实，后面三章再详细都无法防止范围蔓延。

系统功能需求章是篇幅最大的一章，交付物是可核对的模块清单，写法上要细到界面元素和排序规则，后面的 4.1 到 4.3 会专门拆。

接口需求章容易被当成技术细节推给开发，但恰恰是需求阶段必须固定下来的边界：用户界面、硬件需求、网络需求、接口需求、通信需求、运行环境六项，缺一项都会在联调阶段集中爆发。

非功能需求章交付的是可测指标。性能、安全设施、安全性、扩展性、可移植性五项，如果只写“响应快、安全可靠”，等于没写。

五章之间有一条隐含的追踪关系：概述章定范围，功能章填内容，接口章定边界，非功能章定质量门槛，最后所有条目都要能被验证。评审时被问到“这条需求怎么测”，答不上来的条目通常就出自非功能章和接口章。

2.2 版本更新表与审核确认栏：文档的后悔药

模板第 2 页的版本更新表，列是版本号、时间、更新人、更新摘要。示例里三行分别是：V1.0 加入移动办公与车辆管理模块需求，V1.1 加入信息发布平台需求，V1.2 根据业务需要加入电子公文在线预览。这张表如果只更新自己，就是摆设。

实际项目里我一般会加一列「影响章节」，把每次更新落到具体章节号上。原因很直接：V1.2 加了电子公文预览，功能章多了中间层组件，接口章要补文件流返回格式，非功能章要补预览响应时间——如果版本表里只写一句摘要，三个月后没人知道哪些章节是旧的。

审核确认栏一般分供应商与客户方两栏，字段为姓名、职位、审核时间、审核意见、签字。这里有个容易糊弄的地方：签字栏空着，文档就被当成“已完成”。规范做法是每轮评审后当天补签，审核意见写具体到章节的修改要求，而不是“同意”。签字意味着后面提变更要走流程，这一栏空着，等于告诉所有人这份文档随时可以改。

2.3 用目录和占位符把骨架变成可复用工程

五章结构固定下来后，最省事的做法不是每次从模板复制一份 Word 再删改，而是按章拆文件，多人并行填写，合并时用版本对比看差异。

# 按五章骨架生成可并行填写的目录，一章一文件 mkdir -p srs/{01-intro,02-overview,03-function,04-interface,05-nfr,assets} # 每章一个 Markdown 文件，文件名带章节号，合并时天然有序 touch srs/00-cover.md # 封面、文档ID、版本更新表、审核确认栏 touch srs/01-intro.md # 编写目的、分析理论、分析目标、参考文献 touch srs/02-overview.md # 项目背景、需求概述、条件与限制、系统结构、拓扑 touch srs/03-function.md # 各业务模块的功能需求 touch srs/04-interface.md # 用户界面、硬件、网络、接口、通信、运行环境 touch srs/05-nfr.md # 性能、安全设施、安全性、扩展性、可移植性 # 统一占位符命名，避免出现「XXX」「待补」这类无法批量检索的写法 grep -rn '{{.*}}' srs/ | sort # 列出所有未填占位符，评审前必须清零

这段脚本的作用是把“文档”变成“可并行施工的工程”。srs/是根目录，01到05的编号与五章一一对应，assets/放拓扑图和结构图，00-cover.md存放封面与两张管理表。占位符统一成{{项目名称}}、{{单位名称}}、{{文档ID}}、{{模块名称}}这种双花括号形式，好处是能用一条grep把所有未填项列出来。评审前跑一遍，比人工翻 26 页可靠得多。

参数上要注意两点：文件名前缀用两位数，避免 10 和 2 排序错乱；占位符内不要出现空格，替换脚本才好匹配。图表不要直接贴进正文，放assets/并在正文用相对路径引用，后面对图做调整不会打乱正文结构。

提示：拆分文件后，版本更新表里的「影响章节」正好和文件名对应，改动一章就在表里记一行，比在单文件里翻找可靠。

3. 需求概述与系统结构：四层安全控制域、网络拓扑与条件限制

3.1 项目背景：从 4A 目标反推范围边界

模板里的项目背景示例写得很实。它的写法不是抒情，而是先用一句业务目标：把各类信息准确、快速、安全地发布到指定移动终端，同时解决管理人员外出时批阅公文、收发邮件、查询通讯录的问题。然后落到具体目标——4A，即任意地点、任意时间、任意数据、任意设备都能办公。

这个写法值得照搬的地方在于：它先给了一个可检验的目标，再谈技术。4A 本身就是范围边界，比如“任意设备”对应的是多终端适配，“任意数据”对应的是公文、邮件、通讯录这几类数据，而不是所有数据。

项目背景写完之后，紧接着要写“本期不做什么”。这一点模板原文没有明说，但按这个场景合格负责人的做法，通常会在需求概述一节补一句范围说明：本期只做移动端适配与展现，不改动办公系统核心流程与审批规则，车辆管理只做档案与流程申请，不做财务结算。这句话看着像限制，实际是后面抵御“顺手再加个功能”的依据。血泪经验是：范围没写清的项目，需求评审会开成新功能发布会。

条件与限制一节需要单独强调，因为它是需求阶段唯一能提前暴露外部风险的地方。模板列了七类：输入数据的范围与格式、软件环境与硬件环境、必须使用或避免的特定技术工具语言数据库、企业策略与行业标准、硬件限制如定时需求和存储限制、经费与工期、对外部组件的依赖。这七条在评审前逐条填一遍，能挡掉后期很大一部分“这个做不了”。

3.2 四层安全控制域的职责划分

系统结构这一节，模板给的写法是把系统划成四层安全控制域，每层按自身工作特点设计安全措施。这四层分别是：

终端用户层：面向各类手机终端提供展现层，用户通过安装客户端程序使用。职责是界面渲染、本地缓存、终端适配，不负责业务规则判断。

运营商服务层：提供无线网络环境，覆盖多种制式的移动网络与无线局域网。这一层的关键细节是接入点——通常要同时支持两种接入方式，因为不同接入方式在地址分配和访问路径上不一样，只写“支持移动网络”会在真机联调时翻车。

业务逻辑层：核心处理层，承担与外部业务系统、手机终端之间的数据请求处理，包括基础服务支撑、业务解析运行引擎、终端访问安全管理、通用组件和系统管理功能。这一层是需求描述的重点，也是唯一适合写“适配逻辑”的地方。

外部系统层：与外部接入系统对接的适配层，主要是办公自动化系统及其他业务应用。这一层的需求要写清“调用谁、用什么协议、失败怎么办”，而不是只画一个框。

四层划分的价值不只是画图好看，它让需求条目有了归属。比如“审批意见支持多级联动选择”属于业务逻辑层，“公文正文格式支持三种类型”属于终端用户层的展现约束，“新终端接入不改核心逻辑”属于扩展性要求。层次一清楚，写需求时不容易把展现规则和业务规则混在一起。

注意：分层结构的每一层都要写“不负责什么”。只写职责不写边界，评审时一定会有人问“这层能不能顺便处理一下”。

3.3 网络拓扑三分法与条件限制清单

模板里的拓扑图按三个部分来描述：终端侧是发起网络请求的终端设备和软件，网络侧是运营商网络，机房侧是承载业务系统与管理设备的服务器。

三分法的好处是每一侧都能单独列安全措施和依赖项。终端侧要考虑客户端版本兼容和本地数据留存策略；网络侧要考虑接入方式、带宽波动和地址规划；机房侧要考虑服务器部署位置、与办公系统是否同网段、是否经过安全设备。

一个实际案例可以说明拓扑写清的价值：车辆管理模块的拓扑里明确写了车辆管理服务器与办公系统服务器部署在同一局域网内，通过系统接口实现统一登录认证。这句话看着平淡，但它同时确定了三件事——部署位置、网络可达性、认证方式。如果需求阶段没写，实施时很可能被部署到另一个网段，然后统一登录认证这条需求整条作废。

条件与限制可以做成一张检查表，逐项写“是/否/待确认+责任人+时间”：

3.4 外部接口边界：六项清单一页纸填满

接口需求虽然单独成章，但它的边界判断在概述阶段就要完成。模板给出六项：用户界面、硬件需求、网络需求、接口需求、通信需求、运行环境。

用户界面的写法不是“界面美观”，而是列出必须遵守的界面约定，比如列表采用两行显示、第一行放什么、第二行放什么。硬件需求写终端与服务器的最低配置。网络需求写带宽、接入方式、是否支持内外网切换。接口需求写清与哪些外部系统交互、数据流向、调用方式。通信需求写协议、频率、超时与重试。运行环境写操作系统、中间件、数据库版本区间。

六项里最容易留空的是通信需求，而它恰恰是联调阶段最容易出问题的地方。一份合格的写法会写明：请求超时时间、失败重试次数、失败后的用户可见提示，以及是否需要离线缓存。这三行字能省掉后面几天的扯皮。

4. 功能与非功能需求：模块级拆解、界面元素与可测指标

4.1 功能点表的“模块—功能—界面元素”三列法

功能需求最常见的失败是写成功能列表：登录、收文审批、发文审批、会议管理、通讯录……看起来齐全，实际每一条都无法验收。

按这个场景我一般用三列法：模块、功能、界面元素与规则。第一列是业务模块，第二列是该模块下的功能点，第三列写这个功能点落到界面上必须出现的元素、排序方式、交互规则和异常处理。

这张表的第三列是关键。它把“功能”翻译成了可验收的断言：列表是不是两行、字段是不是这些、树形是不是只按部门分类。开发照着做不会跑偏，测试照着写用例也不用再问。

写第三列有个技巧：凡是涉及“展示”的，一定写清字段清单和顺序；凡是涉及“操作”的，一定写清触发条件、结果和失败提示。只写“支持查看详情”，等于把决定权交给了开发。

4.2 排序与展示规则写成可验证的条目

列表类需求最容易出问题的地方是排序。模板里有几处写法可以直接借用：

待办公文列表的排序写了三种依据：按业务种类、按速级、按接收时间。速级分特急、急件、平件三种。这里必须补一句优先级——三种依据同时存在时谁优先。规范写法是明确“先按速级，再按接收时间倒序，业务种类作为分组依据”，否则同一批数据在不同实现下顺序不同，验收时双方各执一词。

会议列表的写法更细：列表包含内部会议和外出会议，对所有用户可见，不做权限过滤；两行显示，第一行会议标题，第二行会议时间和地点；只按会议时间由新到旧排序，默认只展示一周，支持查询上周与下周。这段话里每个短句都是可测的。

通知通告列表同理：两行显示，第一行标题，第二行发布时间，按发布时间由新到旧。

这些规则的共同点是都不长，但每一句都能直接变成测试用例：默认展示范围是不是一周、能不能查到上周、无权限用户能不能看到会议列表。反过来说，凡是写成“列表展示相关信息、按需排序”的条目，验收时一定会吵。

提示：排序规则写完，顺手补一句“数据为空时展示什么”。空态是最容易被漏掉、又最容易被用户第一时间看到的界面。

4.3 阈值、格式白名单与降级路径

模板里有一处写得非常到位，值得单独拿出来当范式：公文正文的文件类型为三种固定格式，公文附件类型不限制，其中办公文档、图片、特定扫描格式可直接在手机端浏览；超过 5M 的文件提供下载但不支持在手机端直接预览。

这三句话构成了完整的三段式：允许什么、能预览什么、超限怎么降级。

第一段是白名单，明确可处理的格式，而不是“支持常见格式”。第二段是能力边界，明确哪些能在线看。第三段是降级路径，明确了阈值和降级后的行为。

按这个范式，任何涉及文件的条目都可以照着写：允许上传的格式清单、单个文件大小上限、总量上限、超限时是拒绝还是转下载、下载失败提示什么。附件阈值这种地方最容易出现差一个数量级的事故——需求写 5M，开发按 50M 实现，测试按 5M 测，上线后用户传 20M 文件直接卡死客户端。

同理，意见录入这条需求也值得照抄：用户可直接输入意见或从常用词条中选择，词条分公用和个人两类；审批意见发送时先选环节，环节顺序与办公系统一致；当需要选择多个下一环节时，通过多级下拉联动实现，上一级选定后下一级自动过滤不可选项或自动选中必选项；当发送至默认环节默认人员时，不再出现环节和人员选择界面，直接发送。

这段描述的价值在于把“智能”写成了规则：多级联动、自动过滤、自动选中、满足条件时跳过界面。三条规则都能测，也都能实现。反过来，如果只写“支持灵活选择审批环节”，开发和测试都要靠猜。

4.4 中间层组件与接口适配需求

电子公文预览是这份模板里设计思路最完整的一段，值得作为“跨系统需求怎么写”的样例。

它的原则是先定约束：对电子公文交换平台和现有移动办公系统做最小改动。在这个约束下，方案是在两个系统之间搭一个中间层组件，承担三件事：把移动办公访问电子公文的请求重定向到中间层；把交换平台中的电子公文转换成移动办公能识别的格式，一般为扫描件格式；把转换后的文件以文件流形式返回到移动终端显示。

三件事对应三条需求，每条都能独立验收：重定向是否覆盖全部公文访问入口、格式转换的成功率和耗时、文件流返回的格式与大小限制。这种写法比“实现公文在线预览”有用得多。

交换网络的结构描述同样值得借鉴，它按组件职责拆成五部分：办公系统侧的交换子系统负责收发文与相关子服务；前置服务负责数据传输，一端对接交换子系统，另一端通过消息队列和接口服务对接；交换接口保护核心不被暴露并分担网络压力；交换核心提供路由、单位与人员管理、跟踪、指令分析应答、数据分解合并、传输以及加解密与签名验证；认证系统只与核心相连，所有通信都经交换网络传送。

流程则拆成五步加两类回执：生成交换对象并签名加密、前置按同步或异步选择通道提交、核心分析路由并分发给各接收单位、接口转发到目标前置、目标侧解析入库；送达回执确认对方收到，解析入库回执确认对方能看到，任一环节失败由上一环节反向发送失败回执。

这套写法的精髓是把“系统之间怎么配合”写成了可追踪的链路：每一步有输入、有输出、有失败处理。做毕设或课程设计时，如果题目涉及系统对接，照这个结构写，评阅人一眼能看出你想清楚了。

4.5 非功能需求的量化：性能、安全、扩展性、可移植性

非功能需求章在模板里只有五个小节标题，具体指标要自己填。填法遵循一个原则：每条都要能被测量。

性能需求至少写三项：并发用户数、关键操作响应时间、批量数据处理的时限。写法示例：待办公文列表首屏加载在正常网络下不超过约定秒数，公文详情打开不超过约定秒数，附件下载按文件大小分档给出预期耗时。

安全设施需求写清用了什么机制、保护什么对象。模板背景里提到的认证体系、加密通道、专用接入方式都属于这一类，需求里要落到“哪些数据必须走加密通道、哪些操作必须二次认证”。

安全性需求写权限模型：普通用户按权限分级看到不同内容，管理员按权限获得不同操作授权；通讯录在人员新增、删除、修改、调动时与源系统保持一致，管理员可在管理端启用或停用用户。这几条都是可验证的。

扩展性需求写“新增一类终端或一类业务时，需要改动哪些层、不需要改动哪些层”。合格写法是：新增终端适配只改终端层与适配配置，不改业务逻辑层。可移植性需求写运行环境的版本区间和依赖组件清单，避免上线时发现中间件版本不匹配。

4.6 需求条目化：给每条需求一个可追踪的 ID

文档写到这个程度，条目数量已经不少，靠章节号追踪会失控。通常的做法是给每条需求一个稳定 ID，并用结构化格式管理。

# 需求条目示例：一条需求 = 一个 ID + 归属章节 + 验收方式 - id: REQ-FUNC-013 chapter: 3.1.2 # 对应功能需求章待办公文列表一节 title: 待办公文列表展示与排序 desc: 列表两行显示，第一行速级图标/业务种类/接收时间，第二行公文标题 rules: - 排序优先级：速级 > 接收时间倒序 > 业务种类分组 - 速级取值：特急 / 急件 / 平件 accept: 构造三类速级各 3 条数据，核对首屏顺序与两行内容 owner: 需求负责人 status: confirmed - id: REQ-NFR-004 chapter: 4.1 # 对应非功能需求章性能一节 title: 公文详情打开耗时 desc: 正常网络条件下，详情页从点击到内容渲染完成不超过约定秒数 accept: 弱网与正常网络各测 20 次，取分位值 owner: 需求负责人 status: pending # 未定指标，评审前必须清零

这份 YAML 的结构说明：id用“类型-序号”命名，类型分功能、接口、非功能三类，序号三位数补零便于排序；chapter指向正文章节，保证文档和条目双向可查；desc写一句可执行描述，不写形容词；rules放展示与排序这类细节；accept写验收方法，这一项空着的条目不允许进入评审；status只有 confirmed 和 pending 两种，pending 就是待办。

用它的好处很直接：评审时按status: pending过滤，剩下的就是需要拍板的事项；测试阶段按accept字段直接生成用例；变更时只改条目，再回头同步章节，不会漏。参数上要注意chapter必须和正文编号一致，改章节号要同步改条目，否则追踪链断掉。

5. 常见问题与排查：需求文档评审现场最容易翻车的五个点

5.1 需求条目写成形容词，验收时无从下手

现象：文档里出现“界面友好”“响应迅速”“操作便捷”“安全可靠”这类描述，评审时没人反对，开发阶段没人知道怎么做，验收阶段双方各说各话。

原因：写文档的人把需求当成了立项汇报，写的是愿景不是约束。另一层原因是需求提出方本身也说不出具体数值，写作者为了避免追问，用了模糊词糊过去。

解决：把所有形容词替换成“对象 + 指标 + 测量方式”。响应迅速改成“列表首屏在正常网络下不超过约定秒数，弱网下不超过约定秒数并给出加载提示”；界面友好改成具体的字段顺序、行高、每行展示内容。改不动的条目，说明需求本身还没想清楚，标成待确认并挂责任人和时间，不要留在正文里充当已完成。

5.2 版本表更新了，正文没跟着改

现象：V1.2 明确写了新增电子公文在线预览，但接口需求章还是 V1.0 的内容，没有文件流返回格式，非功能章也没有预览耗时指标。评审时被问到，才发现三章内容对不上。

原因：版本表被当成“改了什么”的备忘录，而不是“哪些章节受影响”的索引。多人协作时，改功能章的人和改接口章的人不是同一个，没人负责串联。

解决：版本表加「影响章节」列，每次更新必须填章节号；合并文档时先按这一列逐章核对。更彻底的做法是把章节号和文件目录绑定，改哪章就在提交记录里带上章节号，评审前用一条检索把所有待同步章节列出来。

5.3 界面元素漏项，上线后返工改版

现象：待办公文列表需求只写了“展示公文列表”，没写两行显示、没写第一行放速级和业务种类、没写排序优先级。开发按自己的理解做了一版，验收时需求方说“不是这样”，改版连带影响详情页跳转逻辑。

原因：写作者默认“大家脑子里想的一样”。列表类界面看着简单，实际上字段、顺序、行数、空态、排序五个维度都要定，任何一个没定就会返工。

解决：所有列表类需求强制填五项：每行展示什么、共几行、默认排序、空态展示、点击后的跳转。详情类需求强制填字段清单和字段来源系统。填不满的，说明还没到能开发的阶段。

5.4 附件阈值和格式只写“支持常见格式”

现象：需求写“支持常见格式附件上传与预览”，开发实现了图片和办公文档，测试用扫描件格式一测就打不开；阈值也没定，用户上传大文件后客户端直接卡死。

原因：格式和大小是最容易被当成“技术细节”跳过的地方，写作者以为开发会按惯例处理，开发以为需求方没要求就是随便。

解决：按三段式写死——允许格式白名单、可在线预览的格式子集、超限后的降级路径。降级路径必须包含阈值数值、降级后的行为是拒绝还是转下载、下载失败给用户什么提示。三条写全，后面基本不会再因为这个模块返工。

5.5 接口需求整章留空，联调阶段集中爆发

现象：文档前四章写得很满，接口需求章只有六个小标题，下面全是空的。开发按自己的理解对接，联调时发现协议不一致、超时时间没定、失败重试策略两边都不一样，联调窗口被拖长一倍。

原因：普遍认为接口是设计阶段的事，需求阶段写清楚属于越界。但接口的“有无”和“方向”属于需求，“怎么实现”才属于设计。把整章推给设计阶段，等于把风险推后。

解决：六项清单逐项填，填不了的写“待确认 + 责任人 + 确认时间”，不允许留空。重点填三项：与哪些外部系统交互、数据流向是单向还是双向、失败时的用户可见行为。这三项定了，联调阶段大部分争议不会发生。

6. 验收与答辩：用一张需求追踪矩阵自证文档不是抄的

文档写完不等于能交。评审和答辩现场真正会被追问的，是三个问题：这条需求谁提的、怎么验证、改了会影响哪些章节。能答上来，说明文档是长在项目上的；答不上来，再厚也只是模板填空。

我一般会先做一张需求追踪矩阵，把每条需求从来源到验收串成一行：

矩阵填完，把「实现落点」为空的行挑出来，这些就是需求里没想清楚的部分；把「验收方式」为空的行挑出来，这些是答辩时最容易被问倒的部分。

答辩前还有一轮自查，通常按四步走。第一步，跑一遍占位符检索，确认没有遗留的待填项。第二步，核对版本表的影响章节列，逐章确认内容已同步。第三步，随机抽五条功能需求，现场演示对应的界面元素和排序规则，演示不出来的回文档补。第四步，抽三条非功能需求，说明测量方法，说不出来的改成可测表述。这四步走完，文档的完整性和一致性基本站得住。

答辩时有个细节很加分：主动说明本期范围边界，也就是哪些不做、为什么不做。评审人往往更在意边界清不清楚，而不是功能多不多。把“本期只做移动端适配与展现，不改动核心审批流程”这句话讲明白，比多列十个功能更能体现你想过。

从那以后我每次交需求文档前，都会强制走一遍追踪矩阵和占位符检索这两步，哪怕时间再紧也不跳过。翻车最惨的一次就是省了这一步，评审现场被问到某条需求的验收方式，翻遍文档找不到对应条目，只能当场承诺补充，后面连着改了三版。希望这套结构和这张矩阵，能帮你少走一遍这条路。

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