企业官网建设流程全解析

简介：一份基于SpringBoot与Vue的法律咨询系统（律师在线服务平台）项目资料，专为需要完整前后端实现方案的Java开发者、毕设学生与中小型律所信息化建设者准备。系统业务划分清晰，包含用户端、律师端、管理员端三大端口，覆盖用户认证、法律咨询、知识服务、个人中心、工作台、案件管理、个人资料、系统管理、内容管理、数据统计与系统监控等子功能，后端采用SpringBoot 2.7，前端使用Vue 3与ElementPlus，数据库选用MySQL 8.0，并集成Redis缓存、WebSocket实时通信、SpringSecurity与JWT安全控制、阿里云OSS文件存储。资源包为7z压缩格式，总计2006个文件，核心包括1840个Markdown说明文档、87个Java源文件、71个XML配置文件及1个SQL数据库脚本，整体体积166.38MB；其中Markdown文档覆盖需求分析、接口设计、部署说明等，Java与XML文件可对照核心逻辑与配置，SQL脚本用于初始化数据库。当前已有138人学习，适合理解法律咨询业务流程、权限设计、前后端交互及实时消息推送等关键技术点，也可作为课程设计或毕业设计的直接参考。

1. 为什么「在线法律咨询」这类系统，难的不是业务而是状态管理

一个用户想找律师，打开系统，浏览律师列表，发起咨询，要么在线等回复、要么预约线下见面，最后按小时或按次付费，完事后再给律师打分。这套流程听起来和电商、外卖没什么两样，但真正动手做过的人会告诉你，坑全藏在「咨询单的生命周期」里。律师的接单状态、咨询方式切换、超时未接、取消与退款、评价时机，这些状态如果不在后端设计阶段就锁死，后面会演变成一场改一处崩三处的灾难。

基于 Spring Boot 与 Vue 的法律咨询系统（也常叫律师在线服务平台），本质是一个前后端分离的业务管理系统：Spring Boot 负责提供业务接口、处理鉴权与支付回调，Vue 负责用户端、律师端和管理端三个视图层。它适合做毕业设计、个人项目、或者小团队做产品验证，技术难点不在 AI 也不在算法，而在于多角色权限、咨询单状态机、即时通信和订单资金处理。本文会从选型、表设计、核心接口、前端联调到部署避坑，按一线开发的顺序把整条链路拆开讲，新手能照步骤跑通，熟手可以对照检查自己的边界设计。

2. 技术选型与总体设计：先定角色权限，再谈业务模块

2.1 为什么是 Spring Boot + Vue 而不是其他组合

如果你去翻各类外包项目的技术栈，Spring Boot + Vue 出现的频率常年排第一。原因很实际：Spring Boot 的 starter 机制让后端集成 Web、Security、JPA/MyBatis、WebSocket 的成本降到最低，而 Vue 的组件化开发和 Element Plus 这类现成管理端组件，让前端页面能在短时间内铺出来。这个组合的生态资料极其丰富，遇到问题搜索即有答案，对于做毕业设计或接小项目的人来说，能快速满足验收需求，后续也方便交给别人维护。

其他备选方案里，后端用 Node.js + NestJS 也能做，但对 Java 技术栈熟悉度要求高、资料相对少；前端用 React 更灵活，但管理端后台的开发速度不如 Vue + Element Plus。我做类似项目时一般会遵循一条原则：优先选团队最熟的技术栈，其次才看技术先进性。Spring Boot 3 + Vue 3 是目前最稳的组合，Spring Boot 2.7 和 Element UI 也仍可用，但如果是从零开始，建议直接用新版本，别在旧依赖上折腾。

2.2 三角色权限模型：用户、律师、管理员

法律咨询平台天然存在三种身份：普通用户（发起咨询的人）、律师（提供服务的人）、管理员（审核与运营的人）。前端路由要按角色做隔离，后端接口也要按角色做鉴权，缺一个都会出现越权操作。这里推荐用 JWT + RBAC（基于角色的访问控制），在 Spring Security 里配置三个角色对应的访问规则，前端通过路由元信息里的 role 字段控制页面可见性。

