很多后端同事第一次看到我IDE的左侧项目树，都会指着下方那个独立节点问：“这是什么？项目里没这个目录吧？”我的回答通常很简短：“这是IDE的Scratches and Consoles，临时文件都存这里，bat也是从这里跑的。”用过一段时间之后，这套组合已经成为我每天的基础工作流：Scratches存临时文件、Consoles跑交互代码、再借助External Tool或Run配置执行bat脚本。这篇文章就围绕这三件事展开，适合那些不想让验证代码和临时脚本污染项目目录，又希望在IDE内部完成“存储-执行-验证”闭环的开发者。没有复杂原理，全是实际验证过的路径和踩坑记录。

1. 先说清楚：Scratches and Consoles 是什么，它解决了什么问题

1.1 它和项目普通文件的本质区别

项目目录里的Java、Python、SQL文件，本质上都属于某个工程，会被版本控制追踪，会被构建工具扫描，甚至被打进最终的构件里。而Scratches and Consoles下的文件，IDE只是把它们当作“当前工作台旁边的便签纸”，不会参与项目索引、不会进版本控制、更不会影响运行与构建。

这一点决定了它的核心使用价值：你可以放心地把只验证两次就丢弃的代码、一段待优化的SQL、一个接口测试请求放在这里，完全不用担心破坏项目结构。

我早期犯过一个很典型的错误：为了省事，把临时SQL直接写在项目的一个.sql文件里，结果提交代码时忘了排除，顺带把一段带测试数据的查询语句提交了上去，CI构建直接报错，整条流水线被卡住。从那以后，所有“临时”“只验证一次”“还没想好要不要留”的东西，一律进Scratches，项目目录里只放真正属于项目的内容。

1.2 哪些内容最适合往里放

以我的日常为例，最常放的是这几类：

• 一次性SQL查询，比如排查数据时反复修改条件的查询语句；
• 代码片段，比如用Python快速验证某个新库的函数行为；
• HTTP Request文件，IDE支持在Scratches里保存.http格式并直接点击运行；
• 临时写好的批处理命令草稿，还没决定要不要正式放进项目。

还有一个容易被忽略的场景：写博客或做技术总结时，会用到一些临时代码示例，这些内容也和项目无关，放在Scratches里非常合适，既能高亮又能随时改。

好处很明显，这些内容紧挨着代码，不用切换浏览器、不用开记事本、不用新建工程，命令一写就能跑，跑完就留在原地，下次需要翻出来看时，层级和分类都清清楚楚。

1.3 它在磁盘上到底存到了哪里

Scratches默认保存在IDE的配置目录下，而不是项目目录里。在Windows上，大致位于当前用户的配置数据目录中，具体路径会被IDE的名称和版本号影响。正因如此，它天然与项目隔离，但同时也带来了一个容易被忽略的问题：如果只迁移项目目录，不迁移IDE配置，Scratches里的内容不会跟着走。

这个特性让我一度吃过亏。某次重装IDE后，发现所有存过的临时SQL和命令模板全没了，项目代码倒是都在，但一年积累下来的“草稿本”直接清零。后来我专门写了一个备份脚本去处理Scratches目录，这个场景在后面会展开讲。

2. Scratch 文件实操：创建、归类与管理

2.1 最常用的创建路径

在Scratches and Consoles节点上右键，选择New → Scratch File，IDE会弹出语言模板列表；或者在编辑器任意位置按Ctrl+Alt+Shift+Insert，直接呼出新建Scratch的菜单。这个快捷键频率很高，但很多同事都不知道。

选择模板后，IDE会按对应语言提供语法高亮、代码提示和运行方式。我常用到的模板有SQL、Python、HTTP Request、Markdown和Shell Script，基于IDEA内核的主流IDE基本都内置或通过插件支持这些模板。注意一点：Scratch不要求文件有扩展名，但给出正确的扩展名能让IDE自动关联语言，比如.sql后缀会自动切到SQL方言提示，.py后缀会启用Python的语法检查。

如果是临时想验证一段代码但又不知道放哪里，用快捷键新建Scratch是最快的路径，它不需要你思考“这个文件属于哪个模块”“归到哪个包”，直接开写就行。

2.2 用文件夹做分类，而不只靠文件后缀

Scratches和普通目录一样支持新建子目录，右键选择New → Directory即可。随着时间推移，建议按用途分成几个目录，比如“SQL”“Python”“HTTP请求”“命令草稿”。我自己还专门建了一个“临时bat”目录，存放还没定稿的批处理脚本。

