企业官网建设流程全解析

简介：这份开源软件资源面向希望在Windows平台上体验高性能HTTP缓存的开发者与运维人员，核心内容是让Varnish Cache在Cygwin模拟环境中顺利编译运行的适配补丁及相关工具链，解决Varnish原本依赖Linux、在Windows下难以直接部署的问题，适合具备一定C语言与系统运维基础、想低成本验证缓存方案的中高级用户。压缩包共118个文件，约5.54MB，以36个C头文件、18个静态库、14个可执行程序与13个动态链接库为主体，构成可直接使用的运行与编译环境；另有6个libtool的la描述文件、4份readme说明、4个bat批处理脚本，以及vcl示例配置、specs打包规格、license许可文本和若干手册页，便于按需查阅与二次构建。资源附带了精简版cygwin.dll与gcc分发，无需安装完整Cygwin套件即可上手。已有104人学习下载。通过其中的修补源码与手册页，读者可以了解文件路径、网络I/O、线程与信号处理在非标准环境下的适配思路，并借助VCL配置与varnishlog等工具完成缓存策略调试与请求分析。

1. Cygwin 上跑 Varnish Cache：为什么这套组合值得拆一遍

上周有个同行在 Windows 机器上想验证一套缓存策略，第一反应是开虚拟机。我拦住他：先用 Cygwin 把这份 Varnish Cache 开源软件源码包编译出来，二十分钟就能拿到一个能跑 varnishd 的环境。Cygwin 补的是 POSIX 那一层，Varnish Cache 是那套高性能 HTTP 反向代理与缓存服务，两者凑一起的价值不在生产部署，而在于把「改 VCL → 重启 → 看命中率」这条回环压到最短。适合三类人：要在 Windows 桌面上做缓存策略验证的后端、正在做网关选型对比的架构同学、以及想读懂 Varnish 内部 acceptor 与共享内存机制的人。生产环境该上 Linux 还是上 Linux，这点不用犹豫。

但「能编译」和「能跑稳」之间隔着一条沟。Cygwin 不是 Linux，它用一层运行时 DLL 把 POSIX 调用翻译成 Win32 调用，信号、fork、共享内存、文件锁的行为都会走样；而 Varnish 恰恰是个把这三样用到极致的东西——它靠 mmap 出来的共享内存段做统计和日志，靠 acceptor 线程接管连接，靠工作进程崩溃后父进程重新拉起。所以我拆这份源码包时，重点从来不是 configure 那把过不过，而是那几个探测项到底探测到了什么。

2. Cygwin 环境与依赖链：从 POSIX 层到编译工具链

2.1 Cygwin 安装器与包选择

拿到源码包先别急着./configure。Cygwin 上最常见的翻车是编译到一半发现缺库，回头补装又要重跑一遍 configure。我一般先把编译期依赖一次性铺齐，用安装器的静默模式批量装，省得在图形界面里一个个勾。

# -q 静默 -n 不建桌面快捷方式 -N 不建开始菜单项 # -P 后跟逗号分隔的包名列表 -s 指定镜像源 setup-x86_64.exe -q -n -N \ -s https://mirrors.example.invalid/cygwin \ -P gcc-core,gcc-g++,make,automake,autoconf,libtool,pkg-config,\ libpcre2-devel,libedit-devel,zlib-devel,libncurses-devel,python3

参数里-n和-N不是可有可无的装饰，反复跑安装器时它们能避免快捷方式越堆越多。-P列表里每一项都对应一个真实症状，缺了哪个就会在某个阶段卡住：

装完必须验一遍编译器真的能产出可执行文件，而不是只验gcc --version。这两件事在 Cygwin 上有时不相等，尤其是路径里带了非 ASCII 字符或者装在受管目录下的时候。

# 最小闭环验证：预处理、编译、链接、运行，四步都要过 printf '#include <stdio.h>\nint main(void){puts("ok");return 0;}\n' > /tmp/t.c gcc -o /tmp/t.exe /tmp/t.c && /tmp/t.exe

输出ok才算环境通了。如果这一步失败，后面所有报错都没有分析价值。

2.2 依赖库的版本对齐与 pkg-config

