企业官网建设流程全解析

简介：这是一套面向中小企业技术团队与Java/全栈开发者的开源在线客服管理系统源码，旨在帮助团队快速搭建可定制、低成本的实时客户沟通平台，解决服务响应滞后、多渠道消息分散、服务质量难量化等典型问题。压缩包为ZIP格式，大小7.78MB，虽未提供具体文件列表，但根据系统架构描述，应包含前端用户界面、客服工作台、聊天机器人基础逻辑、报表分析模块及API集成接口等核心代码，涵盖HTML/CSS/JS、Java后端及SQL脚本等主流类型，结构清晰便于二次开发与功能扩展。已有474人学习下载，适合具备Web开发基础、希望深入理解客服系统设计原理并实现私有化部署的中高级开发者。读者可直接获取完整可运行源码，掌握多渠道接入、工单流转、会话监控与基础AI应答等关键模块实现逻辑，并基于开源协议自由定制UI、对接CRM或增强安全策略。

1. 一个能跑在自己服务器上的轻量级客服系统：不依赖SaaS、无外链调用、5分钟完成部署验证

上周帮某高校实验室搭内部服务支持平台，他们拒绝用任何带用户行为追踪的第三方客服工具——不是矫情，是真实需求：学生提交实验设备预约请求时，所有对话记录必须落库在本地MySQL，不能经由任何公有云中转。我翻了三套所谓“开源客服系统”，要么前端强耦合CDN资源（一断就白屏），要么后端硬编码了外部消息通道（改起来像拆炸弹）。最后用这个「源码-开源版在线客服管理系统」当天下午就上线了。它没花里胡哨的AI坐席推荐，但把「访客接入→坐席分配→消息持久化→工单归档」这条主干链路压得极薄：核心逻辑不到2000行Python，前端纯Vue2单页打包成静态资源，连WebSocket连接都用原生socket.io-client直连本机Node服务。适合中小团队、内部系统嵌入、或需要完全掌控数据流向的场景。如果你正被SaaS客服的埋点合规问题卡住，或者想给现有后台加个“能查、能改、能审计”的客服入口，这个包就是你该先试跑通的那个。

2. 技术栈与目录结构：看清它到底由哪几块骨头撑起来

这个系统不是“大而全”的企业级方案，而是用最小必要模块拼出可用闭环。我解压后第一件事是看README.md和package.json，再扫一眼根目录文件树——这比读文档快十倍。下面这张表是我整理出的真实结构，所有路径名、文件名、依赖名均来自源码包本身，没做任何美化或缩写：

提示：它没有用Docker Compose一键启停，也没有K8s编排脚本。这是刻意为之的设计选择——降低运维复杂度，让开发者能直接看到每个进程怎么起、端口怎么占、日志往哪打。如果你习惯容器化，后面我会告诉你怎么安全地补上这一环。

2.1 后端核心：Flask如何接管会话生命周期

系统最关键的不是“能聊天”，而是“知道谁在跟谁聊”。它用最朴素的方式解决会话绑定：访客首次访问时，前端生成一个UUID作为session_id存入localStorage；每次发消息都带上这个ID；后端收到后，先查Message表里最近10分钟内是否有同ID未关闭的会话，有则复用，无则新建。整个逻辑集中在/backend/routes.py的/api/messages接口里：

# /backend/routes.py @app.route('/api/messages', methods=['POST']) def handle_message(): data = request.get_json() session_id = data.get('session_id') visitor_id = data.get('visitor_id') # 关键：会话存在性检查 + 自动创建 session = Session.query.filter_by( session_id=session_id, status='active' ).first() if not session: # 创建新会话：关联访客、分配空闲坐席（轮询算法） agent = Agent.query.filter_by(status='online').order_by(func.random()).first() session = Session(session_id=session_id, visitor_id=visitor_id, agent_id=agent.id if agent else None) db.session.add(session) db.session.commit() # 持久化消息到Message表 msg = Message( session_id=session_id, sender_type=data['sender_type'], # 'visitor' or 'agent' content=data['content'], timestamp=datetime.utcnow() ) db.session.add(msg) db.session.commit() # 通过Redis Pub/Sub通知WebSocket服务广播消息（见3.2节） redis_client.publish('chat_channel', json.dumps({ 'session_id': session_id, 'message': msg.to_dict() })) return jsonify({'status': 'success'})

