企业官网建设流程全解析

简介：Android Studio 4.2.2 for Windows 是 Google 官方推出的 Android 集成开发环境稳定版，面向 Windows 平台开发者，提供从代码编写、调试、模拟器运行到性能分析的一站式工具链，兼具可视化布局编辑器、Kotlin 优化、Jetpack 库集成等能力，适合从入门到团队协作的不同场景。资源包共含 2711 个文件，压缩包体积约 934.65MB，主要文件类型包括 jar（构建与库文件）、py（辅助脚本）、json（配置数据）、ttf/otf（字体资源）、dll/exe（运行组件）等，目录结构完整，解压即可安装使用。目前已有 6399 人学习下载。借助内置的 Gradle 插件、Android 模拟器与 Profiler 工具，开发者可快速搭建环境、验证 UI 布局、分析内存与 CPU 性能，并利用代码检查和自动重构维护高质量代码，是一份适合 Windows 用户日常 Android 开发与学习的完整工具包。

1. Android Studio 4.2.2 for Windows：老项目维护为何还值得留一个安装包

Android Studio 4.2.2 for Windows 这个版本，放到今天是有点“过气”，但对做老项目维护的人来说，它反而是最不折腾的选择。它对应的 Android Gradle Plugin（AGP）是 4.2.2，编译 SDK 默认落在 API 30（Android 11），Gradle 从 6.7.1 就能跑，不强制你跟进 Compose、Kotlin DSL 这些新东西。我手里好几个 2018 到 2021 年的项目，最后都是用 4.2.2 收尾的，因为新版 IDE 每次一升级，老工程的 Gradle 和依赖就要跟着抖三抖。

这份资源适合三类人：第一类是手上握着老项目、被新版 IDE 反复升级搞烦的开发；第二类是普通配置的 Windows 电脑，装北极狐之后风扇狂转、点一下编译要喝口水的；第三类是刚开始学 Android、需要找一个报错信息能被搜索引擎命中、教程和资料最多的环境。它就是一个能重复安装的 Windows 安装包，装完以后 SDK、模拟器、Gradle 全都可以离线配置或走镜像流程，不需要一边装一边干等网络。

提示：新版 AS 能打开老项目，但反过来 4.2.2 打不开用新 AGP 语法建的工程。把它定位成“老项目维护机”或“入门学习机”，比当成“最新开发环境”更合适。

2. Windows安装三步走：安装包校验、JDK绑定与SDK目录落位

2.1 安装包类型：exe引导式和免安装包怎么选

4.2.2 在 Windows 上通常是两种形态：一个是带引导界面的 .exe 安装包，一个是解压即用的 zip 包。我不建议一开始就用 zip 包，因为 exe 向导会顺手帮你写入必要的环境变量和文件关联，zip 包解压后虽然也能跑，但命令行工具和文件类型图标经常缺一点，新手排查起来多一层麻烦。

如果是 exe 安装包，安装路径我有两个习惯：一是不要放 C 盘，二是路径里不要出现空格和中文。常见踩坑是用户把 Android Studio 装在C:\Program Files\Android\Android Studio里，后面用 Gradle 时某些 native 工具对空格路径处理不好，就会冒出一堆奇怪错误。我一般放在D:\Android\AndroidStudio这种纯英文短路径下。

拿到安装包后，先校验一下哈希，避免下载过程文件损坏导致安装到一半报错。Windows 自带命令就能做：

# 在 PowerShell 或 CMD 中校验 SHA256，路径换成你实际下载位置 certutil -hashfile "D:\downloads\android-studio-4.2.2-windows.exe" SHA256

命令里的certutil是 Windows 自带的证书工具，-hashfile参数指定要校验的文件，后面跟的SHA256是哈希算法。输出的一长串十六进制值，就是安装包的校验码。发资源的人通常会在下载页给出官方 SHA256，比对一致再安装，能避免 50% 的“装完打不开”问题。如果你是从网盘之类的地方拿到资源，没有官方对照值，至少确认文件大小和资源描述一致，别拿到一个下载到一半的残包。

2.2 JDK版本绑定：AGP 4.2.2对JDK8和JDK11的兼容边界