数据库层面，角色不需要单独建表，在 user 表里加一个 role 字段即可。用户表和律师表要不要分开？我建议别分——律师也是用户，多一套 lawyer_profile 表存执业证号、律所、执业年限等扩展信息就好，这样登录逻辑只用管一张表，查询律师列表时再关联 profile。某开发者在第一次做这类系统时把 user 和 lawyer 拆成两张独立表，结果登录还要判断走哪张表，纯属自找麻烦。

2.3 核心数据表设计与状态机

核心表至少需要这几张：user（用户）、lawyer_profile（律师资料）、consultation（咨询单）、consultation_message（咨询消息）、appointment（预约）、pay_order（支付订单）、evaluation（评价）。咨询单表是业务中枢，需要重点设计状态字段。

CREATE TABLE consultation ( id BIGINT PRIMARY KEY AUTO_INCREMENT, consultation_no VARCHAR(32) NOT NULL COMMENT '咨询单号，业务展示用', user_id BIGINT NOT NULL COMMENT '发起咨询的用户ID', lawyer_id BIGINT NOT NULL COMMENT '接单律师ID', type TINYINT NOT NULL COMMENT '1-在线文字咨询 2-电话咨询 3-预约面谈', status TINYINT NOT NULL DEFAULT 0 COMMENT '0待支付 1待接单 2待回复 3咨询中 4已完成 5已取消 6退款中', amount BIGINT NOT NULL COMMENT '金额，单位分', version INT NOT NULL DEFAULT 0 COMMENT '乐观锁版本号', created_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, updated_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

状态机是这类系统的灵魂。我见过最典型的失误是把状态更新写成一堆散落的 UPDATE 语句，结果有一种路径没考虑，业务数据就卡死在「咨询中」永远结束不了。正确做法是定义一个状态转换校验器，只允许合法的流转路径：待支付 → 待接单 → 待回复 → 咨询中 → 已完成；待支付或待接单状态下用户可以取消。支付回调到达后先判断当前状态是否仍为待支付，防止重复支付。金额字段用 BIGINT 存分而不是 DECIMAL，能避免浮点精度引发对账不平。

3. 后端核心实现：从登录鉴权到咨询会话的闭环

3.1 登录与 JWT 签发的标准写法

登录接口返回 JWT，前端存到 localStorage，后续请求带 Authorization 头。Spring Boot 3 对应 Spring Security 6，写法上比 2.x 略绕，但核心思路不变：放行登录和注册接口，其余请求走过滤链。

// JwtAuthenticationFilter.java @Component public class JwtAuthenticationFilter extends OncePerRequestFilter { @Autowired private JwtUtil jwtUtil; @Override protected void doFilterInternal(HttpServletRequest request, HttpServletResponse response, FilterChain chain) throws ServletException, IOException { String header = request.getHeader("Authorization"); if (header != null && header.startsWith("Bearer ")) { String token = header.substring(7); try { Claims claims = jwtUtil.parseToken(token); // 把 userId 和 role 塞进请求上下文，后续接口直接取用 request.setAttribute("userId", claims.get("userId")); request.setAttribute("role", claims.get("role")); } catch (Exception e) { // token 过期或非法，让 Spring Security 拦截后续鉴权 request.setAttribute("tokenError", "invalid"); } } chain.doFilter(request, response); } }

这段代码在请求到达 Controller 之前先做了一层 JWT 解析，解析成功就把用户身份放到 request 属性里，业务层通过(Long) request.getAttribute("userId")获取当前用户。注意 token 里只放 userId 和 role，不放密码或手机号等敏感信息，如果后续需要律师 ID，可以在登录时查询后一并写入，避免每次请求都查库。密钥放进 application.yml 配置，用@Value读取，不要硬编码在类里。

JWT 过期时间设置需要结合业务场景。普通用户端建议 2 小时，如果用户咨询到一半 token 过期，前端会跳登录页导致体验中断。比较省事的做法是让前端在收到 401 后用 refresh token 静默换新，refresh token 有效期放长到 7 天。但注意，这只适合单机部署，如果未来做多实例负载均衡，JWT 的无状态性反而会变成优点——网关不用维护 session。

3.2 咨询单创建与状态流转的实现

用户发起咨询的接口是整个系统的入口，涉及创建咨询单、锁定律师、生成支付订单三步，必须放在同一个事务里。这里从 Controller 到 Service 的代码值得仔细看。

@Transactional(rollbackFor = Exception.class) public ConsultationDTO createConsultation(CreateConsultationRequest req) { // 1. 校验律师是可接单状态 LawyerProfile lawyer = lawyerMapper.selectById(req.getLawyerId()); if (lawyer == null || !"ACTIVE".equals(lawyer.getStatus())) { throw new BizException("律师不存在或当前离线"); } // 2. 创建咨询单，状态为待支付 Consultation consultation = new Consultation(); consultation.setConsultationNo(generateNo()); consultation.setUserId(UserContext.getUserId()); consultation.setLawyerId(req.getLawyerId()); consultation.setType(req.getType()); consultation.setStatus(0); // 定价规则：文字咨询按条、电话按半小时、面谈按小时，由服务端计算 consultation.setAmount(priceCalculator.calculate(req.getType(), lawyer)); consultationMapper.insert(consultation); // 3. 生成支付订单，金额与咨询单一致 PayOrder payOrder = new PayOrder(); payOrder.setOrderNo(generateNo()); payOrder.setConsultationId(consultation.getId()); payOrder.setAmount(consultation.getAmount()); payOrder.setStatus(0); payOrderMapper.insert(payOrder); return ConsultationConverter.toDTO(consultation, payOrder); }

这个方法里容易踩坑的是事务边界。支付成功回调后续更新咨询单状态，回调接口也要单独加事务，不要和 create 放在一起。priceCalculator.calculate是定价规则的服务类，不同类型的咨询有不同的计费单位，但最终落到consultation表的amount字段统一按分存储。生成订单号时注意用 Redis 自增或数据库雪花 ID，不要直接用System.currentTimeMillis()拼接，并发下极易重复。

律师接单操作要加行级锁或乐观锁，否则两个律师同时点击接单，只有一个人能成功。常见的做法是 UPDATE 语句带WHERE status = 1，影响行数为 0 则说明被别人抢先了。咨询单状态从「待接单」变为「待回复」时，需要把对应律师 ID 写进 consultation 表——这里涉及一个业务规则：用户可以直接指定律师，也可以发布悬赏让多个律师抢单。如果支持抢单模式，需要在表里加一个bidding字段或单独建一张接单记录表，否则无法追踪谁抢过单。

3.3 咨询会话：WebSocket 与在线状态

在线文字咨询需要实时收发消息，HTTP 轮询不是不能用，但体验差、浪费资源。Spring Boot 集成 WebSocket 的复杂度中等，主要坑点在于鉴权和分布式扩展。单体应用阶段，直接在握手拦截器里校验 JWT 最简单。

// WebSocketConfig.java @Configuration public class WebSocketConfig implements WebSocketConfigurer { @Override public void registerWebSocketHandlers(WebSocketHandlerRegistry registry) { registry.addHandler(chatHandler(), "/ws/chat") .addInterceptors(new JwtHandshakeInterceptor()) .setAllowedOriginPatterns("*"); } }

// JwtHandshakeInterceptor.java public class JwtHandshakeInterceptor implements HandshakeInterceptor { @Override public boolean beforeHandshake(ServerHttpRequest request, ServerHttpResponse response, WebSocketHandler wsHandler, Map<String, Object> attributes) { String query = request.getURI().getQuery(); // 前端建立连接时在 URL 上带 token，比 header 方便 Map<String, String> params = parseQuery(query); String token = params.get("token"); Long userId = jwtUtil.parseToken(token).get("userId", Long.class); if (userId == null) { return false; } attributes.put("userId", userId); return true; } }

WebSocket 建立连接后，每个会话要维护 userId 到 WebSocketSession 的映射。消息发送的核心逻辑是：用户发一条消息，后端存库，然后推送给对方。这里推荐先存库再推送，因为推送失败时消息不能丢，对方下次上线还能拉取历史记录。消息表里要有clientMsgId字段，前端生成 UUID，后端用来做幂等去重——WebSocket 断线重连后前端会把未确认的消息重发一遍，没有幂等字段会出现消息重复。

单机部署的会话管理用 ConcurrentHashMap 就能满足。如果未来扩展成多实例，WebSocket 会话会分散在不同机器上，推送时需要用 Redis Pub/Sub 或 MQ 做消息广播，这个复杂度是成体系的，建议在业务量真正起来之前不要碰。

3.4 支付回调处理：本地模拟支付的成功路径

真实对接微信或支付宝需要商户号资质，个人开发很难办。大多数做毕业设计或演示的人会走「模拟支付」路线：前端点支付按钮后，直接调后端一个 mock 支付接口，接口内部模拟支付成功回调并更新订单状态。虽然形式上简化了，但回调逻辑必须按真实场景写，否则后面接真实渠道时要返工。

@Transactional(rollbackFor = Exception.class) public void handlePayCallback(String outTradeNo, String tradeNo) { PayOrder payOrder = payOrderMapper.selectByOrderNo(outTradeNo); if (payOrder == null) { throw new BizException("订单不存在"); } if ("SUCCESS".equals(payOrder.getStatus())) { // 幂等处理：已处理过的回调直接返回 return; } payOrder.setStatus("SUCCESS"); payOrder.setTradeNo(tradeNo); payOrderMapper.updateById(payOrder); // 更新咨询单状态：待支付 -> 待接单 int updated = consultationMapper.updateStatus( payOrder.getConsultationId(), 0, 1); if (updated == 0) { throw new BizException("咨询单状态异常，需人工介入"); } }

模拟支付接口被调用的前提是业务层不区分真实支付还是模拟支付，只认支付成功这一事实，这样后续接支付网关时只替换掉 mock 部分。updateStatus用了乐观锁的思路，状态从 0 变 1 必须基于当前状态确实是 0，防止并发场景下状态被覆盖。真实支付回调是异步到达的，可能比用户点击支付按钮晚几秒，所以前端在点击支付后不要立即轮询订单状态，应该把「等待支付结果」的动作放在 WebSocket 回调或 3 秒后轮询上。

4. 前端工程化实现：路由隔离与咨询会话页

4.1 Vue 3 项目结构与路由角色守卫

前端工程推荐用 Vite 构建，目录结构按模块划分：api/放 axios 封装和各业务接口，views/user/、views/lawyer/、views/admin/分角色放页面，router/里配置带 meta.role 的路由表，stores/用 Pinia 管理用户状态。

// router/index.js const routes = [ { path: '/login', component: () => import('@/views/Login.vue'), meta: { public: true } }, { path: '/consult', component: () => import('@/views/user/ConsultCreate.vue'), meta: { role: 'USER' } }, { path: '/lawyer/orders', component: () => import('@/views/lawyer/OrderList.vue'), meta: { role: 'LAWYER' } }, { path: '/admin/audit', component: () => import('@/views/admin/LawyerAudit.vue'), meta: { role: 'ADMIN' } } ]; router.beforeEach((to, from, next) => { const token = localStorage.getItem('token'); if (to.meta.public) { next(); return; } if (!token) { next('/login'); return; } const role = localStorage.getItem('role'); if (to.meta.role && to.meta.role !== role) { next('/403'); return; } next(); });

路由守卫只做两件事：没登录的跳登录页，角色不对的跳 403 页。但注意，这只防君子不防小人，真正安全的鉴权在后端接口。有些开发者出现过一个案子：用户在浏览器手动改 localStorage 里的 role 为管理员，就能进管理页面，虽然看不了数据（后端拦截了），但这个交互暴露了前端鉴权的脆弱性。前端控制页面展示，后端控制数据权限，必须双层设防。

meta.role是字符串而不是数组，因为一个用户只有一个角色，用数组是做了多余的设计。后续如果要加「超级管理员」之类的角色，扩展成数组也不迟，但现阶段越简单越好。

4.2 Axios 封装与 token 刷新

axios 实例的封装重点在请求拦截器和响应拦截器，这是前后端联调时的关键环节。

// api/request.js import axios from 'axios'; import router from '@/router'; const request = axios.create({ baseURL: '/api', timeout: 10000 }); request.interceptors.request.use(config => { const token = localStorage.getItem('token'); if (token) { config.headers.Authorization = `Bearer ${token}`; } return config; }); request.interceptors.response.use( response => response.data, error => { if (error.response?.status === 401) { localStorage.removeItem('token'); localStorage.removeItem('role'); router.push('/login'); } return Promise.reject(error); } );

后端返回格式建议统一为{ code: 0, data: ..., message: 'ok' }，code 非 0 视为业务失败。不要直接把 HTTP 状态码当业务码用——支付超时导致的业务失败返回 200 但 code=50001，前端能直接在拦截器里统一弹出错误提示。baseURL: '/api'配合后端 context-path 或前端 Vite 代理，可以避免跨域问题在浏览器层反复出现。

如果加了 refresh token 刷新逻辑，响应拦截器要做成队列：多个请求同时返回 401，只发一次刷新请求，其余请求挂起等待新 token 后就重放。这是个大坑，我见过不少团队把刷新请求发成了 N 个导致雪崩。对于个人项目，先简单处理也可以——401 就强制重新登录，代价是体验差一点，但换来实现简单。

4.3 咨询会话页：消息渲染与 WebSocket 客户端封装

咨询会话页面是用户端使用频率最高的界面，核心是消息列表 + 输入框 + 状态提示。WebSocket 客户端封装要注意连接时机：进入页面时建立连接，离开页面时关闭连接，并处理断线重连。

// api/chat.js export class ChatClient { constructor(token, onMessage) { this.ws = new WebSocket(`ws://localhost:8080/ws/chat?token=${token}`); this.ws.onmessage = e => { const msg = JSON.parse(e.data); onMessage(msg); }; this.ws.onclose = () => { // 指数退避重连：1s 2s 4s ... 最大30s setTimeout(() => this.reconnect(), this.getBackoff()); }; } send(content, clientMsgId) { this.ws.send(JSON.stringify({ type: 'CHAT', content, clientMsgId })); } }

消息渲染要注意时间分组和发送状态。每条消息要有status字段：发送中、已发送、发送失败。用户发送消息后先用 clientMsgId 在本地渲染一条「发送中」的占位消息，后端推送 ack 后再改成「已发送」，失败则提示重发。这个模式在 IM 系统里是标配，但在咨询场景里容易被人忽略——如果消息发送失败没有任何提示，用户会以为律师已读不回，实际是消息根本没送达。

消息已读未读功能不要做太复杂。简单做法是用户进入会话页时调一个markRead(consultationId)接口，后端把该会话下所有未读消息批量置为已读。如果做成单条消息确认，数据库压力大且逻辑复杂，对咨询场景收益有限。

4.4 前后端联调：时间格式、枚举值、长文本三个典型问题

联调时遇到最多的三类问题，基本上是每个项目都会踩一遍的：第一，LocalDateTime 序列化格式问题，后端返回的是 ISO 标准字符串，前端需要显示2025-06-01 14:30这种格式，最好在后端统一配置 Jackson 的日期格式，别依赖前端到处转；第二，枚举值传参问题，后端的type字段在 Java 里是 Integer，在数据库是 TINYINT，前端必须用数字而不是字符串，建议在接口文档里写清每个数字的含义，或者后端返回时附带上枚举文案。

{ "code": 0, "data": { "consultationId": 1001, "type": 1, "typeText": "在线文字咨询", "status": 2, "statusText": "待回复", "createdAt": "2025-06-01 10:30:00" } }

后端返回对象中带typeText和statusText，前端直接渲染文本，不做二次映射。这样前端代码量少、不易出错，代价是后端多查一次枚举字典，性能可忽略。长文本问题主要表现在两个地方：律师简介、咨询记录。数据库字段用 TEXT 类型没问题，但列表接口千万不要把 TEXT 字段全量返回，用 SQL 截断或单独提供详情接口，否则列表页会一下子传 5KB 的文字，接口耗时翻倍。

5. 避坑指南：法律咨询系统开发中常见的 6 个典型问题

5.1 咨询单状态被并发修改，数据直接错乱

现象：律师端和管理员端同时操作同一个咨询单，前一个请求刚把状态从「待回复」改成「咨询中」，后一个请求还在用旧状态做判断，导致状态被覆盖回「待回复」。原因：没有做乐观锁控制，多个请求读取到同一状态后各自更新，后更新的覆盖先更新的。解决：在 consultation 表加version字段，更新语句强制带WHERE version = #{oldVersion}，更新成功后 version +1。如果影响行数为 0，说明有人已改过，重新查库再做决策。对资金相关的订单表，同样的策略必须做到位，这关系到对账。

5.2 WebSocket 连接鉴权被绕过

现象：有人不经过登录页，直接构造 WebSocket 连接请求，就能连上 chat 端点。原因：setAllowedOriginPatterns("*")放行了所有来源，而握手拦截器没有校验 token。解决：JwtHandshakeInterceptor 里必须解析并校验 token，校验失败返回 false 拒绝握手。注意 WebSocket 的 URL 会在浏览器 network 面板里暴露，token 放在 query string 里本来就存在泄露风险，生产环境应该改成在首次 HTTP 请求时下发一次性 ticket，用 ticket 建立 WebSocket，但这个方案的复杂度较高，单体演示阶段放 query 里加 HTTPS 也能接受。

5.3 支付金额单位不统一，对账不平

现象：咨询单存的是「分」，前端显示时除以 100，但订单表某些历史数据存的却是「元」，导致统计报表金额全错。原因：前后端开发时没有约定统一单位，出现了一个用 Integer 存元、一个用 Long 存分的拼接情况。解决：所有金额字段一律用 Long 存分，DTO 出参时转成 BigDecimal 的元，前端展示用(amount / 100).toFixed(2)。这个规则要写进接口文档第一页，并在代码 review 时重点核对。

5.4 消息重发导致咨询记录重复

现象：用户网络波动，消息发出后客户端没收到 ack，点击重发，律师看到两条一模一样的消息。原因：缺少客户端消息幂等机制。解决：前端生成clientMsgId（UUID），后端在消息入库前先查该 ID 是否已存在，存在则直接返回成功但不重复入库。这个字段在数据库里要建唯一索引，不建索引的幂等判断在高并发下形同虚设。

5.5 事务范围内调用 WebSocket 推送导致连接泄漏

现象：消息存库和 WebSocket 推送放在同一个事务里，推送时网络超时抛异常，事务回滚后数据库没存上，但部分用户已经收到了推送，状态不一致。原因：把耗时操作写进了事务里。解决：事务只负责数据库写入，WebSocket 推送放在事务提交之后。可以用@TransactionalEventListener监听事务提交事件，或者把推送逻辑放到 service 方法的 finally 块外面调用。

5.6 时区问题导致预约时间差 8 小时

现象：律师设置「明天 10:00 可约」，用户在页面上看到的是「18:00」。原因：前端把本地时间转成了 ISO 字符串传给后端，后端按 UTC 存储，查询时又没转回东八区。解决：在 Spring Boot 里统一设置 Jackson 时区为GMT+8，MySQL 连接串也加serverTimezone=Asia/Shanghai。所有时间接口的入参出参统一用东八区字符串，不存带时区的 ISO 格式，这是最省心的做法。

6. 进阶思路与验证方法：从能演示到能上线

本地跑通这个项目的标准路径是：启动 MySQL 和 Redis，导入初始化 SQL，启动后端，启动前端，注册一个用户和律师账号，跑通「用户创建咨询 → 模拟支付 → 律师接单 → 双方 WebSocket 聊天 → 完成咨询 → 评价」这条闭环。建议用一个 37 行的 shell 或 docker-compose 把 MySQL 和 Redis 拉起来，后端用mvn spring-boot:run启动，前端npm run dev，十分钟内能进入开发自测状态。

再往后走，有四个高价值进阶方向：第一，接入全文检索，用 Elasticsearch 替代 MySQL 的 LIKE 搜索律师擅长领域，查询速度和匹配质量会提升一个量级；第二，律师推荐算法，根据用户浏览行为和历史咨询记录做简单推荐，用协同过滤在本地就能跑；第三，电子签章和文书在线生成，咨询结束后自动生成一份咨询意见书 PDF，这个功能在面向企业客户时很有说服力；第四，接入真实支付网关和短信服务，把模拟模块换成真实渠道，系统就具备了上线条件。

每个方向改完后都建议做一次回归验证：重点测试并发接单场景、消息幂等场景和支付回调幂等场景。前两次做这类系统时习惯重功能轻边界，上线后才被并发问题打脸。现在做任何改动都会先跑一遍状态机逻辑的自测，确认所有路径都走得通。技术方案没有银弹，把状态管理、幂等控制、角色边界这三件事做扎实，这个系统就已经能扛住真实业务了。希望帮到你。

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