1. 先用十分钟搞清楚IDEA 到底把什么东西写进了 C 盘1.1 一次真实的翻车现场去年我给一台开发笔记本做体检C 盘是 512G 的固态可用空间只剩 3.2G系统天天弹磁盘空间不足。机主第一反应是肯定是我下的电影太多了结果我用 WizTree 扫了一遍视频文件夹加起来不到 20G真正的大头在C:\Users\用户名\AppData底下Local\JetBrains占了 38GRoaming\JetBrains占 9G再往下C:\Users\用户名\.m2\repository12G、.gradle8G、AppData\Roaming\npm-cache3.5G。也就是说光这一套开发环境就吃掉了一百来 G 的 C 盘空间。这件事的典型之处在于大部分人查 C 盘只盯着下载文档桌面很少有人会去AppData这个隐藏目录里翻。而 IntelliJ IDEA 恰恰是个重资产 IDE——它不只是一个编辑器它同时是索引引擎、版本历史仓库、插件宿主、构建工具调度器每一个身份都会在系统盘上留下自己的文件夹。更麻烦的是这些目录默认全部落在 C 盘的用户目录下装得越久、项目越多、升级次数越多体积就越夸张。这篇内容要解决的就是这件事把 IDEA 相关的磁盘占用从神秘增长变成可查、可控、可迁移。不管你是刚装 IDEA 的新手还是已经用了五六年、C 盘红了好久的老用户下面的排查思路和迁移步骤都能直接照着做。我会先讲清楚每个目录是干什么的、为什么值得搬、哪些绝对不能乱动再给出一套完整的搬家方案和长期维护清单。1.2 三个默认落盘位置安装目录、config、systemIntelliJ IDEA 在 Windows 上的文件分布可以粗暴地理解成三块地。第一块是安装目录默认在C:\Program Files\JetBrains\IntelliJ IDEA 20xx.x大小通常在 2G 到 4G 之间里面是 IDE 本体、自带的 JBRJetBrains Runtime也就是它自己打包的 JDK、预置插件。第二块是配置目录config位置在%APPDATA%\JetBrains\IntelliJIdea20xx.x也就是C:\Users\用户名\AppData\Roaming\JetBrains\IntelliJIdea20xx.x保存的是你的设置、快捷键、代码模板、已安装插件、许可证信息。第三块是系统目录system位置在%LOCALAPPDATA%\JetBrains\IntelliJIdea20xx.x也就是C:\Users\用户名\AppData\Local\JetBrains\IntelliJIdea20xx.x保存缓存、索引、日志、本地历史、临时文件。这三块地里真正会失控的是第三块。配置目录一般也就几百 M 到 2G其中插件占大头而系统目录随着项目数量增长很容易冲到 20G 以上我见过最夸张的一台机器system\caches单项就有 17G。原因是 IDEA 为了保证代码补全、跳转、全局搜索的响应速度会把整个项目解析成索引坐在磁盘上而且这个索引是按项目缓存的你打开过多少个项目就沉淀多少份数据。做过多个大项目的人这里动辄就是十几 G。提示AppData是隐藏目录在资源管理器地址栏直接粘贴%LOCALAPPDATA%\JetBrains回车比一层层点进去快得多。同理%APPDATA%\JetBrains。还有一个容易被忽略的点IDEA 每升级一个版本就会新建一个带版本号的目录旧版本的目录不会自动删。所以你可能会看到IntelliJIdea2022.3、IntelliJIdea2023.1、IntelliJIdea2024.1三四个文件夹并排躺着每一个都是好几 G。它们本身不会拖慢新版 IDE但会实实在在地占着 C 盘属于典型的看着心疼、删了也不影响的东西。1.3 除了 IDE 本体这四类连带产物更值得先动手只想搬 IDEA 自己的目录往往效果有限因为真正吃掉 C 盘的常常是它调用的周边工具链。按我处理过的机器统计下面四类东西的体积排序通常是这样的类型典型路径常见体积迁移难度Maven 本地仓库C:\Users\用户名\.m2\repository3G - 30G低改一行配置Gradle 缓存C:\Users\用户名\.gradle2G - 15G低设环境变量IDEA system 目录%LOCALAPPDATA%\JetBrains\IntelliJIdea*5G - 30G中需改 properties前端包缓存AppData\Roaming\npm-cache、pnpm store1G - 10G低一条命令Maven 那个.m2\repository是最典型的闷声发大财。你每在pom.xml里加一个依赖它就把 jar 包下一次、存一份而且不同版本各存各的同一个库的2.3.1、2.3.2、2.4.0会并存。做过两三个 Spring Cloud 项目的人这个目录很容易突破 20G。Gradle 同理.gradle\caches里存的是插件、依赖和构建缓存.gradle\wrapper\dists里存的是各个版本的 Gradle 发行包——每个发行包解压后就是 100M 到 200M攒十个版本就上 G 了。前端这边npm-cache是npm的下载缓存pnpm 的 store 更是默认就把所有包的内容集中存在 C 盘用户目录下。IDEA 里跑一个前端项目npm install一执行这些目录就悄悄胖一圈。搞清楚这些你才知道该先搬谁。我的建议是先处理 Maven 和 Gradle改动小、收益大、风险低再处理 IDEA 的 system 目录收益最大但要按流程来。1.4 两条命令定位真正的元凶动手之前别凭感觉先量化。图形化工具推荐 WizTree 或 TreeSize Free前者读取 NTFS 的 MFT 表扫全盘几秒钟缺点是必须用管理员权限运行后者免费版够用界面更直观点。打开后直接看C:\Users\你的用户名下面的目录树按大小排序一眼就能看出谁是大头。如果你不想装额外软件用 PowerShell 也能算下面这段是我常用的脚本把要检查的根目录换成你自己的路径即可# 统计指定目录下每个一级子目录的体积按大小倒序输出 $root $env:LOCALAPPDATA\JetBrains Get-ChildItem $root -Directory -ErrorAction SilentlyContinue | ForEach-Object { $sum (Get-ChildItem $_.FullName -Recurse -File -ErrorAction SilentlyContinue | Measure-Object -Property Length -Sum).Sum [PSCustomObject]{ Directory $_.Name SizeGB [math]::Round($sum / 1GB, 2) } } | Sort-Object SizeGB -Descending把$root依次换成$env:APPDATA\JetBrains、$env:USERPROFILE\.m2、$env:USERPROFILE\.gradle跑四遍一份完整的占用清单就出来了总共不到两分钟。有了这份清单你才知道搬完之后能省下多少——我一般会把这个数字截图存下来作为验证效果的依据。注意统计大目录时如果报拒绝访问是因为个别子目录权限受限脚本里的-ErrorAction SilentlyContinue会跳过它们结果依然有参考价值不用纠结。2. 动手之前三个必须先做的前置动作2.1 彻底退出 IDEA托盘和后台进程都别放过所有迁移类操作的第一步永远是确认目标程序没在运行这句话听起来像废话但它是翻车率最高的一步。IDEA 在 Windows 上通常不止一个进程主进程idea64.exe之外还有文件系统监听器fsnotifier64.exe如果你装了 WSL 或者终端相关插件还可能挂着wsl.exe、conhost.exe的关联进程。这些进程会锁住 config 和 system 目录下的文件导致你剪切到一半报文件正在被另一个程序使用。稳妥的做法是先关闭 IDEA 窗口然后右键任务栏看有没有驻留图标IDEA 关闭主窗口后不一定退出取决于设置打开任务管理器在详细信息里搜idea把所有相关进程结束掉。如果你用的是 JetBrains Toolbox 管理 IDE还要顺手退出 Toolbox否则它对安装目录的监控可能会在你迁移后重新拉一份回来。还有一类隐藏的锁定来自 Windows 的资源管理器缩略图服务和杀毒软件。迁移大量小文件时某些安全软件会逐个扫描既慢又容易抢文件句柄。我的经验是迁移前先在安全软件里把目标目录加进白名单或者干脆临时暂停实时防护搬完再开。这一步能省掉大量莫名其妙的权限不足报错。另外迁移前先执行一次完整退出、再重开确认能正常启动是有意义的——这样一旦迁移失败你能确定问题出在迁移操作本身而不是 IDE 原本就坏了。2.2 目标分区怎么选固态、NTFS、路径别带中文和空格迁移目标盘的第一个原则是别把索引放到机械硬盘上。IDEA 的索引读写极其频繁如果你把system目录搬到一个老式机械盘代码补全、全局搜索、文件跳转都会肉眼可见地卡。所以要么搬到另一块固态要么同一块固态的另一个分区。如果机器只有一个 C 盘一个 D 盘、且只有 C 是固态那搬迁的意义就要重新评估——这种情况下更划算的做法是清理而不是迁移把旧版本目录、日志、缓存删掉能腾出不少空间。第二个原则是路径规范。目标路径里不要有中文、不要有空格、不要有特殊符号尽量用D:\JetBrains\...这种短路径。原因有两层一是 Java 的历史包袱某些组件对非 ASCII 路径处理不干净二是配置文件里写路径时反斜杠是转义字符中文加反斜杠组合更容易出问题。我现在统一用的结构是D:\Dev\JetBrains\config、D:\Dev\JetBrains\system、D:\Dev\.m2、D:\Dev\.gradle简单、好记、不踩坑。第三个原则是权限。目标目录如果你建在某个受保护的位置比如C:\Program Files下面IDEA 写日志时可能因为权限不足启动失败。建议直接把目标目录建在非系统盘的根目录下的一级文件夹里用当前用户身份创建默认权限就是对的。建目录的时候别用新建文件夹层层嵌套直接用命令行一次创建省得路径拼错New-Item -ItemType Directory -Force -Path D:\Dev\JetBrains\config New-Item -ItemType Directory -Force -Path D:\Dev\JetBrains\system2.3 先复制、后验证、再删源别用剪切这是一个我反复强调的习惯迁移大目录时用复制—验证—删除三步走绝对不要用资源管理器的剪切粘贴。理由是剪切操作在你中途取消或者出错时源目录可能已经残缺而 IDEA 的目录结构里有很多相互引用的文件残缺的配置目录会导致启动时报出难以定位的错误。复制虽然多占一会儿空间但整个过程中源数据始终是完整的随时可以回退。具体操作上我会先把目标目录建好然后用robocopy而不是copy。robocopy支持多线程、支持断点重试、能保留属性和时间戳处理几十 G 的小文件比资源管理器靠谱得多# /E 复制子目录含空目录/MT:16 开 16 线程/R:1 重试 1 次/XD 排除指定目录 robocopy C:\Users\你的用户名\AppData\Local\JetBrains\IntelliJIdea2024.1 D:\Dev\JetBrains\system /E /MT:16 /R:1 /W:1复制完成后不要急着删源目录先改配置、启动 IDEA、随便打开两个项目、敲几行代码看看补全和跳转是否正常。确认一切无误之后再回头把 C 盘上的旧目录删掉并且建议保留一个压缩包版本放在别的盘上以防某天需要回滚。整个流程走下来虽然多了十几分钟但心理上踏实得多——我见过太多人图快剪切结果配置丢了、快捷键全没了只能重新配一遍。3. 用 idea.properties 把 config、system、plugins、log 整体搬家3.1 四种改法的优先级别改错地方IDEA 提供了不止一种方式指定这些路径但它们的加载顺序不一样改错位置会出现我明明改了却不生效的情况。官方文档里提到的顺序大致是先读安装目录下bin\idea.properties再读配置目录下的自定义属性文件一般通过菜单里的Edit Custom Properties生成后者覆盖前者而如果你设置了IDEA_PROPERTIES环境变量指向某个文件那个文件的优先级最高。理解这个顺序之后选择就很清楚了。我的推荐是用 Help 菜单里的Edit Custom Properties也就是Help | Edit Custom Properties。它会自动在配置目录下创建一个idea.properties文件并帮你打开这个文件独立于安装目录卸载重装、升级版本都不会被覆盖而且因为它是最后加载的优先级足够高能稳定压过安装目录里的默认值。缺点是这个文件本身就在 config 目录下——但 config 目录通常不大放在 C 盘也无所谓真正要搬走的是 system。如果你希望连配置文件本身都放在别的地方那就用环境变量方案新建一个用户环境变量IDEA_PROPERTIES值指向D:\Dev\JetBrains\idea.properties然后在这个文件里写路径。这个方案的额外好处是同一台机器上多个 JetBrains IDEIDEA、PyCharm、WebStorm可以共享同一份路径配置改一次全都生效。缺点是环境变量改完之后需要重启 IDEA 甚至重新登录桌面才生效容易让人误以为配置没写对。3.2 四个参数逐个拆解顺便把文件名对应上真正要写进idea.properties的是下面这几行。注意几个关键细节必须去掉行首的#注释符路径建议用正斜杠/因为在 properties 文件里反斜杠是转义符写D:\Dev有可能被解析成别的字符写D:/Dev最省心如果一定要用反斜杠就写双反斜杠D:\\Dev。# 配置目录设置、快捷键、插件、模板 idea.config.pathD:/Dev/JetBrains/config # 系统目录索引、缓存、本地历史、日志、临时文件 idea.system.pathD:/Dev/JetBrains/system # 插件目录不写的话默认在 config 目录下的 plugins 子目录 idea.plugins.pathD:/Dev/JetBrains/config/plugins # 日志目录不写的话默认在 system 目录下的 log 子目录 idea.log.pathD:/Dev/JetBrains/system/log四个参数里idea.system.path是收益最大的一个它管着索引和缓存idea.config.path搬不搬看个人因为默认位置本来也不大但它顺带决定了插件的位置有些人的插件目录能到 2G 以上那就值得一起搬idea.plugins.path和idea.log.path属于细粒度控制一般场景下不写也行写了的好处是能把日志单独扔到一个方便清理的位置。另外idea.log.path的目标目录必须真实存在如果 IDEA 启动时写日志失败可能出现启动到一半就没了的现象可以先手动把D:/Dev/JetBrains/system/log建出来。还有一个隐含参数值得一提Windows 上 IDEA 的 vmoptions 文件通过Help | Edit Custom VM Options打开里可以用-Djava.io.tmpdir...把 JVM 的临时目录也挪走。这个目录里会堆积编译中间产物、插件解压的临时文件长期不清理也能长到几 G。但要注意临时目录如果被设置到一个频繁读写的位置对构建速度有轻微影响一般放在另一块固态上没问题。3.3 完整的迁移步骤按顺序执行把上面这些串起来一次完整迁移的流程是这样的。我建议第一次做的时候严格按这个顺序别跳步。关闭 IDEA、Toolbox、任务管理器里所有idea相关进程。在新盘创建三到四个目标目录config、system、config\plugins、system\log。用robocopy把%APPDATA%\JetBrains\IntelliJIdea20xx.x的内容拷到D:\Dev\JetBrains\config把%LOCALAPPDATA%\JetBrains\IntelliJIdea20xx.x的内容拷到D:\Dev\JetBrains\system。注意是拷贝目录里的内容不是把整个IntelliJIdea20xx.x文件夹塞进去。通过Help | Edit Custom Properties打开此时还没生效需要先启动一次 IDEA 让它生成文件或者手动在 config 目录里新建idea.properties写入上面的四行参数。启动 IDEA。第一次启动会比较慢因为它在新的 system 目录下重建索引这个过程根据项目数量可能持续几分钟到十几分钟属于正常现象别以为卡死了。打开两个不同类型的项目验证补全、跳转、Git 集成、Maven/Gradle 同步是否正常。确认无误后删除 C 盘上的旧目录保留一份压缩备份。整个过程里最容易出错的是第 4 步文件还没生效就启动。如果编辑器打不开没法用菜单可以手动在%APPDATA%\JetBrains\IntelliJIdea20xx.x下新建idea.properties效果与菜单生成的一样。另外版本号目录名一定要写对——2023.1和2023.2是两个独立目录配置互不通用写错了就是白改。3.4 改完打不开四种典型症状的排查思路迁移之后如果有问题症状通常很好认。第一种是启动后设置全丢了看起来像重装了 IDE 一样这种情况一般是idea.config.path指向了一个空目录说明拷贝时漏了内容或者指向的路径根本不存在IDEA 默默地用新目录启了一份干净配置。解决办法是检查路径拼写确认目标目录里有options、keymaps这些子目录。第二种是提示无法访问索引或索引重建失败多与idea.system.path的权限有关。检查目标目录的所有者是不是当前用户必要时用命令行给目录授权。还有一种可能是路径里有中文或者空格某些版本对这类路径处理不干净换成纯英文短路径基本能解决。第三种是启动闪退连主界面都看不到。这时候的救命稻草是日志system\log\idea.log里会记录启动阶段抛出的异常。如果因为路径配错导致连日志都写不出来可以临时把idea.log.path去掉让它回到默认位置先能把 IDE 启起来再说。日志里如果出现Cannot create directory或Access is denied基本就是路径或权限问题。第四种是用是能用但补全和搜索慢了很多。这通常说明目标盘性能不行比如搬到了网络盘、机械盘或者目标目录被实时防护软件持续扫描。这种问题不是配置错误但体验下降很明显我的建议是搬回固态或者在安全软件里给目标目录加上排除项。4. 不想动配置文件用目录联结做事后搬运4.1 mklink /J 和 mklink /D 的区别如果你不想改任何配置文件还有个更无痕的办法目录联结junction。Windows 上的mklink命令可以创建几种不同类型的链接其中/J创建的是目录联结/D创建的是符号链接。它们对 IDEA 来说是透明的——IDEA 依然认为自己在读写%LOCALAPPDATA%\JetBrains\...但实际上那些读写被重定向到了 D 盘的真实目录。两者最大的区别在权限创建符号链接/D需要管理员权限或者系统开启了开发者模式而目录联结/J用普通用户权限就能创建。这就是我推荐/J的原因——不需要提权不会因为权限问题卡住而且目录联结的兼容性在 Windows 上更好几乎不会出现某些程序看穿链接的情况。操作思路很简单先把真实数据搬到 D 盘然后把 C 盘上那个目录删掉最后在原位置创建一个指向 D 盘的联结。这样 IDEA 完全不需要感知变化AppData下的路径看起来一切如常。命令大致长这样:: 1. 先确保 IDEA 已关闭数据已复制到 D 盘 :: 2. 删除原目录务必确认数据已备份 rmdir /S /Q C:\Users\你的用户名\AppData\Local\JetBrains :: 3. 在原位置创建指向 D 盘的目录联结 mklink /J C:\Users\你的用户名\AppData\Local\JetBrains D:\Dev\JetBrains执行成功后你会看到一个带快捷方式箭头样式的目录打开它看到的内容就是 D 盘里的内容。删除这个目录的时候要注意删除联结本身不会删掉 D 盘的数据但如果用了某些强制删除工具可能会穿透到目标目录把真实文件一起删了这一点必须小心。4.2 两种方案的取舍我一般怎么选改配置和用联结各有适用场景。我把自己的判断标准整理成了下面这张表你可以对照自己的情况选。对比项改 idea.properties目录联结 mklink /J需要管理员权限否否迁移粒度可按 config/system/plugins/log 分别指定通常整个目录一起搬对升级的适应性好升级后依然有效好但不适用于 Toolbox 重装场景排查难度路径错误时症状明显日志清晰出问题时不容易第一时间想到链接适用场景想精细化控制、多 IDE 共享配置想零配置改动、只求把空间腾出来风险点properties 转义、路径拼写删除时穿透、备份工具识别异常我自己的习惯是如果是给自己的工作机做长期配置用改 properties 的方式因为可控、可文档化以后换机器直接抄这份配置如果是临时给同事的机器救急或者对方完全不想碰配置文件就用联结五分钟搞定。还有一种组合拳先用联结把历史包袱整体搬到 D 盘再在idea.properties里把 system 显式指向新位置等于双保险不过说实话有点多余选一种就够了。最后提醒一个细节即便用了联结idea.properties里的默认值也应该保持干净不要一边改了路径一边又留着链接那样容易出现数据到底存在哪的困惑。迁移这件事清晰比巧妙重要。5. Maven、Gradle、前端缓存真正的空间大头5.1 Maven 本地仓库的迁移以及 settings.xml 的优先级.m2\repository的迁移是最划算的一步改一行配置省几 G 到几十 G而且几乎零风险。做法是在 Maven 的settings.xml里指定localRepositorysettings localRepositoryD:/Dev/.m2/repository/localRepository !-- 其他配置保持原样 -- /settings关键问题是改哪个settings.xml。Maven 会按顺序找两个位置用户级的%USERPROFILE%\.m2\settings.xml和全局的${MAVEN_HOME}\conf\settings.xml用户级优先。如果你在 IDEA 里用的是自带捆绑的 MavenBundled Maven 3它读的其实是插件目录下那份conf\settings.xml改错了地方就不生效。所以更稳的做法是在 IDEA 的Settings | Build, Execution, Deployment | Build Tools | Maven里勾选Local repository的 Override 复选框直接填D:/Dev/.m2/repository。具体到迁移步骤先把旧仓库整个复制到新位置这一步不能省否则重新下载依赖会花掉大量时间然后确认 IDEA 里的 Maven 配置指向新路径重启 IDE随便打开一个项目执行一次Reload All Maven Projects看依赖解析是否正常。确认没问题后再删旧目录。注意迁移仓库之后如果某个项目用了mvn install装到本地仓库的自研包检查一下~/.m2/settings.xml里有没有配过localRepository两处配置冲突时 IDEA 里的设置优先但命令行mvn走的是 settings.xml容易造成IDE 里能找到依赖命令行却找不到的怪现象。5.2 Gradle 的 wrapper 分发包和构建缓存Gradle 这边所有东西默认都在%USERPROFILE%\.gradle下包括caches依赖和构建缓存、wrapper\dists各个版本的 Gradle 发行包、daemon守护进程日志。搬走的办法是设置环境变量GRADLE_USER_HOME# 用户级环境变量设置后所有走 Gradle 的程序都会用这个目录 [Environment]::SetEnvironmentVariable(GRADLE_USER_HOME, D:\Dev\.gradle, User)设置完要重启终端和 IDEA 才生效。注意几个坑第一.gradle目录不要跨机器共享里面有些缓存是跟路径和系统绑定的第二wrapper\dists里那些解压出来的 Gradle 发行版如果只是想让 C 盘松快点可以直接删掉旧版本的目录下次构建时会自动重新下载代价是一点时间和网络流量第三IDEA 里 Gradle 的设置页面在不同版本里位置变动过Gradle user home 输入框在有些版本被精简掉了这种情况下用环境变量是最稳的不依赖 IDE 界面。构建缓存caches\build-cache-1是另一个可以定期清的对象它记录的是任务级的增量构建结果删掉之后第一次构建会变慢之后恢复。如果你的项目组频繁切换分支这里会积累大量无效条目我一般每两三个月清一次配合--build-cache参数重新跑一遍。5.3 npm、pnpm、yarn 的缓存目录迁移前端三件套的缓存默认位置各不相同。npm 的缓存在 Windows 上是%LOCALAPPDATA%\npm-cache老版本在%APPDATA%\npm-cache用一条命令就能改npm config set cache D:\\Dev\\npm-cache npm config set prefix D:\\Dev\\npm-globalprefix是全局安装包的位置也就是npm install -g装的东西落在哪改它顺便也把全局包从 C 盘挪走了。ppnpm 的存储用pnpm config set store-dir D:\\Dev\\pnpm-storeyarn 1.x 用yarn config set cache-folder D:\\Dev\\yarn-cache。这几个命令执行完之后可以用npm config get cache之类的命令验证一下是否写进去了。这里有个实战经验前端缓存的迁移不要和 IDEA 的迁移在同一天做。因为一旦node_modules装不上、依赖报错你会同时怀疑是 IDE 的问题还是缓存路径的问题排查成本翻倍。分开做每做完一项跑一次项目确认没问题再动下一项这种小步验证的习惯能省掉大量时间。另外node_modules本身在项目目录下如果你的项目就放在 C 盘那再搬缓存也治标不治本。真正的解法是把代码仓库整体放到 D 盘或者其他数据盘C 盘只留系统。同理IDEA 的构建输出目录Maven 的target、Gradle 的build也在项目里项目在哪它们就在哪。6. 搬完之后把几个持续增长的开关拧小6.1 索引和 Excluded 目录这是最容易被忽视的一招搬走只是治标要让 C 盘不再反弹得从源头控制增长速度第一刀砍在索引上。IDEA 的索引是按项目内容生成的项目里如果有庞大的构建产物目录、日志目录、数据目录它也会当成源码去解析、去建索引既浪费时间又占用磁盘。正确做法是把这些目录标记为 Excluded在项目视图里右键目录 →Mark Directory as→Excluded。哪些目录应该排除我一般会排除这几类Maven 的target、Gradle 的build、前端的node_modules和dist、日志目录logs、以及任何存放二进制数据或测试数据的目录。标记之后IDEA 不再为它们建索引system\caches的体积增长会明显变慢。但注意Excluded会导致这些目录里的文件无法被全局搜索和跳转命中所以是否排除要看你的实际需求——如果偶尔需要在构建产物里翻东西就别排除或者用File | Invalidate Caches定期清一次。说到索引清理File | Invalidate Caches / Restart是个常用动作但它成本不低清理之后所有项目都要重建索引打开大项目会卡半天。我的建议是不要把它当日常保养只在遇到跳转错乱补全失灵这类疑似索引损坏的问题时用。真正日常该做的是控制索引范围而不是反复重建。6.2 本地历史、日志、撤销层数、临时文件IDEA 有个非常良心的功能叫 Local History它会在你编辑文件时自动留版本不看 Git 也能回滚。代价就是数据存在system\LocalHistory下长期使用可以到几 G。新版 IDEA 在Settings | Appearance Behavior | System Settings附近提供了本地历史保留天数的设置不同版本位置略有差异如果找不到对应选项可以退而求其次定期关闭 IDE 后清理LocalHistory目录代价是丢掉本地历史记录。我个人会保留这个功能但把保留天数调短一些同时在项目里坚持用 Git 提交双重保障。日志是另一个持续增长项。system\log下的idea.log会滚动生成idea.log.1、idea.log.2等文件长期不清理能到几百 M 甚至上 G。这个目录可以直接删——删日志不影响任何功能只是出问题的时候少了排查线索。我的做法是保留最近一周的其余删掉因为排查历史问题基本用不到那么久远的日志。撤销层数也值得一调。默认情况下 IDEA 会把大量编辑历史留在内存和磁盘上可以通过CtrlShiftA搜索Registry打开注册表找到undo.documentUndoLimit和undo.globalUndoLimit这类参数把值调小一点比如从 100 调到 50。不同版本参数名可能有差异找不到就跳过不要强行改不认识的键改错了会影响稳定性。此外Help | Edit Custom VM Options里可以适当调整 JVM 堆大小堆太大也会影响系统的页面文件占用不过这是另一个话题了。6.3 版本升级残留和插件瘦身每次 IDEA 升级都会新建一个版本目录旧的不会自己消失。所以每隔几个版本就该去%LOCALAPPDATA%\JetBrains和%APPDATA%\JetBrains里看看把那些明显不用的老版本目录删掉。判断标准很简单你当前用的版本对应的目录保留其他的都可以删但删之前最好确认自己没有回滚旧版本的需求删掉之后旧版本的设置和历史就找不回来了。我通常的做法是把旧目录压缩打包放到 D 盘存一份然后再删 C 盘的。插件是配置目录里的另一个大项。config\plugins下每个插件都有自己的文件夹装了三四十个插件的机器这个目录能到 3G 以上。清理原则是三个月没用过的、只在特定项目用的、装了发现不好用的直接卸载。特别是那些带大量静态资源的插件主题、图标包、AI 辅助类单个就能到一两百 M。卸载在Settings | Plugins里操作卸载完建议重启一次 IDE。还有一个容易忽略的地方JetBrains Toolbox。如果你用它管理 IDEIDE 的实际安装位置在%LOCALAPPDATA%\JetBrains\Toolbox\apps下每个产品每个版本一份占用量相当可观。Toolbox 的设置里可以调整工具的安装位置改到一个空间充裕的分区再重装对应实例即可。如果你不用 Toolbox就检查一下安装目录是不是放在了C:\Program Files下——装的时候选 D 盘是完全可行的安装向导里有路径选项。6.4 一份可以定期跑一遍的巡检清单为了不每次都重新想一遍要查什么我做了一张清单每个月或者每次感觉 C 盘开始紧张的时候跑一遍基本二十分钟能搞定。参数都换成你自己的用户名和版本号即可。检查项位置处理动作频率IDE 系统缓存%LOCALAPPDATA%\JetBrains\IntelliJIdea*确认已迁至 D 盘超 15G 就清索引每月配置与插件%APPDATA%\JetBrains\IntelliJIdea*卸载无用插件删旧版本目录每季度Maven 仓库%USERPROFILE%\.m2\repository确认已迁移删除*.lastUpdated残留每季度Gradle 缓存%USERPROFILE%\.gradle确认GRADLE_USER_HOME生效清旧 wrapper每季度前端包缓存npm/pnpm/yarn 的 cache 目录确认已迁移必要时清理每月系统临时文件%TEMP%、system\tmp关闭 IDE 后清理每月IDEA 日志system\log保留一周其余删除每月跑清单的时候有个小技巧先跑一遍第 1.4 节那个 PowerShell 脚本看数字有没有异常增长再决定要不要深入处理。如果system目录在两个月内从 8G 涨到 20G那多半是你新开了几个大项目索引自然膨胀属于正常现象不必惊慌如果它在你没开新项目的情况下还在涨那就要看看是不是有插件在疯狂写日志或者本地历史保留时间设得太长。最后分享一点个人的使用体会。C 盘空间这件事本质上是默认值和实际需求的错配——所有工具都默认把数据放在系统盘的用户目录下因为它们要兼容各种环境、要考虑权限但对开发者来说代码、依赖、缓存这类东西放在数据盘才是常态。所以我现在的习惯是新机器装完系统后做的第一件事不是装 IDE而是先把 D 盘的目录结构规划好环境变量一次设到位然后再装开发环境。这样后面几年都不用再为空间发愁也不用在 C 盘爆红的时候手忙脚乱地搬来搬去。