企业官网建设流程全解析

简介：资源为基于Java与HTML实现的智慧乡村管理系统后端源码，面向Java后端开发者、毕业设计及课程实践人群，用于理解乡村管理类系统的模块划分、接口设计与前后端交互方式。资源包共45个文件，核心为40个Java源文件，覆盖用户管理、数据处理、接口定义等后端逻辑；另含YAML与XML配置文件用于环境参数与系统配置，Git忽略文件辅助团队协作，一个HTML文件可作简单界面预览，压缩包整体仅61KB，轻量易部署。目前已有387人学习浏览，适合入门级至中级开发者快速上手。通过研读源码，可学习MVC分层架构、JDBC或JPA数据库交互、Servlet网络通信等关键知识点，同时了解RESTful API设计与异常处理、日志记录等工程实践，为独立开发类似后台管理系统提供可复用的代码参考与设计思路。

1. 智慧乡村管理系统后端源码：它解决的是什么问题

接到一个智慧乡村管理系统的后端设计任务时，对方往往先甩过来几套 HTML 静态页面，人口、补贴、村务公开的表格画得清清楚楚，然后补一句：后端你看着设计。这正是这个标题里真正值钱的部分——基于 Java 和 HTML 的智慧乡村管理系统后端设计源码，难点从来不在页面，而在人口档案怎么建档、补贴怎么防重复、村务怎么留痕、权限怎么隔离。这类系统的数据量不大，并发很低，但业务口径细碎，表与表之间关联复杂。这篇笔记按真实落地顺序展开：先定技术选型，再拆数据模型，然后走读后端核心代码，最后把部署和排错经验一次性讲透。适合正在做 Java 课程设计案例源码、毕业设计，或在小团队接乡镇数字化项目的人。

2. 技术选型与边界：Spring Boot 单体如何撑起 HTML 页面

选型的出发点不是「什么技术新」，而是「谁运维、多少人用、多久交付」。乡镇级管理系统，十来个并发就到顶了，部署环境是台普通服务器，维护的人大概率不是专职后端。所以结论很直接：用 Spring Boot 单体应用，内嵌 Tomcat，打包成一个 jar 就能跑；数据库用 MySQL，一台机器全搞定。页面要不要也给后端渲染？要。标题写「Java 和 HTML」，落到实现里就是服务端模板渲染——后端把数据填进 HTML 模板再吐给浏览器，页面源码里看不到 Java，浏览器收到的仍然是标准 HTML。这套组合的维护成本最低，一个人能交付，换了人也能接手。

2.1 框架取舍：单体能跑通为什么不上微服务

Spring Boot 版本先定下来。如果是 JDK 8 环境，走 Spring Boot 2.7.x；如果是 JDK 17，再上 Spring Boot 3.x。Spring Boot 3 把javax包整体切到jakarta，旧代码里凡是import javax.servlet.*的地方全部要改，这个差异也是 Java 面试题里常拿来考的点。很多乡镇服务器上的 JDK 还是老版本，课程设计和毕业设计的环境也大量停留在 JDK 8，所以从兼容性出发，2.7.x 是更稳的起点。

为什么不拆微服务？看业务就知道了：补贴要关联人口，村务要关联用户，土地要关联家庭，模块之间强耦合。一旦拆开，分布式事务、服务发现、链路追踪全要上，复杂度翻倍。而数据一致性在单体里就是一个@Transactional注解的事——这是单体最值钱的优势。你问 Java 怎么保证数据一致性，在这个项目里最诚实的答案就是：别拆，让数据库事务去保证。微服务那套是给大团队大流量准备的，智慧乡村这个体量用了就是给自己找后悔药。

ORM 层面，MyBatis 是管理类系统的默认答案，XML SQL 直观、可控、面试认可度也高。想省事可以用 MyBatis Plus 处理单表 CRUD，但核心的统计报表 SQL 建议手写，出了问题你能自己看懂。如果你不想从零搭权限和菜单，RuoYi 这类开源管理脚手架已经是这个领域的事实标准，直接在上面改业务表是团队常用的省力做法，代价是先花时间读懂它的代码生成约定和权限模型。

2.2 页面渲染：Thymeleaf 在 Java 后端里填 HTML 模板

