上个月同事火急火燎找我说他那台笔记本的 C 盘只剩不到 3 个 G开机就飘红条连浏览器都开始报错。我让他打开资源管理器看了一眼AppData目录结果 IntelliJ IDEA 一个人就吃掉了 27 个 G。这个数字在装了 IDEA 的机器上真不算夸张——只要你本地跑过几个 Maven 项目、拉过几套 Gradle 依赖、再顺手装十来个插件AppData\Local\JetBrains和AppData\Roaming\JetBrains这两个文件夹就会在你毫无察觉的情况下慢慢长成整块 C 盘里最肥的目录之一。这篇东西就是想把这个过程掰开揉碎讲清楚IDEA 到底往 C 盘写了什么、哪些能搬、怎么搬、搬完出问题怎么办。不管你是刚装完 IDEA 社区版的新手还是本地躺着几十个工程的老手照着做一遍一般都能把 C 盘从红条危机里捞回来。1. 先把 IDEA 在 C 盘上留下的脚印找出来我见过太多人一遇到 C 盘满了第一反应是下载某个清理大师扫一遍删掉两个 G重启之后发现红条还在。原因很简单这类工具的扫描逻辑是按文件类型走的对AppData\Local\JetBrains里那些后缀为.dat、.st、.p的索引碎片根本不敢碰最后清出来的通常只是回收站加临时文件。所以正确的顺序永远是先定位、再动手。定位这件事一点不复杂核心就是记住 IDEA 在 Windows 上会把文件分成几摊来放每一摊的职责和命运都不一样搞清楚谁是谁后面的迁移才不会误伤。1.1 Windows 上 IDEA 的四个目录各自管什么JetBrains 系的 IDE 在 Windows 上默认使用下面这几处位置这是理解全部迁移方案的地基建议先背下来目录类型默认位置主要存放内容能不能搬安装目录C:\Program Files\JetBrains\IntelliJ IDEA 版本或 Toolbox 管理的用户目录程序本体、bin 下的启动配置、默认idea.properties可以但用 Toolbox 装的话不建议手搬配置目录%APPDATA%\JetBrains\IntelliJIdea版本设置项、快捷键、主题、代码模板、已安装插件、最近项目列表可以最值得搬系统目录%LOCALAPPDATA%\JetBrains\IntelliJIdea版本索引、缓存、编译服务、日志、本地 Tomcat 实例、临时文件可以占用最大优先搬插件目录默认在配置目录下的plugins第三方插件本体跟随配置目录走配置目录和系统目录是两块完全不同的东西很多人在这里会绕晕。简单说配置目录里装的是你的习惯系统目录里装的是IDEA 为了变快而攒下来的家当。前者值钱、体积小后者不值钱、体积巨大。把系统目录搬到其他盘几乎没有任何副作用代价只是迁移后的第一次启动要重新建索引会慢上几分钟之后体验完全一致。1.2 系统目录为什么能膨胀到几十个 G搞明白这个目录里到底装了什么你就不会再纠结删掉会不会把 IDE 弄坏这种问题。系统目录的主体是索引和缓存IDEA 为了让代码跳转、补全、重构这些操作做到秒级响应会把项目里所有符号解析出来构建一套持久化的索引结构再叠加虚拟文件系统缓存、拼写检查词典、PSI 树快照等一堆派生数据。项目越大、依赖的 JAR 越多这套东西就越大。一个中型的 Spring Boot 工程光索引就能做出几百兆你要是本地躺着二三十个工程加起来突破十个 G 是分分钟的事。真正让体积失控的是逐个项目累加加上旧版本残留。IDEA 在升级之后新的系统目录会另起一茬老版本目录原封不动留在原地你在不同大版本之间来回切这些目录就会一层层叠上去。我见过一台机器上并存着四个年份版本的IntelliJIdea文件夹加起来 40 多个 G而用户本人完全不知道。除此之外compile-server里堆着编译输出log目录里的日志从来不自动清本地 Tomcat 实例、JUnit 运行器的临时产物也都往这儿丢。这些东西有一个共同特点删了都能重建区别只是重建期间你会等一会儿。2. 三种迁移路线怎么选定位清楚之后方案其实就那么几条。我这些年反复试过的组合大体能归成三类改官方配置重定向、做目录联接、以及整体把 AppData 搬走。前两种是正经做法第三种属于看起来很爽出问题时很惨。先把路线选对比一上来敲命令重要得多因为选错了方式后面遇到 IDE 找不到配置、系统更新报错这类问题排查成本会高到让你想把机器重装。2.1 官方配置重定向、目录联接、整体搬家的取舍改配置是 JetBrains 官方明确支持的路径。IDE 启动时会读取一份idea.properties文件里面定义了配置目录、系统目录、插件目录、日志目录的落点你只要把这几个值指到 D 盘IDE 就会老老实实去新位置读写。这种做法最干净可维护性最好缺点是每个 IDE 大版本升级后需要检查一遍配置是否仍然生效。目录联接junction走的是另一条路不动任何配置在文件系统层面把一个指向 D 盘的假目录挂在 C 盘的原始路径上IDE 以为自己还在用老位置实际数据全在 D 盘。它的优势是对 IDE 完全透明缺点是这个链接一旦被某些清理工具或系统更新破坏你会遇到一些很奇怪的报错而且链接关系不在任何配置文件里体现换人接手时容易一脸懵。把整个AppData目录整体搬迁我不推荐。AppData下面挂着一大堆系统组件和第三方软件的运行数据用目录联接整体重定向之后Windows 更新、某些安装程序、还有一批对路径敏感的老软件都可能出问题。省那点空间不值得冒这个风险。2.2 关于各类清理工具和扩容工具的正确用法搜索c盘满了怎么清理能看到一堆清理软件说实话这类工具的良莠不齐程度超出你想象。有些免费的确实能用但安装过程中捆绑一堆推广还有的清理逻辑过于激进把开发环境的缓存目录当成垃圾直接端掉第二天你打开 IDEA 发现所有配置回到出厂状态。我的做法一直是清理这件事优先用系统自带能力设置 → 系统 → 存储里的存储感知、磁盘清理cleanmgr就够覆盖大部分场景开发相关的目录宁可自己写几条命令去统计体积也不要交给来路不明的软件去智能识别。至于 C 盘扩容这类操作属于有风险的系统级动作。分区调整过程中断电、异常中断都有可能导致分区表损坏数据丢失的代价远大于省下的那点空间。真要做先备份重要数据用口碑成熟的工具操作过程中接好电源不要动鼠标。我的观点很简单先把能搬的东西搬走、把能删的垃圾删掉如果还不够再考虑扩容这条路。3. 手把手把配置目录和系统目录迁到 D 盘前面说了半天思路接下来是真正能抄作业的部分。整套操作的核心就一份文本文件和几条复制命令但里面藏着几个格式坑第一次做的人有相当比例会栽在路径分隔符上。先把顺序理清楚规划目标目录 → 关闭 IDEA → 改配置 → 迁移数据 → 验证。3.1 迁移前的准备与目标目录规划先做一件容易被忽略的事确认 IDEA 完全退出。不是关掉窗口就完事而是要确保任务管理器里没有残留的idea64.exe和它拉起来的java.exe进程。索引文件在 IDE 运行期间是被独占打开的你一边运行一边复制轻则复制失败重则把索引文件写坏下次启动直接提示索引损坏要重建白白浪费时间。稳妥的做法是关掉 IDE 后在任务管理器里搜一遍jetbrains和java看到相关的就结束掉。然后是规划目录。我的习惯是在非系统盘建一个统一的开发数据根目录比如D:\DevData下面再按用途分D:\DevData\JetBrains\config、D:\DevData\JetBrains\system以后 Maven 仓库、Gradle 缓存也都往这下面放时间长了维护起来一目了然。目录路径里千万别带中文和空格IDEA 本身能处理但你的构建脚本、某些插件、还有一部分命令行工具未必能处理等到构建报莫名其妙的错再回头改路径成本就高了。另外提醒一句别把目标目录设在移动硬盘或者 U 盘上索引文件对随机读写非常敏感用外接盘会让 IDE 卡到没法用。3.2 改 idea.properties四个路径和两个格式坑真正的操作在idea.properties这个文件里。它在 IDE 安装目录的bin文件夹下用任意文本编辑器打开就能看到一堆以#开头的注释里面正好列着我们要改的那几项。把下面这几行前面的#去掉然后改成你自己的路径idea.config.pathD:/DevData/JetBrains/config idea.system.pathD:/DevData/JetBrains/system idea.plugins.path${idea.config.path}/plugins idea.log.path${idea.system.path}/log这里有三个必须知道的细节都是踩过坑才记住的。第一路径分隔符要用正斜杠/或者用双反斜杠\\绝对不能写成D:\DevData\JetBrains。因为 properties 文件的语法里反斜杠是转义字符\D、\J这种组合会被解析成别的东西结果就是路径莫名其妙变成错的IDE 启动后可能在 C 盘重新建了一套目录你会以为配置根本没生效。第二${idea.config.path}这种变量引用是支持的用它来定义插件和日志路径以后改主路径时不用一个个改能省不少事。第三如果你的 IDE 装在Program Files下编辑这个文件需要管理员权限最省事的办法是把文件复制到桌面改好再覆盖回去。如果安装目录不允许写入还有个替代方案新建一个自己的 properties 文件然后用系统环境变量IDEA_PROPERTIES指向它效果完全一样。JetBrains 官方帮助里对这个方式有说明适合那种完全没有管理员权限的办公机器。3.3 旧数据用 robocopy 搬还是让它重新建改完配置之后面临一个选择题旧的系统目录里那几十个 G 要不要一起搬过去。我的经验是分情况。配置目录一定要搬因为它装的是你的设置、快捷键、主题和插件清单不搬等于一切重来系统目录可以不搬让 IDEA 在新位置重新生成索引就行代价是第一次打开每个项目时会经历一轮索引构建CPU 跑满几分钟之后恢复正常。如果你确实想省掉重新索引的时间Windows 自带的robocopy是最稳的复制工具它对长路径、大文件、中断续传的处理都比资源管理器强得多robocopy C:\Users\你的用户名\AppData\Local\JetBrains\IntelliJIdea2023.3 D:\DevData\JetBrains\system /E /COPYALL /R:1 /W:1 /MT:16/E表示复制所有子目录包括空目录/COPYALL保留所有属性/R:1 /W:1表示失败只重试一次、每次等一秒默认是重试一百万次卡住了你都不知道/MT:16开多线程加速。复制完确认目标目录内容完整、大小对得上再回头删掉 C 盘上的旧目录。删之前建议先启动一次 IDEA 验证一切正常确认没问题再删这是给自己留退路。注意迁移系统目录后第一次启动会重建索引期间 IDE 可能卡顿甚至短暂无响应这是正常现象不要以为迁移失败就急着重装。3.4 不想改配置文件用目录联接junction如果你完全不想碰配置文件还有一条路在文件系统层面做重定向。先把 C 盘的原始目录整体复制到 D 盘删掉原目录然后管理员身份打开命令提示符执行mklink /J C:\Users\你的用户名\AppData\Local\JetBrains D:\DevData\JetBrains\Local/J创建的是目录联接对上层程序完全透明IDEA 访问老路径时会被系统自动导到 D 盘。这种方式的好处是不依赖任何配置IDE 升级版本、换新版本号都不影响代价是链接本身比较脆弱某些系统清理工具会把 junction 当成无效目录删掉删掉之后你原来的数据还在 D 盘但 IDE 会在 C 盘重建一个空目录配置丢失的错觉就是这么来的。所以用这种方式一定要记住自己做过这个链接别用激进的清理工具。4. 顺着往下挖Maven、Gradle、Tomcat 这些隐藏大户把 IDE 本体搬完之后C 盘通常能回收十个 G 以上但别急着收工。真正让开发机 C 盘反复变红的往往是 IDEA 下游的那几套东西。它们和 IDE 是合作关系但存储位置各自独立IDEA 搬走了不代表它们也跟着走这部分得单独处理。4.1 Maven 本地仓库改一行配置省下十个 G只要你用过 MavenC:\Users\你的用户名\.m2\repository这个目录就一定存在。它存的是所有下载过的依赖 JAR而且 Maven 的设计是所有项目共用一份本地仓库所以你用得越久这个目录越大。我见过最夸张的一台机器.m2目录 38 个 G里面躺着好几个版本的同一个包还有一堆下载中断留下的.lastUpdated文件。搬家只需要改settings.xml通常在C:\Users\你的用户名\.m2\settings.xml如果不存在就自己建一个settings xmlnshttp://maven.apache.org/SETTINGS/1.0.0 xmlns:xsihttp://www.w3.org/2001/XMLSchema-instance xsi:schemaLocationhttp://maven.apache.org/SETTINGS/1.0.0 https://maven.apache.org/xsd/settings-1.0.0.xsd localRepositoryD:/DevData/maven/repository/localRepository /settings改完之后记得在 IDEA 里确认一下Settings → Build, Execution, Deployment → Build Tools → MavenLocal repository那一栏应该自动变成你设置的新路径如果还显示老路径就手动覆盖一次。旧仓库目录可以直接删掉也可以先改名留着等确认新仓库能正常拉依赖、项目能正常构建之后再删。顺手还能做一件事清掉.lastUpdated文件这些是下载失败的残留标记留着会让 Maven 反复跳过下载命令是del /s /q %USERPROFILE%\.m2\repository\*.lastUpdated。4.2 Gradle 缓存与 GRADLE_USER_HOMEGradle 的缓存目录在C:\Users\你的用户名\.gradle它比 Maven 更奔放一些里面除了依赖缓存还有 wrapper 下载的各种 Gradle 发行版、构建缓存、守护进程日志。一个用 Gradle 跑了几年的人这个目录二十个 G 很正常其中wrapper\dists里躺着好几个版本的 Gradle 完整发行包每个都上百兆。迁移方式是设置环境变量GRADLE_USER_HOME指向D:\DevData\gradle。设置完重启 IDEA新下载的依赖和发行版就会往新位置走。除了环境变量也可以在 IDEA 的Settings → Build Tools → Gradle里指定Gradle user home两者选一个即可我一般用环境变量因为它对命令行构建同样生效。搬完之后老目录里那些历史版本可以清理掉但注意保留你项目 wrapper 里指定的那个版本否则下次构建又要重新下载。4.3 Tomcat 实例、构建产物与项目日志本地调试用的 Tomcat 也值得说一句。当你在 IDEA 里配置本地 Tomcat 服务器时IDE 会在系统目录下为每个配置建一份独立的实例目录包含conf、logs、work、temp这个实例目录的日志会在你反复调试的过程中不断累积。好消息是它跟着系统目录走前面的迁移已经一并处理了需要额外留意的是如果你在配置里手写了CATALINA_BASE指向别的路径那部分得单独检查。项目自身的构建产物同样是空间黑洞target、build、out、node_modules这些目录分散在你各个工程目录里单个不大几十个项目加起来就很可观。写个脚本定期扫一遍比手工翻要靠谱但这类批量删除命令一定要慎用先把命令改成只打印不删除跑一遍看看清单Get-ChildItem -Path D:\workspace -Directory -Recurse -Force -ErrorAction SilentlyContinue | Where-Object { $_.Name -in (target,build,out) } | Select-Object -ExpandProperty FullName确认打印出来的都是可以安全重建的构建目录再把管道换成Remove-Item -Recurse -Force真正执行。注意node_modules和前端的构建缓存不在这个清单里删之前确认项目能重新装依赖否则一删就是几十分钟等待。5. 长期维护怎么让 C 盘不再变红迁移是一次性动作维护是长期的事。我自己的机器上有一套固定的小流程每个月花五分钟跑一遍基本不会出现 C 盘告急的情况。这套流程的核心思路是先量化、再决策不要凭感觉删东西。5.1 几条命令看清空间去向Windows 自带的能力其实够用我常用的组合是资源管理器的文件夹大小排序右键属性太慢用WinDirStat之类的可视化工具更直观加上一段 PowerShell 快速统计 JetBrains 相关目录的体积$base $env:LOCALAPPDATA\JetBrains Get-ChildItem $base -Directory | ForEach-Object { $size (Get-ChildItem $_.FullName -Recurse -Force -ErrorAction SilentlyContinue | Measure-Object -Property Length -Sum).Sum {0,-35} {1,10:N0} MB -f $_.Name, ($size / 1MB) }把$base换成$env:APPDATA\JetBrains就能看配置目录换成$env:USERPROFILE再配合过滤就能看.m2、.gradle这些。跑出来的结果一眼就能看出是哪个版本、哪个目录在膨胀。如果发现同一个 IDE 有多个版本号的目录说明你升级过多次老版本的目录可以放心删掉前提是你已经不再使用那个版本。系统层面也顺手看一眼C:\Windows\SoftwareDistribution\Download是 Windows 更新的下载缓存几百兆到几个 G 不等hiberfil.sys是休眠文件笔记本上通常和内存一样大甚至更大如果平时不用休眠功能可以用powercfg /h off关掉回收这块空间不过要注意关掉之后快速启动也会一起失效。系统还原点占用的空间在系统属性 → 系统保护里可以调整上限我一般给它留 5% 左右够用又不至于吃掉太多。5.2 常见问题速查表迁移过程中能遇到的问题大体就那么几个我把这些年遇到的整理了一下现象大概率原因处理方式迁移后 IDEA 提示找不到配置、主题变回默认配置目录路径写错或旧数据没复制过去检查idea.config.path拼写把旧配置目录内容补复制到新位置配置改了但 C 盘还是重新生成了目录properties 文件路径写法有误用了单反斜杠或文件根本未被读取用正斜杠重写路径确认文件在bin目录下且有读权限迁移后启动极慢、CPU 持续跑满正常现象正在重建索引等它跑完期间不要反复重启 IDE项目依赖全部标红、找不到符号Maven/Gradle 仓库路径变更后未重新导入重新导入项目必要时删除工程下的.idea和*.iml让它重新生成清理工具跑完后 IDE 配置全丢工具误删了配置目录或 junction 链接从备份恢复禁用该工具的深度清理明明删了文件C 盘空间没变文件被进程占用或进了回收站结束残留的java.exe进程清空回收站索引目录反复增长本地工程数量多或磁盘被反复重新挂载触发重建减少同时打开的项目数量把索引盘固定下来别用外接存储5.3 踩过的坑与几条个人经验最后说几个文档里不会写、但实际很要命的点。第一迁移之前一定先备份配置目录整个复制一份到别处放着几十兆的东西出问题时能救你半小时的重新配置。第二如果你的机器在域环境里AppData\Roaming会被同步到服务器把配置目录留在那里会导致登录变慢迁到本地固定盘反而更稳定。第三把项目目录和索引盘都加进 Windows Defender 的排除列表能明显降低索引和编译时的 CPU 占用路径在病毒和威胁防护 → 排除项里这个设置对构建速度的影响比换硬件还直观。第四也是我最想强调的一点不要迷信一键搬家。开发环境里的路径引用是多层的IDE 有 IDE 的配置构建工具有构建工具的配置还有一部分写死在项目里的脚本。任何号称一键搞定的工具本质上都是帮你执行前面这些步骤只是把细节藏起来了一旦某一步出问题你连从哪查起都不知道。自己动手走一遍你对这套环境的理解会完全不一样以后换机器、重装系统半小时就能搭出同样的结构。至于索引盘选哪个如果机器上有 SSD 就用 SSD没有的话把索引放在和项目同一个物理盘上能减少大量随机寻道。我自己的习惯是把工程、索引、依赖仓库统一放在同一块数据盘上C 盘只留系统和软件本体两年下来再没遇到过 C 盘飘红的情况。