简介面向开发者、运维人员以及需要搭建在线客服体系的中小企业提供一套开源在线客服管理系统的完整源码可用于快速部署、二次开发与架构学习。系统能力覆盖网页端多渠道接入、客服工作台、机器人自动应答、工单处理、数据报表、多语言切换及安全隐私控制等模块值得研究其会话分配、登录鉴权与集成扩展的实现思路。压缩包大小约7.78MB以源码文件为主体体量轻便便于技术团队直接下载解析并按需改造。目前已有468人学习下载。读者可获得一套可运行的客服系统基础框架既可参照开源协议进行功能定制与性能优化也可将座席管理、机器人回复等核心机制迁移至自有业务系统有效降低从零开发成本。1. 开源版在线客服管理系统这套客服源码能解决什么问题把源码-开源版在线客服管理系统.zip下载到本地之后真正的分水岭不是解压速度而是你能不能把一条完整的客服链路跑通访客在网页上点开聊天窗、消息进队列、坐席在后台点击接待、对话结束归档可查。在线客服系统和普通聊天室的本质差别就在这儿——消息永远挂在会话上会话又带着来源页面、分配坐席、转接记录、满意度评价这一串状态。这就决定了你部署这套源码时最值得花时间研究的不是聊天功能本身而是会话状态机。这套东西适合谁第一类是产品已经上线、不想按坐席数持续付第三方客服软件费用的小团队自建一套开源的能省下长期订阅成本第二类是业务方突然提需求官网要挂在线客服后端同学需要快速交付一个可维护的方案第三类是拿它当二次开发底子在会话路由、工单、数据报表上做定制的人。目标读者就是这三类新手可以从零把它跑起来熟手可以借它理解客服系统的设计边界。我拿到这类源码包的习惯是先跑通最小链路再谈定制。因为客服系统涉及访客端嵌入、坐席端后台、消息推送三块任何一块配置错了都会让能用变成看着能跑但一接待就翻车。下面从部署开始把启动步骤、参数调整、常见坑位一次讲完。2. 把源码包跑起来技术栈识别、数据库初始化与三个必改配置拿到一个名为源码-开源版在线客服管理系统.zip的包绝大多数人的第一反应是解压后找 README。我的习惯是先不急着读 README直接看目录结构和构建文件。原因很简单这份源码可能基于 Java 也可能是 Node.js两者本机环境要求完全不同README 里写的部署步骤未必和你下载到的这份包完全一致但目录结构和构建文件的格式不会骗人。2.1 先看目录再动手后端、前端、访客插件的分层结构一个典型的在线客服系统源码包解压后通常是三层结构后端服务、管理后台前端、访客端嵌入 SDK。后端负责消息转发、会话管理、数据存储管理后台是坐席和运营人员用的界面访客端 SDK 是挂在业务网页上的一段独立脚本实现浮动按钮和聊天窗口。先分清这三层后面所有操作都不会迷路。我先做技术栈识别用几条 find 命令把关键信息捞出来# 解压并查看顶层结构 unzip 源码-开源版在线客服管理系统.zip -d kf-system cd kf-system # 找后端构建文件pom.xml 是 Java/Maven 工程package.json 是 Node 工程 find . -maxdepth 3 \( -name pom.xml -o -name package.json -o -name composer.json \) -not -path */node_modules/* | head # 找数据库初始化脚本一般在 sql/ 或 doc/ 下 find . -name *.sql -type f -not -path */node_modules/* | head # 看访客端 SDK 目录通常叫 sdk、web-sdk 或 visitor ls -d */ | grep -iE sdk|web|visitor三条命令分别对应后端识别、数据库脚本定位、访客端定位。-maxdepth 3是控制扫描深度避免进到 node_modules 和依赖目录里把输出刷爆-not -path */node_modules/*是常见排除写法没有它 find 会在大型前端工程里卡半天。如果 pom.xml 和 package.json 同时存在说明后端是 Java、管理后台是 Node 工程两套构建环境都要准备。确认技术栈之后还要确认数据库选型。多数这类系统用关系库存会话和消息表少数把消息丢给非关系库看 SQL 脚本和配置文件的 datasource 段就能确定。这里有个容易忽略的细节初始化脚本里通常不止一个 SQL 文件可能有 schema.sql 负责建表、data.sql 负责初始数据也可能只有一个 init.sql 全包含。导入顺序错了会导致外键建不出来下一节会说怎么处理。2.2 初始化数据库与启动后端服务的最小步骤技术栈确认后最小启动步骤一般就四步建库、导脚本、改配置、启动后端。我习惯先把数据库层做扎实因为客服系统对数据完整性的要求比普通展示站高——会话和消息一旦丢业务上很难交代。下面这套命令是从解压到库就绪的标准动作。# 1. 创建业务库客服系统里访客可能用 emoji 当昵称必须用 utf8mb4 mysql -uroot -p -e CREATE DATABASE IF NOT EXISTS kf_system DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci; # 2. 按依赖顺序导入结构脚本和初始数据 mysql -uroot -p kf_system sql/schema.sql mysql -uroot -p kf_system sql/data.sql # 3. 确认导入结果表数量和默认账号是否写入 mysql -uroot -p -e USE kf_system; SHOW TABLES; SELECT id, username, role FROM kf_agent LIMIT 5;第二步特别提醒如果 sql 目录下只有一个 init.sql直接导入它即可如果有多个文件按文件名编号顺序导。判断表是否建全的最快方式是 SHOW TABLES 看数量而不是逐个看表结构。第三步的 SELECT 是验证初始管理员账号是否写进去了很多包的管理员账号不是写在 SQL 里而是后端启动时自动创建这种情况以启动日志为准。数据库就绪后启动后端。Java 系常见启动方式如下# 开发环境直接跑控制台会输出监听端口和加载的配置 cd server mvn spring-boot:run -Dspring-boot.run.profilesdev # 生产环境更常见的是打 jar 再跑 mvn clean package -DskipTests java -jar target/kf-server.jar --spring.profiles.activeprod-DskipTests是跳过测试编译第一次跑为了快可以加但跑通后建议去掉跑一遍因为有些包的测试类里藏着接口契约说明。--spring.profiles.activeprod指定激活的配置文件Java 系项目常见有 application-dev.yml 和 application-prod.yml 两套区别通常在日志级别和数据库地址。启动成功的标志不是控制台没有报错而是出现明确的 Started 字样和监听端口日志比如 Tomcat started on port 8080。2.3 三个必须改的配置端口、数据库连接、上传目录这部分对应在线客服系统源码包最常踩的三处配置。我不追求列全所有配置只挑三个不改就必然出问题的按优先级排好。配置项常见位置典型默认值不改的后果服务端口application.yml 的 server.port8080 或 8090与机器上其他服务冲突启动时直接报 Address already in use数据库连接spring.datasource.url / username / passwordjdbc:mysql://localhost:3306/kf连不上库启动报错或写会话记录时才发现上传目录文件存储路径配置相对路径 ./upload头像、聊天图片存到运行目录重启或换目录全部丢失第一个好理解第二个看起来简单但有一个很隐蔽的坑源码包自带的配置文件里密码可能是占位符或者和打包者本机一致的值而你用的是自己的库。我见过不止一次打消息、坐席端完全正常但会话一归档就报数据库错误的情况原因就是 datasource 配置里混着两套数据库地址改掉了主配置、没改 profile 对应的那份。第三个上传目录是血泪教训最多的。客服系统的图片默认存本地磁盘很多包的默认路径是相对路径。相对路径意味着你从 /home/user 启动和从 /opt/kf 启动文件落盘位置完全不同配合 systemd 或容器部署时工作目录一变历史图片全部 404。我一般会改成绝对路径比如 /data/kf/upload并在自己的部署笔记里单独标注。提示如果这份包的后端配置里有 Redis 相关的键说明在线状态或消息队列依赖 Redis本地也要装并改连接地址。判断依据是配置里有没有 spring.redis 或 redis.host 之类的字段。3. 访客端与坐席端联调从网页挂载到会话分发的完整链路后端启动不代表系统能用。在线客服系统的能用标志是访客端在业务网页上能发起会话坐席端能收到并回复两端消息实时互通。这一章讲这条链路的三个关键点嵌入脚本怎么挂、坐席工作台怎么接会话、消息推送靠什么机制。联调顺序建议从前到后——先验证访客端连上后端再让坐席登录最后才测消息收发出问题能立刻定位是哪一段。3.1 访客聊天按钮的嵌入脚本与参数访客端是这个系统的门面也是一个独立于业务站点的前端模块。常见做法是后端把 SDK 脚本作为静态资源暴露出来业务页面在 body 末尾引入然后调用初始化方法传服务地址、租户标识和样式参数。下面是一段标准嵌入代码参数是这类系统里出现频率最高的几个。!-- 业务页面 body 末尾引入放在其他脚本资源之后 -- script srchttps://your-kf-domain.com/sdk/kf-sdk.js/script script window.KF_SDK.init({ serverUrl: wss://your-kf-domain.com/ws, // 后端 WebSocket 服务地址 companyId: demo-company, // 多租户标识单租户部署填 default theme: blue, // 主题色尽量和业务站点一致 position: right-bottom, // 浮动按钮位置可选 left-bottom autoPopup: false, // 是否自动弹出聊天窗建议关掉 visitorName: 落地页访客, // 未登录场景下的默认访客名 avatar: // 访客头像留空用默认占位图 }); /script参数里有三个值得单独说明。第一个是 serverUrl它必须是 wss:// 而不能是 ws://除非你的业务页面本身就是 http 明文否则现代浏览器会因混合内容直接拦截 WebSocket 握手现象是按钮出来了但一点开永远连接中。第二个是 companyId单租户部署填 default 就能跑但如果你后面想分多个业务域名共用一个后端这个字段就是数据隔离的钥匙建议一开始就认真规划。第三个是 autoPopup默认 false 是对的自动弹窗会带来高跳出率业务方通常测几天就会要求关掉。嵌入之后要验证的不是按钮有没有出现而是浏览器控制台里有没有成功建立 WebSocket 连接以及 Network 面板里 ws 连接状态是不是 101 Switching Protocols。这一步能过访客端基本没问题可以进入坐席端联调。3.2 坐席工作台登录、在线状态与会话分配规则坐席端一般是一个独立的管理后台页面部署时和访客端 SDK 不共享同一个静态目录。初始化脚本通常会在数据表里写入一个默认管理员账号用户名密码写在 SQL 文件头部注释或 data.sql 里。首次登录后第一件事是改密码然后把坐席账号建好、技能组配好这一步不做后面所有分配测试都是摆设。坐席端有三个状态直接影响会话分配在线可接待、小休不接新会话但保留已接入会话、离线不参与分配。这套状态机看着简单但分配的公平性完全取决于它。常见的分配规则有三种我整理成一张对比表分配规则工作方式适合场景缺点轮询新会话按坐席列表轮流分配坐席能力完全同质的小团队不考虑空闲程度有人忙有人闲最小空闲分配统计每个坐席活跃会话数分给最少的大多数中小团队的主流选择会话长短不一短会话场景偏差技能组路由按访客来源绑定技能组组内再分配多产品线、需专业分工需要维护技能组和坐席映射关系联调时我会故意开两个坐席账号在线然后从访客端发一条消息看会话落在谁头上。如果连续两次都落在同一个坐席说明默认规则不是轮询而是别的策略要去后端看路由实现。第四章会讲怎么改这个分配逻辑。3.3 消息推送选型WebSocket 连接与断线重连逻辑在线客服系统的消息链路是典型的双向通信访客发消息 → 后端收到 → 路由给对应坐席 → 坐席回复 → 后端推回访客端。这个闭环必须建立在长连接上轮询方案在这个场景里已经被淘汰——客服消息对延迟敏感轮询的固定间隔要么浪费请求、要么延迟明显而且在线状态、输入中提示这类功能用轮询做非常别扭。WebSocket 连接建立之后最大的问题是连接会被各种中间设备掐断Nginx 的 proxy_read_timeout、云平台的空闲连接回收、手机网络切换。所以断线重连和心跳是访客端必须有的能力很多客服系统挂了一天没人收到消息的事故根因就是连接悄悄断了、没有重连逻辑。访客端重连的标准实现是带退避的重试加上定时心跳// 访客端连接管理退避重连 心跳保活 function connectWithBackoff(retries 0) { const ws new WebSocket(window.KF_SDK.config.serverUrl); ws.onopen () { console.log([kf] connected); retries 0; // 连上就把重试计数清零 }; ws.onclose () { // 指数退避重复失败时延迟翻倍封顶 30 秒避免打爆后端 const delay Math.min(1000 * Math.pow(2, retries), 30000); console.warn([kf] disconnected, retry in delay ms); setTimeout(() connectWithBackoff(retries 1), delay); }; // 心跳每 30 秒发一个 ping后端回 pong不行就重建连接 const heartbeat setInterval(() { if (ws.readyState WebSocket.OPEN) { ws.send(JSON.stringify({ type: ping })); } }, 30000); } connectWithBackoff();退避公式里1000 * 2 ** retries的意思是最初 1 秒、第 2 次 2 秒、第 3 次 4 秒依此类推Math.min把上限锁在 30 秒——重试间隔过大的话访客重新打开页面都等不到重连体验很差。心跳 30 秒是常见默认值低于多数网关的空闲回收时间就能保活如果你的服务部署在云负载均衡后面建议把它调到网关 idle timeout 的一半。这个脚本跑起来后可以在浏览器 DevTools 里手动执行ws.close()模拟断线观察是否按预期退避重连这是联调阶段必做的一步。4. 二次开发切入点会话路由、消息存档与权限模型怎么改跑通联调只是起点。多数人拿到这套源码不是为了原样用而是要改客服分组、VIP 优先、消息存档合规、坐席只能看自己的会话。这一章我给三个最常被改动的切入点每个都给出判断依据和最小改法。原则是先找到方法在源码里的位置再小改验证不要上来就动整体结构。4.1 会话分配策略从随机分配到按技能组路由分配策略在源码里通常收敛到一个方法新会话进来调用它返回一个坐席 ID如果返回空就进入排队。这个方法通常长这样以 Java 系为例其他语言结构类似// 会话分配核心按坐席当前负载选择接待人 public Agent assignSession(Session session) { // 1. 按技能组过滤会话来源上带着 groupId比如售前售后 ListAgent candidates agentService.listOnlineByGroup(session.getGroupId()); // 2. 过滤不可接待状态小休、离线、达到最大接待数 candidates.removeIf(a - !a.isAccepting() || sessionService.countActiveByAgent(a.getId()) a.getMaxSessions()); // 3. 按当前活跃会话数排序选择最少负载的坐席 candidates.sort(Comparator.comparingInt(a - sessionService.countActiveByAgent(a.getId()))); // 4. 没有可用坐席则返回 null由上层放入排队队列 return candidates.isEmpty() ? null : candidates.get(0); }这段代码的精髓是过滤条件写在排序之前。如果你想改成 VIP 优先在步骤 2 之前加一步判断 session 是否 VIP 客户是就直接指定资深坐席想改成严格技能组路由把步骤 1 的 listOnlineByGroup 换成多条件查询比如按来源页面再加一道过滤。改完用两个坐席账号做对照测试——同一个访客来源连续发起 10 次会话看分配分布是否符合预期。注意别在排序比较器里做耗时统计那会在高并发下放大性能问题。4.2 消息持久化与历史查询的取舍消息存储是客服系统里最容易埋雷的地方。实时消息走 WebSocket 没错但每条消息还必须落库否则会话结束、刷新页面、坐席换端之后历史全丢。常见做法是消息表按会话 ID 归档查询时按会话分页拉取。存储方案上有一个经典取舍我直接给对比表方案写入能力查询能力复杂度适合阶段纯关系库中等单表写入瓶颈明显强可按会话、时间、关键词查低单机部署、日会话量几千以内关系库加缓存高热数据走缓存强冷数据回源查库中日会话量过万热点会话集中关系库加搜索服务中高极强全文检索和聚合报表方便高有合规检索、客服质检需求我的建议是起步用第一种把消息表的主键设计成会话 ID 消息序号的联合主键这样归档和分页都顺手。等会话量上来了再考虑缓存热会话而不是一开始就上搜索服务——那会让部署复杂度立刻翻倍。另一个常见误用是把消息存成 JSON 大字段塞进会话表查询历史时把整个 JSON 拉出来在内存里过滤数据量一上去就会把数据库 IO 拖垮。4.3 权限模型与数据隔离的常见改法在线客服系统的权限模型一般分三层管理员建账号、看全部会话、组长看本技能组会话、分配坐席、坐席只看自己接待的会话。源码里通常有角色字段和拦截器但数据隔离经常做得不彻底——列表查询接口忘记按角色过滤导致普通坐席能翻出全公司会话。这是合规上最不能忍的问题。改法集中在查询层。给历史会话查询加上数据权限条件是这套系统最常见的定制点-- 历史会话列表组长只能看本技能组坐席只能看自己的 SELECT s.id, s.visitor_name, s.source_page, s.status, s.created_at FROM kf_session s WHERE s.group_id :currentGroupId -- 数据权限组长按组过滤 AND (s.assignee_id :currentAgentId -- 数据权限最小粒度到坐席本人 OR :currentRole GROUP_LEADER) AND s.created_at :startTime ORDER BY s.created_at DESC LIMIT :pageSize OFFSET :offset;currentGroupId和currentAgentId不能从请求参数里取必须从登录态里解析否则坐席换个参数就能越权看别的组。判断权限改得对不对用两个不同角色账号分别调同一个接口返回数据集不能有交集。改完这层之后还要检查导出接口——很多包的历史导出功能是单独写的接口常常漏掉过滤条件数据泄露往往从导出接口走漏。5. 在线客服系统部署避坑启动失败、消息丢失与连不上 WebSocket这一章从我实际部署这类系统的踩坑记录里挑出高频故障每一条都按现象、原因、解决来写。你在自己环境里遇到按同样的顺序排查能少走弯路。5.1 后端启动即退出端口占用与配置读取顺序现象执行 java -jar 或 mvn spring-boot:run 后几秒钟内进程退出控制台出现 Port 8080 was already in use 或配置文件解析报错。原因端口占用的原因很直白——机器上已有服务占用了默认端口。配置文件报错的原因更隐蔽包里有多个 profile 配置文件你改了 application.yml 但实际激活的是 application-prod.yml等于没改或者配置里引用了环境变量环境变量没设置导致解析失败。解决先定位再改。用lsof -i :8080看谁占着端口换端口或停旧服务配置读取顺序用启动日志确认日志里会打印加载了哪个 profile 文件。我习惯在启动命令里显式指定 profile不让它走默认值这样配置来源一目了然排查时间能省一半。5.2 访客端一直连接中WebSocket 握手失败排查现象访客端按钮正常弹出打开聊天窗后状态一直转圈控制台里 WebSocket 连接显示 failedNetwork 面板里状态码是 400 或 404。原因最常见的三个——serverUrl 配错路径后端 WebSocket 端点不在 /wshttps 页面用了 ws:// 被浏览器拦截后端有登录鉴权访客端握手时没带 token 或 Cookie 被拒。404 基本是路径错400 多半是握手参数不对403 是鉴权问题。解决先看 Network 面板里握手请求的完整路径和状态码。路径错就去后端源码里找 WebSocket 注册的端点路径通常在一个 addHandler 配置类里鉴权问题就把 WebSocket 握手拦截器放行访客匿名连接或者让 SDK 在 URL 参数里带上 token让后端在握手阶段校验。验证标准是网络面板出现 101 Switching Protocols。5.3 消息发了没记录事务与异步写入的配合问题现象聊天过程一切正常消息实时能收到但关闭会话后翻历史记录少了几条或者数据库里消息表的记录数和实际聊天条数对不上。原因这类系统在做性能优化时经常把消息落库改成异步写入——先通过 WebSocket 推给接收方再往消息队列里丢一条落库任务。如果异步任务的事务边界没处理好或者队列消费失败没有重试消息就悄悄丢了。还有一种变体发送方把消息 insert 和会话表的最后消息时间 update 放在两个事务里第二个失败时消息在、会话时间戳没更新列表排序错乱。解决排查分两步。第一步看后端日志有没有消息队列消费失败的异常没有日志的话在消息表加一个临时统计对比 WebSocket 推送数量和落库数量第二步检查落库代码的事务注解把写消息 更新会话状态合并到同一个事务方法里并给队列消费加上失败重试。修复后建议用第六章的并发脚本压一波再验证。5.4 图片加载不出来静态资源路径与反向代理现象访客和坐席发的图片发送时显示正常过一段时间刷新页面就裂图或者部署到服务器后全部 404本地开发时却没有问题。原因本地能显示是因为图片存在本地磁盘访问路径是相对路径部署到服务器后静态资源经过 Nginx 或网关转发但配置里没有把 /upload 这类路径代理到后端或者后端静态资源映射的磁盘路径和实际不符。另一个原因是上传目录用了相对路径重启服务后工作目录变化文件找不到了。解决把上传目录改成绝对路径2.3 那节说过然后在 Nginx 配置里加一条 location /upload 代理到后端服务同时在后端确认静态资源映射目录是否指向同一个绝对路径。部署后随手传一张图然后重启服务再访问图片地址能打开才算真正解决。5.5 数据库连接池被打满长连接与并发上限现象坐席端登录正常访客一多后端日志开始报连接池超时比如 Connection is not available, request timed out或者数据库端显示连接数飙到几百。原因在线客服是典型的连接密集型业务——每个访客一个 WebSocket 长连接每条消息落库要占用一次数据库连接长连接本身还会定期发心跳。如果连接池最大连接数没调过默认值往往扛不住几百访客并发。更隐蔽的原因是有些包把心跳也做成落库操作导致长连接存活期间连接池一直被占用。解决先把连接池最大连接数从默认值调大比如从 10 调到 50 或更大同时看数据库侧的最大连接数是否匹配。然后把心跳逻辑改成非落库方式——心跳只更新在线状态或直接不回库。最后用第六章的并发脚本压测观察连接池监控曲线确认峰值连接数在池上限的 70% 以内。6. 从能用走向好用并发验证、数据备份与上线前检查清单系统跑通、坑也排完了最后一件事是把它从能用推到敢上线。我的做法是三道工序先压一道消息通道再定备份和日志策略最后过一遍检查清单。6.1 用并发脚本验证消息通道的真实吞吐不上线就不知道系统扛不扛得住但上线后被访客教做人成本太高。我习惯用一个最小并发脚本模拟访客同时发消息看后端是否丢消息、回包延迟多少。# 最小并发验证50 个访客各发 5 条消息等待每条的确认回包 import asyncio import websockets import json async def send_messages(visitor_id): uri fws://localhost:8080/ws?visitorId{visitor_id} async with websockets.connect(uri) as ws: for i in range(5): await ws.send(json.dumps({ type: chat, content: fvisitor-{visitor_id}-msg-{i} })) # 等后端确认回包带超时收不到说明消息可能丢了 resp await asyncio.wait_for(ws.recv(), timeout5) if json.loads(resp).get(type) ! ack: print(visitor_id, ack mismatch) print(fvisitor {visitor_id} done) async def main(): tasks [send_messages(i) for i in range(50)] await asyncio.gather(*tasks) asyncio.run(main())脚本里最关键的是等 ack 再发下一条——无脑灌包测的是后端抗压不是真实消息链路。跑完后重点看三件事有没有超时异常、消息表记录数是否等于 250、每个访客的 ack 延迟曲线是否均匀。如果延迟从第 30 个访客开始陡增说明连接池或消息队列开始吃紧回到 5.5 那节调参。6.2 备份策略与日志轮转客服数据是业务资产丢了没法补。我定两条规矩数据库每天全量备份保留 7 天日志按天轮转防止单文件无限增长。# 数据库每日备份保留 7 份 mysqldump -uroot -p kf_system | gzip /data/backup/kf_$(date %F).sql.gz find /data/backup -name kf_*.sql.gz -mtime 7 -delete # 后端日志按天轮转保留 14 份用 logrotate 的 daily 配置 logrotate -f /etc/logrotate.d/kf-server备份恢复比备份本身更重要我每次上线前会故意把库删掉演练一次恢复流程确保备份文件不是摆设。find -mtime 7 -delete的意思是删除 7 天前的备份文件保留最近一周的恢复点这个保留天数可以根据业务要求调不建议少于 3 天。6.3 上线前的检查清单检查项验证方法不过会怎样WebSocket 握手浏览器 Network 里看 101 状态访客永远连接中消息落库完整性压测后比对消息表计数历史查询缺消息上传目录持久化重启后访问已传图片图片 404数据权限隔离两个角色调同一接口对比数据越权泄露默认账号改密用默认账号登录并修改后台被入侵备份可恢复演练从备份恢复数据丢失无法挽回压测、备份、检查这串动作做完我才能放心把系统交给业务方。最后说一个习惯每次排完一个坑我会在源码包根目录建一个部署笔记文件把现象、原因、改了什么配置记下来。原因很简单——这套系统大概率不只部署一次第二次部署时翻看笔记比重新踩坑快得多也希望帮到你。本文还有配套的精品资源点击获取