Cygwin 的库安装路径有两套：安装器装到/usr/lib，自己源码编译的装到/usr/local/lib。pkg-config 默认按内置搜索路径找.pc文件，/usr/local/lib/pkgconfig通常在后，这就导致你手动编译了一个更新版本的库，configure 却仍然捡到系统里那个旧的。这个坑我在别的项目上踩过一次，排查了两个小时——症状是版本号对不上但ldd看着又没问题。

先确认关键库能不能被找到，顺带打印版本号：

# 逐个探测，找不到就显式打印 NOT FOUND，避免空行骗过眼睛 for p in libpcre2-8 libedit zlib; do printf '%-14s ' "$p" pkg-config --modversion "$p" 2>/dev/null || echo "NOT FOUND" done # 打印 pkg-config 的实际搜索路径顺序，确认 /usr/local 是否被前置 pkg-config --variable pc_path pkg-config | tr ':' '\n'

如果静态库和动态库同时存在，链接器默认会挑.so，运行时就得保证PATH里有对应的 DLL。Cygwin 的.dll查找规则跟 Linux 的LD_LIBRARY_PATH不同，靠的是 Windows 的PATH。我自己编译的库装到/usr/local之后，会把/usr/local/bin提到PATH最前面：

# 写进 ~/.bashrc，新开的 shell 自动生效 export PATH="/usr/local/bin:/usr/local/sbin:$PATH" export PKG_CONFIG_PATH="/usr/local/lib/pkgconfig:/usr/lib/pkgconfig:$PKG_CONFIG_PATH"

这里PKG_CONFIG_PATH的顺序就是优先级顺序，把自己装的路径放前面，configure 拿到的版本才跟你预期一致。改完重开 shell 再验一遍 2.2 开头那段探测，版本号必须变。

2.3 源码树布局与 configure 最小参数

Varnish 的源码树结构比较规整，认几个目录就够定位问题了：bin/varnishd/是主程序，lib/libvarnish/是公共库（哈希、时间、锁），lib/libvcc/是 VCL 编译器，include/是对外头文件，vmod/下是各个 VMOD 模块，doc/里是 reStructuredText 格式的手册。

Cygwin 上的可选特性要靠 configure 的开关裁剪，别指望它全都探测对。先看源码包声明了哪些开关：

# 从 configure.ac 里抓可选项，避免拿到一份过时的 README 照着配 grep -nE 'AC_ARG_(ENABLE|WITH)' configure.ac | sed 's/^[0-9]*://' | head -40

这条命令输出的就是全部--enable-*和--with-*，比查文档快，而且和当前这份源码树严格对应。看到输出之后，再决定哪些关掉——Cygwin 上没有 jemalloc、没有原生 kqueue/epoll，这类特性在 configure 阶段就会被判否，硬开只会在 make 阶段炸。

# 生成 configure（源码包如果已带可跳过） autoreconf -i # 最小可用配置：路径全部显式指定，避免默认值散落在各处 ./configure \ --prefix=/usr/local/varnish \ --sysconfdir=/etc/varnish \ --localstatedir=/var/lib/varnish \ --disable-jemalloc \ --without-curses 2>&1 | tee configure.log

参数含义需要说清：--prefix决定varnishd装哪儿；--sysconfdir是 VCL 和 secret 文件的默认去处；--localstatedir最重要，Varnish 的共享内存段和实例目录默认落在这里，路径里绝对不要有空格和非 ASCII 字符，Cygwin 的路径转换在这上面经常出意外；--disable-jemalloc是因为 Cygwin 下这块内存分配器的探测基本不会通过；--without-curses会牺牲varnishhist之类的可视化工具，但能减少一条链接链。

configure 跑完，把 log 里所有checking for ... no的行捞出来看一遍：

grep -E "checking .*\.\.\. no" configure.log

凡是影响核心功能的no（比如丢掉了pthread、mmap、clock_gettime），都得回头补，不能指望编译期自动降级。Cygwin 的兼容层对某些调用的模拟是「能过但语义弱化」，比如信号量在某些实现下会退化为轮询——这类问题 configure 是查不出来的，只能等运行期暴露。

3. 编译 Varnish Cache：configure、make 与裁剪

3.1 configure 参数逐条说明

上一节给的是最小集，实际编译时还得针对 Cygwin 补几项。我把常用参数列成表，后面标注了在 Cygwin 下的取舍理由：

