企业官网建设流程全解析

简介：qt-virt-manager 是一套基于 Qt/C++ 的图形化虚拟机管理工具资料，面向系统管理员、运维开发者和虚拟化学习者，用于以统一界面管理 VMware、LXC、BHYVE、Libvirt、Hyper-V、OpenVZ、QEMU-KVM、VirtualBox 等多种虚拟化平台，减少跨平台虚拟环境的操作与切换成本。压缩包约 3.08MB，文件总数与主要类型明细上游暂未提供，无法按文件类型展开说明。该资源已有 353 人浏览学习，适合需要建立多虚拟化技术对照框架的读者。资源描述覆盖虚拟机创建、启停、监控、资源分配、网络配置、克隆备份与迁移等典型场景，并涉及 Virt-Viewer 远程查看和 QtC++ 界面组织方式，可作为理解统一虚拟化管理思路、进行工具选型与后续实践的参考。

1. 结论先给：桌面管虚拟机，Qt 这套前端适合谁不适合谁

我前后在四台机器上装过 qt-virt-manager：两次想用它替掉 virt-manager，两次又老老实实装了回来。结论先摆出来：当后端是 libvirt 一系的 qemu-kvm、lxc、bhyve、openvz 时，它是少数能把这几家和 vbox、vmware、hyper-v 塞进同一个左侧连接树的 Qt/C++ 图形前端；但如果你只跑单机 qemu-kvm 加一条 system 连接，virt-manager 配 virt-viewer 的组合仍然更省心。下面按我实际打分的维度逐项比较，装完之后会翻车的地方也一并写在前头，免得你走一遍我踩过的弯。

2. 五个评判维度：我用什么标准给虚拟机管理前端打分

我挑虚拟机管理前端从来不先看截图，因为截图只说明作者会画画。我的习惯是先列一张表：把手上要管的宿主机、后端类型、认证方式全部写成一列，然后拿三个问题筛——能不能连上、连上之后能做什么、做失败了能不能查。这三个问题会自然展开成下面五个维度，权重从高到低。

2.1 后端覆盖度：一套界面能不能吃下异构 hypervisor

第一个维度是覆盖度，但要区分“标称支持”和“真能做完”。qt-virt-manager 在设计上就把后端当成可插拔的模块来写：libvirt 这条主干覆盖 qemu-kvm、lxc、bhyve、openvz、xen，厂商侧另开一路走 vbox、vmware、hyper-v 和 PowerVM 那类小型机管理接口。听起来很美，实际打分时我会把它拆成四个动作逐个问：新建、启停、快照、控制台。

我的做法很土：给每个后端建一台测试机，只做上面四个动作，任何一个做不到就在表里记一格红。经验是 libvirt 这条路四个动作基本都能做完；厂商侧通常能做完启停和控制台，新建和快照就要看具体环境，很多是“能看见但点不动”的状态。判断依据不在于界面上有几个图标，而在于点下去之后有没有人给你兜底——一个连不出控制台的管理器，对排障来说就是废的。

所以这条维度的及格线我定得比较低：只要你要管的机器里，有超过一半落在 libvirt 这一支上，qt-virt-manager 就值得试；反过来，如果你的资产八成是 vbox 桌面虚拟机和 vmware 主机，那它是配角，不是主角。

2.2 连接层：libvirt URI 决定的可用性

第二个维度是连接层，这一层最容易被忽略，但它决定了你后面所有的体验。libvirt 的连接是用 URI 描述的，URI 写错整个 GUI 就只是个漂亮壳子。我一般会先在命令行把 URI 验证一遍，再往图形界面里填，这样出了问题能立刻分清是 GUI 的问题还是认证的问题。

# 先用 virsh 验证 URI，跑通了再往 GUI 的连接对话框里抄 virsh -c qemu:///system list --all # 本机 system 实例 virsh -c qemu+ssh://ops@192.0.2.10/system list --all # 远端主机，走 SSH 隧道 virsh -c lxc:/// list --all # 本机容器 virsh -c vbox:///session list --all # 当前桌面会话里的 vbox

