PhpStorm 启动卡在 Splash 页面，大概率是 JVM 内存或 inotify 耗尽
先明确一个核心判断：PhpStorm 启动时停在那个带 JetBrains Logo 的启动画面（Splash），鼠标能动但 IDE 就是不继续加载，这可不是简单的“假死”。本质上，这是底层进程被阻塞了。这种情况特别爱在首次打开大型项目、刚升级完版本，或者系统监控文件的“名额”被占满时冒出来。麻烦的是，此时 IDE 连主界面都还没进去，你想点那个经典的“Invalidate Caches”都没地方下手，必须得从系统和 JVM 的层面去“动手术”。
检查并调大 max_user_watches（Linux 必做）
这恐怕是最容易被忽略的硬性瓶颈了。系统默认的 fs.inotify.max_user_watches=8192 这个值，在现代开发环境下简直不堪一击。一个典型的、包含了 node_modules 和 vendor 目录的 Lara vel 加 Vue 项目，轻松就能突破十万个文件监听数。一旦这个配额耗尽，IDE 就会卡在“扫描文件”的初始阶段，外在表现就是 Splash 画面死活不消失。
- 查看当前值：打开终端，运行
cat /proc/sys/fs/inotify/max_user_watches。 - 临时生效：执行
sudo sysctl -w fs.inotify.max_user_watches=524288。 - 永久生效：创建或编辑文件
/etc/sysctl.d/60-jetbrains.conf，写入fs.inotify.max_user_watches=524288，然后运行sudo sysctl -p使其生效。 - 关键一步：修改完成后，必须重启 PhpStorm 应用程序本身，仅仅重新打开项目是没用的。
验证 phpstorm64.vmoptions 是否配错堆内存
JVM 堆内存配置是个精细活，配小了不行，配大了反而更糟。堆内存设得太小（比如默认的 -Xmx750m），会导致垃圾回收过于频繁，在 Splash 阶段就可能卡住；设得太大（比如在 16GB 的机器上配 -Xmx8g），又可能触发系统交换内存（swap），导致响应速度急剧下降。核心原则是匹配物理内存，并留出合理余量。
- 8GB 物理内存：建议配置
-Xms1024m -Xmx2048m -XX:ReservedCodeCacheSize=512m -XX:+UseG1GC。 - 16GB 及以上物理内存：上限建议不超过
-Xmx4096m。同时，务必检查一下是否有全局的_JA VA_OPTIONS环境变量覆盖了你的设置（查看/etc/profile或~/.bashrc）。 - 配置文件路径：Linux 系统通常在
/opt/phpstorm/bin/phpstorm64.vmoptions；macOS 则在~/Library/Caches/JetBrains/PhpStorm。/phpstorm64.vmoptions - 修改保存后，必须彻底退出 PhpStorm（包括系统托盘或菜单栏的后台进程），然后重新双击启动。
禁用插件 + 清缓存（Splash 卡住后仍可操作）
如果 Splash 画面卡住了，但你还能在任务栏右键图标，或者通过 ps aux | grep phpstorm 命令看到进程，这说明 JVM 其实已经启动，只是 UI 线程被阻塞了。这种情况下，可以尝试强制清理缓存——完全不需要进入图形界面。
立即学习“PHP免费学习笔记（深入）”；
- 关闭所有 PhpStorm 进程：在 Linux/macOS 终端执行
pkill -f phpstorm；在 Windows 则使用任务管理器结束相关进程。 - 删除缓存目录：Linux 执行
rm -rf ~/.cache/JetBrains/PhpStorm*；macOS 执行rm -rf ~/Library/Caches/JetBrains/PhpStorm*。 - 删除配置目录（需谨慎）：执行
rm -rf ~/.config/JetBrains/PhpStorm*（Linux）或对应路径。这会重置所有插件和用户设置，非常适合解决因插件冲突导致的问题。 - 另外，如果刚刚升级了 PhpStorm 版本，优先检查并删除
~/.PhpStorm这样的旧版配置残留目录，它们常常是引发 Splash 卡死的元凶。
话说回来，真正顽固的 Splash 卡死问题，往往不是单一原因造成的。它更像是 inotify 句柄耗尽、JVM 内存配置不当、以及插件或缓存冲突三者叠加的结果。单独调整内存或者删除缓存可能收效甚微，需要多管齐下。尤其要注意，很多用户修改了 max_user_watches 的配置文件，却忘了执行 sysctl -p 来激活它，这一步可千万别漏了。