很多人一看标题里有 HTML，下意识以为要走纯静态页面加 Ajax 的路子。在这个技术组合里，常规做法是服务端渲染，模板引擎用 Thymeleaf，页面直接放在src/main/resources/templates下。一个最小的模板片段长这样：

<p>村民姓名：<span th:text="${villager.name}">张三</span></p>

浏览器直接打开这份 HTML，看到的是「张三」这个占位文字；只有经过后端渲染，它才会被数据库里的真实姓名替换。这就是 Java 和 HTML 结合的最小单元：HTML 负责结构，Java 负责往里填数据。这样做有三个好处：不需要 Node 环境，不需要解决跨域，写页面的人不懂 Java 也能看懂模板结构。

什么时候才值得改成前后端分离？判断标准不是流行，而是「有没有第二个客户端要复用同一批接口」。如果将来要做小程序、App，或者团队里有专职前端，再把 Vue、React 引进来，接口本来就是 REST 风格，页面层替换不影响后端设计。智慧乡村的典型落地场景里，九成没有这个需求。前后端分离项目实战里那套工程复杂度，在这个项目里属于过早优化。

2.3 工程骨架：一套可以直接开写的包结构与配置

拿到源码先看包结构，这是最快了解项目的方式。一个常见的单模块 Spring Boot 工程长这样：

核心配置文件application.yml里，有三处配置决定了项目能不能跑起来：

server: port: 8080 spring: datasource: url: jdbc:mysql://127.0.0.1:3306/village?useUnicode=true&characterEncoding=utf8&serverTimezone=Asia/Shanghai username: root password: 123456 driver-class-name: com.mysql.cj.jdbc.Driver mybatis: mapper-locations: classpath:mapper/*.xml configuration: map-underscore-to-camel-case: true

map-underscore-to-camel-case打开后，数据库里的create_time能自动映射到 Java 实体的createTime，写 XML 时不用整天起别名。mapper-locations写错最常见的症状是启动时报Invalid bound statement，后面排错章节还会遇到。另外在common包里通常有一个Result<T>，只有code、message、data三个字段，所有接口统一返回它，前端模板判断code再决定展示逻辑。读源码时先认这个类，接口的返回结构就全通了。

3. 数据模型先行：智慧乡村核心业务怎么落成九张表

「智慧乡村」听起来很大，落到 MySQL 里无非九张左右的表：用户、角色、家庭、村民、房屋、农田、补贴记录、村务公开、数据字典。表结构设计要先于写代码，因为 Java 后端绝大多数的代码就是围着表在转。一个字段设计失误，后面会冒出一堆别名、转换逻辑和特判来补，补着补着就成了技术债。这一章把核心表的建表思路过一遍，并解释关键字段为什么这样设。建表字符集统一用utf8mb4，村民姓名里可能出现生僻字，MySQL 的utf8存不下。

3.1 人口与家庭：身份证唯一索引与一对多建模

家庭表和村民表是整个系统的地基。村委会的管理单位不是个人而是「户」，补贴发放、宅基地审批、土地确权都跟户走，所以先建家庭表，村民通过family_id归属到户：