-c后面跟的就是连接 URI。qemu:///system三个斜杠表示本机、走系统级 libvirtd，权限受 polkit 管；qemu+ssh://用户@主机/system把认证整个交给 SSH，所以前提是免密登录已经通了，否则 GUI 会在“正在连接”上转很久然后给你一句含糊的话；lxc:///同样三个斜杠，管的是本机容器域；vbox:///session里的 session 很关键，它只覆盖当前登录会话里的 vbox 实例，换个用户登录就什么都看不见，这是很多人以为“连不上”的真实原因。

判断一个管理前端连接层做得好不好，我看两点：一是能不能保存多条不同类型的连接并在同一个树里共存，二是连接失败时给的是 libvirt 的原始错误还是自己编的一句话。前者决定你能不能用一套工具管一个异构机房，后者决定你排障要花十分钟还是两小时。

2.3 控制台链路：VNC、SPICE 与 virt-viewer 的边界

第三个维度是控制台，虚拟机管理里最玄学的一环。管理器的本职工作其实只有一半——把域管起来；另一半是把画面送到你眼前，而画面这条链路上游下游全是依赖：qemu 侧要开 VNC 或 SPICE 服务，SPICE 还要 qxl 显卡驱动配合，客户端要 spice-gtk，USB 重定向要 usbredir。

qt-virt-manager 自带一个 viewer 模块，同时也支持把控制台交给外部的 virt-viewer 去开。我一般会这么比：先看内置 viewer 能不能直接在你的桌面上开出第一个画面，开不出来再看它调外部 virt-viewer 时命令行拼得对不对。后者其实更好排查，因为你能看到它到底传了什么参数。

这条维度的及格线是：控制台失败时必须给出可读的原因。黑屏、闪退、转圈，这三种都属于不可接受，因为它们把问题丢回给你猜。合格的实现至少要在日志里留下“连接了哪个端口、用了什么协议、服务端回了什么”。

2.4 构建与依赖：Qt 版本和 libvirt 开发包的耦合

第四个维度是构建。图形化的虚拟机管理器不像命令行工具那样解压即用，它一头连着 Qt，一头连着 libvirt 的 C 接口，中间还挂着 glib、libxml2、spice、usbredir 一串。判断依据很简单：你的发行版仓库里有没有现成的包。有包，这条维度可以直接跳过；没有包，就得接受一次源码构建。

Qt/C++ 项目在这一步最容易出的事不是代码错，而是元对象编译器（moc）和界面编译器（uic）的生成顺序被构建系统搞混，表现是一堆莫须有的“未定义引用”和“vtable”报错。我在 2.4 这条上的立场是：优先用项目主推的那套构建方式，另一套当备选，千万不要两个混着来。

另外要提前想清楚：你要的是能跑，还是能改。能跑的话，发行版的新旧程度直接影响依赖能不能凑齐；能改的话，Qt5 和 Qt6 的差异、libvirt 头文件版本带来的 API 变化，都会变成你二次开发时的隐性成本。这条维度不打分，只做预算。

2.5 可维护性：日志、错误回传与二次开发成本

第五个维度是可维护性，说白了就是别做成黑匣子。我见过太多图形化工具，出错时弹一个红叉，日志目录里空空如也，最后只能靠抓包和猜。合格的实现应该把 libvirt 的错误结构透出来——错误码、错误域、原始消息，这三样一个都不能少。

二次开发成本也要算进去。Qt 的信号槽是异步事件模型，libvirt 的 C 接口是回调加轮询，两套模型对接的时候很容易写出“界面刷新比实际状态慢半拍”的毛病。你要做二次开发，就得接受自己会去读那层适配代码。我的判断标准是：这份代码里有没有一个集中的“后端抽象层”，如果有，改起来还算有救；如果每个窗口都直接调 libvirt，那就趁早别碰。

这五条维度加起来，构成了我后面所有对比的骨架。覆盖度决定它能不能进你的候选名单，连接层和控制台决定日常好不好用，构建和可维护性决定你三个月后会不会想换掉它。

3. 逐项对比：qt-virt-manager 对上 virt-manager 与 virt-viewer

把维度立好之后，对比才有意义。这一章我把 qt-virt-manager 放在三个不同的场景里跟 virt-manager、virt-viewer 过招：单机实验、容器负载、异构机房。先说清楚一点，virt-manager 和 virt-viewer 通常是一起出现的组合，virt-manager 管域、virt-viewer 开控制台，所以真正要比的是“qt-virt-manager 单体”对“virt-manager + virt-viewer 组合”。