--enable-debugging-symbols这一项我踩过反直觉的坑：开了之后varnishd的启动参数里如果带-d，进程会在初始化完成后停下来等命令，看起来像是「卡住了」，其实是设计如此。排查启动问题时开着方便，但别把它带进日常使用的构建里。

# 完整一点的配置：显式指定 PCRE2，避免探测歧义 ./configure \ --prefix=/usr/local/varnish \ --sysconfdir=/etc/varnish \ --localstatedir=/var/lib/varnish \ --disable-jemalloc \ --without-curses \ --with-pcre2 2>&1 | tee configure.log # 关键探测结果的快速核对 grep -E "pcre2|pthread|mmap|clock_gettime" configure.log

PCI 无关，这里提一下--with-pcre2的实际作用：VCL 里的~正则匹配、acl的 CIDR 计算、std.系列 VMOD 的字符串处理都依赖它。pcre1 和 pcre2 在边界匹配上有一处细微差异，同一套 VCL 在两边跑出来的结果可能不同。既然是从源码编，就别留这种不确定性。

3.2 make 阶段的高频报错处理

编译阶段的报错分两类：一类是「真缺东西」，另一类是「Cygwin 语义差异导致代码本身过不了」。后者才是这个移植场景的核心工作量。

# 并行编译并把完整输出留档，出错时不用重跑 make -j"$(nproc)" 2>&1 | tee build.log # 出错后按错误类型归类，先看 undefined reference 再看语法错 grep -nE "undefined reference|error:|No such file" build.log | head -30

undefined reference是最常见的。在 Cygwin 上它有个特殊变种：undefined reference to '__imp_xxx'，带__imp_前缀说明链接器认为符号要从 DLL 导入，而你链接的却是静态库。这通常是 PATH 里混进了 MinGW 或者另一套工具链（比如某个 IDE 自带的 gcc），导致gcc实际指向了非 Cygwin 的编译器。

# 确认编译器身份，Cygwin 的 gcc 输出里会明确带 cygwin gcc -v 2>&1 | grep -i target which -a gcc

如果which -a gcc列出了多个路径，把非 Cygwin 的那个从 PATH 里剔掉，重新开 shell 再编。这个问题的迷惑之处在于gcc --version看着一模一样，只有 target 三元组不一样。血泪经验：环境变量清理比代码修补更快，先怀疑环境。

另一类报错是error: 'CLOCK_MONOTONIC' undeclared或者implicit declaration of function 'clock_gettime'。Cygwin 的clock_gettime支持取决于版本和特性宏，需要在 configure 阶段检测-lrt是否存在，没有的话某些计时逻辑会退回到gettimeofday。这类问题一般不用改代码，调编译宏或换用源码树里已有的兼容实现即可，具体看lib/libvarnish/下有没有对应的 fallback 文件。

还有一类是信号相关：SIGUSR1的处理在 Cygwin 下与 Linux 行为不同，编译能过，但运行期发信号没反应。这类问题在编译阶段看不到，必须留到第 5 章的排查清单里。

3.3 安装路径与运行时目录规划

make install之前先把运行时目录建好，比事后补要省事。Varnish 启动时会往实例目录里写共享内存文件（文件名形如_.index和每个实例的S.<name>.vsm），目录不存在就直接退出，报错信息还不一定直白。

# 预建目录，注意属主和权限：共享内存文件需要对运行用户可读写 mkdir -p /var/lib/varnish/instance1 mkdir -p /etc/varnish chmod 755 /var/lib/varnish # 安装主程序与 VMOD make install 2>&1 | tee install.log

装完检查关键文件是否在位，这一步不能省，make install报错被tee吞掉的情况我见过不止一次：

# 三类产物必须齐：主程序、管理客户端、VCL 编译用的 VMOD 目录 ls -l /usr/local/varnish/sbin/varnishd ls -l /usr/local/varnish/bin/varnishadm ls -l /usr/local/varnish/lib/varnish/vmods/ | head

vmods目录里放的是.so形式的模块，varnishd启动时通过-p vmod_path=找到它们。Cygwin 下这些.so实际上是 PE 格式的 DLL，扩展名却保留.so，这个细节在排查Symbol not found时很重要——不是文件不存在，而是依赖的 DLL 加载失败。