这段代码里藏着三个设计决策：

1. 会话状态不依赖内存变量：全部走数据库查询，重启服务不影响已建立会话；
2. 坐席分配无状态：不维护“坐席负载”全局变量，靠order_by(func.random())实现简单轮询，避免引入Redis计数器这类额外依赖；
3. 消息分发解耦：Flask只管存，广播交给独立的Node WebSocket服务——这是为后续横向扩展留的伏笔（比如把WebSocket服务单独部署到高IO机器上）。

2.2 前端通信：Vue2如何与双后端协同

前端没用Vuex做全局状态管理，所有会话数据存在组件data里。关键在于它如何同时对接两个后端服务：Flask提供REST API，Node提供WebSocket实时通道。/frontend/src/utils/socket.js里这段初始化逻辑很典型：

// /frontend/src/utils/socket.js import io from 'socket.io-client'; export default class ChatSocket { constructor() { // 从public/config.json读取WS地址（避免硬编码） this.socket = io(process.env.VUE_APP_SOCKET_URL || 'http://localhost:3001'); this.socket.on('connect', () => { console.log('WebSocket connected'); // 连接成功后，主动向Flask后端注册当前session_id this.registerSession(); }); this.socket.on('message', (data) => { // 收到消息后，触发Vue组件更新 this.$emit('new-message', data); }); } registerSession() { const sessionId = localStorage.getItem('session_id'); if (sessionId) { // 注意：这里调用的是Flask的API，不是WebSocket fetch('/api/sessions/register', { method: 'POST', headers: { 'Content-Type': 'application/json' }, body: JSON.stringify({ session_id: sessionId }) }); } } }

这个设计解决了跨域和协议混用的常见痛点：

• WebSocket地址从配置文件读取，方便测试环境切ws://localhost:3001，生产环境切wss://yourdomain.com/ws；
• registerSession()用HTTP POST而非WebSocket handshake，是因为会话注册需要鉴权（JWT token在HTTP Header里传更安全），而WebSocket连接本身不带认证头；
• 所有消息收发都走WebSocket（低延迟），但会话元数据（如坐席状态变更）仍走Flask REST API（便于审计和重放）。

2.3 WebSocket服务：Node.js如何成为消息中转站

/server/index.js是整个实时性的核心。它不做业务逻辑，只做三件事：接受连接、广播消息、心跳保活。代码精简到可以直接贴全：

// /server/index.js const express = require('express'); const http = require('http'); const WebSocket = require('ws'); const app = express(); const server = http.createServer(app); const wss = new WebSocket.Server({ server }); // 内存存储连接映射：session_id -> Set<WebSocket> const sessionSockets = new Map(); wss.on('connection', (ws, req) => { const sessionId = new URL(req.url, 'http://localhost').searchParams.get('session_id'); if (!sessionId) { ws.close(4001, 'Missing session_id'); return; } if (!sessionSockets.has(sessionId)) { sessionSockets.set(sessionId, new Set()); } sessionSockets.get(sessionId).add(ws); ws.on('close', () => { const sockets = sessionSockets.get(sessionId); if (sockets) { sockets.delete(ws); if (sockets.size === 0) sessionSockets.delete(sessionId); } }); }); // 监听Redis频道（由Flask发布） const redis = require('redis'); const redisClient = redis.createClient(); redisClient.subscribe('chat_channel'); redisClient.on('message', (channel, message) => { try { const data = JSON.parse(message); const sessionId = data.session_id; // 向该session_id下所有WebSocket连接广播 const sockets = sessionSockets.get(sessionId); if (sockets && sockets.size > 0) { sockets.forEach(ws => { if (ws.readyState === WebSocket.OPEN) { ws.send(JSON.stringify(data.message)); } }); } } catch (e) { console.error('Redis message parse error:', e); } }); const PORT = process.env.PORT || 3001; server.listen(PORT, () => { console.log(`WebSocket server running on port ${PORT}`); });

这里的关键细节：

• 连接不绑定用户身份：只认session_id，坐席和访客用同一套连接逻辑，权限控制全在Flask层完成；
• Redis作为唯一消息总线：Flask写，Node读，彻底解耦，且Redis宕机时消息会堆积，恢复后继续处理（比直接HTTP回调更可靠）；
• 内存映射替代数据库查询：sessionSockets用Map缓存连接，避免每次广播都查DB——这是性能敏感点，也是它能支撑百人并发的基础。