3.1 能力矩阵：八个后端 × 四个动作

下面这张表是我自己按实际环境填的，格子里的词描述的是“我能不能顺利做完”，不代表任何官方承诺，你的环境不同结论可能就不同。

从表里能读出一件事：qt-virt-manager 的价值不在“每一项都最强”，而在“一张表能装下这么多后端”。virt-manager 只在 libvirt 这一行里，而且做得更深。选择的分歧点就在这里——你是要广度，还是要深度。

3.2 单机实验场景：qemu-kvm 上的日常操作差异

单机是我最常打交道的场景：一台开发机，跑两三个 qemu-kvm 域，偶尔做快照回滚。这个场景里 virt-manager 的优势非常明显，创建向导把内存、CPU 拓扑、磁盘总线、网络模型一步步问清楚，最后还给你一份可编辑的 XML 预览；改配置时图形化面板和 XML 编辑器可以来回切，改错了能直接看到差异。

qt-virt-manager 在单机场景里更像一个“连接管理器 + 域列表”的组合：列表清爽，多条连接并排摆着，启停和状态刷新都挺快；但到了设备级微调，它的图形面板覆盖度不如 virt-manager 细，很多参数最终还是要落到 XML 上改。这不是缺点，只是定位不同——它假设你可能同时管着五台不同后端的机器，而不是把一台机器调到极致。

快照这块我要多说一句。单机做快照，最容易翻车的不是创建，而是回滚之后网络和磁盘的一致性。virt-manager 在这条链路上把内部快照和外部快照的差别展示得比较清楚，qt-virt-manager 的入口更朴素一些。我的做法是无论用哪个前端，回滚前都先virsh snapshot-list确认一遍层数，别指望界面替你想。

3.3 容器负载：lxc 与 openvz 的支持边界

容器这一支是我认为 qt-virt-manager 比较有意思的地方，因为它把容器和虚拟机当成同一个“域”概念来呈现。lxc 走 libvirt 的 LXC 驱动，在管理器里就是一个没有图形控制台的域，状态、启停、资源限制都能看，进去靠的是文本 console。

这里有个认知差要提前打掉：容器没有 VNC，也没有 SPICE。你在图形管理器里点“打开控制台”，对 qemu-kvm 是开一个画面，对 lxc 是接一个 tty，两者的期望完全不同。很多人第一次用会以为是黑屏故障，其实是没配 tty 或者没分配 console。合格的用法是先在命令行virsh -c lxc:/// console 域名验证能进，再回图形界面点。

openvz 就更特殊了，它依赖宿主内核的补丁和一套独立的管理工具，在现代发行版上基本已经退役。管理器里能列出来、能看状态，已经算是尽力了。我的建议很直接：如果你现在还有 openvz 的存量，把 qt-virt-manager 当“统一视图”用可以，但别指望它替代原来的管理工具，迁移规划要单独做。

3.4 异构机房：hyper-v、vmware、bhyve、PowerVM 的接入实际

真正让 qt-virt-manager 区别于 virt-manager 的，是这一节。bhyve 走的是 FreeBSD 宿主上的 libvirt 驱动，理论上跟 qemu-kvm 一样是 libvirt 家族，只是宿主机换了系统，URI 换成bhyve:///system；这一支相对干净，前提是你得有一台 FreeBSD 机器。

hyper-v 和 vmware 就不在 libvirt 的覆盖范围里了，它们各自有自己的远端管理接口和凭据体系。图形前端在这里扮演的角色其实是个“壳”：把凭据收好，把远端的虚拟机列表拉回来，把启停指令发出去，把控制台交给外部客户端。这类接入的可用度高度依赖网络策略——管理端口通不通、凭据有没有过期、证书是不是自签，任何一项不对，界面上就是一句很笼统的失败提示。

PowerVM 那类小型机虚拟化，走的是硬件管理控制台那一侧，跟 x86 上的玩法完全不是一个路子。这一支我做过的验证最少，只能给一个保守结论：把它当成“有比没有好”的只读视图，别把关键操作押在上面。

这一段的价值判断很朴素：异构机房最贵的成本不是软件许可，是人。能让一个人用一个界面看到全部资产状态，哪怕只能看不能改，也能省掉每天切换五套工具的时间。qt-virt-manager 在这件事上的定位是准的，问题只在于每一支的完成度参差。

