升级到 IntelliJ IDEA 新 UI 之后，我第一反应不是赞叹界面变好看了，而是找了一个晚上 XRebel 的入口。右侧栏的图标没了，快捷面板也变了位，我以为插件在新界面下失效，还专门去 Plugin Marketplace 重装了一遍，结果装完还是老样子。后来才发现，插件其实一直在跑，只是入口被新 UI 重新塞到了另一个层级里。如果你也遇到同样的情况，这篇就是写给你们的——从安装激活到面板入口，从请求分析到常见故障排查，照着走一遍，就能在新 UI 下继续用 XRebel 定位服务端性能问题。
1. 为什么升级新 UI 后 XRebel 会“隐身”
先说结论：绝大多数情况下，不是 XRebel 失效，也不是 IDEA 把插件禁用了，而是新 UI 对工具窗口的排布逻辑变动太大，旧习惯找不到新入口。
1.1 新 UI 重新定义了工具栏与工具窗口的层级
老版本 IDEA 的右侧栏是一排工具窗口按钮，Structure、Maven、Database、XRebel 这些图标可以停靠在一起，鼠标点一下就能展开。新 UI 改成了更紧凑的布局，右侧那一排按钮被收进了界面底部和侧边的“工具窗口区域”，默认情况下只显示一行小图标，图标不带文字标签，陌生插件图标混在里面很难一眼认出来。
XRebel 本质上是一个 Tool Window 插件，它把入口挂到了 IDE 的工具窗口系统里。新 UI 调整了工具窗口的停靠位置和显隐规则，插件自身没变，但入口跟着整个窗口体系一起挪了地方。这就是为什么很多人升级后满屏找不到 XRebel，不是它消失了，是它被“重新安置”了。
1.2 插件并不兼容所有 UI 状态，入口要靠你自己找回来
新 UI 里工具窗口按钮的显示策略也变了。有些版本在非 Distraction Free 模式下才会完整显示工具窗口列表，如果你开了专注模式，几乎所有工具窗口入口都会被隐藏。另外，新 UI 对工具窗口默认使用“图标 + 悬停提示”的表现形式，XRebel 的红色标识本来就偏暗色系，在深色主题下更容易被忽略。
我见过不少同事在升级后急着把 IDEA 回滚到旧版，其实没必要。先用两步确认一下插件死活，再决定换不换 UI 模式。
1.3 先用两步判断插件是否真的在运行
第一步，看控制台输出。用 Run 或 Debug 启动 Web 应用后，正常输出里会出现 XRebel 的 agent 启动日志，类似 XRebel: Started agent 这样的字样。如果这条日志存在，说明插件已经成功挂到了 JVM 里。
第二步，看 View 菜单。点开 IDEA 顶部的 View，找到 Tool Windows 子菜单，在里面挨个找有没有 XRebel 这一项。如果菜单里能看到，说明插件在运行，只是工具窗口图标没显示出来；如果菜单里根本找不到，才考虑插件未启用、版本不兼容或 license 失效的问题。
这两步能省掉大量瞎折腾时间。
2. 在新 UI 下确认安装、激活与启动方式
排除掉“插件隐身”问题后，接下来是完整走一遍安装、激活和启动流程，确保 XRebel 真正进入工作状态。
2.1 从 Plugins 市场安装并重启，确认插件状态
先打开设置窗口。新 UI 下齿轮图标的位置有变化，但快捷键没变：Windows/Linux 按 Ctrl+Alt+S，macOS 按 Cmd+, 或者用 Shift 双击打开 Search Everywhere 输入 Settings。
进入后点左侧的 Plugins，切到 Marketplace 页签，搜索 XRebel。找到后点击 Install，安装完 IDEA 会提示重启，正常重启即可。重启后回到 Installed 页签，确认 XRebel 一栏显示的是 Enabled，而不是 Disabled，也不要出现黄色的兼容性警告图标。
有一点容易被忽略：插件市场搜索不到 XRebel，有时不是插件没了，而是网络环境访问插件仓库超时。这种情况见得多的是在内网办公网环境，插件市场索引加载失败。可以先检查 IDEA 的 HTTP 代理设置，确认能正常访问插件仓库，再查是否需要设置代理白名单。
2.2 许可证激活：新 UI 下设置入口更隐蔽
XRebel 不是免费工具，安装完不代表就能直接用，还需要有效许可证。老版本里设置入口相对直观，新 UI 的设置面板结构变了，很多人会卡在这一步。
打开设置窗口，直接用右上角搜索框输入 XRebel，就可以跳到对应的设置页。如果状态显示未激活，点击 Activation 或 License Management，输入授权信息。常见激活方式分三种：个人试用、许可证服务器、离线激活文件。个人试用最简单，但只能撑一段时间；团队开发建议用许可证服务器统一管理，成员之间不用反复手工输入激活码。
这里必须说一句：不要使用网上流传的破解激活方式，这类操作一旦触发许可证校验失败，轻则插件失效，重则 IDE 直接被标记为非法使用，得不偿失。老老实实申请官方试用或者让团队买授权，成本并不高。
2.3 Run/Debug 启动应用，XRebel 才会真正介入
XRebel 不是“打开面板就采集数据”的工具，它的工作方式是在 JVM 启动时注入 agent，由 agent 拦截请求并上报给 IDE 面板。换句话说，你得用 IDEA 的 Run/Debug 方式启动应用，XRebel 才能搭上车的。
实操里我见过很多“面板空白”的情况，原因就一个：应用是用命令行起的。命令行启动时缺少 agent 注入过程，XRebel 自然采集不到数据。正确做法是在 IDEA 里找到 Spring Boot 启动类、Tomcat 配置、或别的 Run Configuration，点右上角的 Run 或 Debug 按钮。
应用启动成功后，到浏览器里访问一下接口，哪怕只是打开一个首页或健康检查路径，XRebel 面板就会开始显示一条条请求记录。如果应用本身不是 Web 项目，只是普通 Java 进程，XRebel 不会采集到 HTTP 请求，面板当然也是空的。
3. 找回新 UI 里的 XRebel 面板并定制工作区
安装激活都搞定后，真正影响日常使用的问题是：怎么把 XRebel 面板调到最顺手的位置。新 UI 给了更多窗口布局自由度，调好之后比旧版还舒服。
3.1 View 菜单与工具窗口列表
打开 XRebel 面板最稳定的办法就是走 View 菜单：顶部菜单栏 View -> Tool Windows -> XRebel。点击后面板会出现在默认位置，通常是下方或侧边，具体取决于上一次停靠的位置。
如果觉得一步步点菜单太慢，可以直接双击 Shift 呼出 Search Everywhere，输入 XRebel，回车就能打开对应工具窗口。这个方法不受 UI 布局变化的影响，记不住快捷键时最实用。
3.2 工具窗口区域的图标识别与停靠
新 UI 左下角有一排小图标，逐个悬停会弹出工具提示，找到写着 XRebel 的那个，点一下就能唤出面板。如果图标实在找不到，还有一个办法：在底部工具窗口区域的任意空白处右键，会弹出“工具窗口列表”，凡是已启用的窗口都会列在里头。
找到面板后，建议把它固定到常用位置。右键面板的标题栏，选择 Move To，可以快速把它移到窗口底端或右侧。我的个人习惯是把 XRebel 停靠在底栏，和 Run / Debug 窗口放在同一排，这样看请求耗时和看应用日志能在同一个视线范围内完成。
双显示器的朋友可以试试把 XRebel 整块拖到副屏，让它浮动显示。调试接口时主屏写代码，副屏看请求详情，不用来回切换标签，效率会高不少。
3.3 让 XRebel 在新 UI 下更好用的自定义设置
XRebel 的设置项不算多，但有几个值得调整。
一个是请求保留条数。默认会留在面板里的一批历史请求，方便回溯，但并发量高的项目刷屏很快，可以把保留条数调少，只关注当前请求。
另一个是请求过滤。如果项目里有很多监控探活请求，面板会被频繁刷屏，真正的业务请求反而被淹没了。可以在过滤条件里配置只监听指定的 URL 路径或 context path，把这些噪音请求排除掉。
还有一个容易忽略的问题：SQL 参数展示。同一个查询语句，带上参数后能看到真实查询值，便于排查慢 SQL，但如果在共享屏幕演示代码，这些参数可能包含敏感信息。团队协作时建议合理权衡是否显示实际参数。
3.4 绑定快捷键，不靠鼠标
新 UI 下工具窗口太多，光靠图标找窗口也费劲。给 XRebel 单独绑一个快捷键，比记图标位置可靠得多。
进入 Settings -> Keymap，在搜索框输入 XRebel，就能看到打开 XRebel 工具窗口的绑定项。默认可能没有绑定快捷键，或者绑到了某个不常用的组合键。建议手动设置为 Ctrl+Shift+X 或 Cmd+Shift+X。设置时如果提示冲突，就换一个顺手的组合，比如 Ctrl+Alt+X。
绑定完成后，无论当前在哪个标签页，按组合键就能唤出或收起 XRebel 面板，比鼠标定位稳定太多了。
4. 读取 XRebel 面板，分析一次请求到底慢在哪
工具窗口找回来后，真正的工作才开始。XRebel 的价值不在“能记录请求”，而在于它能告诉我们一个请求到底慢在哪个环节。这一节我用实际分析习惯来说说面板该怎么读。
4.1 请求列表视角：先看耗时，再定位层级
XRebel 面板的请求列表和浏览器 Network 面板的思路类似，按时间倒序排列，每一行代表一个 HTTP 请求，关键字段包括请求 URL、HTTP 方法、状态码、总耗时、时间戳。
排查性能问题我习惯先看耗时排序。点击列表表头按照耗时降序排列，把最慢的那批请求挑出来，挨个点开。点进去之后，面板会展示该请求的耗时分布：JDBC 查询占了多少毫秒、外部 HTTP 调用占了多少毫秒、日志和渲染又占了多少毫秒。
这一步的目的不是立刻改代码，而是先确定“时间去哪了”。如果数据库查询占总耗时 80%，再花大量精力优化业务代码就是抓错重点了。先看分布，再决定下一步看哪个明细标签页。
4.2 数据库查询与 N+1 问题的判断
在请求详情里切到 SQL 标签页，能看到该请求执行过的所有 SQL 语句，包括执行耗时、绑定参数、返回行数。这是 XRebel 最实用的功能之一，因为它把 SQL 和具体请求、具体代码调用位置串起来了。
最常见的慢请求原因就是 N+1 查询。明明只是查一条订单，结果关联查询把订单明细、商品信息、用户信息逐条循环查询了一遍，SQL 标签页里就会出现同一条 SQL 反复执行几十次的情况。判断方法很简单：数一数完全相同的 SQL 出现了多少次，次数明显大于业务预期，就是典型的 N+1。
定位到 N+1 之后，改法通常是调整 ORM 映射的抓取策略，用 JOIN FETCH 或批量抓取一次性把关联数据带出来，而不是在循环里逐条查询。改完再跑一次同一接口，看 SQL 标签页里重复的语句是不是降下来了。
返回行数这个字段也很重要。一条 SQL 显示返回上万行，即使单次耗时不高，也可能是全表扫描或者没有走索引。把这条 SQL 复制到数据库客户端里，用 EXPLAIN 分析一下执行计划，看有没有索引可用，比凭空猜要快得多。
4.3 外部 HTTP 调用、日志与异常对照
微服务架构下，一个请求往往要调用多个下游服务，XRebel 的 HTTP 标签页可以展示本请求发起的每一次外部调用，包含目标 URL、HTTP 方法、响应状态、耗时等。
如果耗时分布显示“外部调用占大头”，先别急着怀疑自己代码有问题。点开这条外部调用，确认是不是调用了某个很慢的基础服务或第三方接口，再去下游系统排查。很多跨系统性能问题，靠“互相推诿”是解决不了的，但 XRebel 给出的调用链路和耗时数据，能让两边坐下来面对同一个事实。
Log 标签页可以把该请求执行期间产生的日志聚合到一起，配合日志框架的时间戳，能看到异常抛出前的一连串业务日志。遇到“接口返回异常但不知道怎么复现”的情况，切换到快速定位到具体请求的日志，比满服务器翻日志高效得多。
Exceptions 标签页会展示请求过程中抛出的异常堆栈，重点不是看堆栈本身，而是看它发生在整个请求链路的哪一段。比如一个慢查询之后跟着一个超时异常，那根因大概率还是慢查询把下游接口拖垮了。
5. 新 UI 下 XRebel 的常见故障排查清单
机器和人一样，用久了总会闹脾气。新 UI 环境下，XRebel 出问题时的表现五花八门，我按实际排查经验列一份顺序清单，照着走能省不少时间。
5.1 面板不出数据时按顺序检查
遇到 XRebel 面板始终是空白的情况，按下面顺序逐项排查，不要跳步，也不要一上来就重装插件。
第一步，确认应用是通过 IDEA 的 Run/Debug 启动的。命令行启动不会注入 XRebel agent，面板自然没有数据。
第二步，确认真的访问了应用接口。XRebel 只采集 HTTP 请求，启动应用后如果一直没发请求，面板就是空的，这不叫故障。
第三步，确认许可证状态。打开设置里的 XRebel 页面，看 License 是否有效。试用过期后插件不会主动弹窗打扰，但数据采集会悄悄停掉。
第四步，检查面板里的过滤条件。如果之前设置过 URL 过滤，可能把当前访问的路径过滤掉了。
第五步，看日志。Help -> Show Log in Explorer 打开 IDEA 日志目录，搜索 XRebel 关键字。绝大多数插件启动失败都会在这里留下直接线索。
5.2 插件版本与 IDEA 版本的兼容性
新 UI 从发布到逐步推广期间，插件适配一直是个大问题。IDEA 出了新版本，刚切换的新渲染框架可能会导致老插件图标无法渲染、工具窗口无法注册甚至直接 NoClassDefFoundError。
遇到这种情况，优先把 XRebel 升级到最新版，再考虑其它方案。插件市场通常会在兼容性上标注支持到哪个 IDEA 版本，如果你用的是预览版或抢先体验版，第三方插件跟不上是很正常的。真遇到了，要么回退到稳定版 IDEA，要么等插件发版，没有第三条捷径。
偶尔也会出现插件市场索引更新不及时的情况。你可以去官网手工下载兼容版本的插件 zip 包，从设置里的 Install Plugin from Disk 安装。不过手工安装时要留意插件包声明的兼容版本，不然装上后 IDE 甚至可能启动不了。
5.3 与 JRebel 等工具的协同设置
很多 Java 开发会同时安装 JRebel 和 XRebel，一个负责热部署，一个负责性能监控，理论上很配，实际上一不小心就会互相干扰。
JRebel 和 XRebel 都需要通过 Java agent 注入 JVM。如果 Run Configuration 里手动配置过 -javaagent 参数，两套 agent 的加载顺序和冲突覆盖面就可能出问题。最稳妥的做法是不要手动添加这些参数，让 IDE 的插件机制自己去管理，特别是用 JRebel 的导航中心和 XRebel 的许可证做统一配置时，保持默认是最省心的。
同时使用 Spring Boot DevTools 的场景也要留意。DevTools 本身会做类加载器重置，XRebel 采集时的调用栈信息容易被干扰。如果只是改个小功能，开 DevTools 无妨；一旦要精细分析某次请求的耗时，可以临时关掉 DevTools，再重启应用跑一次，数据会准确不少。
另外，Java 17 以上的版本对新 UI 和 XRebel 的 agent 支持都在持续调整，如果项目部署在较新的 JDK 上，建议把 XRebel 插件和 JDK 都保持在受支持的稳定版本，避免为了尝鲜新特性而牺牲工具链的稳定性。
我在实际使用中的一个小体会是：新 UI 刚推出时我也差点放弃 XRebel，直接切回旧版界面。后来花了半小时把工具窗口和快捷键重新调了一遍，发现新 UI 的紧凑布局其实更适合频繁切换工具窗口的开发场景，XRebel 面板和底部标签的整合效果也比旧版好。现在我在新 UI 下的习惯是：把 XRebel 用 Ctrl+Shift+X 快速唤起，固定到底部与 Run 窗口并排；调试单个接口时，先在请求列表里按耗时排序，找到最慢的请求，再跳到 SQL 和 HTTP 标签页看明细。最意外顺手的一个功能是请求过滤框可以直接写路径片段，输入某个 Controller 的路径前缀，列表里立刻只剩相关请求，排查单接口问题特别高效。如果你也刚迁到新 UI，先别急着回滚，把入口找回来，把快捷键绑上，习惯之后你会觉得这套组合比老版本还方便。