Android Studio 4.2.2 自带了一个 JetBrains Runtime，理论上不配 JDK 也能启动 IDE。但 Gradle 构建进程用的是你系统里的 JDK，尤其老项目里compileOptions经常写着sourceCompatibility = 1.8，这时候 JDK 版本匹配就直接影响构建稳定性。我在 Windows 上维护老项目，统一装 JDK 8 的最后一个更新版本，也就是1.8.0_202之后的版本，如果项目有用到新版依赖要求 JDK 11，也不会冲突，因为 AGP 4.2.2 本身兼容 JDK 8 到 JDK 11。

先确认系统里当前用的是哪个 JDK：

# 查看当前 JAVA_HOME 和 java 版本 echo %JAVA_HOME% java -version

echo %JAVA_HOME%在 CMD 里打印当前 Java 主目录，java -version输出版本信息。如果%JAVA_HOME%是空的，或者版本和你预期不符，就用下面的命令重新指定：

# 设置 JAVA_HOME 指向 JDK8 安装目录，并追加到 PATH setx JAVA_HOME "D:\Java\jdk1.8.0_202" setx PATH "%JAVA_HOME%\bin;%PATH%"

setx是 Windows 的持久化环境变量命令，第一个命令把 JAVA_HOME 固定到D:\Java\jdk1.8.0_202，第二个命令把 JDK 的 bin 目录加到 PATH 最前面。执行完以后要重新打开终端才会生效。这里有个细节：PATH里的%JAVA_HOME%是在环境变量读取时才展开的，所以不会因为你后来改 JAVA_HOME 而失效。JDK 版本选错最典型的翻车现象是 Gradle 编译时报 “Unsupported class file major version”，看到这个就说明 JDK 太新，往回降一级就行。

2.3 首次启动：SDK目录、Build-Tools版本与命令行补装

第一次启动 AS 4.2.2，会弹“Import Settings”向导，这里我建议选“Do not import settings”，不要图省事去导入旧配置。旧配置里可能带着上一台机器或上一个版本的缓存路径、SDK 路径，一旦路径对不上，后面每一步都在排查遗忘的“历史遗留问题”。

接着是 SDK 组件选择，选 Custom 而不是 Standard，因为 Standard 会把 SDK 放到用户目录下，路径里有空格而且越来越臃肿。我会把 SDK 和 IDE 分开，SDK 单独放一个目录，比如D:\Android\Sdk，方便备份和清理。首次进入后，用 SDK Manager 勾选对应组件，重点不是把 API 全部装齐，而是按项目需要装：

• platforms;android-30：对应 Android 11 的 android.jar，4.2.2 默认编译目标。
• build-tools;30.0.3：AAPT2、dx/d8 等编译工具，缺了会在构建中段报错。
• platform-tools：adb、fastboot 这些和设备交互的命令行工具。

如果 SDK Manager 界面因为网络原因列不出列表，或者你更习惯命令行，可以直接用 sdkmanager 命令补装：

# sdkmanager 在 SDK 的 cmdline-tools\latest\bin 目录下 sdkmanager "platforms;android-30" "build-tools;30.0.3" "platform-tools"

platforms;android-30是 SDK 包内部的唯一标识，build-tools;30.0.3指定构建工具的具体版本，platform-tools是独立分发的 adb 工具集。用命令行装的优点是可以脚本化，重装系统之后一条命令把常用组件全部拉回来。首次启动还有一个容易被忽略的点：右下角会提示是否启用Android Studio 的统计分享，关不关随你，但如果你所在网络访问外网不稳定，关掉反而能减少一点启动时的网络请求。

装完以后建议重启一次 IDE，让它重新扫描 SDK、检测 HAXM 等模拟器依赖。这一步不是玄学，4.2.2 对“首次配置后不重启就直接建工程”的支持确实不好，经常出现 SDK 路径识别延迟，导致新工程创建失败。

3. 设置中文与提速：语言包、vmoptions和更新站点三个配置文件

3.1 中文化：插件市场安装还是离线zip

Android Studio 4.2.2 本身没有中文界面选项，这点和新版不一样。中文化唯一比较稳妥的途径是装 JetBrains 官方的“Chinese (Simplified) Language Pack”插件，它本质是个语言包插件，会替换 IDE 界面里的菜单文字。4.2.2 对应的 IDE 内核是 2021.1 这一代，所以语言包要选兼容这个内核的版本，装错版本会导致菜单文字乱码或界面显示异常。

