简介宠物领养网站是JavaEE方向经典的毕业设计选题这份论文文档围绕“基于JavaEE下宠物领养网站的设计与实现”展开定位为计算机专业学生完成毕设的参考范例。文档从课题背景与国内外现状切入依次介绍需求分析、系统设计、数据库设计、实现与测试等核心环节并详细说明了JSF表现层、EJB业务逻辑层以及MySQL数据存储层的技术选型与应用方式。包体为1个docx文件整体大小2.44MB内容编排完整目录结构清晰便于按章节查阅。目前已有167人学习下载。读者可借此学习毕业设计论文的写作框架、项目功能模块划分与数据库设计思路也能获取宠物领养相关功能如用户注册登录、宠物信息管理、领养申请、论坛交流的具体实现参考对独立完成同类系统设计与论文撰写具有较大帮助。1. JavaEE宠物领养网站一份把线下领养流程搬上线的毕设文档线下领养一只流浪猫有多折腾救助站纸质登记、电话反复沟通、现场看宠、等一周审核信息稍不透明就可能错过。基于JavaEE的宠物领养网站核心做的就是把发布寄养信息、用户在线申请、寄养人审核、查看结果这条链路完整搬到浏览器端。这篇毕设文档的技术主线是JSPServletMySQL走B/S三层架构从需求分析、可行性论证、六张核心表设计、前后台功能落地到测试用例都有完整论述不是那种只有截图和空话的拼凑论文。适合正在选JavaWeb毕设题目、需要参考需求分析和数据库设计的学生也适合要做宠物信息平台但不想从零梳理业务模型的开发者。2. 技术选型与架构梳理B/S三层结构为什么是这套组合2.1 为什么B/S架构对宠物领养网站是更优解宠物领养网站的用户是谁普通爱宠人士、救助站志愿者、空巢老人和空巢青年。这部分人里相当一部分没有安装客户端软件的习惯要让他们为了领养一只猫去装一个桌面程序注册门槛会直接劝退一半人。B/S架构把这个问题消解掉了用户只要有浏览器输入网址就能访问注册、浏览、申请领养全在网页里完成服务端的HTML代码直接以网页形式返回给客户端。论文对B/S和C/S的对比也写得很清楚。C/S模式要分客户应用程序、服务器管理程序和中间件三部分每个客户端都要装对应软件升级时所有使用客户都要重新安装。B/S模式把传统C/S里的服务器部分拆成数据服务器和Web服务器构成三层结构第一层是浏览器负责展示和交互第二层是Web服务器动态生成HTML响应请求第三层是数据库服务器协调来自Web服务器的SQL请求。对宠物领养这个场景来说站点访问量不大但用户分布散B/S的维护优势非常明显——功能改动只改服务器端用户那边刷新页面就是新版不用做任何安装操作。从技术可行性角度看这套方案的成熟度也够。Java作为开发语言发展了这么多年资料多、报错信息好查MySQL体积小、易安装对服务器硬件要求不高Tomcat作为Servlet容器对JSP的原生支持很稳定。整个系统跑起来不需要高配机器一台普通云服务器带一个小型MySQL实例就够了经济可行性也顺带满足了。提示论文的可行性分析章节把技术、时间、经济、操作、法律五个维度都做了论证。复现时这五个维度可以直接改写成自己题目的开题报告素材论证框架是通用的。2.2 工具链分工JDK、Tomcat、MyEclipse 10、MySQL各管哪一段这四样工具的职责边界很多新手混在一起分不清先列个表工具角色对应开发环节JDKJava编译器和运行环境含javac、调试分析工具编写代码、编译、运行TomcatServlet/JSP容器负责把JSP翻译成Servlet执行部署运行Web应用MyEclipse 10JavaEE集成开发环境扩展自Eclipse完整支持JSP、CSS、SQL调试编码、调试、发布MySQL关系型数据库管理系统存储用户、宠物、申请等数据数据持久化JDK是地基。没有JDKJava代码连编译都过不了Tomcat也跑不起来所以装环境时最先装的应该是JDK。Tomcat是承重墙浏览器发来的HTTP请求先到它手里它把JSP文件翻译成Servlet再执行把执行结果拼成HTML返回给浏览器。MySQL是仓库所有用户账号、宠物信息、领养申请记录都存在这里。MyEclipse 10则是把上面三样捏合在一起的工作台——你在IDE里写代码IDE帮你调用JDK编译、帮你把Web应用部署到Tomcat、帮你配置数据库连接。论文里选的MyEclipse 10是那个年代毕设环境的标配完整支持JSP、Servlet、CSS、SQL、Hibernate等一堆技术。放到今天它已经显得很老旧了但用VSCode配置JavaEE语言环境也能达到同样的开发效果装Java Extension Pack配置好JAVA_HOME指向的JDK路径再装一个Tomcat插件把服务器地址指到本地的Tomcat目录项目结构和部署逻辑跟MyEclipse时代完全一致。工具可以换但代码-容器-数据库这三者的角色关系不会变。注意论文正文的技术综述章节把Spring、SpringMVC、MyBatis、Struts、Hibernate都带了一遍这是毕设综述的常规操作。真正落到后面系统设计章节的实现还是JSPServletMySQL这条经典路线。读论文时别被综述带偏复现按正文系统设计为准。2.3 环境搭建的兼容性JDK版本和Tomcat版本先对齐环境搭建最大的坑是版本不匹配。MyEclipse 10对应的JDK版本很老如果你直接用JDK 17去跑老项目Tomcat和IDE插件大概率会报各种兼容性错误。常见做法是装JDK 8配Tomcat 8.5或9这套组合到现在依然稳定能完整支持论文里的JSP技术。装完先验证JDK环境java -version javac -version echo $JAVA_HOME # 期望输出 java version 1.8.xJAVA_HOME指向JDK安装根目录这段命令的作用是确认编译器和运行环境的版本一致。java对应运行环境javac对应编译器两个版本不一致时会出现编译出来的class文件跑不了的情况。JAVA_HOME这个环境变量是给Tomcat和IDE找JDK用的必须指向JDK安装的根目录不是bin目录。验证Tomcat时先解压到无中文无空格的路径然后启动容器cd /path/to/tomcat/bin ./startup.sh # Linux/macOS启动脚本Windows用startup.bat # 控制台出现 Tomcat started 后浏览器访问 http://localhost:8080如果8080端口被占用启动会立刻失败日志里会报Address already in use。这时改Tomcat目录下conf/server.xml里的Connector port把8080改成8081再启动。改端口这个操作后面还会遇到先记住日志路径和排查方法。Tomcat能启动、能访问首页整条链路的地基就算打好了。3. 需求分析与数据库设计六张表如何支撑领养全流程3.1 功能需求拆解前台六个板块与后台三个管理面论文把系统按前后台切开这个切法本身就是需求分析的产物。前台面向所有访问者包含六个板块登录注册、宠物寄养、宠物走失、养宠经验、网站动态、个人中心。其中宠物寄养板块不只是浏览还承载了申请成为领养人的核心动作宠物走失板块支持查看和发布走失信息个人中心只有在注册用户登录后才出现负责修改资料密码、发布寄养信息、审核寄养申请人、对寄养人评价、查看申请结果。后台是管理员的地盘三个管理面个人信息管理、用户信息管理、网站动态管理。权限模型只有两级管理员和注册用户但有个设计细节值得注意——寄养人对领养申请人的审核动作发生在个人中心而不是后台。这意味着平台管理员不参与具体领养业务的裁定只做平台层面的用户和内容管理。这个权限边界划分得很清晰既避免了管理员审核所有申请的工作量膨胀又把审核这个关键节点下放给了最了解宠物情况的信息发布者。权限的边界可以用一张表收束角色可执行操作边界游客浏览寄养、走失、经验、动态板块不能申请领养、不能发布信息注册用户前台全部板块 个人中心发布与审核不能进入后台管理页面管理员后台个人信息、用户信息、网站动态管理不参与具体领养业务这张表对应的就是系统的功能框架。毕设答辩时评委问系统的权限是怎么设计的按这张表回答再把个人中心的审核权下放逻辑讲清楚基本就能站住。3.2 表结构设计领养申请的状态字段怎么定论文的数据库逻辑结构设计章节逐表给出了字段定义按这套逻辑落到MySQL里最核心的是六张表。用户表负责账号与角色宠物信息表负责寄养信息与展示状态领养申请表负责申请流转走失信息表独立成表经验帖和网站动态各一张。先看两张核心表user表字段类型说明idINT 主键自增用户IDusernameVARCHAR(50) 唯一登录名passwordVARCHAR(64)登录密码不应存明文roleTINYINT0普通用户1管理员phoneVARCHAR(20)联系电话emailVARCHAR(100)邮箱create_timeDATETIME注册时间pet表字段类型说明idINT 主键自增宠物IDnameVARCHAR(50)宠物名typeVARCHAR(20)猫或狗breedVARCHAR(50)品种ageINT年龄genderCHAR(2)公/母health_statusVARCHAR(100)健康描述如已驱虫、已疫苗photoVARCHAR(200)图片路径descriptionTEXT详细描述statusTINYINT0待审核1已发布2已领养publisher_idINT发布人关联user.idcreate_timeDATETIME发布时间为什么走失信息要单独拆一张lost_pet表而不是复用pet表因为业务语义完全不同。pet表的核心是领养状态机从待审核到已发布再到已领养每一步都有状态迁移走失信息侧重的是特征描述、丢失地点、联系方式生命周期和领养流程没有交集。硬塞进一张表status字段会变得语义暧昧——不知道是领养状态还是走失状态。单拆出来的代价是多一张表收益是查询逻辑和状态管理都清爽。领养申请表是系统里业务动作最频繁的一张表字段类型说明idINT 主键自增申请IDpet_idINT申请哪只宠物关联pet.idapplicant_idINT申请人关联user.idreasonTEXT领养理由statusTINYINT0待审核1已通过2已拒绝apply_timeDATETIME提交时间audit_timeDATETIME审核时间这套设计的巧妙之处在status字段的配合pet.status负责宠物侧的状态展示adoption_request.status负责申请侧的状态流转两边通过pet_id关联。审核通过时两边状态要一起变这是后面实现里最容易翻车的地方。3.3 建表SQL把字段定义落成可执行DDL字段定义是设计建表SQL是把设计落成可执行代码。以用户表为例标准DDL长这样CREATE DATABASE pet_house DEFAULT CHARACTER SET utf8mb4; CREATE TABLE user ( id INT NOT NULL AUTO_INCREMENT, username VARCHAR(50) NOT NULL, password VARCHAR(64) NOT NULL, role TINYINT NOT NULL DEFAULT 0 COMMENT 0-普通用户, 1-管理员, phone VARCHAR(20) DEFAULT NULL, email VARCHAR(100) DEFAULT NULL, create_time DATETIME DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (id), UNIQUE KEY uk_username (username) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT用户表;这里有几个参数不是随手写的。字符集用utf8mb4而不是utf8是因为utf8在MySQL里最多存3字节的中文字符遇到生僻字或表情符号会报错领养者的自我介绍里带个表情是常见事。ENGINEInnoDB是为了事务支持后面审核领养申请要同时更新两张表MyISAM不支持事务两条更新要么都成功要么都失败的需求满足不了。UNIQUE KEY加在username上保证注册时不会出现重名用户。领养申请表在建表时要注意外键策略CREATE TABLE adoption_request ( id INT NOT NULL AUTO_INCREMENT, pet_id INT NOT NULL, applicant_id INT NOT NULL, reason TEXT, status TINYINT NOT NULL DEFAULT 0 COMMENT 0-待审核, 1-已通过, 2-已拒绝, apply_time DATETIME DEFAULT CURRENT_TIMESTAMP, audit_time DATETIME DEFAULT NULL, PRIMARY KEY (id), KEY idx_pet_id (pet_id), KEY idx_applicant_id (applicant_id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT领养申请表;外键我一般不建议物理加约束而是用索引加应用层逻辑保证一致性。物理外键在删除用户或宠物时会带来级联操作的不可控影响尤其是毕设项目经常要手动改数据外键约束反而碍事。KEYidx_pet_id是普通索引加速按宠物查申请的SQL同时不限制删除操作。pet表、lost_pet表这样带publisher_id的表也照此办理。这套建表SQL跑完数据库侧就绪可以开始写功能了。4. 核心功能实现思路注册登录、领养申请与前后台联动4.1 注册登录实现Session会话与表单校验两个细节注册登录是JSP项目最基础但也最容易出问题的模块。注册页就是一个表单用户名、密码、确认密码、手机号提交到ServletServlet先校验两次密码是否一致、用户名是否已被占用再调用DAO往user表插一条记录。这里最容易踩的坑是密码明文入库——论文正文里没有明确写加密方案但实际开发中把密码明文存在数据库里一旦数据库泄露所有账号就全裸奔了。常见做法是用MD5加盐或SHA摘要存摘要值不存原文。登录校验时对用户输入的密码做同样的摘要再比对这样即使数据库被拖走也还原不出原始密码。登录成功后的会话管理是关键。用户提交用户名密码Servlet查user表命中后把用户对象放进Session然后重定向到首页后续每个页面通过Session里有没有这个对象来判断登录态。protected void doPost(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException { request.setCharacterEncoding(UTF-8); String username request.getParameter(username); String password request.getParameter(password); User user userDao.findByUsernameAndPassword(username, password); if (user ! null) { request.getSession().setAttribute(loginUser, user); response.sendRedirect(index.jsp); } else { request.setAttribute(error, 用户名或密码错误); request.getRequestDispatcher(login.jsp).forward(request, response); } }这段代码的逻辑是先按用户名密码查库命中就把user对象塞进Session并重定向到首页没命中就把错误提示塞进request作用域并转发回登录页。注意区分setAttribute的作用域——loginUser放在Session里整个会话期有效所有页面都能取到error放在request里只在一次转发内有效。sendRedirect是浏览器重新发起请求地址栏会变forward是服务端内部转发地址栏不变所以登录失败时页面URL还停留在登录地址。表单校验除了后端Servlet前端JSP页面也应该有基础校验。用户名不能为空、两次密码要一致这类校验放前端可以减少无效请求但后端必须再校验一次因为前端校验可以通过绕过页面直接POST来规避。记住一句话前端校验是体验优化后端校验才是安全边界。4.2 领养申请的状态流转从发布到审核的四步领养申请是这套系统业务逻辑的核心可以分为四个状态迁移节点第一步寄养人登录后在个人中心发布宠物信息此时pet.status是0前台宠物列表不展示。这是因为新发布的宠物还没经过信息确认直接挂到前台可能涉及虚假信息或重复发布。第二步管理员在后台或寄养人本人确认信息无误后把pet.status改成1前台开始展示这只宠物。第三步用户在前台宠物详情页看到这只宠物点击申请领养填领养理由系统往adoption_request表插一条记录status默认是0。第四步寄养人在个人中心的申请管理列表里审核这条申请要么通过要么拒绝。审核通过时有一个关键联动动作adoption_request.status改成1的同时pet.status必须改成2已领养。这一步如果漏掉宠物会被重复申请。很多毕设项目现场翻车就翻在这里。正确的更新逻辑是把两条SQL放在同一个事务里UPDATE adoption_request SET status 1, audit_time NOW() WHERE id ?; UPDATE pet SET status 2 WHERE id ?;第一条把申请置为已通过第二条把宠物置为已领养。这两条不能分开执行。在JDBC里用Connection对象的setAutoCommit(false)开启事务两条UPDATE执行完统一commit任何一条失败就rollback。用MyBatis的话在Service方法上加Transactional注解即可。为什么必须事务因为申请通过但宠物没下架和宠物下架但申请没通过都是数据不一致前者让宠物被重复申请后者让审核结论丢失都不是能接受的状态。拒绝的逻辑简单一些只要把adoption_request.status改成2pet.status保持在1不变宠物继续留在可领养列表里等下一个申请人。这部分状态流转的表设计在第3章已经铺垫好了实现时只需要严格按状态机走不要在Servlet里随手写死状态值。4.3 前后台文件目录划分权限控制不能只靠前端隐藏JSP项目的目录结构直接影响权限控制的可维护性。论文里的系统分前台和后台落到webapp目录下就是两个清晰的子目录webapp/ ├── index.jsp # 前台首页 ├── register.jsp # 注册页 ├── login.jsp # 登录页 ├── pet/ │ ├── petList.jsp # 可领养宠物列表 │ ├── petDetail.jsp # 宠物详情与申请入口 │ └── petPublish.jsp # 发布寄养信息表单 ├── lost/ │ └── lostList.jsp # 走失信息列表 ├── experience/ │ └── experienceList.jsp # 养宠经验列表 ├── notice/ │ └── noticeList.jsp # 网站动态列表 ├── personal/ │ └── personalCenter.jsp # 个人中心 └── admin/ ├── userManage.jsp # 用户信息管理 └── noticeManage.jsp # 网站动态管理这个目录结构的价值在于URL路径和权限边界一一对应。admin目录下的页面只能管理员访问personal目录下的页面只能登录用户访问前台其他页面游客可看。权限控制要在这层实现常见的做法是写一个Filter拦截请求String uri request.getRequestURI(); if (uri.startsWith(/admin/)) { User user (User) request.getSession().getAttribute(loginUser); if (user null || user.getRole() ! 1) { response.sendRedirect(login.jsp); return; } } if (uri.startsWith(/personal/)) { User user (User) request.getSession().getAttribute(loginUser); if (user null) { response.sendRedirect(login.jsp); return; } } chain.doFilter(request, response);这段Filter的逻辑是凡是访问admin开头的路径必须把Session里的loginUser取出来检查角色是否为管理员不满足就直接重定向到登录页访问personal开头的路径必须已登录。有人会问直接在JSP页面里用if判断用户角色非管理员就隐藏后台入口不行吗不行。隐藏入口只是UI层面的优化用户直接敲/admin/userManage.jsp的URL照样能访问。JSP页面里的角色判断可以做但不能作为唯一防线Filter拦截才是真正生效的权限边界。领养申请提交的Servlet放在web层它的职责是接收参数、组装adoption_request对象、调用DAO插入数据、返回结果给页面。事务控制在Service层做不要在Servlet里写事务代码否则多个Servlet都要连数据库操作时事务边界会越写越乱。这套目录结构和分层约定论文里虽然没有逐行代码但设计思路上是一致的复现时按这个骨架填充就行。5. JavaWeb毕设避坑排查端口、字符集与状态流转五个坎5.1 数据库连接中文乱码页面显示一串问号现象从后台发布的中文宠物名前台页面上显示成????数据库里存进去的也是问号。 原因MySQL的默认字符集是latin1JSP页面以UTF-8提交数据但JDBC连接URL里没指定characterEncoding数据在写入时按latin1编码解析中文字符直接变成问号落库。 解决建库时用utf8mb4第3章已经强调过JDBC连接URL加上字符集参数jdbc:mysql://localhost:3306/pet_house?useUnicodetruecharacterEncodingutf8同时三个环节要保持一致JSP页面顶部加% page contentTypetext/html;charsetUTF-8 %Servlet处理请求时调用request.setCharacterEncoding(UTF-8)HTML的meta标签声明charsetutf-8。三处缺一处都可能出现部分乱码。排查时先看数据库里存的是什么再确认连接URL参数最后检查JSP页面声明按这个顺序能快速定位是写入环节坏了还是读取环节坏了。5.2 Tomcat端口被占用启动闪退现象执行startup.bat或startup.sh后窗口一闪而过日志里出现Address already in use: JVM_Bind。 原因8080端口被本机其他程序占用。最常见的是本地同时在跑SpringBoot项目、或者其他Web服务器占了8080。 解决改Tomcat/conf/server.xml里的Connector port把8080改成8081改完重启。或者查出占用进程并结束它Windows下用netstat -ano | findstr 8080拿到PID再taskkill /PID 进程号 /FLinux或macOS用lsof -i:8080找PIDkill掉。端口解决后IDE里部署时也要同步修改Tomcat配置的端口号否则IDE连的还是8080启动时照样报错。5.3 数据库驱动类找不到ClassNotFoundException现象页面首次访问数据库时报java.lang.ClassNotFoundException: com.mysql.jdbc.Driver。 原因mysql-connector-java的jar包没有放进WEB-INF/lib目录或者IDE部署时没把lib下的新jar包同步到Tomcat的webapps目录。 解决把mysql-connector-java.jar复制到项目WEB-INF/lib下在IDE里右键项目选择Clean再重新部署。如果用的新版驱动还要注意两点驱动类名变成了com.mysql.cj.jdbc.Driver连接URL需要额外加serverTimezoneAsia/Shanghai参数否则会报时区错误。很多老教程里的URL写法在新驱动下直接不能用这不是写错了是驱动版本差异。5.4 审核通过后宠物仍出现在可领养列表现象寄养人通过了某位用户的领养申请但这只宠物在首页还能被其他人申请数据出现重复申请的风险。 原因更新adoption_request表的状态时没有同步把pet表的status改成已领养。列表查询只看pet.status所以宠物一直挂在可领养列表里。 解决按第4章的状态联动手法两条SQL放同一个事务。排查时先确认现状查pet表看status是不是2再看adoption_request表对应的记录status是不是1两个值对不上就说明更新逻辑漏了。这个问题的根因往往是代码里把两个更新放在了不同方法里中间隔了一个非事务的Service调用第二个更新抛异常时第一个已经提交了。解决方法是把两个更新收敛到同一个事务方法中。5.5 表单重复提交同一用户给同一宠物申请两次现象用户手快双击了提交申请按钮数据库里出现两条同用户同宠物的领养申请寄养人审核时要处理两条重复数据。 原因前端按钮没有在提交后禁用后端也没有做唯一性校验。 解决两层都做。前端在按钮点击后设置disabled属性防止连点后端在insert之前先查一下是否已有记录SELECT COUNT(*) FROM adoption_request WHERE pet_id ? AND applicant_id ?;如果查询结果大于等于1直接返回您已申请过这只宠物不再插入新记录。这个幂等处理在演示和真实使用中都很重要。补充一点如果希望从约束层面杜绝可以在adoption_request表加一个联合唯一索引(pet_id, applicant_id)在数据库层面保证同一用户对同一宠物只能有一条申请记录。但这样处理的话用户想撤回申请再重新提交就不太方便了毕设场景下应用层判断已经够用。5.6 测试用例设计论文测试章节的复现对照表论文第六章包含系统功能测试和性能测试复现时可以把功能测试整理成一张用例表逐项对照系统行为。以核心流程为例编号测试用例操作步骤预期结果T01用户注册填写新用户名密码提交注册成功可用新账号登录T02错误密码登录输入正确用户名、错误密码提示用户名或密码错误T03发布宠物信息登录后填写寄养表单提交pet表新增记录status0T04宠物上架修改宠物状态为已发布前台宠物列表可见该宠物T05提交领养申请登录用户点击申请并填写理由adoption_request新增记录T06审核通过寄养人通过申请申请状态变1宠物状态变2T07管理员发布动态后台新增网站动态前台动态板块可见这套用例覆盖了从注册到领养完成的主链路。跑的时候建议按顺序执行T01到T07是一条完整的业务全链路。任何一个用例不通过就回到对应功能模块排查比随机点页面靠谱得多。性能测试方面论文里做了并发访问和响应时间记录毕设场景下用JMeter模拟几十个并发用户访问首页和查询列表就可以满足要求重点观察数据库连接是否稳定、页面响应时间是否在可接受范围内。6. 验证方法与一次交付检查按下线前清单逐项过拿到论文资源只是第一步真正值钱的是把文档里的设计转成能跑的验证能力。我一般在项目交付或答辩前会把论文里的功能点压成一张下线前验证清单逐项勾选跑一遍。这张清单不长但每一行都对应一个真实风险点检查项操作方法合格标准环境版本执行java -version查看Tomcat启动日志JDK与Tomcat版本匹配无报错数据库初始化运行第3章DDL脚本查看表结构六张表全部建立中文无乱码注册登录新注册账号、登录、退出Session正确创建与失效领养主链路发布宠物→上架→申请→审核通过pet和adoption_request状态联动正确权限边界未登录直接访问/admin/userManage.jsp被重定向到登录页数据一致性对比pet表和adoption_request表状态已领养宠物无重复申请中文显示前后台各发布一条中文信息页面无问号无乱码逐行跑完大约半小时。第一次带这种毕设项目我就是在答辩前一晚发现审核通过后宠物没有下架连夜改DAO层事务那晚的体验很深刻。从那以后我每次交付前都强制走一遍这张清单从环境版本到数据一致性逐项勾选再没出过类似问题。把论文里的需求分析和数据库设计当作底稿去复现再靠这张清单守住交付质量这套资料的参考价值才算真正用到位。希望帮到你。本文还有配套的精品资源点击获取