目录规划上，我自己的习惯是：/usr/local/varnish只放装出来的二进制和库，/etc/varnish放 VCL 和 secret，/var/lib/varnish/<实例名>每个实例一个，互不干扰。这样同时开两个varnishd做对比实验时，共享内存文件不会打架。

4. VCL 与运行时配置：让缓存真正生效

4.1 VCL 编译流程与 varnishd 启动参数

VCL 不是启动时现解释的脚本，它先被编译成 C 代码、再编译成共享对象，最后由管理进程加载。理解这条链，才能看懂那些「VCL 语法没错但加载失败」的报错。

# 先做语法检查，不启动进程：-C 表示只编译不运行 /usr/local/varnish/sbin/varnishd -C -f /etc/varnish/default.vcl

-C是排错的第一道闸，它会把 VCL 编译成 C 代码打到标准输出，同时报告任何语法或符号错误。这一步过了，再谈启动。

# 前台运行，便于看日志和 Ctrl-C；-n 指定实例目录，-s 指定存储后端 /usr/local/varnish/sbin/varnishd \ -a 127.0.0.1:6081 \ -T 127.0.0.1:6082 \ -f /etc/varnish/default.vcl \ -s malloc,256m \ -n /var/lib/varnish/instance1 \ -F

逐项说明：-a是面向客户端的监听地址，本地验证用 6081 不和常见端口冲突；-T是管理接口，varnishadm连的就是它；-s malloc,256m表示用普通内存做缓存后端，在 Cygwin 下这比 file 后端稳得多，因为文件后端的 mmap 语义在兼容层上更容易出偏差；-n是实例目录；-F强制前台运行——这一条在 Cygwin 上是关键，后台守护模式涉及 fork 与文件描述符继承，兼容层的模拟经常出问题，宁可用nohup ... &自己托管，也别用-F之外的守护模式。

4.2 后端探测与缓存命中策略

VCL 的写法本身不难，难点在于每条规则的副作用。下面这份配置覆盖了探测、Cookie 处理、错误响应降级三件最常做的事：