3.5 什么时候我会主动退回 virt-manager + virt-viewer

说了这么多优点，得把话说回来。下面这几种情况我会毫不犹豫地退回 virt-manager 加 virt-viewer：

一是要长期稳定跑生产实验环境，virt-manager 的迭代历史和周边生态更厚，遇到问题搜得到答案；二是需要 virt-install、virt-v2v、virt-clone 这一整套命令行工具配合，图形界面只是入口，真正的活在命令行；三是团队协作，别人打开也是同一套界面、同一套术语，沟通成本低；四是对快照、存储池、网络过滤器这类细粒度配置有强需求。

反过来，如果你的场景是“一个人管一堆杂牌后端”，qt-virt-manager 的连接树就是省事的那一个。这两者不是替代关系，我自己的机器上两个都装着，看当天要干什么。

4. 构建与首连：从源码编到看见第一帧画面

这一章是给准备真上手的人看的。我按自己的顺序走一遍：装依赖、选构建方式、建第一条连接、验控制台。每一步都说清楚失败时该看什么，省得你在“编译不过”和“连不上”之间来回猜。

4.1 依赖清单：Qt、libvirt 开发包与图形控制台组件

依赖分三组：构建工具、Qt、虚拟化与图形控制台。构建工具是 cmake 或 qmake 加编译器和 pkg-config；Qt 至少要有 Widgets、Network、Svg 这几个模块的开发包；虚拟化侧是 libvirt 的头文件和 glib 绑定；控制台侧是 spice 协议头、spice-gtk 和 usbredir。

# Debian/Ubuntu 系，按需增删；包名以你仓库里的实际名称为准 sudo apt install build-essential cmake pkg-config \ qtbase5-dev libqt5svg5-dev \ libvirt-dev libvirt-glib-1.0-dev libxml2-dev libglib2.0-dev \ spice-protocol libspice-client-gtk-3.0-dev libusbredirhost-dev

这份清单里，libvirt-dev提供libvirt/libvirt.h，是所有连接能力的来源；libvirt-glib-1.0-dev提供 glib 风格的事件循环绑定，用不用取决于代码怎么写的；spice-protocol只是协议定义，真正画图的是libspice-client-gtk-3.0-dev；libusbredirhost-dev关系到 USB 设备能不能透传进虚拟机。装完之后用pkg-config --modversion libvirt确认一下版本能被找到，找不到就是安装路径或 pkg-config 路径的问题，先解决这个再谈编译。

4.2 构建：cmake 与 qmake 两条路的关键开关

两条构建路径我都走过，结论是优先用项目当时主推的那套，另一套当备选，别混。

# 路线一：cmake git clone <仓库地址> qt-virt-manager && cd qt-virt-manager mkdir -p build && cd build cmake .. -DCMAKE_BUILD_TYPE=Release -DCMAKE_INSTALL_PREFIX=/usr/local make -j"$(nproc)" sudo make install # 路线二：qmake（在项目根目录或指定的 .pro 所在目录） qmake .. make -j"$(nproc)"

-DCMAKE_BUILD_TYPE=Release决定优化级别，调试阶段可以换成Debug并加上-DCMAKE_EXPORT_COMPILE_COMMANDS=ON方便编辑器索引；-DCMAKE_INSTALL_PREFIX决定装到哪，装到/usr/local一般不需要额外配库路径。-j"$(nproc)"用满核心数，但内存小的机器建议降到-j2，C++ 模板编译吃内存是常态。

两条路的差别在于元对象生成规则不同。cmake 通过find_package(Qt5 ...)引入自动化处理，qmake 靠.pro里的QT +=声明。混着用最典型的表现是链接期报一堆“未定义引用”，指向的全是staticMetaObject之类的符号，这时候别去改代码，先确认你到底用的哪套构建系统，把生成目录清干净重来。

4.3 第一条连接：本地 system 与 remote+ssh 的写法差别

装完之后第一次启动，界面上通常是空的，需要自己加连接。建议顺序是：先加本机qemu:///system，确认能动；再加一条远端qemu+ssh，确认认证链路通。

# 第一步：命令行确认本机 system 实例可用 virsh -c qemu:///system list --all # 第二步：确认 SSH 免密已经通了，再测远端 ssh -o BatchMode=yes ops@192.0.2.10 'virsh -c qemu:///system list --all'