在线安装的路径是File > Settings > Plugins > Marketplace，在搜索框输入 Chinese 或 中文语言包，找到“Chinese (Simplified) Language Pack”点 Install，装完按提示重启 IDE。如果你所在网络访问插件市场很慢，常见做法是先从插件仓库下载对应版本的 zip 包，然后在 Plugins 界面点齿轮图标，选Install Plugin from Disk，把 zip 路径指过去，重启后就会生效。这里要提醒一句：插件市场的版本号预览经常和 IDE build 号不一致，装完如果界面出现中英混杂，可以在已安装插件列表里 Disable 再重新下载，不要凑合用，后面找设置项会被界面文字坑到。

中文化本身不改任何编译行为，它只是换了菜单文案，所以老项目导进来之后编译结果不会有影响。真要说影响，反而是某些教程里的英文菜单名对不上，你需要在 Keymap 里自己搜功能名。这也是为什么我建议初学者先开中文化，遇到问题再切回英文对照搜索，两种界面语言各有各的方便。

3.2 修改 vmoptions：给IDE和Gradle留够堆内存

Windows 上 AS 4.2.2 跑老项目最常见的卡顿，不是 CPU 不行，而是默认堆内存给得太小。IDE 本身和 Gradle 构建进程是两套 JVM，IDE 的内存由安装目录下bin\studio64.exe.vmoptions控制，Gradle 的内存由gradle.properties里的org.gradle.jvmargs控制。我会先把 IDE 堆内存调大：

# 编辑安装目录下的 studio64.exe.vmoptions -Xms1024m -Xmx2048m -XX:ReservedCodeCacheSize=512m

-Xms1024m表示 JVM 启动时分配的初始堆内存是 1GB，-Xmx2048m表示最大堆内存 2GB，-XX:ReservedCodeCacheSize=512m是给 JIT 编译后的代码预留的缓存空间，太小会导致“代码缓存耗尽”的警告。如果你的电脑内存是 16GB 以上，-Xmx可以给到 4096m，但 8GB 内存的老电脑就别贪，2GB 比较稳，给多了反而频繁 GC。

与此同时，在项目根目录的gradle.properties里加上这一行：

org.gradle.jvmargs=-Xmx2048m -XX:MaxMetaspaceSize=512m

org.gradle.jvmargs是 Gradle 守护进程的 JVM 参数，-XX:MaxMetaspaceSize=512m限制了元空间上限，防止加载大量依赖时内存溢出。这里有个常见误区：有些人把-Xmx同时写进两个文件，结果 IDE 和 Gradle 各占一份内存，物理内存不够时两条进程互相挤兑。正确的做法是 IDE 内存管 IDE，Gradle 内存管 Gradle，不要靠一个文件通吃。

3.3 更新站点与镜像：SDK组件下载慢的确定性解法

SDK 组件默认从dl.google.com拉取，在部分网络环境下这个域名不稳定，所以 SDK Manager 经常卡在 “Fetching…” 或者进度条半天不动。4.2.2 支持自定义更新站点，说白了就是让 SDK Manager 从镜像仓库读取组件列表。常见做法是添加国内高校或云厂商的 Android SDK 镜像，比如腾讯云的 Android SDK 镜像，地址格式一般是https://mirrors.cloud.tencent.com/AndroidSDK/。在File > Settings > Appearance & Behavior > System Settings > Android SDK > SDK Update Sites里，把默认的https://dl.google.com/android/repository/repository2-1.xml替换成镜像地址。

替换后要重启 SDK Manager 让它重新拉取列表。这里有个坑：镜像站不一定同步全部组件，如果你装某个特定版本的 build-tools 一直报 “Package not found”，建议把默认站点改回来，单独下载那个组件，或者直接把资源包里的 SDK 目录离线导入。离线导入的方法是把整套 SDK 目录放到你想放的位置，然后在 SDK Manager 里把“Android SDK Location”指过去，点 Next 让它识别，不需要重新下载任何组件。这个方法依赖资源包里的 SDK 是完整解压过的，所以拿到资源后建议先看一眼目录结构，确认platforms、build-tools、platform-tools三个核心目录都在，再决定镜像还是纯离线。

4. 把老项目导进来：Gradle版本、镜像仓库与资源重复错误

4.1 迁移前的三处配置确认

把老项目从别的机器迁到 Windows 上的 AS 4.2.2，第一件事不是点 Open，而是先看三个文件。第一个是项目根目录的gradle\wrapper\gradle-wrapper.properties，它决定 Gradle 版本；第二个是build.gradle里的classpath 'com.android.tools.build:gradle:xxx'，它决定 AGP 版本；第三个是gradle.properties，它控制 AndroidX、构建内存等全局选项。很多人直接双击.gradle文件让 IDE 打开，结果 IDE 按自己的默认配置去解析，报一堆错，本质就是这三个文件没对齐。