分类的意义在于，Scratch内容多了以后，如果全部平铺在根节点下，照样会乱。命名上我也建议带上场景词和日期，比如月度对账_20250105.sql、调试接口返回_临时.py，这样几周后翻出来，能一眼知道当时为什么要建这个文件。

另外，IDE的Scratches支持拖拽排序和移动，在目录间调整位置非常顺手。发现某个文件归档错了，直接拖走就行，比在文件管理器里操作还直观。

2.3 把有价值的Scratch“晋升”到正式项目

Scratch的定位是临时，但“临时”和“长期可复用”之间没有绝对边界。我的做法是：如果一个脚本在三天内被翻出来两次以上，就把它复制到项目对应的目录，或者挪到一个专门存放经验文档的目录里，让团队里其他同事也能看到。如果内容是通用的，还可以考虑沉淀成公司内部的知识库条目。

这里要提醒一句：别让Scratch变成垃圾堆。定期清理很重要，我一般周末花十分钟过一遍，已经完成的验证代码直接删，可能有用的改个清晰名字留下，已经确认有长期价值的移出Scratches。这样整个Scratches节点始终保持轻量状态，而不是变成一个什么都往里面塞的无底洞。

3. Console：不止是“能跑代码”，而是项目外验证环境

3.1 如何打开一个干净的控制台

在Scratches and Consoles节点的右键菜单里，或者在IDE顶部Tools菜单中，通常能找到对应语言插件的Console入口。以Python环境为例，打开Python Console后，下方会出现一个交互式窗口，它加载的是当前IDE配置的解释器。如果当前正打开某个项目，Console会自动继承项目的依赖和路径；如果把IDE当成纯编辑器用，Console也会使用默认解释器。

Console和Scratch文件最大的区别在于交互性：你不需要写一个完整的入口函数，也不需要新建脚本文件，输入代码回车运行，结果立刻出来，变量还会驻留在内存中。

这一点在日常验证中极其有用。比如想确认某个字符串解析逻辑在不同时区下的表现，直接在Console里import相关库，写一两行构造代码，立刻能看到输出。如果建一个临时脚本文件跑，反而要写main、要处理输出格式，流程重得多。

3.2 一个“选中执行”的实用技巧

这里分享一个我几乎每天都在用的功能：在编辑器中写好一段代码，选中后右键，用“Execute Selection in Console”或类似入口发送到控制台执行。这样既能享受编辑器的代码高亮和自动补全，又能利用Console的即时反馈。

举个例子：某次联调接口返回了一个嵌套很深的JSON，我要快速抽出某个字段验证是否合法。在Python Console里直接粘贴JSON字符串，然后写两行遍历逻辑，肉眼都不需要看到完整结构，结果就出来了。如果每次都在项目代码里写单元测试，光准备测试数据就要花不少时间。

Console还有一个隐藏优点，它适合反复操作同一份数据。比如从一个接口拉取数据后，先解析、再过滤、再格式化输出，每一步之间变量都存在，不用把整个流程塞进一个脚本里，测试哪个环节就单独写哪个环节，灵活很多。

3.3 Console的边界和释放

Console确实方便，但它不是万能的。它默认是一个常驻解释器进程，变量会一直保留，这既是优点也是风险。比如你修改了项目的依赖配置，已经打开的Console很可能还在用旧的classpath，此时需要重建Console，否则会遇到一些令人困惑的“找不到模块”或“旧代码生效”的问题。

另外，用完的Console建议及时关闭，右键面板标题栏选择Close Console即可。尤其是Python Console，解释器进程会占内存，时间开久了还会把临时变量堆成一团。我习惯验证完一段就关掉，下次需要时再开，几秒钟的事情，但内存和思路都会清爽很多。

对于并发、多线程、GUI这类场景，Console并不适合，它终归是文本交互环境，没有完整的主程序生命周期。真要验证这类逻辑，还是老老实实写在Scratch文件里用IDE的Run方式跑，至少能看到完整的堆栈和线程状态。

4. 在IDE里执行bat文件：三条路径，按场景选

4.1 最省事：内置Terminal直接跑

打开IDE内置Terminal，默认Shell可能是cmd、PowerShell或bash，取决于IDE版本和系统设置。最简单的方式就是直接输入脚本路径执行，比如.\scripts\build.bat，或者先cd到bat所在目录再执行。如果当前Shell不是cmd，也可以用cmd /c xxx.bat来显式调用。

