1. 离线模式并不是“断开网络”，而是把这三层全部按住
很多人在配置 IDEA 离线工作模式时都会踩同一个坑：把系统网络断开，或者把 WiFi 关了，然后打开 IDEA 继续干活，结果发现项目要么起不来，要么明明本地有依赖却还在报错。问题出在哪？因为 IDEA 的“联网行为”从来不是单一的开关，而是分散在三层里的。
- 第一层是构建工具层，也就是 Maven、Gradle 这类依赖管理工具。它们会默认去远程仓库拉包、检查快照版本。
- 第二层是 IDE 本身，IDEA 会定期检查更新、同步插件、上传使用统计信息。
- 第三层是项目运行环境层，比如数据库连接、Redis、Nacos 注册中心、容器远程调试等，这些其实都需要网络。
所以，“设置离线工作模式”的正确理解，是分别把这三层里能关的联网行为都关掉，同时让本地可有可无的东西都变成真正从本地读取。这样哪怕彻底断网，你也能保持一个稳定可用的开发状态。
这篇文章不会讲那些和离线无关的花活。我就只拆这一个问题：怎么让 IDEA 在完全没网的情况下依然能顺畅开发。我会按构建工具、IDE 自身、项目运行环境三个方向，把操作步骤、原理和坑全部说完，适合那些经常出差、在高铁上写代码、或者公司内网和外网隔离的开发者参考。
2. Maven 离线：先让依赖仓库能自给自足
2.1 界面上的 Maven 离线开关，只是一个“启动信号”
IDEA 里最容易被找到的离线设置，是 Maven 面板上的 Work offline 选项。
打开路径：Settings -> Build, Execution, Deployment -> Build Tools -> Maven，右侧有一个Work offline复选框，勾上就是离线模式。Gradle 也类似，在Build Tools -> Gradle里有Offline work。
但这里我必须说清楚：这个开关的作用，只是告诉 IDEA，在解析项目依赖时不要发起远程网络请求。它不会自动把本地需要的依赖打包好，也不会帮你准备一个完整的依赖目录。如果你本地的~/.m2/repository目录里本来就没有某个依赖，那勾了 Work offline 之后，IDEA 会快速报错，提示缺少某个 artifact，而不是等网络超时后再报。
换句话说，Work offline 更像是一个“只读本地仓库”的启动信号，它不会帮你造出本地仓库来。
2.2 settings.xml 才是决定本地仓库位置的“总地图”
Maven 的本地仓库默认在用户主目录下的.m2/repository目录。如果你换过 Maven 的 settings.xml，或者公司内网用的是统一管理的 maven 配置，那本地仓库的实际位置可能完全不一样。
离线模式下，这个位置必须稳定，而且要确保项目用到的所有依赖都已经在里面。我见过很多人在公司电脑上一切正常，结果到了没网的环境打开 IDEA，项目直接挂掉，最后发现是 settings.xml 里配置了一个公司内网仓库地址，IDEA 尝试连内网仓库连接不上，导致整个依赖解析直接卡死。
所以，离线之前你先做两件事：
- 打开 settings.xml，找到
<localRepository>标签，确认它指向的是一个你机器上确实存在的目录。 - 检查
<mirrors>标签。如果镜像地址写的是局域网 IP，断网后这些镜像全部无效。最好准备一份“离线专用”的 settings.xml，把镜像去掉，并且把<offline>true</offline>写进去。
<settings xmlns="http://maven.apache.org/SETTINGS/1.0.0"> <localRepository>D:/maven_repo</localRepository> <offline>true</offline> </settings>这样配置之后，Maven 不会再尝试访问远程仓库，题目上标注的“离线”才真正在命令行层面生效。IDEA 里的 Work offline 是配套的，你最好两边同时开，而不是只依赖界面上的那个复选框。
2.3 离线之前先把依赖“喂饱”
如果你现在就准备去没网的环境，最合理的操作是在有网的时候先做一次依赖预拉取。
Maven 提供了专门的目标命令：
mvn dependency:go-offline -Dmaven.repo.local=D:/maven_repo这条命令会把你当前项目 pom.xml 中声明的所有依赖、插件全部下载到本地仓库。但要注意，go-offline并不绝对完整，它有可能漏掉一些在特定 profile、特定执行阶段才会用到的插件。更保守的做法，是直接跑一次完整的项目构建：
mvn clean verify -Dmaven.repo.local=D:/maven_repo只要构建能成功，说明这个项目当前需要的依赖基本都齐了。然后将D:/maven_repo目录一起带走，到没网的环境里配置好 localRepository，才是真正的万无一失。
如果你用的是 IDEA 自带的 Bundled Maven，那它默认读取的也是~/.m2/settings.xml。如果你用的是自己下载的 Maven，记得在 IDEA 的 Maven Settings 里把 User settings file 指向你的离线 settings.xml。
2.4 Maven 离线最容易踩的坑
离线模式下，光是 Maven 这一层就有几个非常典型的问题。
快照版本依赖。如果你的项目依赖了某个子模块的 SNAPSHOT 版本，即使本地仓库有缓存，Maven 有时也会在联网状态下主动去远程仓库检查快照是否更新。断网后这个问题没那么严重，但如果你切换回在线模式，会发现 IDEA 经常卡在“Resolving Maven dependencies”，原因就是它在反复检查快照。解决办法是在 settings.xml 里配置快照策略，让所有快照只从本地获取：
<repositories> <repository> <id>central</id> <url>https://repo.maven.apache.org/maven2</url> <snapshots> <enabled>false</enabled> </snapshots> </repository> </repositories>另一个是缺包时提示不友好。离线模式下如果你少了某个依赖，Maven 不会告诉你“这个包在远程可以下载”，它只会直接报Cannot access central或者missed artifact。很多人看到报错还以为是网络问题，其实本质是本地仓库缺包。这时候不用慌，记住一个判断标准：报错信息里如果带着local repository，那大概率就是本地没这个包；如果带着Could not resolve dependencies，也可能是本地仓库里对应的_remote.repositories文件记录出了问题。
第三个是.lastUpdated文件残留。在线模式下，Maven 下载失败会生成.lastUpdated后缀的文件，下次构建会被标记为“刚刚失败过”，离线模式读到这些文件也可能直接拒绝重试。清理方式很简单，把仓库里的这些文件删掉：
find ~/.m2/repository -name "*.lastUpdated" -delete做完这一步，很多“离线模式打不开项目”的诡异问题就消失了。
3. Gradle 离线：缓存预热和动态版本锁定
3.1 IDEA 里的 Gradle 离线开关，和 Maven 不是一回事
Gradle 的离线开关在Settings -> Build, Execution, Deployment -> Build Tools -> Gradle里，勾选Offline work。
但 Gradle 和 Maven 的区别在于：Gradle 的依赖缓存不是简单放在~/.gradle/caches/modules-2里，它还有一层自己的元数据索引。所以你光勾选 Offline work，如果 Gradle 缓存不完整，依然会报Could not resolve all dependencies。
另外，IDEA 的 Gradle 离线开关只对 IDEA 自身的 Gradle 调用生效。如果你在终端里执行gradle build，那这个开关完全不起作用。终端里的离线方式是加参数：
gradle build --offline3.2 构建一次，把 Gradle 缓存预热到位
Gradle 的依赖下载比 Maven 更隐蔽，因为它不仅下载 jar 包，还会下载对应的 POM、模块元数据、校验和文件。单纯依赖 IDEA 解析一次，并不能保证所有任务执行阶段需要的依赖都缓存的完整。
我习惯的做法是，在有网环境下直接执行：
gradle clean build --stacktrace这样会把项目的依赖和插件完整下载到~/.gradle/caches。如果项目里有单元测试或者 lint 任务，建议也一并执行一遍，因为这些任务也可能拉取额外的测试库。
3.3 动态版本和依赖锁定的问题
Gradle 支持类似1.0.+的动态版本，也支持latest.release这样的动态声明。在线模式下，Gradle 会定期检查这些动态版本是否有更新；离线模式下，它只能使用本地缓存里已有的版本。
所以，如果你想离线工作更稳定，最好在项目里启用依赖锁定。Gradle 的依赖锁定机制会把所有依赖的精确版本写入一个.lockfile文件，构建的时候直接按锁定文件解析。启用方式：
dependencyLocking { lockAllConfigurations() }加在build.gradle里，然后执行一次gradle dependencies --write-locks，生成锁文件。之后离线环境构建时，Gradle 不再需要去查最新版本，直接用锁定的版本，自然也就不会因为动态版本问题报错了。
3.4 Gradle 离线下常见的缓存目录误区
~/.gradle目录里除了caches，还有wrapper目录。IDEA 按 Gradle 项目时会自动下载对应版本的 Gradle Wrapper 分发包，这个分发包同样需要网络。如果你到了没网的环境才第一次打开这个项目，即使依赖缓存是全的，Gradle Wrapper 本身没下载过，照样启动失败。
所以在离线之前，务必在有网环境下构建过一次，并确认~/.gradle/wrapper/dists目录里有对应版本的 Gradle 发行包。检查方法：冷启动一次 IDEA 或者打开终端执行./gradlew --version，能正常运行说明 Wrapper 已经准备好。
4. IDEA 自身：更新、插件、统计信息一个都别让它乱跑
4.1 关掉 IDEA 的自动更新和插件检查
构建工具层面的离线只是第一关，IDEA 自己还有不少联网行为。最惹人烦的就是自动更新检查。
在较新的 IDEA 版本里，路径是Settings -> Appearance & Behavior -> System Settings -> Updates，把Automatically check updates取消勾选。版本不同，菜单路径会有细微差别，有的在Settings -> Appearance & Behavior -> System Settings -> Automatic Updates，有的在Settings -> Appearance & Behavior -> System Settings -> Updates。
如果你用的是公司统一管理的 IDE 套件，还可能有一个JetBrains Runtime更新选项，同样取消勾选。这里要提醒一句：有些插件自己也有更新检查，比如某些主题插件、框架插件，它们不走 IDEA 的更新设置，需要到Settings -> Plugins里把自动更新关闭。虽然在完全断网的情况下它们不会真的连网，但在弱网环境下，这些插件会反复尝试连接服务器，导致 IDE 卡顿。
4.2 数据共享和统计信息上传的关闭方式
IDEA 默认会收集一些使用数据，虽然不一定影响开发，但离线场景下，这种后台请求会占用本来就紧张的带宽，甚至会触发电脑防火墙的安全提示。
处理路径：Settings -> Appearance & Behavior -> System Settings -> Data Sharing，把Send usage statistics这类选项取消勾选。如果你的 IDEA 版本没有这个入口，也可以在欢迎页面的Configure -> Settings里改，或者直接修改idea.properties。
4.3 离线环境装插件：不要用插件市场的上传数据
离线环境里装插件是一个大家都会遇到的需求。如果你在没网之前已经在有网环境下载了插件安装包，那安装很简单。
IDEA 的路径是Settings -> Plugins -> 右上角齿轮图标 -> Install Plugin from Disk...，选择本地.zip文件即可。注意，插件安装包不要解压，直接选 zip 文件，IDEA 会自动处理。
但这里有个坑：很多插件的 zip 下载下来之后，只包含当前版本代码，并不包含它的依赖插件。比如你下载了一个依赖其他基础插件的工具插件，离线安装时 IDEA 会提示“插件依赖缺失”，这时你就得把那几个基础插件一起打包下载，再逐个从磁盘安装。
另一个细节是，有些插件的打包格式是.jar，在旧版 IDEA 里可以直接放到plugins目录。安装位置一般在 IDEA 安装目录的plugins文件夹下，或者是用户目录的%APPDATA%\JetBrains\<版本号>\plugins目录。放进去之后重启 IDE，插件就能识别。
4.4 远程开发、共享编程这类功能尽量别在离线模式开会
新版 IDEA 推出了远程开发、代码共享等功能，这些功能本质上是基于网络连接的。在离线环境下，它们虽然不会主动破坏什么，但会在右下角一直转圈，消耗 CPU。
如果你在完全没有网络的高铁上，最好把这类功能入口关掉，尤其是Remote Development的服务器列表，避免 IDEA 一直尝试连接历史记录里的远程主机。这个操作没有全局开关，只能把已知的远程服务器从列表里删掉。
5. 项目本身也要“离线”：本地调试环境怎么自理
5.1 把依赖的中间件全部本地化
构建工具和 IDE 都处理好之后，真正的开发场景还得打通一层：项目运行时依赖的数据库、缓存、注册中心。
有些项目在 IDEA 里直接启动，默认连接的是远程开发环境的数据库和 Redis。到了离线环境，连接超时，项目启动直接失败。这时候有人会误以为是 IDEA 离线模式没设好，其实这是项目配置层面的问题。
一个比较实用的做法是，为本地开发准备一套application-local.yml，把数据源、Redis、MQ 全部指向localhost，并且用本地安装的 MySQL、Redis 去跑。离线之前，把这些中间件启停一遍，确认能用。
5.2 端口占用和本地服务的管理
在离线环境里，你还可能会遇到 DNS 解析延迟的问题。很多项目的配置里会写一个内网域名，比如mongo.internal，在线时可以解析到公司服务器，离线时解析失败，项目启动报 UnknownHostException。这种情况不是 IDEA 的锅，但要解决，只能在本地 hosts 文件里把域名指向127.0.0.1，或者直接改配置文件。
5.3 Docker 镜像离线怎么准备
不少人喜欢用 Docker 跑中间件，这本身没问题。但离线之前必须把镜像准备好，不然到了没网络的地方docker pull直接失败。
我常用的方式是先在网络上执行：
docker pull mysql:8.0 docker pull redis:7.0 docker save mysql:8.0 -o mysql-8.0.tar把打包出来的 tar 文件带走，离线环境中执行docker load -i mysql-8.0.tar。这样本地的运行环境就能完全自理。
6. 离线开着 IDEA，这几个隐藏问题最容易反复出现
6.1 依赖解析“假离线”的问题
有些项目看似离线了，但 IDEA 依然会偷偷连接某个远程仓库。原因通常是项目的pom.xml里直接声明了自定义的<repository>，这个仓库地址不在 settings.xml 的 mirror 匹配条件内。IDEA 会把它判定为“需要连接”，从而卡在网络阶段。
判断方法：离线模式下启动项目，点击事件日志，如果看到类似Unable to resolve repository ...的警告，说明项目里还有远程仓库声明。解决方式就是把确认不需要的 repository 配置从 pom.xml 里删掉，或者加入 settings.xml 的 mirror 白名单，让所有远程请求都指向本地。
6.2 证书和 SSL 握手问题
离线环境里经常出现PKIX path building failed或者SSLHandshakeException。这不是因为你没有证书，而是因为项目配置的远程仓库使用了 HTTPS，IDEA 在尝试握手时失败了。
如果你确定不需要访问远程仓库，最好直接采用离线模式，这样不会触发握手。但如果你只是弱网环境，还需要使用远程仓库，那就需要把仓库的证书导入到本地 JDK 的cacerts里。离线场景下这个问题的根源往往是之前的网络劫持或者代理缓存残留，直接删掉本地仓库里的.lastUpdated文件再试一次。
6.3 内存和缓存膨胀
IDEA 在离线模式下，某些后台任务会不断重试连接，导致 CPU 占用飙升。一种典型表现是，打开项目之后风扇狂转，右下角显示正在Indexing，但要很长时间。
遇到这种情况，可以先进入File -> Invalidate Caches...，勾选Clear file system cache and Local History，然后重启 IDEA。这样会把之前在线状态下残留的索引破坏掉，让它重新基于本地依赖构建索引，往往会快很多。
6.4 常见问题速查表
为了让你不踩那么多坑，我把离线开发中最常见的情况整理成了一个表格，方便对照：
| 现象 | 可能原因 | 优先操作 |
|---|---|---|
| 项目启动卡在 Maven 导入 | Work offline 没勾选，或 settings.xml 里的 offline 没开启 | 同时开启 IDE 开关和 settings.xml 的 offline |
| 编译报错找不到依赖 | 本地仓库没有对应 jar | 离线前执行一次mvn clean verify或者go-offline |
| Gradle 项目提示无法解析插件 | Gradle Wrapper 发行包没下载过 | 在离线前执行至少一次./gradlew --version |
| IDEA 插件安装后无法生效 | 插件的依赖插件缺失 | 把依赖插件一并下载，从磁盘安装 |
| 启动时显示远程连接超时 | 项目配置连接远程中间件 | 改用本地 localhost 配置和本地服务 |
| Https 证书握手异常 | 远程仓库 SSL 证书问题 | 离线状态下直接跳过远程仓库访问 |
7. 我在实际使用中的做法：三种离线场景区别对待
讲完所有配置之后，我必须实话实说：离线工作模式本身不复杂，真正难的是判断什么时候开离线、什么时候不彻底离线。
我现在的做法是把日常场景分成三种。
第一种是“完全断网”场景。比如坐飞机、出差到没有外网的园区。这个时候我会把 IDEA 的 Maven/Gradle 离线开关全部打开，把 settings.xml 里的<offline>设为 true，同时把项目的远程配置全部切成 localhost。这种场景下，依赖解析速度是最快的，因为完全没有网络超时的等待窗口。
第二种是“弱网”场景。比如连着的 WiFi 信号很差，或者公司网络对部分域名限速。这种情况下，我一般不会把 IDEA 的 Maven 离线开关打开，因为有时候还需要下载一个临时缺失的包。但我一定会调整 IDEA 的网络连接超时时间，并把更新检查、数据共享全部关掉，减少后台请求抢带宽。
第三种是“内网有镜像”的场景。很多公司内网有私服，虽然不是外网，但依赖可以从私服拉。这种情况我不建议开启真正的离线模式，而应该调整 Maven 镜像地址，把远程仓库指向内网私服。这样既不会断库，又能保证构建速度。
这三个场景的做法差异很大，如果你不管三七二十一直接勾选离线模式，有时候反而会把自己坑了——比如刚想下载一个新插件，才发现忘了关闭离线选项。
最后分享一个我踩过很多次坑之后总结的习惯：每次要出差之前，我会在项目目录里执行一次mvn clean verify和gradle clean build，确认本地依赖完整，并且跑通一次本地中间件启动流程。这个过程大概多花五分钟，但能保证我在任何完全没网的环境里，依然可以打开 IDEA 立刻进入开发状态。这个习惯帮我省了很多次在高铁上对着 IDEA 转圈发呆的时间。