AGP 4.2.2 要求 Gradle 最低 6.7.1。如果你拿到的项目distributionUrl指向的是 6.5 或更低，先手动改掉再同步：

distributionBase=GRADLE_USER_HOME distributionPath=wrapper/dists distributionUrl=https\://services.gradle.org/distributions/gradle-6.9-bin.zip zipStoreBase=GRADLE_USER_HOME zipStorePath=wrapper/dists

distributionUrl是 Gradle Wrapper 下载 Gradle 发行版的地址，gradle-6.9-bin.zip表示 6.9 版本的二进制发行版，不带-all是因为bin版体积小，能满足日常构建。https\://里那个反斜杠是 properties 文件对冒号的转义写法，不要删掉。6.9 和 AGP 4.2.2 的搭配我验证过多次，是老项目里比较顺手的组合；如果你非要往上顶，最高也建议控制在 7.0 以下，AGP 4.2.2 本身没有适配 Gradle 7 的完整测试。

4.2 依赖仓库从google()到镜像站的切换

补完 Gradle 版本，接下来是settings.gradle或项目顶层build.gradle里的仓库配置。老项目常见写法是：

allprojects { repositories { google() mavenCentral() jcenter() } }

这里google()是 Google 的 Maven 仓库，Android 官方依赖都在里面；mavenCentral()是 Sonatype 维护的中央仓库；jcenter()已经停止维护，新项目里可以直接删掉。如果在 Windows 上拉google()超时或反复失败，常见做法是往阿里云镜像仓库补一层：

allprojects { repositories { maven { url 'https://maven.aliyun.com/repository/google' } maven { url 'https://maven.aliyun.com/repository/gradle-plugin' } google() mavenCentral() } }

注意我把镜像仓库写在了google()前面，这样 Gradle 解析依赖时会优先去镜像找，找不到再回源站。这个顺序不是随便排的，因为 Gradle 是“先到先得”，如果让google()排第一，它一旦超时，整个同步过程要等很久才会轮到下一个仓库。镜像仓库偶尔会缺个别冷门库，所以保留google()作为兜底，两套并行最稳。

4.3 资源重复错误：不是玄学，是资源合并冲突

老项目导入 4.2.2 后高频报错之一，就是构建中段弹出一串 “Duplicate resources” 或 “Attribute xxx has already been defined”。这个错误的本质是 AAPT2 在合并资源时，发现同一个资源名出现在两个来源里，它不知道该用哪个。

我遇到最多的一种场景是：项目里多个 Module 的res/values下都有同名字符串，比如app_name，或者某个依赖库的aar里也定义了一个同名资源。另一种场景是之前构建失败后，build目录里残留了旧的merged_res，增量构建时新旧产物混在一起。

处理顺序我一般这样来:

# 先清掉构建缓存，排除残留产物干扰 gradlew.bat clean # 带堆栈信息重新构建，定位到具体资源名 gradlew.bat :app:assembleDebug --stacktrace

clean会删除所有模块的build目录，清掉合并资源的过程产物；:app:assembleDebug是指定要构建的模块和构建类型，--stacktrace让 Gradle 打印完整调用栈，这样错误日志里会直接暴露冲突的资源路径和来源文件。如果日志看不出来哪个库带的，可以单独跑一次资源合并任务：

gradlew.bat :app:mergeDebugResources --debug

--debug会把资源合并时的详细日志打出来，搜索overlap或duplicate关键字就能看到冲突双方的文件路径。真正解决时，优先改自己的资源文件名字，因为依赖库里的资源你不好动；如果冲突来源是META-INF之类的非资源文件，在build.gradle里排除即可：

android { packagingOptions { resources { excludes += ['META-INF/DEPENDENCIES', 'META-INF/LICENSE'] } } }

packagingOptions.resources.excludes是 AGP 4.2 引入的写法，老写法是packagingOptions.exclude，4.2.2 两种都支持，但推荐resources.excludes，因为新版构建工具已经废弃旧的顶层写法。这里排除的是打进 APK 的冗余文件，不影响资源合并冲突。如果排除了还报，就检查各 Module 的sourceSets，看是不是把同一份res目录同时挂到了两个变体上，那属于配置结构问题，删掉重复挂载的那一行就好。