Terminal方式的优点是零配置、可交互，环境变量和shell状态和手动开一个cmd窗口几乎一致，适合随手跑一下脚本、临时改个参数再跑的场景。缺点也很明显：每次都要输入命令，没有“一键运行”的按钮感，输出记录也不集中在Run面板，长期看日志不太方便。

4.2 可复用：Run配置方式

想让bat像项目里的其他启动程序一样，出现在顶部运行按钮的下拉列表里，可以用Run/Debug Configurations来新建一个Shell Script配置。具体做法是：打开Run/Debug Configurations，点“+”新建Shell Script；Script path选择bat文件路径；Interpreter path填cmd.exe；Interpreter options填/c；Working directory填脚本所在目录；有需要的话，还可以在Environment variables里定义脚本要用到的环境变量。

配置完成后，点击Run就会执行这个bat。输出会出现在Run工具窗口，日志可视、退出码可见，和运行一个Java程序或Python脚本的体验基本一致。适合那些在项目内固定的脚本，比如构建后自动拷贝文件、启动本地依赖服务、批量清理日志等。

4.3 全局顺手：External Tool方式

External Tool更适合“在任意项目中执行同一批bat”的场景。配置入口在Tools → External Tools，新增一个工具项：Name随意取，Program填cmd.exe，Arguments填/c call "D:\path\to\xxx.bat"，Working directory填bat所在目录，勾选Open console让输出可见。保存后，Tools菜单里就会出现这个工具，还可以在Keymap中给它绑定一个全局快捷键。

我之所以更推荐External Tool，是因为它不需要为每个项目重复配置Run Configuration，工具列表和IDE设置绑定，换项目依然在。把高频动作变成一个菜单项甚至一个快捷键，比每次去终端敲命令稳定得多，也不容易记错路径。

4.4 三种方式怎么选

我的选择习惯很简单：随手跑用Terminal；一个项目里要反复用的固定脚本，花两分钟配一个Run configuration；如果是那种“不管在哪个项目里都可能用到”的高频bat，例如备份Scratches、启动本地数据库、切换开发环境变量，全部走External Tool并绑快捷键。

5. 执行bat时踩过的坑：编码、工作目录、退出码

5.1 中文乱码：chcp不是银弹

bat里echo中文在IDE控制台输出乱码，这个问题几乎每个人都遇到过，而且很多人会误以为是IDE显示问题，其实是控制台代码页和文件编码不匹配。Windows的cmd默认代码页通常是936也就是GBK，而IDE默认按UTF-8存储和读取文件，两边不一致，中文理所当然会乱。

我的建议是分两种情况处理：

• 如果必须使用中文输出并且想省事，把bat文件另存为ANSI（GBK）编码。cmd按936代码页读取时刚好对上，无需任何额外操作；
• 如果想保持项目文件统一切UTF-8，就在bat开头加一行chcp 65001 >nul，把cmd代码页切换到UTF-8。此时注意文件一定要存成不带BOM的UTF-8，否则第一行输出前面可能会出现一个BOM字符。

还有一点需要测试：部分版本的Windows控制台在chcp 65001之后，中文字体渲染依然可能不理想，这种情况下与其和编码纠缠，不如直接让bat输出英文提示，脚本本身需要调用的路径和文件名则建议不用中文。

5.2 工作目录坑：让bat自己认路

双击bat和在IDE里运行bat，默认工作目录很可能不一样。IDE的Terminal默认在项目根目录；Run配置的默认工作目录是你填写的目录；如果什么都不填，可能继承上一个运行配置。当bat里写了copy .\a.txt D:\tmp这类相对路径时，很可能找不到目标文件。

最稳的办法是让bat自己切换到所属目录。在bat开头加这两行：

@echo off cd /d "%~dp0"

%~dp0是批处理中一个非常实用的参数扩展：%0代表脚本本身的路径，~d提取盘符，~p提取目录，组合起来就是bat脚本所在的完整目录。cd /d则会在切换盘符时也生效。这样无论从哪里执行，工作目录都会先切到脚本自己所在的位置，后续所有相对路径都基于这个位置计算，基本杜绝了“找不到文件”的问题。

5.3 别把pause带进IDE执行的bat

双击bat的时候加pause避免窗口闪退，这是无数教程教过的常规操作。但在IDE里跑bat时，pause会让脚本卡住，Run面板一直显示“按任意键继续”。我见过同事把带pause的bat注册成External Tool，执行后面板一直挂着，还以为是脚本死循环了。

