简介：这是一份基于Web的任务管理系统的设计与实现论文文档，适合高校计算机相关专业学生、软件开发人员及准备撰写同类毕设课题的读者。内容从软件开发背景切入，分析T、Q、C、S、E竞争要素与项目管理难题，完整阐述了B/S架构下采用JSP+SQL Server 2000的具体方案，并围绕任务分配、权限控制、自动化处理、文档管理、变更追踪等功能模块展开，同时讨论了配置管理与持续改进策略。文中还涉及中间产品维护、变更申请与回滚等配置管理细节，能够帮助读者理解软件开发过程中的规范化管理，可作为系统设计、论文撰写和答辩准备的参考资料。资源包内共1个文件，为Word格式（.doc）论文正文，大小约935KB，章节结构完整，包含摘要、需求背景、架构设计、功能介绍等。当前已有164人学习下载，适合需要快速搭建任务管理系统理论框架或完成课程设计文档的读者。
1. 基于 Web 的任务管理系统：这份设计与实现文档到底能帮你什么
如果你正在为毕业设计选题发愁，或者在公司里被临时拉去搭一个内部任务管理工具，这份《基于 Web 的任务管理系统的设计与实现》论文文档是一个很合适的参考起点。它不像市面上那些包装华丽的商业项目，而是老老实实地走完了“需求分析 → 系统设计 → 数据库设计 → 页面实现”的完整流程，技术栈也很朴素：JSP + Servlet + SQL Server 2000，B/S 架构。文档里你能看到任务录入、日报周报转任务表、权限控制、SVN 资源库权限管理这些真实业务场景是怎么落地的，而不是一个只有登录注册的空壳 demo。适合的人群很明确：需要写毕业设计的在校生、刚接触 Java Web 开发想找一套完整案例的初学者，以及要给团队快速搭一个轻量任务管理原型的一线开发。它能帮你省下大量从零梳理业务流程的时间，直接照着改就能用。
2. 技术选型为什么是 JSP + SQL Server 2000：不是复古，是这套组合的边界最清晰
2.1 为什么这个年代还要看 JSP 方案
很多人一看到 JSP 和 SQL Server 2000 就觉得这是上古技术，但这份文档恰恰选的是一套“教学边界最清晰”的组合。JSP 的本质是 Java 系动态网页技术，它和 Servlet 的关系是：JSP 最终会被容器翻译成 Servlet 来执行。你在 JSP 里写的 HTML 标签会变成 Servlet 里 response 输出的内容，而<% %>里面的 Java 代码则直接成为 Servlet 方法体的一部分。这个机制决定了 JSP 特别适合做“页面逻辑为主、业务逻辑不复杂”的办公类系统——任务管理恰恰就是这种场景。
从文档第 2 章可以看到，作者对比了 ASP、PHP、CGI 和 JSP 的优缺点，最终选择 JSP 的核心理由是跨平台性和“一次编写到处运行”。在真实的开发环境里，这意味着你可以在 Windows 上开发、部署到 Linux 服务器，代码不用改。另外 JSP + JavaBeans 的组合能把数据库连接、用户登录校验这些重复逻辑封装成组件，JSP 页面里就不用堆大段脚本。文档里提到的三种 JSP 元素——Scripting elements、Directives、Actions，对应到实际代码就是：
<%@ page language="java" contentType="text/html; charset=GBK" %> <%@ page import="java.sql.*" %> <jsp:useBean id="db" class="com.task.DBBean" scope="page" /> <html> <body> <% ResultSet rs = db.executeQuery("SELECT * FROM task_info WHERE status='未开始'"); while (rs.next()) { %> <tr><td><%= rs.getString("task_name") %></td></tr> <% } %> </body> </html>这段代码里能看到三层东西：<%@ %>是 Directive 指令，用来设置页面属性和导入 Java 类；<jsp:useBean>是 Action 动作，用来复用外部 JavaBean；<%= %>是 Scripting 元素，负责输出 Java 变量的值到 HTML 中。实际开发中我一般会把数据库操作全部收拢到 JavaBean 里，JSP 页面只保留executeQuery调用逻辑，这样美工改页面时不会误伤业务代码。
2.2 SQL Server 2000 在 B/S 架构里扮演的角色
文档将 SQL Server 2000 定位为后台数据服务器，这个选择在当年是很务实的。SQL Server 2000 的体系结构就是标准的三级模式：外模式对应视图、模式对应基本表、内模式对应存储文件。任务管理系统里最核心的就是任务表、用户表、权限表之间的关联查询，用 SQL Server 2000 的 T-SQL 写起来很直接。
CREATE TABLE task_info ( task_id INT IDENTITY(1,1) PRIMARY KEY, task_name NVARCHAR(100) NOT NULL, task_type NVARCHAR(20) DEFAULT '日常任务', reporter NVARCHAR(20) NOT NULL, assignee NVARCHAR(20) NOT NULL, task_date DATETIME DEFAULT GETDATE(), task_status NVARCHAR(10) DEFAULT '未开始', task_desc NTEXT, CONSTRAINT fk_reporter FOREIGN KEY (reporter) REFERENCES user_info(user_name) );这段建表语句体现了几个关键设计。IDENTITY(1,1)是自增主键，避免手动维护任务编号；reporter字段设成外键关联用户表，保证录入任务的人必须存在于系统中；task_status设置默认值 '未开始'，减少前端传参的出错概率。SQL Server 2000 的GETDATE()函数可以自动记录任务创建时间，这在日报周报统计时非常有用。需要提醒的是，如果读者现在用的是更新版本的 SQL Server（2012 及以上），这段脚本里只有NTEXT需要改成NVARCHAR(MAX)，其余语法完全兼容。
2.3 Servlet 在处理请求流程中的位置
文档里有一个容易被忽略但很重要的点：作者在第 2.1.4 节特意对比了 Servlet 与 CGI、Servlet 与 JSP 的差异。在 B/S 架构里，Servlet 扮演的是控制器角色——接收浏览器请求、调用 JavaBean 处理业务、转发到 JSP 渲染页面。任务管理系统里最常见的流程是：用户提交新增任务表单 → Servlet 接收参数 → 调用 DAO 写入数据库 → 重定向到任务列表页。
protected void doPost(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException { request.setCharacterEncoding("GBK"); String taskName = request.getParameter("taskName"); String taskType = request.getParameter("taskType"); String assignee = request.getParameter("assignee"); TaskDAO dao = new TaskDAO(); boolean flag = dao.insertTask(taskName, taskType, assignee); if (flag) { response.sendRedirect("taskList.jsp"); } else { request.setAttribute("errorMsg", "任务新增失败，请检查输入"); request.getRequestDispatcher("taskAdd.jsp").forward(request, response); } }这段 Servlet 代码有三个工程点值得学习。一是setCharacterEncoding("GBK")必须放在读取参数之前，否则中文参数会乱码；二是成功操作用sendRedirect，防止刷新页面时表单重复提交；三是失败操作通过setAttribute带上错误消息再forward回原页面。文档里提到的“Servlet 是位于 Web 服务器内部的服务器端 Java 应用程序，由 Web 服务器加载”，在实际部署中就对应 Tomcat 的web.xml配置：
<servlet> <servlet-name>TaskAddServlet</servlet-name> <servlet-class>com.task.servlet.TaskAddServlet</servlet-class> </servlet> <servlet-mapping> <servlet-name>TaskAddServlet</servlet-name> <url-pattern>/taskAdd</url-pattern> </servlet-mapping>2.4 B/S 模式相比 C/S 模式的核心优势
这篇论文采用 B/S 模式，背后是有实际考量的。C/S 模式需要每台客户端安装专用软件，而任务管理系统面向的是企业办公场景，使用者可能分布在不同的操作系统环境。B/S 模式只要服务器部署一套 Tomcat + SQL Server，客户端用浏览器访问即可。这样带来的直接好处是运维成本大幅降低，升级业务逻辑只需要替换服务器端的 JSP 和 Servlet，不需要逐台更新客户端。
但 B/S 模式也有它的边界——SQL Server 2000 的 TCP/IP 端口默认是 1433，如果你的服务器开了防火墙，必须显式放行这个端口，否则客户端会一直报“无法连接数据库”。这个坑在文档里没写，但实际部署时几乎必踩。另一个注意点是 SQL Server 2000 默认允许远程连接的配置比较保守，需要在服务器端用“服务器网络实用工具”启用 TCP/IP 协议，不然 Java 代码和服务器的 Tomcat 能连，但局域网其他机器连不上。
3. 核心功能模块拆解：任务录入、日报周报转表、权限控制是怎么一步步落地的
3.1 系统静态结构图与领域模型
文档在第 4.1.1 节给出了系统领域模型图，并强调“最重要的就是资源库的设计”。这句话点出了任务管理系统的核心矛盾：日常办公中产生最多的不是代码文件，而是各类文档、报表、任务记录。领域模型里至少要有三类实体：用户实体（包含用户名、密码、角色）、任务实体（包含任务名称、类型、录入人、负责人、状态）、日报周报实体（包含日期、数据内容、所属任务）。这三类实体之间的关联关系是：一个用户能录入多个任务，一个任务能对应多份日报周报。
在这份文档里，作者把配置管理和任务管理放在一起讲，这说明系统的设计思路是：任务不仅是“待办事项”，更是软件工程中的“中间产品”。我把这个理解翻译成实际的数据表设计，大概需要这几张表：
| 表名 | 用途 | 关键字段 |
|---|---|---|
| user_info | 用户账号表 | user_name, user_pwd, user_role |
| task_info | 任务主表 | task_id, task_name, task_type, task_status |
| task_log | 任务日志表 | log_id, task_id, operator, operate_time |
| report_daily | 日报表 | report_id, user_name, work_date, content |
| report_weekly | 周报表 | report_id, user_name, week_start, week_end, summary |
这个表结构覆盖了任务管理的完整闭环：任务创建 → 任务执行 → 日志记录 → 日报周报汇总。文档里提到的“将其转变为各种任务表并作出分析”，落到底层就是通过 SQL 对report_daily和report_weekly表按日期字段做分组统计。
3.2 JSP + JavaBeans 实现日报数据智能化管理
日报周报数据管理是这份文档区别于普通 CRUD 项目的核心亮点。常规的任务管理系统只做任务的增删改查，而这篇论文要求“从日报、周报中读取数据，将其转变为各种任务表”。实现思路并不复杂：日报表里每条记录关联一个任务 ID，周报则汇总一周内该任务下所有日报的工作量。
<jsp:useBean id="reportBean" class="com.task.ReportBean" scope="page" /> <% String startDate = request.getParameter("startDate"); String endDate = request.getParameter("endDate"); String sql = "SELECT task_id, task_name, COUNT(*) AS report_count, " + "SUM(work_hours) AS total_hours FROM report_daily " + "WHERE work_date BETWEEN '" + startDate + "' AND '" + endDate + "' " + "GROUP BY task_id, task_name ORDER BY total_hours DESC"; ResultSet rs = reportBean.executeQuery(sql); %> <table border="1"> <tr><th>任务编号</th><th>任务名称</th><th>日报数</th><th>总工时</th></tr> <% while (rs.next()) { %> <tr> <td><%= rs.getString("task_id") %></td> <td><%= rs.getString("task_name") %></td> <td><%= rs.getInt("report_count") %></td> <td><%= rs.getDouble("total_hours") %></td> </tr> <% } %> </table>这个 JSP 片段展示了一个典型的“按时间段维度分析任务投入”功能。BETWEEN条件用来筛选指定日期范围的日报记录，GROUP BY task_id把同一任务下的多条日报合并成一行，SUM(work_hours)计算出这段时间花在该任务上的总工时。通过这个报表，管理层能直接看出哪些任务投入工时最多、哪些任务停滞没有更新。需要注意的坑点：这里用了字符串拼接 SQL，在真实场景中推荐改用PreparedStatement防止注入，但在 JSP 里直接拼接有个前提——日期参数必须在前端做合法性校验。
3.3 任务录入界面的表单提交逻辑
文档第 5.1 节专门提到了“任务录入界面”和“任务管理—新增测试任务”。任务录入是日常使用频率最高的功能，它的设计质量直接决定用户愿不愿意用这个系统。一个合格的任务录入页面至少要包含五个要素：任务名称、任务类型、任务描述、负责人、计划完成时间。表单提交后走的是上一章展示的 Servlet 处理链路。
实际项目里，我一般会把任务类型用下拉框而不是文本框实现，这样能避免同一任务被录成“测试”“测试任务”“bug测试”三种不同写法，导致后续统计报表数据混乱。这个细节在文档的需求分析部分其实有暗示——系统要求“数据智能化管理”，前提就是数据格式规范。如果允许自由输入任务类型，那么日报转任务表时的GROUP BY就会把语义相同的任务拆成多行。
function validateTaskForm() { var taskName = document.getElementById("taskName").value.trim(); var assignee = document.getElementById("assignee").value; if (taskName.length === 0) { alert("任务名称不能为空"); return false; } if (assignee === "") { alert("请选择任务负责人"); return false; } return true; }这段前端校验代码放在表单onsubmit事件里。校验逻辑分两层：第一层是空值检查，任务名称用trim()去掉首尾空格再判断长度；第二层是业务校验，任务负责人必须从已存在用户中选择。前端校验的意义在于减少无效请求打到服务器，但后端 Servlet 里必须重复同样的校验——前端检查可以被绕过，后端才是安全边界。
3.4 SVN 资源库权限管理如何融入任务系统
文档第 4.2 节专门设计了 SVN 资源库权限管理，这是很多任务管理系统容易忽略的部分。SVN（Subversion）是版本控制工具，但文档在这里不是讲 SVN 本身，而是把 SVN 的目录结构映射成任务系统的权限模型——谁有权限提交代码、谁只读、谁完全不可见，这些规则需要一个管理界面。
这个功能落到实现层面，核心就是一张权限配置表，记录“用户-路径-权限等级”的映射关系。权限等级通常分为只读（r）、读写（rw）、完全控制（rw+）。任务系统启动时读取这张表，生成 SVN 的 authz 配置文件。文档把它作为任务管理的一部分，逻辑很通顺：软件开发任务往往伴随着代码提交，任务进行到哪个阶段、谁能改哪个模块，都应该和任务系统联动。这个设计思路即使放到现在依然有参考价值——很多团队用 Jira + Git 的组合，权限管理依然是割裂的两套体系。
CREATE TABLE svn_access ( access_id INT IDENTITY(1,1) PRIMARY KEY, user_name NVARCHAR(20) NOT NULL, repo_path NVARCHAR(200) NOT NULL, access_level CHAR(2) NOT NULL DEFAULT 'r', CONSTRAINT fk_svn_user FOREIGN KEY (user_name) REFERENCES user_info(user_name) );这张表的repo_path字段指向 SVN 仓库中的具体目录，access_level用两位字符表示权限等级。任务系统在用户登录后可以根据这个人的角色和承担的关联任务，动态决定他在 SVN 界面上能看到哪些目录、能提交哪些文件。这样权限控制就不是孤立的静态配置，而是跟着任务走的动态策略——任务是你的，你就有对应代码目录的写权限；任务交接后，权限自动回收。当时文档把这个设计放在了资源库管理下，说明作者已经意识到“任务”和“资源”是同一枚硬币的两面。
4. 常见问题排查与避坑指南：JSP + SQL Server 2000 组合下的五个真实踩坑记录
4.1 页面中文乱码
- 现象：任务名称录入“测试任务”，提交后数据库里显示“????”，页面上也是乱码。
- 原因：JSP 页面编码、Servlet 接收编码、数据库存储编码三者不一致。JSP 默认
ISO-8859-1，SQL Server 2000 默认排序规则可能是Chinese_PRC_CI_AS，前端提交的中文经过两次错误转码彻底损坏。 - 解决：JSP 文件头部声明
<%@ page contentType="text/html; charset=GBK" %>，Servlet 在读取参数前统一执行request.setCharacterEncoding("GBK")，数据库建表时字段类型使用NVARCHAR而不是VARCHAR，三处保持一致。如果用的是 MySQL，则统一改成UTF-8，原理相同。
4.2 客户端无法连接 SQL Server 2000
- 现象：Tomcat 部署在同一台机器上，任务系统能正常登录；但换成局域网内另一台电脑通过 IP 访问，就一直卡在登录页面或直接报 500 错误。
- 原因：SQL Server 2000 默认使用的命名管道协议在某些网络环境下不可用，且服务器端的 TCP/IP 协议可能被禁用了。另外 Windows 防火墙默认拦截 1433 端口。
- 解决：在“SQL Server 服务器网络实用工具”中启用 TCP/IP 协议，并记录端口号（默认 1433）；在 JDBC 连接串中显式指定 IP 和端口，例如
jdbc:sqlserver://192.168.1.100:1433;DatabaseName=TaskDB；防火墙放行 1433 端口的入站规则。注意 SQL Server 2000 的 JDBC 驱动是com.microsoft.jdbc.sqlserver.SQLServerDriver，和 2005+ 版本的驱动类名不同。
4.3 任务列表页分页无效或重复加载
- 现象：日报转任务表的查询结果太多，页面一次性全部渲染，操作卡顿；或者点击“下一页”后数据没有变化。
- 原因：分页逻辑没有持久化查询条件。点击下一页时刷新页面，
startDate和endDate参数丢失，SQL 查询变成了无条件全表扫描；另外结果集没有使用数据库端分页。 - 解决：在 JSP 的翻页链接中显式携带全部查询条件参数，SQL 语句使用
TOP配合NOT IN实现分页（SQL Server 2000 不支持OFFSET-FETCH），例如用子查询先取出前 N-1 页的任务 ID，再取剩余记录。Servlet 端把条件对象放在 Session 中，翻页时优先从 Session 读取。
4.4 JSP 修改后不生效
- 现象：改了 JSP 文件里的某个表格字段，刷新浏览器还是旧页面。
- 原因：Tomcat 的 JSP 缓存或浏览器端缓存。JSP 第一次被请求时容器会编译成 Servlet class 并缓存，如果服务器配置了
development=false或者 JSP 文件时间戳没变化，容器不会重新编译。 - 解决：开发阶段确认 Tomcat 的
web.xml中 servlet 配置的development=true，刷新页面时使用Ctrl + F5强制浏览器绕过本地缓存。如果改动频繁，直接重启 Tomcat 是最快的方式。生产环境则反过来，关闭 development 模式减少 JSP 重复编译的开销。
4.5 SQL Server 2000 在 64 位系统上的兼容问题
- 现象：Windows Server 2008 R2（64 位）上安装 SQL Server 2000 失败，或者装上后服务无法启动。
- 原因：SQL Server 2000 原生不支持 64 位操作系统，需要安装 32 位兼容模式，且安装文件必须有 SP4 补丁。这个问题在文档写成年代不存在，但现在拿来复现的人大概率会遇到。
- 解决：可以考虑用 SQL Server 2005 Express 或 SQL Server 2012 Express 替代，JDBC 代码的改动量很小。SQL Server 2000 的
NTEXT、IMAGE类型在新版本中已废弃，但选用 2012 Express 只需要把建表脚本里NTEXT改成NVARCHAR(MAX)即可。如果坚持用 SQL Server 2000，必须找到带 SP4 的安装介质，并在安装时勾选“向上兼容”选项，同时打开 32 位子系统支持。
5. 把论文变成能跑的系统的落地验证：三步复现法加一条老工程师的保命习惯
5.1 从论文文档中提取可执行的建表脚本
拿到这份论文文档后，不要急着通篇阅读，先做“信息抽取”。论文里第三章的需求分析和第四章的详细设计已经给出了系统边界和核心实体，你需要做的是把这些描述翻译成具体的数据结构。从我的习惯来看，第一步永远是先把用户表和任务表的建表 SQL 跑通，因为这两张表是其他所有功能的基石。复现项目时用现有的 SQL Server 2019 也可以，把文档里的NTEXT批量替换成NVARCHAR(MAX)，把GETDATE()保留不动，其余语法在 2019 上完全兼容。
-- 用户表 CREATE TABLE user_info ( user_id INT IDENTITY(1,1) PRIMARY KEY, user_name NVARCHAR(20) NOT NULL UNIQUE, user_pwd NVARCHAR(50) NOT NULL, user_role NVARCHAR(10) DEFAULT '普通用户' ); -- 任务表 CREATE TABLE task_info ( task_id INT IDENTITY(1,1) PRIMARY KEY, task_name NVARCHAR(100) NOT NULL, task_type NVARCHAR(20) DEFAULT '日常任务', reporter NVARCHAR(20) NOT NULL, assignee NVARCHAR(20) NOT NULL, task_date DATETIME DEFAULT GETDATE(), task_status NVARCHAR(10) DEFAULT '未开始', task_desc NTEXT, FOREIGN KEY (reporter) REFERENCES user_info(user_name), FOREIGN KEY (assignee) REFERENCES user_info(user_name) );注意FOREIGN KEY (reporter) REFERENCES user_info(user_name)这里有个设计决策：外键关联的是user_name而不是user_id。这样做的优点是查询任务时不需要多表 JOIN 就能直接显示用户名，代价是如果用户名被修改，需要同步更新任务表。对这种内部管理系统，用户名基本不会改，所以这个设计是划算的。
5.2 按文档页面结构搭建 JSP 页面骨架
文档第 5 章给出了系统实现的关键界面说明和“任务录入界面、任务管理—新增测试任务”的展示重点，你可以据此拆出 JSP 页面清单：login.jsp登录页、taskList.jsp任务列表页、taskAdd.jsp任务录入页、taskEdit.jsp任务修改页、reportView.jsp日报周报统计页。页面之间的跳转遵循“每个模块之间应具有相互转换的功能，无需退回主界面重新选择”这条需求，所以在导航栏里永远放上所有模块的链接。
webapps/ └── taskms/ ├── login.jsp ├── taskList.jsp ├── taskAdd.jsp ├── taskEdit.jsp ├── reportView.jsp ├── WEB-INF/ │ ├── web.xml │ └── classes/ │ └── com/task/ │ ├── DBBean.java │ ├── TaskDAO.java │ └── servlet/ │ ├── TaskAddServlet.java │ └── TaskListServlet.java └── META-INF/这个目录结构是从文档描述中推导出的最小可运行骨架。DBBean.java负责 JDBC 连接管理，TaskDAO.java封装任务增删改查，Servlet 负责请求分发，JSP 只负责展示数据。对于刚接触 JSP 的开发者来说，这套分层能让你少走很多弯路——最忌讳的就是把所有 Java 代码都塞进 JSP 的<% %>里，虽然能跑，但后期调试起来会非常痛苦。
5.3 权限控制的最小实现方案
文档多次提到权限管理，从“系统在用户输入管理员姓名、管理员密码时，应具有自动识别的功能”到“通过权限设置，确保不同角色的用户访问相应级别的信息”。最小可用的权限控制方案是：user_info表里加一个user_role字段，区分管理员和普通用户；在 JSP 页面头部做角色判断，控制功能按钮的可见性。
<% HttpSession session = request.getSession(); String role = (String) session.getAttribute("userRole"); boolean isAdmin = "管理员".equals(role); %> <% if (isAdmin) { %> <a href="taskAdd.jsp">新增任务</a> <a href="userManage.jsp">用户管理</a> <% } else { %> <a href="taskList.jsp">我的任务</a> <a href="reportView.jsp">我的报表</a> <% } %>这个方案的优点是简单直接，适合小团队内部系统；缺点是当角色类型变多、权限粒度变细（比如普通用户只能看自己录入的任务、部门主管能看整个部门）时，页面级判断会变得难以维护。遇到这种情况就需要引入过滤器（Filter）统一控制 URL 访问权限了。从这份论文的定位看，它没有涉及这么深的层次，所以复现时做到角色区分这一层就足够应对答辩。
5.4 最后一公里：对我自己的“复盘后路”习惯和给你的一个有效技巧
做了几年 Java Web 项目后，我自己悟出一个保命习惯：每次动手复现类似项目前，先抽出半小时把数据库脚本和 JSP 页面骨架完整跑通，再回头细读论文的设计章节。因为这个资源是一份毕业设计论文文档，不是现成的完整源码包，它的核心价值在于给你一张可执行的系统设计蓝图，而不是给你一份开箱即用的代码。如果你直接去搜索“任务管理系统源码”，得到的往往是代码超过三千行但设计一团乱麻的“黑匣子”，出了问题根本无从下手。而这个资源最实用的就是它把“为什么这样设计、为什么选这个技术栈”讲得明明白白——你复现时遇到问题，翻回去看对应的章节就能找到答案。从那以后，我每次拿到这种设计文档类资源，都会强制自己先走一遍“建库→建表→跑通一个页面”的最小闭环，再展开做其他功能；这个习惯在后来接手一个年代久远的 OA 系统时救了我一回，那套老系统的任务模块结构基本就是 JSP + SQL Server，得益于这个习惯，我只花了一个下午就理清了它的运行逻辑。希望帮到你，复现过程如果卡住了，回到这份文档第 3 章和第 4 章的对应小节，你会比我多踩很多坑之后，才发现作者早就把答案写进了那几段看似平淡的描述里。
本文还有配套的精品资源，点击获取