5. 避坑：Windows上AS的五个高频翻车点与排查思路

5.1 现象：双击studio64.exe没反应

双击 IDE 图标后进程一闪而过，甚至没有任何界面弹出来，任务管理器里也找不到studio64.exe的踪迹。最常见原因是安装目录下jbr目录损坏或缺失，这个jbr是 AS 自带的 JetBrains Runtime，IDE 启动第一步就依赖它；其次是没有安装 VC++ 运行库，4.2.2 在 Windows 上依赖vcruntime140.dll这一系列底层库。

解决：先打开安装目录的bin文件夹，在地址栏输入 cmd 回车，执行studio64.exe，让错误信息直接打在终端里。如果提示缺 dll，去微软官网装 “Visual C++ 2015-2022 Redistributable x64”；如果是jbr报错，把另一台能跑的同版本机器上的jbr目录拷贝过来覆盖，或者重装资源包。我以前图省事用过 zip 绿色版，结果少了jbr子目录，折腾半小时才发现是解压工具漏了文件。

5.2 现象：SDK Manager卡在Fetching或列表空白

打开 SDK Manager，进度条一直转，组件列表刷不出来。这个一般不是网络完全不通，而是更新站点地址被改过，指向了一个连不上的地址，或者 DNS 解析 google 域名异常。SDK Manager 是阻塞式拉取的，请求不发完就不会显示列表，所以会一直卡着。

解决：手动打开C:\Windows\System32\drivers\etc\hosts检查有没有老的映射记录，有就先注释掉；然后回到 SDK Manager 的 “SDK Update Sites” 列表，把所有自定义站点恢复成默认的https://dl.google.com/android/repository/repository2-1.xml，或者直接切镜像站。改完以后关闭 SDK Manager 再重开，不用重启 IDE，重新拉一次列表。如果还是空白，去日志目录%USERPROFILE%\AppData\Local\Google\AndroidStudio4.2\log找 idea.log，里面会写明 SDK Manager 最终访问的 URL 和返回码，按返回码判断是被墙还是地址错误。

5.3 现象：Gradle构建报Could not resolve com.android.tools.build:gradle

同步或构建时报Could not resolve com.android.tools.build:gradle:4.2.2，大概率是依赖仓库没包含这个插件版本，或者本地 Gradle 缓存里的对应文件损坏。很多人以为是网络问题，反复重启，其实缓存损坏才是元凶。

解决：先检查项目顶层build.gradle的dependencies { classpath 'com.android.tools.build:gradle:4.2.2' }写没写对版本号，再确认仓库里有google()或镜像仓库。如果版本号没问题，直接删掉本地缓存里对应目录强制重启下载：

# 删除 gradle 插件缓存，Windows路径按实际用户名调整 rmdir /s /q "%USERPROFILE%\.gradle\caches\modules-2\files-2.1\com.android.tools.build\gradle"

/s /q是强制连带子目录静默删除。删除后重新 Sync，Gradle 会重新从仓库拉取并解压到缓存目录。如果删除后报同样的错误，再用镜像仓库替换google()，因为某些网络环境下直接访问 Google Maven 就是不通。这一步是我在 Windows 上处理老项目导入时最常用的“后悔药”，比卸载重装快得多。

5.4 现象：模拟器启动黑屏或adb连不上

AVD 启动后窗口是黑的，或者adb devices看不到模拟器。先排除虚拟化问题：AS 4.2.2 时代模拟器常用 Intel HAXM，它在 BIOS 里要求开启 VT-x，而且和 Windows 的 Hyper-V 冲突。另一个容易被忽略的是 adb 端口被占用，热词里经常提到的 5037 端口就是 adb 的服务端口，一旦被别的进程占住，所有设备都会消失。

解决：先看 adb 端口：

# 查看5037端口被哪个进程占用 netstat -ano | findstr :5037 # 确认进程后按PID结束，这一步等同于手动恢复adb服务 taskkill /PID 1234 /F

netstat -ano列出所有端口和对应 PID，findstr :5037过滤出 5037 端口的记录；taskkill /PID 1234 /F强制结束对应进程。如果是 VT-x 问题，去 BIOS 找 “Intel Virtualization Technology” 打开，然后在 Windows 功能里关闭 Hyper-V，装 HAXM。装完在 SDK Manager 的 SDK Tools 页勾选 “Intel x86 Emulator Accelerator (HAXM)” 安装。这块每次换电脑都要从头查一遍，我会把这两个检查项并排写在笔记里，排查顺序固定为“先端口、再虚拟化”。