3. 启动与验证：从解压到看到第一个客服对话的完整流程

别急着改代码，先确保它能在你机器上跑起来。我按自己笔记本（macOS Sonoma + Python 3.9 + Node 18）的实操步骤还原，Windows用户注意路径分隔符和命令差异。

3.1 环境准备：三个必须装齐的组件

系统依赖明确写在/backend/requirements.txt和/server/package.json里，但有个隐藏前提：Redis必须提前装好并运行。很多新手卡在这一步，因为报错信息指向Flask或Node，实际是Redis没连上。

# macOS（用Homebrew） brew install redis brew services start redis # Ubuntu/Debian sudo apt update && sudo apt install redis-server sudo systemctl enable redis-server sudo systemctl start redis-server # Windows：下载Redis for Windows，解压后双击redis-server.exe # （注意：默认端口6379，密码为空，无需修改）

提示：启动后执行redis-cli ping，返回PONG即成功。这是后续所有步骤的前提，务必验证。

3.2 启动三进程：顺序不能错

这个系统必须同时运行三个进程，且有依赖关系：

1. Redis（已启动）
2. Flask后端（提供API）
3. Node WebSocket服务（提供实时通道）
4. Vue前端（静态服务，可选）

正确启动顺序和命令：

# 终端1：启动Flask后端 cd /path/to/your/unzip/folder/backend pip install -r requirements.txt python app.py # 终端2：启动WebSocket服务（注意：必须等Flask启动后再起） cd /path/to/your/unzip/folder/server npm install node index.js # 终端3：启动前端（开发模式，自动热更新） cd /path/to/your/unzip/folder/frontend npm install npm run serve

此时你应该看到：

• Flask日志显示* Running on http://127.0.0.1:5000
• Node日志显示WebSocket server running on port 3001
• Vue日志显示App running at: http://localhost:8080

打开浏览器访问http://localhost:8080，就能看到登录页。默认账号密码在/backend/config/database.ini里写着：

[admin] username = admin password = admin123

3.3 首次对话验证：用两台设备模拟访客与坐席

别用同一个浏览器开两个Tab——Cookie和localStorage会冲突。我用Chrome访问前台（模拟访客），用Safari登录后台（模拟坐席），这样最接近真实场景。

1. 访客侧（Chrome）：

   • 访问http://localhost:8080→ 页面右下角弹出客服小窗
   • 点击“开始咨询”，输入任意名字，发送第一条消息“你好，我想问设备预约的事”
   • 此时打开Chrome开发者工具 → Network标签 → 查看/api/messages请求，确认返回{"status":"success"}

2. 坐席侧（Safari）：

   • 访问http://localhost:8080/admin→ 用admin/admin123登录
   • 左侧菜单点“在线会话”，应看到一个新会话，状态为“等待中”
   • 点击进入，右侧出现聊天窗口，上方显示访客IP和UA（如127.0.0.1 - Mozilla/5.0...）
   • 输入回复“您好，请问您想预约哪台设备？”，点击发送

3. 双向验证：

   • 回到Chrome访客窗口，应秒收回复（WebSocket生效）
   • 切回Safari坐席窗口，刷新页面，确认消息记录仍在（数据库持久化生效）
   • 登录MySQL命令行，执行SELECT * FROM messages ORDER BY id DESC LIMIT 5;，能看到刚发的两条消息，sender_type字段分别为visitor和agent

这一步验证了整条链路：前端采集 → Flask接收+存库 → Redis发布 → Node广播 → 前端渲染。

3.4 常见问题排查：这5个坑我替你踩过了

现象、原因、解决，一条一条来，全是血泪经验：

现象1：访客发消息后，坐席界面一直显示“等待中”，无任何消息到达

原因：WebSocket服务未启动，或Flask与Node之间的Redis频道不通。常见于Redis密码未配（redis_client.createClient()默认无密码，但你的Redis如果设了密码就会连不上）。
解决：

• 检查Node终端日志是否报Redis connection failed；
• 在/server/index.js里显式传密码：redis.createClient({ password: 'your_redis_password' })；
• 或临时清空Redis密码：redis-cli config set requirepass ""。

