IntelliJ IDEA 2026.1.4 已发布。这不是一个堆满新功能的大版本，而是一次更贴近日常开发摩擦点的修补更新：Git 活动分支显示、Docker Compose 中 PHP 解释器创建、以及 WSL 环境下 Gradle 同步状态，都得到修复。
这次修复的重点不在“炫”，在少打断
这类 IDE 小版本最有价值的地方，往往不是新增一个菜单，而是让已有工作流少出错。
本次更新提到的几个问题都属于“开发者很容易碰到，但排查成本不低”的类型：
- 当前 Git 活动分支现在能够正确更新。
- Docker Compose 文件使用
pull_policy时，不再阻塞 PHP 解释器创建。 - 在 WSL 上运行 Gradle 9.5.0 时，IDE 不再把成功的 Gradle 同步错误标记为失败或异常状态。
这些点分布在版本控制、容器化开发和 JVM 构建系统三个区域。它们不一定影响代码本身，但会影响开发者对 IDE 状态的信任。一旦 IDE 的分支、解释器或同步状态显示不准，团队成员就会开始怀疑环境，而不是专注于代码。
Git 活动分支：状态显示必须可信
Git 分支状态是 IDE 里最基础的上下文之一。尤其在多分支并行开发、频繁切换 feature branch、hotfix branch 的项目里，IDE 顶部或状态栏显示的当前分支如果没有及时更新，就可能带来误判。
可以这样实践，在升级前后用一个小仓库快速确认 IDE 与命令行看到的是同一个分支：
mkdir idea-branch-check
cd idea-branch-check
git init
git commit --allow-empty -m "init"
git switch -c feature/idea-2026-1-4-check
git branch --show-current
运行后，命令行应输出：
feature/idea-2026-1-4-check
接着用 IntelliJ IDEA 打开这个目录，查看 IDE 中显示的当前分支。再执行一次切换：
git switch -c fix/status-refresh-check
git branch --show-current
如果 IDE 已升级到 2026.1.4，可以重点观察分支显示是否及时变为 fix/status-refresh-check。这个检查很小，但能帮助团队确认本地 IDE 状态和 Git 实际状态一致。
Docker Compose 的 pull_policy 不该挡住 PHP 解释器
本次更新还修复了一个和 Docker Compose、PHP 解释器有关的问题：当 Compose 文件里使用 pull_policy 时，IDE 现在可以正常创建 PHP 解释器。
pull_policy 在容器化开发里很常见，用来表达镜像拉取策略。例如团队希望开发环境尽量使用远端最新镜像，或者避免每次都重新拉取镜像。可以参考下面这个最小 Compose 文件进行环境验证：
services:
php:
image: php:8.3-cli
pull_policy: if_not_present
working_dir: /app
volumes:
- .:/app
command: php -v
保存为 compose.yaml 后，可以先在命令行确认 Docker Compose 本身能正常解析：
docker compose run --rm php
如果输出 PHP 版本信息，说明 Compose 文件本身可用。之后在 IntelliJ IDEA 中基于这个 Compose 服务配置 PHP CLI Interpreter。对于依赖容器解释器的 PHP 项目，这个修复能减少“命令行可用、IDE 配不起来”的割裂感。
需要注意的是，pull_policy 的具体行为仍取决于 Docker Compose 版本和镜像策略。IDE 修复的是解释器创建流程，不等于替代 Docker 侧的镜像拉取、认证和网络配置。
WSL + Gradle 9.5.0：同步成功就应该显示成功
另一个值得关注的修复发生在 WSL 场景：在 WSL 上运行 Gradle 9.5.0 时，IDE 不再错误地把成功的 Gradle 同步标记为异常状态。
对使用 Windows + WSL 做 JVM 开发的团队来说，Gradle 同步状态非常关键。IDE 需要根据同步结果建立 classpath、识别模块、生成索引。如果同步实际上成功，但 UI 标记为失败，开发者很容易重复刷新、清缓存，甚至怀疑 Gradle 脚本写错。
可以这样准备一个最小 Gradle 项目，用于升级后验证：
mkdir idea-wsl-gradle-check
cd idea-wsl-gradle-check
cat > settings.gradle <<'EOF'
pluginManagement {
repositories {
gradlePluginPortal()
mavenCentral()
}
}
dependencyResolutionManagement {
repositoriesMode.set(RepositoriesMode.FAIL_ON_PROJECT_REPOS)
repositories {
mavenCentral()
}
}
rootProject.name = 'idea-wsl-gradle-check'
EOF
cat > build.gradle <<'EOF'
plugins {
id 'java'
}
group = 'dev.check'
version = '1.0.0'
java {
toolchain {
languageVersion = JavaLanguageVersion.of(21)
}
}
EOF
gradle --version
gradle help
运行前需要把 gradle 换成你项目实际使用的 Gradle 入口，例如 ./gradlew。如果团队已经固定 Gradle Wrapper，建议始终使用：
./gradlew --version
./gradlew help
在 WSL 中命令行执行成功后，再用 IntelliJ IDEA 打开项目并触发 Gradle sync。2026.1.4 的重点是：当同步已经成功时，IDE 不应再错误展示失败状态。
升级建议：先覆盖高频项目，再推给全队
这次 2026.1.4 更像是“减少误报和环境摩擦”的维护版本。建议按以下方式采用：
- 如果你经常在 IDE 内切换 Git 分支，值得尽快升级。
- 如果 PHP 项目依赖 Docker Compose interpreter，并且 Compose 文件使用了
pull_policy，建议优先验证。 - 如果团队使用 Windows + WSL + Gradle 9.5.0，建议用一个真实项目跑一次 Gradle sync，确认状态显示正常。
- 升级前保留当前 IDE 设置同步或导出配置，尤其是使用自定义 SDK、远程解释器和复杂 Run Configuration 的团队。
小版本更新的判断标准很直接：它是否让开发者少做无意义排查。IntelliJ IDEA 2026.1.4 修复的几个点都落在这个范围内，适合在本地验证通过后纳入团队推荐版本。