CREATE TABLE family ( id BIGINT AUTO_INCREMENT PRIMARY KEY, family_code VARCHAR(30) NOT NULL COMMENT '户编号', head_villager_id BIGINT COMMENT '户主ID', address VARCHAR(200) COMMENT '家庭地址', member_count INT DEFAULT 0 COMMENT '成员数', UNIQUE KEY uk_family_code (family_code) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='家庭表';

村民表是核心中的核心，字段设计直接决定后面报表好不好写：

CREATE TABLE villager ( id BIGINT AUTO_INCREMENT PRIMARY KEY, family_id BIGINT NOT NULL COMMENT '所属家庭ID', name VARCHAR(50) NOT NULL COMMENT '姓名', id_card VARCHAR(18) NOT NULL COMMENT '身份证号', gender TINYINT NOT NULL DEFAULT 0 COMMENT '性别 0女 1男', birthday DATE COMMENT '出生日期', nation VARCHAR(20) DEFAULT '汉族' COMMENT '民族', phone VARCHAR(20) COMMENT '联系电话', household_type VARCHAR(20) DEFAULT '农业' COMMENT '户籍类型', is_low_income TINYINT NOT NULL DEFAULT 0 COMMENT '是否低保户', is_poor_filed TINYINT NOT NULL DEFAULT 0 COMMENT '是否建档立卡户', create_by VARCHAR(32), create_time DATETIME, update_by VARCHAR(32), update_time DATETIME, UNIQUE KEY uk_id_card (id_card), KEY idx_family_id (family_id), KEY idx_name (name) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='村民基本信息表';

两个设计点值得说。第一，身份证号建唯一索引，这是防止同一个人被重复建档的最硬约束，入参时还要校验 18 位、末位 X 统一转大写；第二，gender、is_low_income这类字段用TINYINT0/1，不要写「男/女」「是/否」字符串，否则报表统计时全是CASE WHEN。family_id加索引是因为「按户查人」是最频繁的查询路径，户主补贴、家庭名单都要走它。

3.2 补贴与村务：金额精度与状态机

补贴发放是智慧乡村系统里最容易出事的业务，设计上要同时管住金额精度和重复发放：

CREATE TABLE subsidy_record ( id BIGINT AUTO_INCREMENT PRIMARY KEY, villager_id BIGINT NOT NULL COMMENT '补贴对象ID', subsidy_type VARCHAR(50) NOT NULL COMMENT '补贴类型，取数据字典', amount DECIMAL(12,2) NOT NULL COMMENT '补贴金额', pay_date DATE NOT NULL COMMENT '发放日期', status TINYINT NOT NULL DEFAULT 0 COMMENT '0待发放 1已发放 2已退回', remark VARCHAR(255), create_by VARCHAR(32), create_time DATETIME, UNIQUE KEY uk_type_villager_date (subsidy_type, villager_id, pay_date) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='补贴发放记录表';

金额用DECIMAL(12,2)，绝不用float或double，浮点精度漂移在钱上面不能忍。状态字段status是一个小状态机，通常只有三条合法流转：待发放可以转为已发放或已退回，已发放只能转为已退回。

联合唯一键(subsidy_type, villager_id, pay_date)是防重复发放的关键：同一个人、同一个补贴类型、同一天只能有一条记录。没有这条约束，财务手抖点两次保存，钱就发出去了。

村务公开表相对简单，但状态字段同样不能省：

CREATE TABLE village_affairs ( id BIGINT AUTO_INCREMENT PRIMARY KEY, title VARCHAR(100) NOT NULL, content TEXT NOT NULL, category VARCHAR(30) COMMENT '分类：通知/财务/建设/其他', publish_user VARCHAR(32) COMMENT '发布人账号', publish_time DATETIME COMMENT '发布时间', status TINYINT NOT NULL DEFAULT 0 COMMENT '0草稿 1已发布 2已下架', view_count INT DEFAULT 0, create_by VARCHAR(32), create_time DATETIME, update_by VARCHAR(32), update_time DATETIME ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='村务公开表';

publish_time必须在后端发布操作时生成，不要接受前端传值，不然谁都能给自己造一个发布时间。status让「草稿→发布→下架」的流转可追溯，已发布的公告不能物理删除，只能先下架，这在第 4 章的 Service 代码里会体现。

3.3 公共字段与数据字典：少写重复代码

所有业务表都带create_by、create_time、update_by、update_time四件套，这是审计底线。哪天乡镇问「这条补贴谁录的、什么时候改的」，没有这四列你什么都查不了。Java 侧做一个BaseEntity让业务实体继承：

public class BaseEntity { private String createBy; private LocalDateTime createTime; private String updateBy; private LocalDateTime updateTime; }

MyBatis Plus 可以用MetaObjectHandler自动填充这两个时间字段；原生 MyBatis 就在 Service 层统一 set，别在每一条 insert 里手动写。另外还有三张表要补全：房屋表house，关键字段是户主 ID、建筑面积、结构类型、安全隐患等级；农田表farmland，关键字段是承包户 ID、地块编号、面积、流转状态；数据字典表sys_dict，存dict_type、dict_value、dict_label、sort，补贴类型、村务分类这些可增删的选项都放这里。用户表sys_user在起步阶段可以不建完整 RBAC，一个role_code字段区分管理员和普通干部就够，等角色多了再拆sys_role和sys_user_role。九张表到这里就齐了，后面写代码基本是围着它们转。

4. 核心链路代码走读：登录、权限与村务管理的完整闭环

从打开登录页到发布一条村务公告，把 Java 后端的主链路完整走一遍。框架是 Spring Boot + MyBatis，页面用 Thymeleaf，代码不追求炫技，关键是让你看懂每一层在干什么。拿到源码后，建议按这条链路去读，比从头翻文件高效得多。

4.1 登录态与权限拦截：HandlerInterceptor 下的会话管理

登录接口是整套系统的入口，先看 Controller：

@Controller public class LoginController { @PostMapping("/login") public String login(String username, String password, HttpSession session, Model model) { SysUser user = userService.findByUsername(username); // 密码用 BCrypt 加盐哈希，不能用明文比对 if (user != null && passwordEncoder.matches(password, user.getPassword())) { session.setAttribute("loginUser", user); return "redirect:/dashboard"; } model.addAttribute("error", "用户名或密码错误"); return "login"; } @GetMapping("/logout") public String logout(HttpSession session) { session.invalidate(); return "redirect:/login"; } }

这里用HttpSession而不是 JWT，原因很简单：页面是后端渲染的，浏览器自动维护 Cookie，session 方案最自然。JWT 是给前后端分离接口用的，硬塞进来反而要自己处理 token 存储和刷新，属于过度设计。密码校验只依赖spring-security-crypto一个库就能用BCryptPasswordEncoder，不需要把整套 Spring Security 引进来。

登录之后的请求拦截，用一个HandlerInterceptor就能解决：

public class AuthInterceptor implements HandlerInterceptor { @Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception { SysUser user = (SysUser) request.getSession().getAttribute("loginUser"); if (user == null) { response.sendRedirect("/login"); return false; } // 角色校验可按注解扩展，这里只做最基础的登录校验 return true; } }

在配置类里注册拦截路径：

@Configuration public class WebConfig implements WebMvcConfigurer { @Override public void addInterceptors(InterceptorRegistry registry) { registry.addInterceptor(new AuthInterceptor()) .addPathPatterns("/**") .excludePathPatterns("/login", "/css/**", "/js/**", "/images/**"); } }

excludePathPatterns别漏了静态资源，否则登录页的 CSS 全部白屏。如果要做角色细粒度控制，在这个拦截器里读 session 中的roleCode判断，或者定义一个@RequireRole("admin")注解，在拦截器里反射拿到方法上的注解做校验，都比只在页面里隐藏按钮靠谱。

4.2 村务公开的增删改查：三层职责怎么分

村务公开是整个系统最典型的 CRUD 模块，看 Controller 怎么收口：

@Controller @RequestMapping("/affairs") public class VillageAffairController { @GetMapping("/list") public String list(@RequestParam(defaultValue = "1") int pageNum, @RequestParam(defaultValue = "10") int pageSize, String title, Model model) { PageInfo<VillageAffair> page = affairService.pageQuery(pageNum, pageSize, title); model.addAttribute("page", page); return "affair/list"; } @PostMapping("/save") public String save(VillageAffair affair) { affairService.saveAffair(affair); return "redirect:/affairs/list"; } @PostMapping("/delete") public String delete(Long id) { affairService.deleteAffair(id); return "redirect:/affairs/list"; } }

Controller 只做三件事：收参、调服务、决定跳转。删除和保存用 POST 而不是 GET，避免 URL 被收藏或被爬虫反复触发。方法返回的字符串是 Thymeleaf 视图名，对应templates/affair/list.html。

Service 层管业务规则和事务边界：

@Service public class VillageAffairServiceImpl implements VillageAffairService { @Transactional public void deleteAffair(Long id) { VillageAffair affair = affairMapper.selectById(id); if (affair == null) { throw new BusinessException("公告不存在"); } if (affair.getStatus() == 1) { throw new BusinessException("已发布的公告不能直接删除，请先下架"); } affairMapper.deleteById(id); } }

@Transactional保证「校验 + 删除 + 写日志」要么全成功要么全失败，这就是单体里保证数据一致性的直接答案。已发布的公告不给物理删除，强制先走「下架」流程，页面上看不到，后台还留着记录，符合村务留痕的要求。

Mapper 层用 XML 写动态 SQL，分页查询是最高频的场景：

<select id="pageQuery" resultType="com.village.entity.VillageAffair"> select * from village_affairs <where> <if test="title != null and title != ''"> and title like concat('%', #{title}, '%') </if> </where> order by create_time desc limit #{offset}, #{pageSize} </select>

<where>标签会自动处理第一个条件前面的and，避免手写where 1=1的坏味道。分页参数pageNum、pageSize由前端传，后端算出offset传进 SQL。手写 limit 分页最直观，用 PageHelper 也行，但要记住startPage只对紧随其后的第一条查询生效，中间插了别的查询分页就会错乱。

4.3 表单提交与数据回显：HTML 页面如何与 Java 对象绑定

新增和编辑公告共用一个表单页面form.html，Thymeleaf 的属性绑定让这套逻辑非常省事：

<form th:action="@{/affairs/save}" th:object="${affair}" method="post"> <input type="text" th:field="*{title}" placeholder="公告标题" required /> <textarea th:field="*{content}" rows="8"></textarea> <select th:field="*{category}"> <option value="通知">通知</option> <option value="财务">财务</option> <option value="建设">建设</option> </select> <button type="submit">发布公告</button> </form>

th:object="${affair}"绑定后端塞进 Model 的VillageAffair对象，th:field="*{title}"同时完成两件事：输出控件的name属性，并在编辑场景下自动把旧值回显到 input、select 里，不用手写selected判断。提交时浏览器把表单控件按name拼成 POST 参数，Spring MVC 按属性名绑定到对象的字段上。

渲染后的页面是标准 HTML，浏览器右键查看源码看不到任何th:痕迹，数据已经在服务端填好。这就是「Java + HTML」组合最直观的工作方式。如果哪天改成前后端分离，这里的表单会变成 JSON 加@RequestBody，页面由 JavaScript 渲染，那是另一套工程结构，但后端的三层划分可以原样保留。

5. 高频翻车点排查：智慧乡村后端最常踩的五个坑

下面五条是这套系统从开发到部署最容易翻车的地方，顺序基本按项目推进的时间排。每一条都按现象、原因、解决来讲，修过一次之后就不会再犯。

5.1 中文乱码：连接串没带 UTF-8 导致全村名字乱掉

现象是页面新增村民后，列表里名字变成一串问号，或者登录页的提示文字全部乱码。乱码问题是最像玄学的一类报错，但九成是字符集不统一。最常见的原因有两个：JDBC 连接串里没指定字符集，或者建表时没指定utf8mb4。解决方法是连接串显式带上参数：

url: jdbc:mysql://127.0.0.1:3306/village?useUnicode=true&characterEncoding=utf8&serverTimezone=Asia/Shanghai

同时建表语句里统一DEFAULT CHARSET=utf8mb4。注意utf8mb4和utf8的差别：MySQL 的utf8最多存 3 字节，生僻字和人名里的特殊字符会存不进去，utf8mb4才是完整的 UTF-8。页面 HTML 的<head>里也要声明<meta charset="UTF-8">，三层字符集一致，乱码问题基本绝迹。

5.2 日期格式冲突：页面传 2024-07-15 后端直接报 400

表单里有个日期输入框，填2024-07-15，提交后后端直接 400，控制台报Failed to convert property value of type java.lang.String to required type java.util.Date。原因是 Spring MVC 默认的日期转换格式不是yyyy-MM-dd。解决方案是全局注册一个日期编辑器，一次解决所有接口：

@ControllerAdvice public class DateConverterConfig { @InitBinder public void initBinder(WebDataBinder binder) { binder.registerCustomEditor(Date.class, new CustomDateEditor( new SimpleDateFormat("yyyy-MM-dd"), true)); } }

第二个参数true表示允许空字符串转换成null，否则表单里日期不填也会报错。顺手再检查一件事：接口返回 JSON 时的日期格式是不是也统一了，否则前端拿到的是时间戳数字，又得在页面上写格式化函数。

5.3 权限绕过：按钮隐藏不等于接口安全

现象是删除按钮按角色隐藏了，普通干部登录后直接拼 URL 访问/affairs/delete?id=1，数据照样被删掉。原因是前端只是做了展示控制，后端接口没有任何鉴权。按钮隐藏只是用户体验，不是安全边界——后端才是最后一道门，永远不要信任页面。解决方法是给接口加角色校验，先定义一个注解：

@Target(ElementType.METHOD) @Retention(RetentionPolicy.RUNTIME) public @interface RequireRole { String value(); // 例如 "admin" }

在拦截器的preHandle里通过HandlerMethod反射拿到方法上的@RequireRole，与 session 里用户的roleCode比对，不匹配就返回 403 或者重定向到无权限页。写一次，后面所有敏感接口都能用，比在 Controller 里到处写if判断干净得多。

5.4 SQL 注入：MyBatis 的 ${} 是怎么被利用的

现象是列表页的排序功能突然报 SQL 语法错误，或者模糊搜索输入一个%把整张表拖出来。原因大概率是 XML 里用了${}直接拼接参数。${}是字符串替换，#{}是预编译占位符，能用#{}就不要碰${}。但ORDER BY和表名、列名这些位置不能写#{}，常规做法是给排序字段加白名单：

private static final Map<String, String> ORDER_MAP = new HashMap<>(); static { ORDER_MAP.put("createTime", "create_time"); ORDER_MAP.put("updateTime", "update_time"); } // 拼 SQL 时只取 ORDER_MAP.get(key)，查不到就返回默认排序

前端能传的只有白名单里的 key，永远碰不到真实列名。模糊搜索也记住一个写法：like concat('%', #{keyword}, '%')，不要写成like '%${keyword}%'。

5.5 部署后白屏：本地能跑服务器上资源全部 404

现象是本地 IDEA 跑得好好的，java -jar部署到服务器后 CSS 丢失、上传的图片不显示、点开就白屏。原因通常是两类：第一，文件上传写到了项目内的target/classes目录，jar 包内目录不可写；第二，代码里写死了 Windows 风格路径D:\upload，Linux 上根本不认。解决方式是把上传路径抽成配置，再用资源映射暴露出去：

app: file-path: /data/village/upload

@Configuration public class WebConfig implements WebMvcConfigurer { @Value("${app.file-path}") private String filePath; @Override public void addResourceHandlers(ResourceHandlerRegistry registry) { registry.addResourceHandler("/upload/**") .addResourceLocations("file:" + filePath + File.separator); } }

拼接路径不要自己用+拼字符串，用Paths.get(filePath, fileName)，它会自动处理系统分隔符。部署后排查的第一步是打开浏览器控制台看 404 路径——是/upload还是/static，对应到配置去查，比瞎猜快得多。

6. 部署与验收：十分钟自检系统的验证顺序

部署本身不复杂，两条命令的事：

mvn clean package -DskipTests java -jar target/village-management.jar

首次部署记得先把init.sql导进 MySQL，再改application.yml里的数据库连接串。能跑起来不算完，会用才是交付。我每次交付前会按一条固定顺序点一遍：用不同角色登录，复测权限差；新增一个村民，看身份证重复建档是否被拦；给这个人发一笔补贴，确认同一天重复发放存不进去；发布一条村务公告，验证已发布状态不能直接删除；上传一张照片，刷新页面确认外部存储目录生效；最后看操作日志，每一步都留痕。这一组操作把第 5 章的雷区全部覆盖了一遍。

如果这套源码还要往下做，三个方向性价比最高。第一个是把权限从单一角色升级到菜单和按钮粒度，新增sys_menu表和角色授权表，接口从数据库校验权限点，而不是把角色写死在注解里。第二个是给补贴发放加一个@Scheduled定时任务，每月自动把待发放状态转成已发放并生成提醒，Spring 自带能力，不引入额外组件。第三个是操作日志用 AOP 切面统一记录，代替在每个 Service 里手动插入日志——这三个方向做完，这套代码就从「能交差的课程设计」跨到「能接乡镇项目的水平」。

我自己的习惯是交付前把管理员初始密码、测试数据全部清掉再打包。吃过一次上线后被客户拿默认密码登进去的亏，从那以后每次打包前都会扫一遍数据库里的脏数据。这套方案不算惊艳，但每一步都是照着真实项目的血泪经验来的，希望帮到你。

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