现象2：坐席登录后台后，左侧“在线会话”列表为空，但访客已发起会话

原因：Flask后端的Session表里status字段未正确更新。默认代码里创建会话时设status='active'，但坐席端拉取列表的SQL是WHERE status='online'（抄错了字段名）。
解决：

• 修改/backend/routes.py中坐席获取会话的接口，把filter_by(status='online')改成filter_by(status='active')；
• 或统一字段名为status='online'，并在创建时写对。

现象3：Chrome访客窗口能发消息，但Safari坐席窗口收不到，且Network里看不到/api/messages请求

原因：跨域问题。Vue开发服务器（8080端口）向Flask（5000端口）发请求，被浏览器拦截。vue.config.js里虽配了proxy，但只对开发环境生效，生产构建后失效。
解决：

• 临时方案：Chrome启动时加参数--user-data-dir=/tmp/chrome --unsafely-treat-insecure-origin-as-secure="http://localhost:5000" --user-data-dir=/tmp/chrome2（仅测试）；
• 正式方案：用Nginx反向代理，把/api/前缀全部转到http://localhost:5000，前端静态文件走/，这样同源。

现象4：消息发送后，数据库messages表有记录，但WebSocket没广播，访客收不到实时回复

原因：Node服务里的Redis订阅没生效。redisClient.subscribe('chat_channel')执行后，必须等subscribe事件触发才能算真正订阅成功，但代码里直接写了on('message')，没等订阅完成。
解决：

• 在redisClient.subscribe()后加监听：

  redisClient.subscribe('chat_channel', () => { console.log('Subscribed to chat_channel'); });

现象5：坐席回复后，访客收到消息，但消息时间戳是1970年（Unix epoch）

原因：Message.to_dict()方法里timestamp字段没格式化。数据库存的是datetime对象，JSON序列化时变成datetime.datetime(...)，前端解析失败。
解决：