vcl 4.0; backend default { .host = "127.0.0.1"; .port = "8080"; .connect_timeout = 1s; .first_byte_timeout = 5s; .between_bytes_timeout = 2s; .probe = { .url = "/healthz"; .timeout = 1s; .interval = 5s; .window = 5; .threshold = 3; } } sub vcl_recv { # 非幂等方法直接放行，避免缓存层改写语义 if (req.method != "GET" && req.method != "HEAD") { return (pass); } # 管理路径不缓存，且不清理 Cookie（后端需要会话） if (req.url ~ "^/admin") { return (pass); } # 其余请求统一剥掉 Cookie，否则默认规则会全部判为不可缓存 unset req.http.Cookie; } sub vcl_backend_response { # 5xx 不缓存，但保留 10s 的短暂标记，避免故障期间被反复打穿 if (beresp.status >= 500) { set beresp.uncacheable = true; set beresp.ttl = 10s; return (deliver); } set beresp.ttl = 60s; set beresp.grace = 30s; }

.probe块里window = 5和threshold = 3的组合含义是：最近 5 次探测里至少 3 次成功，后端才算健康。这两个值调小会让后端在抖动时被过早摘除，调大则故障时摘除不及时。interval别低于 1s，Cygwin 下定时器的精度比 Linux 差，过密的探测反而引入噪声。

grace = 30s是 Varnish 里性价比最高的一个参数：对象过期后 30 秒内，如果后端不可用，仍然把旧对象发出去而不是返回 503。配合vcl_hit里的默认行为就能生效，不需要额外写逻辑。这个机制在本地验证时特别有用，因为你的后端常常是临时起的，重启一下就会触发。

4.3 观测：varnishstat / varnishlog 关键指标

配置写完不代表生效，得用指标证明。varnishstat的字段很多，日常盯这几个就够：

# -1 输出一次快照后退出，-f 只取关注的字段，输出适合直接贴进对比表 /usr/local/varnish/bin/varnishstat -1 \ -f MAIN.cache_hit \ -f MAIN.cache_miss \ -f MAIN.backend_fail \ -f MAIN.sess_dropped \ -f MAIN.n_object

判断标准很直接：cache_hit占比应该在预热后明显上升；如果一直是cache_miss增长而cache_hit纹丝不动，问题一定在vcl_recv或vcl_backend_response里——要么请求被pass了，要么响应带了不可缓存的头（Set-Cookie、Cache-Control: no-store、Vary: *三者最常见）。

# 按请求维度串起完整生命周期，定位是哪一个阶段把对象变成了不可缓存 /usr/local/varnish/bin/varnishlog -g request \ -q "BereqURL eq '/index.html'" | head -60

-q的过滤表达式语法和 VCL 类似，BereqURL是后端请求的 URL 字段。看日志时重点找VCL_call那几行，它会明确告诉你走了RECV、HIT、MISS还是PASS，以及进入backend_response之后TTL被设成了多少。如果 TTL 显示0.000或者uncacheable，往前翻找set beresp.那行，答案就在那儿。

5. 避坑与排查：构建期到运行期的五条实战记录

5.1 构建与启动阶段的三个坑

坑一：configure 全绿，varnishd 一启动就静默退出。

现象是命令行返回码非 0，但不打印任何有用信息，只有一行 "Child exited" 之类。原因九成是-n指定的实例目录不存在，或者路径里含空格、中文、盘符映射异常。Varnish 启动时要在这个目录下创建共享内存文件，创建失败就直接退，错误信息被吞进了管理进程的日志里。

解决办法：启动前显式建目录并验证可写，路径只使用 ASCII 字符。Cygwin 下/var/lib/varnish实际映射到C:\cygwin64\var\lib\varnish，如果安装时选过非默认根目录，这个映射可能不是你以为的那个。

# 用与 varnishd 相同的用户身份验证写权限，别用 root 验完就以为没事 mkdir -p /var/lib/varnish/instance1 touch /var/lib/varnish/instance1/.wtest && rm /var/lib/varnish/instance1/.wtest && echo writable

坑二：varnishadm 连不上管理端口。

现象是varnishadm -T 127.0.0.1:6082 status返回 "Connection refused" 或者 "Authentication required"。前者的原因是启动参数里根本没加-T，默认不开放管理接口；后者是 secret 文件权限不对，客户端读不到口令就无法完成握手。

解决办法：启动时显式给-T 127.0.0.1:6082，别监听0.0.0.0；secret 文件用-S指定，权限收到 600 且属主与运行用户一致。

# 生成 secret 并锁定权限 dd if=/dev/urandom of=/etc/varnish/secret bs=32 count=1 2>/dev/null chmod 600 /etc/varnish/secret /usr/local/varnish/bin/varnishadm -S /etc/varnish/secret -T 127.0.0.1:6082 status

坑三：编译期出现__imp_前缀的链接错误。

现象是undefined reference to '__imp_pthread_mutex_lock'这类，符号名前面带__imp_。原因是链接器以为这个符号来自 DLL 导入表，说明参与链接的库和目标文件不是同一套工具链产出的。在 Windows 上装过多个编译器的人几乎必踩。

解决办法：先查编译器身份，再查PATH里有没有残留的其他工具链目录，清理后重开 shell。

# target 必须是 cygwin，不能是 mingw32 或 msys gcc -dumpmachine # 列出所有 gcc 来源，非 Cygwin 路径一律从 PATH 移除 which -a gcc

5.2 运行期缓存不命中的两个坑

坑四：命中率始终为零，varnishstat里只有 miss 在涨。

现象是压测几十次同一 URL，cache_hit一直是 0。原因通常是响应头里有Set-Cookie，或者请求头里带了Cookie、Authorization，Varnish 的默认规则遇到这些会直接判为不可缓存。在vcl_recv里unset req.http.Cookie只解决了一半，如果后端仍然在响应里回Set-Cookie，对象照样进不了缓存。

解决办法：在vcl_backend_response里根据路径决定是否剥掉Set-Cookie，并且用日志确认 TTL 真的被设上了。

sub vcl_backend_response { # 静态资源不需要会话，剥掉 Set-Cookie 才能缓存 if (bereq.url ~ "^/static/") { unset beresp.http.Set-Cookie; set beresp.ttl = 300s; } }

坑五：Cygwin 下给进程发信号没有反应。

现象是kill -USR1 <pid>之后预期的日志轮转或者缓存清空没发生，进程安安静静。原因是 Windows 的信号模型和 POSIX 不同，Cygwin 只模拟了一部分，SIGUSR1这类自定义用途的信号在跨进程边界时经常丢失或不被投递。

解决办法：别依赖信号做运维动作，改用管理接口。varnishadm的ban和vcl.load能覆盖绝大多数场景，而且有返回值可以判断成败。

# 用管理接口清缓存，比发信号可靠且可验证 /usr/local/varnish/bin/varnishadm -S /etc/varnish/secret -T 127.0.0.1:6082 \ "ban req.url ~ ^/static/"

这五条按出现频率排下来，前三条属于「配置没给对」，后两条属于「Varnish 的默认行为与预期不符」。区分开之后排查路径完全不同：前者去看启动命令和日志，后者去看varnishlog里的VCL_call序列。

6. 进阶：用 vcl_hash 修正灰度分流的缓存污染

灰度发布是缓存层最容易埋雷的场景。常见的写法是在vcl_recv里按比例把请求打到新后端，看起来没问题，实际跑起来会发现新旧两个版本的内容互相串——用户刷新一次看到旧页，再刷新看到新页，因为同一个 URL 的响应被写进了同一个缓存键。

vcl 4.0; import std; backend blue { .host = "127.0.0.1"; .port = "8080"; } backend green { .host = "127.0.0.1"; .port = "8081"; } sub vcl_recv { # 显式指定优先，便于用 curl -H 定点验证 if (req.http.X-Canary) { set req.backend_hint = green; set req.http.X-Canary-Id = "green"; } else if (std.random(100) < 10) { set req.backend_hint = green; set req.http.X-Canary-Id = "green"; } else { set req.backend_hint = blue; set req.http.X-Canary-Id = "blue"; } } sub vcl_hash { # 关键一步：把灰度标识并入缓存键，隔离两套后端的内容 hash_data(req.url); if (req.http.host) { hash_data(req.http.host); } if (req.http.X-Canary-Id) { hash_data(req.http.X-Canary-Id); } return (lookup); }

vcl_hash里必须显式return (lookup)，否则默认逻辑会再叠加一轮。hash_data的调用顺序本身不影响结果（内部是逐段拼接），但把req.url放第一段、X-Canary-Id放最后一段，读日志时更容易分辨这个键属于哪个版本。

验证不能靠人肉刷新。Varnish 自带varnishtest，写一个.vtc脚本就能把分流比例和缓存隔离一起测掉：

# canary.vtc：起一个 mock 后端，验证带 X-Canary 的请求命中 green varnishtest "canary isolation" server s1 { rxreq txresp -hdr "Content-Type: text/plain" -body "blue" } -start server s2 { rxreq txresp -hdr "Content-Type: text/plain" -body "green" } -start varnish v1 -vcl+backend { backend blue { .host = "${s1_addr}"; .port = "${s1_port}"; } backend green { .host = "${s2_addr}"; .port = "${s2_port}"; } sub vcl_recv { if (req.http.X-Canary) { set req.backend_hint = green; set req.http.X-Canary-Id = "green"; } else { set req.backend_hint = blue; set req.http.X-Canary-Id = "blue"; } } sub vcl_hash { hash_data(req.url); if (req.http.X-Canary-Id) { hash_data(req.http.X-Canary-Id); } return (lookup); } } -start client c1 -connect ${v1_sock} { txreq -url "/a" -hdr "X-Canary: 1" rxresp expect resp.body == "green" } client c2 -connect ${v1_sock} { txreq -url "/a" rxresp expect resp.body == "blue" }

跑varnishtest canary.vtc，两个 client 块分别断言 green 和 blue，全部通过才说明缓存键真的隔离了。这套脚本的价值在于可回归——以后改 VCL 之前先跑一遍，比上线后靠监控发现串内容要便宜得多。

一个容易忽略的边界：std.random在vcl_recv里每次请求都会重新取值，所以同一个客户端连续请求可能落到不同后端。如果业务要求同一会话粘住，得改成基于 Cookie 或client.ip的哈希取模，而不是随机数。我在一个模拟项目X上就因为这个细节被用户投诉过「页面在两种样式之间跳」——分流的判定条件必须是稳定的，随机只适合做流量比例统计，不适合做用户归属。

从那以后我每次动 VCL 的哈希逻辑，都会先补一个varnishtest用例，再跑一遍varnishstat -1看n_object是不是按预期翻倍。改缓存策略最怕的不是改错，是改错了还看不出来。希望帮到你。

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