第一行如果报权限错误，多半是当前用户不在libvirt组里，或者 polkit 策略没放行；第二行的BatchMode=yes是关键的验证手段，它强制 SSH 不走交互式密码输入，如果这一步失败，GUI 里那条qemu+ssh连接一定也连不上，别浪费时间在界面里反复点。

远端连接还有个易忽略的点：远端 libvirtd 的 socket 权限。SSH 登进去的用户如果不在远端的libvirt组，qemu:///system一样会被拒。这不是前端的问题，是宿主机的用户组问题，改完组记得重新登录会话才生效。

4.4 控制台与 USB 重定向：virt-viewer 被怎么调起来

连上之后最想干的事是看画面。qt-virt-manager 内置的 viewer 能开一部分场景，但更稳的做法是让外部 virt-viewer 接手，因为它对 SPICE 和 USB 重定向的支持更完整。

# 查这个域当前暴露的图形端点 virsh -c qemu:///system domdisplay vm-demo # 典型输出：spice://127.0.0.1:5900 或 vnc://127.0.0.1:5900 # 交给 virt-viewer，-w 表示域没起来就等着 virt-viewer -c qemu:///system -w vm-demo

domdisplay的输出告诉你协议和端口，SPICE 走 5900 起，VNC 也是 5900 起，但两者不能同时开在同一个域上。-w是等待域出现，适合开机瞬间就盯画面；如果域已经在跑，加不加都行。USB 重定向的前提是域 XML 里有redirdev设备，并且宿主侧 usbredir 服务在跑，缺任何一环，virt-viewer 的设备菜单里就是灰的。

4.5 验收清单：从域列表到首帧画面要过的四关

我不看“能不能启动”，我看四关能不能连续过：第一关，连接树里出现目标主机且图标不是断开的；第二关，点进去能看到域列表，包括关机状态的域；第三关，对一个关机域执行启动，状态在几秒内从关闭变成运行；第四关，打开控制台看到画面，能敲键盘。

四关里最容易卡的是第二关和第四关。第二关卡住，八成是 URI 指向了session而不是system，两个实例的域列表完全独立；第四关卡住，八成是图形端点的协议不匹配——域配的是 SPICE，客户端只有 VNC 能力，或者反过来。把这两条记住，能省掉大量“玄学”猜测。

5. 避坑与排查：五个真实翻车现场的现象、原因和解法

这一章全是血泪经验，每一条我都至少踩过一次。写法统一：先说看到什么，再说为什么会这样，最后给能直接照做的解法。

5.1 编译到链接阶段报一堆 staticMetaObject 未定义

现象：make跑到 90% 突然爆出几十行“undefined reference to vtable for ...”，涉及的类全是继承自 Qt 的窗口类。

原因：元对象代码没有生成，或者生成了但没被编译进目标。通常是构建系统混用——先用 qmake 生成了一套 Makefile，又在同一目录跑 cmake，两套规则互相覆盖，moc_*.cpp被漏掉。

解决：删掉构建目录，从干净状态重来，只用一套构建系统。如果坚持用 cmake，确认set(CMAKE_AUTOMOC ON)和set(CMAKE_AUTOUIC ON)已经打开；用 qmake 则确认.pro里该有的头文件都列进了HEADERS。清目录这一步别省，增量构建的残留最难查。

5.2 主机图标是绿的，点进去域列表一片空白

现象：连接显示已建立，左侧树里主机节点正常，展开之后一个域都没有，但用virsh在同一个账号下明明能看到一堆。

原因：URI 指向的实例不对。qemu:///session和qemu:///system是两个完全独立的 libvirt 实例，各自的域列表互不相干。桌面环境下很多前端默认填 session，图省事不用提权，结果就是你看到的是空的。

解决：把连接 URI 明确改成qemu:///system，并确认当前用户在libvirt组内。改完组之后必须重新登录，组关系不会在已有会话里生效。验证方式是virsh -c qemu:///session list --all和virsh -c qemu:///system list --all各跑一遍，看域到底在哪一边。

5.3 控制台打开黑屏，几秒后自己关掉

现象：点“打开控制台”，窗口弹出来是黑的，鼠标移进去没反应，过几秒窗口消失，日志里只有一句连接被关闭。