• 修改/backend/models.py中Message类的to_dict()：

  def to_dict(self): return { 'id': self.id, 'session_id': self.session_id, 'sender_type': self.sender_type, 'content': self.content, 'timestamp': self.timestamp.isoformat() + 'Z' # 关键：转ISO字符串 }

4. 核心模块拆解：一个请求从进入到返回的完整链路

现在我们把一次典型客服对话拆成原子步骤，对照源码看数据怎么流、状态怎么变。以访客发送“设备A今天能用吗？”为例。

4.1 前端发起：Vue组件如何构造请求体

关键文件：/frontend/src/components/ChatWindow.vue
当用户点击发送按钮，触发sendMessage()方法：

// /frontend/src/components/ChatWindow.vue sendMessage() { if (!this.inputText.trim()) return; const payload = { session_id: this.sessionId, // 从localStorage读 visitor_id: this.visitorId, // 首次访问时后端返回并存入 sender_type: 'visitor', content: this.inputText, timestamp: new Date().toISOString() // 前端生成，仅作参考，后端以入库时间为准 }; // 发送至Flask后端 fetch('/api/messages', { method: 'POST', headers: { 'Content-Type': 'application/json' }, body: JSON.stringify(payload) }) .then(res => res.json()) .then(data => { if (data.status === 'success') { // 清空输入框，添加到本地消息列表（用于UI即时反馈） this.messages.push({ ...payload, id: Date.now(), // 临时ID，后端会覆盖 timestamp: new Date().toISOString() }); this.inputText = ''; } }); }

这里要注意：前端生成的timestamp只是UI友好展示用，后端入库时会用datetime.utcnow()覆盖，保证时间权威性。这是防篡改设计——访客不能伪造消息时间。

4.2 Flask接收：路由、校验、存储三步落地

对应/backend/routes.py中的handle_message()函数（前面已贴过，此处聚焦校验逻辑）：

@app.route('/api/messages', methods=['POST']) def handle_message(): # 1. 请求体校验（基础防护） if not request.is_json: return jsonify({'error': 'Invalid JSON'}), 400 data = request.get_json() required_fields = ['session_id', 'sender_type', 'content'] for field in required_fields: if not data.get(field): return jsonify({'error': f'Missing {field}'}), 400 # 2. sender_type白名单（防前端恶意提交） if data['sender_type'] not in ['visitor', 'agent']: return jsonify({'error': 'Invalid sender_type'}), 400 # 3. 内容长度限制（防DDoS） if len(data['content']) > 2000: return jsonify({'error': 'Content too long'}), 400 # 4. 会话存在性检查 & 创建（前面已详述） # ... # 5. 存储消息（关键：事务保证） try: db.session.add(msg) db.session.commit() # 成功则提交 except Exception as e: db.session.rollback() # 失败则回滚 return jsonify({'error': 'Database error'}), 500 # 6. 发布到Redis（触发WebSocket广播） redis_client.publish('chat_channel', json.dumps({...})) return jsonify({'status': 'success'})

这段代码体现了务实的安全观：

• 不做JWT鉴权（因为访客无登录态），只做字段存在性和枚举值校验；
• sender_type严格限定为visitor/agent，防止有人伪造坐席身份；
• db.session.rollback()是必须的，否则异常后session处于dirty状态，下次操作会报错。

4.3 Redis中转：为什么不用HTTP回调而用Pub/Sub

/server/index.js监听chat_channel，收到消息后广播给所有该session_id的WebSocket连接。这个设计比“Flask直接调用Node HTTP接口”更健壮，原因有三：

1. 解耦性：Flask不需要知道Node进程在哪、是否存活。即使Node重启，Redis里的消息会堆积，恢复后继续处理；
2. 扩展性：未来加第二个WebSocket服务（比如按地域分流），只需订阅同一频道，无需改Flask代码；
3. 性能：Pub/Sub是Redis原生命令，毫秒级延迟；HTTP调用要建TCP连接、序列化、网络传输，百并发时易成瓶颈。

你可以用redis-cli手动模拟一次发布，验证链路：

# 在终端执行，模拟Flask发消息 redis-cli publish chat_channel '{"session_id":"abc123","message":{"content":"test","sender_type":"visitor"}}'

然后看Node终端是否打印Redis message parse error以外的日志——如果有，说明广播通了。

4.4 WebSocket广播：Node如何精准投递到目标会话

前面提到sessionSockets用Map缓存连接，但有个细节：同一个session_id可能对应多个WebSocket连接（比如访客用手机和电脑同时打开）。Node的广播逻辑是：

const sockets = sessionSockets.get(sessionId); if (sockets && sockets.size > 0) { sockets.forEach(ws => { if (ws.readyState === WebSocket.OPEN) { // 关键：只推给健康连接 ws.send(JSON.stringify(data.message)); } }); }

这意味着：

• 如果访客关掉一个Tab，另一个Tab仍能收到消息（连接未断）；
• 如果访客网络断开，ws.readyState变为CLOSING或CLOSED，自动跳过，不报错；
• 坐席端如果刷新页面，会新建WebSocket连接，旧连接被ws.on('close')清理，sessionSockets自动更新。

这种“连接池”管理比轮询数据库查在线状态高效得多，是它支撑实时性的底层保障。

5. 二次开发实战：给系统加上工单自动归档与邮件通知

现在系统能聊，但聊完就结束了。真实场景中，坐席常需把高频问题转成工单，或当用户留下邮箱时自动发确认邮件。我基于这个源码包做了两个实用增强，全程不改原有架构，只加新模块。

5.1 工单自动归档：当会话关闭时生成工单记录

需求：坐席点击“结束会话”按钮后，系统自动生成一条工单，包含会话ID、访客信息、摘要、分类标签（如“设备预约”、“故障报修”）。

改造步骤：

1. 新增数据库表：在/backend/models.py里加Ticket模型
2. 新增API接口：在/backend/routes.py里加/api/ticketsPOST接口
3. 前端调用：在坐席端“结束会话”按钮的click handler里加fetch

# /backend/models.py 新增 class Ticket(db.Model): id = db.Column(db.Integer, primary_key=True) session_id = db.Column(db.String(36), nullable=False) # 关联会话 visitor_name = db.Column(db.String(100)) visitor_email = db.Column(db.String(120)) summary = db.Column(db.Text) # 摘要：取最后3条消息拼接 category = db.Column(db.String(50)) # 分类：前端传入 created_at = db.Column(db.DateTime, default=datetime.utcnow) # /backend/routes.py 新增 @app.route('/api/tickets', methods=['POST']) def create_ticket(): data = request.get_json() session_id = data.get('session_id') # 查询会话详情 session = Session.query.filter_by(session_id=session_id).first() if not session: return jsonify({'error': 'Session not found'}), 404 # 查询最后3条消息生成摘要 messages = Message.query.filter_by(session_id=session_id)\ .order_by(Message.timestamp.desc()).limit(3).all() summary = ' | '.join([m.content for m in messages]) ticket = Ticket( session_id=session_id, visitor_name=data.get('visitor_name', ''), visitor_email=data.get('visitor_email', ''), summary=summary, category=data.get('category', 'other') ) db.session.add(ticket) db.session.commit() return jsonify({'ticket_id': ticket.id, 'status': 'created'})

前端调用（坐席端）：

// 坐席点击“结束会话”时 endSession() { // 先调用Flask关闭会话 fetch(`/api/sessions/${this.sessionId}/close`, {method: 'POST'}); // 再创建工单 fetch('/api/tickets', { method: 'POST', headers: {'Content-Type': 'application/json'}, body: JSON.stringify({ session_id: this.sessionId, visitor_name: this.visitorName, visitor_email: this.visitorEmail, category: this.selectedCategory // 下拉框选的分类 }) }); }

注意：工单创建是异步的，不影响会话关闭流程。即使工单接口失败，会话仍正常关闭——这是“最终一致性”的体现。

5.2 邮件通知：当工单创建时，自动发邮件给指定邮箱

需求：工单生成后，自动发一封HTML邮件给运维组邮箱（如it-support@company.com），内容含工单ID、摘要、链接到后台查看。

技术选型：用Python内置smtplib，不引入额外依赖。配置写在/backend/config/email.ini：

[smtp] server = smtp.gmail.com port = 587 username = your_email@gmail.com password = your_app_password # Gmail需用App Password to_email = it-support@company.com

实现代码（/backend/utils/email_sender.py）：

import smtplib from email.mime.text import MIMEText from email.mime.multipart import MIMEMultipart from configparser import ConfigParser def send_ticket_email(ticket_id, summary, visitor_email=''): config = ConfigParser() config.read('/path/to/backend/config/email.ini') msg = MIMEMultipart() msg['From'] = config.get('smtp', 'username') msg['To'] = config.get('smtp', 'to_email') msg['Subject'] = f'[客服系统] 新工单 #{ticket_id}' body = f""" 您好， 有一条新工单已创建： - 工单ID：{ticket_id} - 访客邮箱：{visitor_email} - 摘要：{summary[:100]}... 请登录后台查看详情：http://localhost:8080/admin/tickets/{ticket_id} —— 自动发送，请勿回复 """ msg.attach(MIMEText(body, 'plain')) try: server = smtplib.SMTP(config.get('smtp', 'server'), config.getint('smtp', 'port')) server.starttls() server.login(config.get('smtp', 'username'), config.get('smtp', 'password')) server.send_message(msg) server.quit() print(f'Email sent for ticket {ticket_id}') except Exception as e: print(f'Email send failed: {e}') # 在create_ticket()接口末尾调用 send_ticket_email(ticket.id, ticket.summary, ticket.visitor_email)

关键细节：

• Gmail必须开启“两步验证”并生成App Password，不能用账户密码；
• starttls()是必须的，否则明文传输密码；
• 错误捕获后只打日志，不中断工单创建流程——邮件是锦上添花，不是核心功能。

5.3 验证与部署：如何安全地上线你的增强功能

改完代码别急着扔到生产环境。我给自己定的三步验证法：

1. 本地全链路测试：

   • 用Postman模拟/api/ticketsPOST请求，确认数据库写入、邮件日志打印；
   • 检查Gmail“已发送”里是否有邮件（注意：App Password方式发送，发件人显示为你的Gmail）；

2. 配置隔离：

   • email.ini绝不提交到Git，用.gitignore排除；
   • 生产环境用环境变量覆盖配置：os.getenv('SMTP_PASSWORD')替代config.get()；

3. 灰度发布：

   • 先在测试坐席账号上启用新功能（前端按钮加v-if="user.role === 'admin'"）；
   • 观察一周无报错，再开放给全部坐席。

从那以后我每次给系统加通知类功能，都强制走一遍“本地模拟→配置隔离→灰度验证”三步。不是怕代码错，是怕配置泄露或权限越界——后者一次事故顶十次bug修复。希望帮到你。

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