★ FEATURED ARTICLE 简介这是一份面向Java、Android及JVM生态开发者的Gradle 8.6版本资源包适合需要快速获取构建工具、对照版本升级或研读构建自动化实现的中高级用户。压缩包共2000个文件以1962个Java源码类、34个properties配置为主另含3个txt说明和1个pdf文档整体约209.99MB覆盖命令行、Wrapper、核心库与文档等组成部分。该版本涉及自定义加密密钥配置缓存、构建初始化脚手架、构建创作API更新及性能优化可用于理解缓存安全策略、插件生命周期扩展与构建效率改进在隐私数据项目、团队协作和性能敏感场景中具有参考意义。内容预览中的BuildProgressListenerAdapter、DefaultServiceRegistry、JavaBasePlugin等类便于按模块查阅构建事件监听、服务注册以及JVM和原生插件实现可辅助定位构建流程关键实现。已有1673人学习适合作为版本特性对照、插件开发参考与源码研读资料。1. gradle-8.6-all.zip 卡在进度条一个 200MB 压缩包为什么要单独下新建工程后第一次同步进度条停在 Downloading gradle-8.6-all.zip 这一行不动等五分钟、十分钟最后超时重来——这个画面在内网办公环境和 CI 流水线里都出现过。gradle-8.6 属于 8.x 系列里相对稳的版本而 all 分发包不只是一份构建工具它还带着 Gradle 自身的源码和 API 文档是离线环境和二开插件时最省事的底本。日常构建只想快bin 就够了但只要涉及看源码、查 DSL、在断网机器上把构建跑通all 才是那个不该省的选项。下面按「包结构 → 下载路径 → 落地配置 → 踩坑 → 版本对齐」把这条链路拆开每一步都能照着复现。2. 分清 all 与 bin目录差异、体积构成和三条选型判断很多人拿到 gradle-8.6-all.zip 的第一反应是「不就是一个大一点的 bin 吗」解压后随手丢进某个目录然后在 IDE 里发现源码跳转还是灰的、DSL 文档还是查不到才回头怀疑是不是包下错了。这两个分发包的差距不在功能而在「随包带的东西」——构建引擎本身完全一致跑出来的产物也一致差别只在你能不能离线自查。2.1 解压后的目录结构对照先看解压出来的东西长什么样。bin 包的结构非常克制四个目录加一个许可文件all 包在前者基础上多了两棵子树。# gradle-8.6-bin 解压后 gradle-8.6/ ├── bin/ # gradle、gradle.bat 两个启动脚本 ├── lib/ # 构建引擎、各模块 jar、可信插件 ├── init.d/ # 全局初始化脚本目录放这里对所有项目生效 └── LICENSE # gradle-8.6-all 解压后在上述基础上追加 ├── src/ # Gradle 自身的 Java/Groovy/Kotlin 源码 └── docs/ # javadoc、userguide、DSL 参考手册bin/里那两个启动脚本是入口Windows 下 Gradle 会调用gradle.batLinux/macOS 走gradle脚本的作用是拼出一串-classpath再拉起 JVMlib/是真正干活的 jar 集合构建过程中加载的插件、序列化组件、增量编译组件基本都在这里。init.d/容易被忽略往里面丢一个.gradle文件就等于给这台机器上所有项目注入了初始化逻辑做企业内统一仓库地址配置时很常用。src/和docs/是 all 独有。前者让你在 IDE 里点进某个 Gradle 内部类时能落到真实源码而不是反编译的伪代码后者是慢着翻的离线手册在没有外网的机器上排错时比搜索引擎可靠。对比项bin 分发包all 分发包内容构成启动脚本 运行库启动脚本 运行库 源码 文档体积量级较小明显更大多出的是源码与文档两棵树源码跳转调试不可用可用离线查 DSL 文档不可用可用纯 CI 构建完全够用没有必要内网/断网开发机能用但受限推荐体积上 all 大约是 bin 的一倍多多出来的部分对构建速度没有任何影响——Gradle 运行时不会去加载src/和docs/它们纯粹是给人看的。所以「装 all 会让构建变慢」是个误判慢的原因通常在别处。2.2 三条选型判断避免下错包判断标准只有三条对号入座即可。第一条这台机器能不能稳定访问外网。完全断网或者访问极不稳定的直接选 all。因为 bin 只能解决「跑构建」一旦构建脚本里用了较新的 DSL 写法报错你连查文档的地方都没有只能重启网络去搜这种情况下 bin 省下的那点体积毫无价值。第二条会不会碰到 Gradle 内部 API。写自定义插件、改 buildSrc 里的共享逻辑、排查插件冲突时想看某个Task的真实实现all 的源码是刚需。反编译出来的方法体没有注释、变量名被混淆成var1读起来非常消耗耐心。第三条这台机器是不是只在流水线里跑assemble、test这类标准任务。是的话 bin 就够CI 镜像里带 all 只会让镜像层变大缓存命中率变低。提示同一个项目里开发者本机装 all、CI 镜像装 bin是完全正常的组合wrapper 用同一个 distributionUrl 不会因此产生构建差异。2.3 下载完先别解压校验与自检包下完第一件事不是解压是校验。Gradle 官方在分发包旁边提供了一份.sha256文件内容就是压缩包的哈希值。断点续传、镜像同步、下载工具分片这些环节都可能让文件「看起来完整、实际损坏」而损坏的 zip 解压到一半才报错排查成本远高于提前算一次哈希。# 1. 下载压缩包与官方哈希文件文件名规则见第 3 章 curl -L -O https://services.gradle.org/distributions/gradle-8.6-all.zip curl -L -O https://services.gradle.org/distributions/gradle-8.6-all.zip.sha256 # 2. 计算本地文件哈希 sha256sum gradle-8.6-all.zip # 3. 与官方文件内容逐字符比对去掉首尾空白 cat gradle-8.6-all.zip.sha256Linux 下用sha256summacOS 用shasum -a 256Windows PowerShell 用Get-FileHash gradle-8.6-all.zip -Algorithm SHA256。三个平台输出格式不同但比对的是同一串十六进制字符串只要前六位和后六位都一致中间基本不会出问题——真要严谨就整串比对。curl的参数含义-L表示跟随重定向Gradle 的下载地址会跳到实际存储位置-O表示用远程文件名保存到本地如果是续传加-C -让 curl 从断点接着写。这一步在下载大文件时很实用尤其是网络抖动频繁的环境比重新下一遍省事得多。校验通过之后再解压到目标目录进入第 4 章配置环境变量。跳过校验直接解压的人不少翻车现场通常是「解压到 97% 报 unexpected end of file」然后怀疑是下载工具的问题实际是文件本来就不完整。3. 三条下载路径直链、镜像替换与 wrapper 缓存预置同一个 zip 有三种拿到手的方式适用场景完全不同直链适合能访问官方源的个人机器镜像替换适合持续集成和内网wrapper 缓存预置适合「机器压根不能联网、但必须把项目跑起来」的场合。三条路径可以混用关键是把文件放到 Gradle 认的位置。3.1 官方直链与命名规则Gradle 的分发包地址有固定规律把版本号和包类型替换掉即可# 官方分发地址 https://services.gradle.org/distributions/gradle-8.6-all.zip https://services.gradle.org/distributions/gradle-8.6-bin.zip # 配套校验文件 https://services.gradle.org/distributions/gradle-8.6-all.zip.sha256规律是gradle-版本号-all|bin.zip版本号必须精确到小版本8.6不能写成8或8.x路径不存在会直接 404。下载时建议一次性把.sha256也拿下来后面配置镜像时如果镜像站不同步校验文件这份就是对照基准。超过两百兆的文件在普通宽带上不算慢但如果公司出口带宽紧张、或者下载被限速单线程 curl 可能要跑很久。这时候可以拆成多段并发下代价是要自己合并和校验# 分四段并发下载仅在有校验手段时使用 for i in 0 1 2 3; do start$((i * 52428800)) end$(((i 1) * 52428800 - 1)) curl -L -r ${start}-${end} -o part_${i} \ https://services.gradle.org/distributions/gradle-8.6-all.zip done wait cat part_0 part_1 part_2 part_3 gradle-8.6-all.zip sha256sum gradle-8.6-all.zip # 必须重新校验-r指定字节区间让四段并行wait等全部结束。合并后的文件必须重新算哈希只要分片边界错一个字节得到的就是一个能解压但内容错乱的包而且往往要到构建阶段才暴露。这个玩法我只在网络确实卡死的时候用日常还是老老实实单线程加--retry。3.2 镜像站改 distributionUrl 而不是改下载习惯镜像站的价值不是让你手动下得更快而是让 wrapper 自己自动从镜像拉包。做法是把项目里gradle/wrapper/gradle-wrapper.properties的distributionUrl换掉# 原始官方源 distributionUrlhttps\://services.gradle.org/distributions/gradle-8.6-all.zip # 替换为镜像主机名换成你所在环境可用的镜像域名 distributionUrlhttps\://mirror-host/gradle/gradle-8.6-all.zip这里有两个坑必须提前说清楚。第一properties 文件里的冒号要转义成\:反斜杠不能省否则 Java 的 Properties 解析会把冒号当分隔符读出来的 URL 从https就断了。第二换完地址后wrapper 缓存的目录名也会跟着变——因为目录名是由 URL 字符串算出来的——所以旧目录里的 zip 不会被复用等于要重新下一次。这一点在第 3.3 节还会展开。镜像站是否同步.sha256文件要看具体镜像的实现有些只同步了 zip 本体。如果镜像缺校验文件把官方那份存下来对照即可。另外要注意镜像的目录层级不同镜像的路径习惯不一样有的是/gradle/gradle-8.6-all.zip有的是/gradle/distributions/gradle-8.6-all.zip先用curl -I看响应头再决定# -I 只取响应头能看到状态码、Content-Length 和重定向 curl -I https://mirror-host/gradle/gradle-8.6-all.zip如果返回 200 且Content-Length是几十万到几百万字节量级的数字说明路径对了返回 301/302 就跟着Location再试返回 404 就是路径错了别硬猜。3.3 把 zip 预置进 wrapper 缓存无网环境的确定性做法Gradle 每次同步前会检查GRADLE_USER_HOME/wrapper/dists/下有没有它要的那个版本。判断依据是目录名而目录名是用distributionUrl字符串的 MD5 值转 36 进制得到的。所以只要把 zip 放进正确目录wrapper 就会跳过下载、直接解压。最稳的做法是「先让它自己跑一次再替换」。在能联网的机器上打开一次项目让 wrapper 把目录建出来然后进目录看结构# 定位缓存目录默认在用户主目录下 ls ~/.gradle/wrapper/dists/ # 输出类似 # gradle-8.6-all/一串hash/ # ├── gradle-8.6-all.zip # 下载的压缩包 # ├── gradle-8.6-all.zip.lck # 下载锁文件 # ├── gradle-8.6-all.zip.part # 下载中的临时文件存在说明没下完 # └── gradle-8.6/ # 解压后的目录拿到这串 hash 之后在内网机器上手工建同名目录把校验过的 zip 拷进去再触发一次构建即可。整个过程不需要任何网络请求。如果手头没有能联网的机器也可以自己算这个目录名。算法是对distributionUrl字符串取 MD5把 16 字节结果当无符号大整数转成 36 进制。import hashlib url https://services.gradle.org/distributions/gradle-8.6-all.zip digest hashlib.md5(url.encode(utf-8)).digest() n int.from_bytes(digest, big) alphabet 0123456789abcdefghijklmnopqrstuvwxyz out while n: n, r divmod(n, 36) out alphabet[r] out print(out or 0)encode(utf-8)不能省URL 里的非 ASCII 字符会影响字节序列int.from_bytes(..., big)对应 Java 里new BigInteger(1, digest)的语义符号位用 1 表示正数。算出来的字符串应该和 wrapper 实际创建的目录名完全一致。注意这个目录名对 URL 是敏感的distributionUrl里多一个空格、少一个转义反斜杠算出来的 hash 就完全不同。手工建目录之前先把gradle-wrapper.properties里的那行复制出来逐字符核对一遍比事后对着空目录发愁强。放置完成后执行一次./gradlew --version看到的版本号是 8.6 就说明缓存被认了。如果仍然在下载八成是目录名不对或者 zip 文件名被改过比如浏览器自动加了(1)后缀wrapper 只认gradle-8.6-all.zip这个名字。4. 落地配置解压位置、GRADLE_USER_HOME 与四行 wrapper 参数文件到手只是第一步接下来要决定它放在哪、怎么被找到、缓存写到哪里。这三件事决定了后续是「一次配好长期省心」还是「每次换机器重来一遍」。4.1 解压位置与环境变量手动安装的 Gradle 建议放在一个不带空格、不带中文的固定路径下Windows 用D:\tools\gradle-8.6Linux/macOS 用/opt/gradle-8.6。带空格的路径在批处理脚本和某些插件里会被拆成两个参数这类问题排查起来非常费神。# Linux / macOS解压到 /opt 并配置环境变量 sudo unzip gradle-8.6-all.zip -d /opt/ export GRADLE_HOME/opt/gradle-8.6 export PATH$GRADLE_HOME/bin:$PATH # 写入 shell 配置文件避免每次开终端重设 echo export GRADLE_HOME/opt/gradle-8.6 ~/.bashrc echo export PATH$GRADLE_HOME/bin:$PATH ~/.bashrc source ~/.bashrc# Windows PowerShell解压并追加到用户级 PATH Expand-Archive -Path .\gradle-8.6-all.zip -DestinationPath D:\tools\ [Environment]::SetEnvironmentVariable( GRADLE_HOME, D:\tools\gradle-8.6, User) [Environment]::SetEnvironmentVariable( Path, $env:Path ;D:\tools\gradle-8.6\bin, User)GRADLE_HOME这个变量 Gradle 自己其实不读它只是给人和给部分 IDE 用的约定真正起作用的是PATH里那个bin目录。所以配完必须重开一个终端窗口验证当前窗口里的PATH不会因为SetEnvironmentVariable而刷新——这是 Windows 下最常见的「明明配了却找不到命令」。提示项目里同时存在gradlew时优先用./gradlew而不是全局的gradle。wrapper 锁定的是项目约定的版本全局命令用的是你 PATH 里那个两者不一致会导致「本机能构建、换台机器就失败」。4.2 GRADLE_USER_HOME 与缓存布局默认情况下 Gradle 把一切缓存写到~/.gradle。系统盘紧张或者需要在多台机器间共享依赖时可以改GRADLE_USER_HOME指向一个大盘目录# 指向独立数据盘 export GRADLE_USER_HOME/data/gradle-home mkdir -p $GRADLE_USER_HOME改了之后 wrapper 缓存、依赖缓存、daemon 日志全部跟着搬家原来~/.gradle里的东西不会自动迁移需要手动拷# 迁移旧缓存先停掉所有 daemon避免文件被占用 ./gradlew --stop cp -a ~/.gradle/. /data/gradle-home/缓存目录里值得认识几个子目录子目录作用出问题时的表现wrapper/dists/各版本分发包与解压结果每次同步都重新下载caches/modules-2/依赖 jar 与元数据依赖解析反复走网络caches/jars-9/等构建缓存与转换结果构建变慢但功能正常daemon/守护进程日志构建莫名卡住时看这里native/平台相关的本地库跨平台共享目录时容易出问题跨平台共享GRADLE_USER_HOME比如同一个网络盘给 Windows 和 Linux 用是一个典型的错误用法native/目录下放的是编译好的本地库两个平台互相覆盖会直接导致 JVM 崩溃。要共享就只共享caches/modules-2/通过gradle.properties里的只读缓存配置单独指定。4.3 gradle-wrapper.properties 里值得改的四行wrapper 配置项不多但每一行出错都能让你多等十分钟。下面是完整形态和逐行解释# 缓存根目录默认就是 GRADLE_USER_HOME distributionBaseGRADLE_USER_HOME # 相对根目录的存放路径 distributionPathwrapper/dists # 压缩包下载地址冒号需转义 distributionUrlhttps\://services.gradle.org/distributions/gradle-8.6-all.zip # 压缩包单独存放路径不写则与 distributionPath 一致 zipStoreBaseGRADLE_USER_HOME zipStorePathwrapper/dists # 网络超时单位毫秒弱网环境适当调大 networkTimeout10000 # 是否校验分发地址的合法性 validateDistributionUrltruedistributionUrl是核心版本和包类型都写在这里networkTimeout默认值偏小弱网下经常没下完就断调到 60000 也合理validateDistributionUrl打开时会检查 URL 协议关掉它一般没什么好处除非你确实在用自定义协议。distributionBase和zipStoreBase支持GRADLE_USER_HOME和PROJECT两个值。选PROJECT会把包放进项目目录下的gradle/wrapper/dists好处是可以随项目一起打包带走坏处是每个项目都存一份磁盘占用翻倍而且容易被误提交到仓库。除非有明确的离线分发需求否则维持默认。4.4 验证三步确认这套配置真的生效配置完不要急着开 IDE先用命令行跑三步每一步都有明确预期。# 第一步确认版本与 JVM ./gradlew --version # 预期输出包含Gradle 8.6、Launcher JVM 的版本、Kotlin 与 Groovy 的版本 # 第二步确认没有走网络下载 ./gradlew --version --offline # 如果上一步刚跑完这一步应该秒回说明包已在本地 # 第三步跑一次最小任务确认依赖解析链路通 ./gradlew help --info # --info 会打印分发包路径、用户主目录、JVM 参数--version的输出里有一行Gradle user home这是确认GRADLE_USER_HOME有没有生效的最直接证据。如果它指向的还是~/.gradle而你明明设了环境变量说明变量没被当前进程继承检查是不是在 IDE 里跑的——IDE 往往有自己的环境变量来源。--info输出的前几行会打印实际使用的分发包位置形如Gradle distribution: file:/data/gradle-home/wrapper/dists/...。这一行就是「你的包到底有没有被用上」的最终答案比任何猜测都准。5. 避坑六个让下载白费的细节与对应排查手法前面几章的路径走通之后剩下的问题基本都集中在「文件对了但没被认」和「认了但版本不匹配」两类。下面六条是我自己踩过、也在别人机器上复现过的每条按现象、原因、解决写清楚。5.1 下载与缓存环节的三条坑一包下到一半就解压报 unexpected end of file。现象解压到某个百分比突然中断提示压缩包损坏或者 CRC 校验失败。 原因下载被中断或者用的是镜像站但该站同步不完整文件长度不足。很多人看到.part文件存在还以为是解压产生的。 解决先看目录里有没有gradle-8.6-all.zip.part有就说明下载没完成删掉重下没有就对照官方.sha256算一次哈希。判断标准是文件大小和哈希双一致不要只看「解压能打开」。坑二手工解压到 wrapper 目录结果每次构建还在下载。现象明明把gradle-8.6目录放进了wrapper/dists/hash/./gradlew却还是发起网络请求。 原因wrapper 认的是压缩包不是解压后的目录。它发现目录里没有gradle-8.6-all.zip就当没缓存过重新下载。而且解压完成的判定依赖一个.ok标记文件手工解压不会生成它。 解决只放 zip不放解压目录让 wrapper 自己解压。如果非要手工解压确认目录结构和自动解压出来的一致并且补上标记文件——但这属于不推荐操作容易在版本升级后出问题。坑三改了 distributionUrl旧缓存直接失效。现象把官方地址换成镜像地址后原本已经下好的包不被复用重新开始下载。 原因缓存目录名由 URL 字符串的 MD5 决定URL 变了目录名就变了等于换了一个缓存槽位。 解决换镜像地址之前先想清楚是长期用镜像还是临时救急。临时救急建议直接下载 zip 再手工放进原目录不动distributionUrl长期用镜像就把这一行固化成项目约定写进仓库避免每个人各改各的。5.2 版本与运行时环节的三条坑四JDK 版本不满足报 Unsupported class file major version。现象./gradlew --version直接报错提示 unsupported class file major version 65 之类。 原因运行 Gradle 的 JVM 版本和 Gradle 版本不匹配。gradle-8.6 最低要求 JDK 8可以运行在更高的 JDK 上但反过来用过低版本去跑新版 Gradle 就会失败。major version 65对应 Java 21出现这个报错通常是某个环节用了比 Gradle 支持范围更高的 JDK。 解决java -version和./gradlew --version里的 JVM 版本对一遍。项目需要固定 JDK 时在gradle.properties里显式指定# 指定构建使用的 JDK 路径避免受系统 JAVA_HOME 影响 org.gradle.java.home/opt/jdk-17 # 守护进程的堆大小大项目建议调到 2g 以上 org.gradle.jvmargs-Xmx2g -Dfile.encodingUTF-8org.gradle.java.home只影响 Gradle 自身运行用的 JVM编译产物的目标版本由java.toolchain或sourceCompatibility决定两者不是一回事混淆了会得出「明明换了 JDK 还是报同样的错」的结论。坑五wrapper 版本和构建插件版本对不上。现象包下好了、版本也对构建仍然在配置阶段报错提示某个插件需要更高或更低的 Gradle 版本。 原因Android Gradle Plugin、Kotlin 插件这类组件对 Gradle 版本有明确的兼容区间单看 Gradle 版本没问题组合起来就越界了。 解决回到项目根目录看插件的版本声明对照该插件文档里的兼容表确认区间。降级 Gradle 不是唯一解很多时候是插件版本偏旧升插件比降 Gradle 更安全。改 wrapper 版本时记得同步改distributionUrl和本地缓存两者不一致会出现「命令行是 8.6、IDE 里还是旧版本」的错位。坑六GRADLE_USER_HOME 指向了只读或无写权限的路径。现象构建能启动但下载依赖时报Permission denied或者卡在写缓存这一步。 原因环境变量指到了一个当前用户没有写权限的目录常见于把缓存放在系统级路径或者只读挂载盘上。 解决确认目录属主和权限ls -ld $GRADLE_USER_HOME看一眼。CI 环境里更常见的是容器内用户 UID 和挂载卷属主不一致要么改挂载权限要么把GRADLE_USER_HOME指到容器内可写的路径再通过卷把caches/modules-2映射出去复用。注意这六条里有四条最终都指向同一个动作——先确认「Gradle 实际用的是哪个目录、哪个版本、哪个 URL」再动手改。--version和--info两个命令能省掉大半猜测。6. 版本对齐与离线构建把 gradle-8.6 用稳的两个习惯包能下、能解压、能跑起来之后真正决定这套环境能不能长期用的是两件事版本矩阵别踩线离线开关别乱开。这两个习惯养成之后换机器、换项目、进内网都不用重新摸索。6.1 先对 JDK再对插件Gradle 的版本兼容问题绝大多数出在 JDK 和构建插件的组合上而不是 Gradle 本体。我的做法是先把三者的关系列成一张小表贴在项目 README 里新人进来直接对照省掉互相问。运行 Gradle 的 JDK可行性备注JDK 8可用gradle-8.6 的最低要求仅建议老项目JDK 11 / 17推荐与 gradle-8.6 配合最稳的区间JDK 21可用需确认构建插件已支持该版本表里第一列是「跑 Gradle 的那个 JVM」不是「编译产物的目标版本」。很多团队把这两件事混为一谈结果在gradle.properties里写了org.gradle.java.home又去改sourceCompatibility改完发现报错没变。正确顺序是先确认 Gradle 自己跑在哪个 JDK 上再确认 toolchain 声明的编译目标版本最后才看插件兼容性。插件这边Android Gradle Plugin、Kotlin 插件、各类代码质量插件都有自己的兼容区间。判断方法不是背表而是看报错信息里给出的区间提示然后去插件的发布说明里核对。我一般会在升级 Gradle 之前先把插件版本查一遍反过来也一样——单边升级是最容易出事的操作。6.2 离线开关要配合缓存验证使用--offline是个好开关但它只保证「不去网络取新东西」不保证「本地一定有」。所以正确的用法是先在线跑通一次把依赖全部落进caches/modules-2/再断网验证# 第一次在线把所有依赖拉全 ./gradlew build # 第二次离线验证本地缓存是否完整 ./gradlew build --offline # 如果报 Could not resolve说明有依赖没进缓存 # 用 --refresh-dependencies 在线再跑一次把缺的补上 ./gradlew build --refresh-dependencies--refresh-dependencies会让 Gradle 忽略缓存里的元数据重新解析代价是慢但能解决「版本号带 SNAPSHOT 或动态版本导致缓存过期判断失效」的问题。CI 里我一般只在缓存命中率异常下降时才用它平时靠固定的版本号加缓存挂载就够了。另外一个常被忽略的点是--offline和 daemon 的关系。daemon 会缓存一部分解析结果改了gradle.properties之后如果没重启 daemon新配置可能不生效。./gradlew --stop是低成本的排错手段比逐项排查快得多。从那次在内网机器上折腾了整整一个下午、最后发现是手工解压目录缺.ok标记之后我每次配新环境都会先跑一遍./gradlew --version看它打印的 user home 和 distribution 路径对不对再往下走。这个习惯看着笨但确实把大部分「玄学问题」挡在了前面。希望帮到你。本文还有配套的精品资源点击获取
阅读完成 · 觉得有帮助？