给IDE执行的bat，应该一律去掉pause。真正需要在结束时反馈退出状态的场景，用exit /b %errorlevel%把退出码传递出来，Run面板右下角会显示Process finished with exit code 0；失败时也能立刻看到非零退出码，定位问题比卡在一个“按任意键”的提示上高效得多。

5.4 环境变量和路径空格的细节

External Tool和Run配置默认继承的是启动IDE时的系统环境变量，你在Terminal里临时set的变量，它们是看不到的。需要传递环境变量时，要么在Run配置的Environment variables窗口里添加，要么在bat内部用set明确设置。

另一个高频问题就是路径空格。Program和Arguments只要含空格，就必须用引号包起来。常见错误写法是把D:\my tools\build.bat直接写进Arguments，被解析成多个参数后执行失败，正确写法是/c call "D:\my tools\build.bat"。参数本身若含有空格，同样应当用独立的引号包围，嵌套引号在一些场景下会略显繁琐，但这是值得的。

6. 一套组合打法：Scratch存脚本，bat做批处理，Console做验证

6.1 场景一：每日开发自检流程

假设一个常规业务系统，每天开工要先清理缓存、启动依赖服务、查关键数据。我会用一个bat把这几个动作串起来，注册成External Tool一键执行；同时把常用的SQL和HTTP请求存成Scratch，需要看数据时直接在Scratch里运行；遇到要快速验证的接口返回结构，在Python Console里处理JSON并抽取字段。整个过程不用离开IDE，不需要切去浏览器、不需要找单独的cmd窗口。

实际执行顺序大致是：先External Tool跑bat做环境准备，然后打开Scratch里的核心表检查.sql，按当天场景改where条件，点运行看结果；如果需要验证某个接口的字段合法性，在Console里粘贴返回片段，写几行解析逻辑。这套流程下来，每天光是“切换窗口”这个动作就能省下不少时间，注意力也更集中在当前的问题上。

6.2 场景二：用Scratch暂存命令模板，再用bat固化

有些命令行工具参数很长，比如某个内部Java程序启动时需要java -cp lib\xxx.jar com.example.Main -c config.json --env=test。我会先把这行命令存在Scratch的“命令草稿”文件里，因为这时还不确定后面要改几次参数；跑了两次发现确实常用，就把它改写成bat，封装成带默认参数的脚本，再加入External Tool列表。

这样分工就明确了：Scrtaches负责“草稿→沉淀”的前半段，让人先以低门槛的方式记录和试用；bat负责“常态化执行”的后半段，让高频操作变成一键触发。IDE里的文件既能看又能跑，整个链路都在一个工具里完成。

6.3 场景三：备份Scratches整目录

前面提到，Scratches存储在IDE配置目录而不是项目目录里，重装IDE时很容易丢失。我吃过一次亏之后，写了一个bat定期把Scratches目录压缩成zip放到备份路径，再通过External Tool绑定快捷键，隔几天执行一次。

具体压缩命令不依赖第三方工具，Windows自带的PowerShell就能完成：

@echo off set "src=%APPDATA%\你的IDE名\scratches" set "dst=D:\backup\scratches_%date:~0,10%.zip" powershell -Command "Compress-Archive -Path '%src%\*' -DestinationPath '%dst%' -Force" echo backup done

注意%date:~0,10%在不同区域设置的Windows上格式有差异，中文系统可能是“2025/01/05”这种带斜杠的形式，直接拼进文件名会出问题。第一次使用时先把这个变量echo出来确认一下格式，再固化到脚本里。

6.4 一个稳定的个人工作流小结

最终固定下来的工作流是：Scratches当作随身草稿和命令库，所有临时内容先进这里；Consoles当作快速验证区，情况清楚之前先不落盘；bat脚本负责所有重复性的、跨工具的批处理动作；External Tool把bat整合进IDE的菜单和快捷键。

三者互相配合后，日常开发中大部分临时任务都可以在IDE里完成，切换外部程序的次数明显减少，遇到“这个脚本上次怎么跑的”这类问题，翻Scratches里的记录就能找到答案。整个体系没有很高深的部分，但每个环节都在解决一个具体痛点，用顺了之后很难退回去。

最后分享一个小习惯：用Scratch记录“怎么跑某个工具”，用bat固化“这个工具怎么自动跑”，用Console验证“跑完的数据对不对”。如果你想尝试，建议今天先在Scratches里存一段SQL或一个HTTP请求，再把常用的一条bat注册成External Tool，完整体验一次“不切窗口”的工作流。等用顺了，你大概率会和我一样，把这些当成开发环境里的标配。