5.5 现象：提示“此应用无法在你的电脑上运行”或“没有被指定在Windows上运行”

安装包或 exe 双击后弹这句，通常不是资源本身有问题，而是 Windows 的安全机制拦截了未签名的程序，或者下载的文件被标记为“来自其他计算机”。有时候下载工具会破坏 exe 的扩展属性，导致系统误判。

解决：右键安装包或studio64.exe，选择“属性”，在“常规”选项卡底部如果看到“解除锁定”，勾选后确定，然后再运行。如果是从 zip 解压出来的，确认解压工具没有跳过任何文件，完整解压后目录大小和资源描述一致。还有一种是 32 位系统跑 64 位安装包，AS 4.2.2 官方只发布了 64 位版，32 位 Windows 就别挣扎了，换机器或换旧版本。这个错误最坑的地方在于它不会告诉你缺哪个文件，我的习惯是先“解除锁定”，不行再校验哈希，最后才怀疑位宽问题，顺序反了浪费时间。

6. 进阶：用快捷键与Lint给老项目做一次清理

6.1 抽取方法与变量：把重构成本降到最低

Windows 上 AS 默认的抽取快捷键和 IDEA 一致，最高频的三个是：抽取方法Ctrl+Alt+M，抽取变量Ctrl+Alt+V，抽取字段Ctrl+Alt+F。我每次接老项目，第一轮代码梳理全靠这三个键，比手动复制粘贴安全得多。

// 重构前：一长串临时逻辑堆在 onCreate 里 String displayName = user.getName(); String city = user.getAddress().getCity(); Log.d("demo", displayName + " lives in " + city);

选中这段代码按Ctrl+Alt+M，AS 会弹窗问你要提取成什么方法名、访问修饰符、参数列表，确认后自动生成新方法并替换调用点。抽取变量则是给重复出现的表达式命名，比如user.getAddress()出现三次，选中表达式按Ctrl+Alt+V变成Address address = user.getAddress();。这套快捷键在 4.2.2 里是稳定可用的，而且支持多光标选择，特别适合处理历史代码里那些“复制三遍再加个前缀”的写法。如果你不习惯默认键位，可以在Settings > Keymap里搜 “Extract Method” 改成自己顺手的组合。

6.2 跑一遍Lint：把隐藏的无用资源找出来

老项目里最不缺的就是积攒多年的无用资源，drawable、layout、strings 一堆，没人敢删。AS 4.2.2 内置的 Lint 能给出资源引用分析，比人肉搜索可靠。命令行跑一次就能拿到报告：

gradlew.bat :app:lintDebug

lintDebug是 lint 任务加 Debug 变体后缀，跑完后报告生成在app\build\reports\lint-results-debug.html，用浏览器打开，按 “UnusedResources” 过滤，能看到每个无资源引用的具体位置和引用次数。这个报告只是参考，动态加载资源或反射调用可能被抓成“无引用”，删之前需要手动搜一遍代码里的字符串引用。如果项目确实有大量不再使用的资源，也可以在build.gradle里开启资源缩减：

android { buildTypes { release { minifyEnabled true shrinkResources true } } }

minifyEnabled true开启代码混淆和裁剪，shrinkResources true开启资源裁剪，两者必须同时开启，资源缩减才会生效。但注意开启后 Debug 包不受影响，只有打 Release 包时才会处理。我一般不会在生产老项目上直接开这个，而是先用 Lint 定位、再手动清理，这样每次改动都能独立验证构建。

6.3 用重复构建验证环境稳定

快捷键顺手了、资源也清了，最好再做一次重复构建验证环境本身是稳的。同一个项目，连续执行两次gradlew.bat clean build，第一次是冷启动，第二次会有缓存，两次都成功且构建时间波动不大，说明这台 Windows 机器上的 4.2.2 环境算是真正养好了。如果第二次反而报错，多半是缓存目录权限或杀毒软件扫掉了 Gradle 的临时文件，去%USERPROFILE%\.gradle\caches把对应目录加入杀毒白名单即可。

从那以后我每次接到老项目，都强制走一遍“先确认 JDK 和 Gradle 版本、再清一次缓存、最后跑 Lint”，这个顺序几乎把这几年在 Windows 上踩过的坑全部绕开了。希望帮到你。

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