原因：图形端点没起来或者协议对不上。域配置里写的是 SPICE，但 qemu 启动时没加载 qxl 设备，或者端口被宿主防火墙挡了；也可能是 TLS 要求客户端带证书，而客户端没配。

解决：先用virsh domdisplay确认端口和协议，再从宿主机本地用virt-viewer直连那个地址，绕开管理器排除前端因素。能连上说明是前端参数问题，连不上就往 qemu 的启动参数和防火墙查。SPICE 场景还要确认虚拟机里有显卡驱动，没有驱动就是黑屏但连接是通的。

5.4 远端连接一直卡在“正在连接”，最后报认证不可用

现象：加了qemu+ssh连接，进度条转到超时，提示里提到认证失败，但同一个账号手动 ssh 进去完全正常。

原因：qemu+ssh的认证完全依赖 SSH 的非交互登录。手动能登是因为你输了密码，GUI 里没有交互终端，密码没地方输，于是失败。另外远端 libvirtd 的 socket 权限也可能拦一道。

解决：先配好免密（公钥认证），用ssh -o BatchMode=yes 用户@主机 true验证，返回 0 才算通。再确认远端用户在libvirt组里、远端 libvirtd 正在跑。两关都过了 GUI 才能连上。这一步别在界面里试错，命令行验证一次比点十次快。

5.5 关掉管理器，虚拟机跟着停了

现象：从管理器里启动的域，把窗口一关，域状态变成关闭，一查日志是被正常销毁的。

原因：域是以会话级身份启动的，生命周期绑在了启动它的会话上。桌面环境下的会话总线一退出，会话内的域就跟着结束。这跟用哪个前端没关系，是 libvirt 的会话语义。

解决：需要长期运行的域，一律用qemu:///system启动，并设置virsh autostart 域名让它在宿主机启动时自动起来。已经跑起来的域可以用virsh domstate确认是不是 system 实例下的。这一条我吃过一次亏，之后凡是“要活过我这个终端”的机器都走 system。

6. 落到人身上：三类使用者各自该怎么选

比到最后其实不是软件之争，是人的场景之争。我把这三类人分开说，你可以对号入座。

第一类是学生和刚动手的人，通常只有一台机器，跑 qemu-kvm 做实验。结论很明确：先用 virt-manager 加 virt-viewer，把域、磁盘、网络、快照这几个概念摸熟，再来看 qt-virt-manager。因为你现在的瓶颈不是“后端太多管不过来”，而是“不知道每个参数在干什么”，virt-manager 的向导和 XML 双视图对建立概念更友好。

第二类是一个人管一堆杂牌机器的人，可能是小团队的运维，也可能是自己攒了一屋子实验环境。这一类是 qt-virt-manager 的甜区：连接树把 libvirt 的 qemu-kvm、lxc、bhyve 和厂商侧的 vbox、vmware、hyper-v 摆在一起，状态一眼扫完，日常启停不用切五个工具。前提是你要接受它的定位——统一视图优先，深度配置交给 XML 和命令行。

第三类是要做二次开发的人。Qt/C++ 的底子在这里是优势，信号槽加 libvirt 回调的组合虽然别扭，但可控。我给的建议是先花半天读它的后端抽象层，看域对象是怎么被封装的，再决定要不要在这上面加东西。如果那层抽象是散的，每个窗口直连 libvirt，那就别在这上面投入。

最后说个具体技巧，也是我现在的固定动作：不管用哪个前端新建域，我都会在创建完成之后立刻跑一遍virsh dumpxml 域名 > 域名.xml，把这份 XML 存进版本库。图形界面会骗你，它显示的和实际生效的经常差一两个参数，而 XML 不会。要改配置就先改这份文件再virsh define，图形界面只用来查看和启停。这样做还有一个额外好处：换机器、换前端、甚至换人接手，只要这份 XML 在，域就能一模一样地重建出来。

回过头看，我最早用 qt-virt-manager 的动机很不纯粹——就是嫌 virt-manager 的界面老气。折腾了两轮之后才明白，选这类工具真正要比的从来不是界面，而是它能不能在你出错的时候把问题指出来。从那以后我每次试新工具，都强制走一遍那四关验收：连接、列表、启停、控制台，一关不过就不往下投入。省下来的时间，比我多试五个工具都值。希望帮到你。

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