Spring Tools 工程手册
普通 Java 能补全，Spring 能力仍可能完全失效
Spring Tools 出故障时最迷惑的一幕是：Maven 或 Gradle 能构建，Eclipse 里的 Java 跳转也正常，只有配置属性提示、bean 导航和 Boot Dashboard 消失。此时删除 workspace 往往没有用，因为多数 Spring 专用能力运行在独立 Java language server 进程里；它与 Eclipse 基座、JDT 和项目进程共享界面，却有自己的启动 JRE、日志与生命周期。
Eclipse 的 package、workspace、p2 与 Oomph 基线见 Eclipse IDE 工程手册。Spring Tools 的产品边界从安装组合开始，继续延伸到项目识别、语言服务器、Boot 应用运行调试、升级与退出；这些对象不能再被 workspace 通用教程顺带带过。
先定义最低能力，再评价“Spring 支持好不好”
Spring Tools 的验收样本应覆盖团队真实项目，而不是只创建一个空 Boot 应用。至少选择一个多 module 仓库、一个包含配置元数据和 profile 的服务，以及一个需要企业依赖源的项目。每个样本记录哪些能力必须存在：配置键补全、bean 导航、请求映射或 Spring symbol、Dashboard 启停、测试和调试。实验性视图可以观察，不进入默认放行条件。
这份能力清单还能避免故障沟通退化成“补全不好用”。配置提示缺失、语言服务器未启动、项目没有被识别、构建模型错误和索引仍在运行是不同故障。每一项都要对应日志、进程或项目模型证据，以及明确的恢复验证。多人共用基线时再记录首次索引时长、稳定内存和后台 CPU，以代表项目数据判断是否需要关闭实验能力，而不是凭一次卡顿下结论。
发行包和插件安装是两条不同维护路线
Spring Tools 官网提供可直接使用的 Spring Tools for Eclipse 发行包。它把受测试的 Eclipse 基座与 Spring Tools 组合在一起，适合希望减少兼容组合、集中归档一个产品制品的团队。下载后仍要核对系统与 CPU 架构，记录 Help -> About 中的 Eclipse 和 Spring feature 版本，并按发行包内法律文件检查许可证。
另一条路线是在受支持的 Eclipse 中通过 Marketplace 或 p2 安装。官方 Installation 文档给出 https://cdn.spring.io/spring-tools/release/update/latest/，也列出按 Eclipse 基座区分的专用 release site。latest 适合当前受支持基座，不能作为任何旧 Eclipse 的万能地址。基座、JDK、Spring Tools、JDT、m2e/Buildship 与其他插件共同组成兼容矩阵，选择插件路线就必须维护这张矩阵。
团队不要混用两条路线后仍把环境称作“STS 最新版”。基线至少记录：发行包或插件安装；Eclipse 产品/build；Spring Tools feature；update site；IDE JVM；批准的第三方插件。Spring Tool Suite 3 属于历史产品，迁移时按官方指南识别旧项目设置，不把旧 workspace 整体搬进当前产品。
p2 安装会执行插件代码。更新源从官方页复制，安装计划核对 feature ID、版本与 signer，不开启全局 unsigned content 放行。企业代理导致 PKIX 时修 Eclipse JVM 的 CA 信任；未知签名者则升级为供应链审查。浏览器能下载并不能替 p2 的 TLS 与 artifact 身份作证。
三套 Java 各自回答一个问题
Spring Tools 环境里至少要辨认三套 Java。Eclipse JVM 负责启动 IDE 与插件平台；Spring language server JRE 负责 Spring 专用分析进程；project JDK/toolchain 负责编译、测试和运行应用。三者的路径和版本都应能从运行证据中还原，而不是依赖设置页显示名称。
三者可以指向同一安装，但兼容边界不同。旧业务项目以 Java 8 编译，不代表当前 Spring language server 也能由 Java 8 启动；反过来，IDE 使用较新 JVM 也不会自动把 Maven compiler release 改成同一版本。
官方安装文档说明语言服务器会优先查看专用 *.ls.java.home，再看 JAVA_HOME 与 PATH。不要只看终端里的 java -version。发生能力缺失时，应从 Spring language server 日志、操作系统进程命令行和 Eclipse Error Log 找到实际可执行文件；项目侧则用 Wrapper 和 build scan/日志确认 toolchain。
配置专用 JRE 时只写本机路径，不提交到项目共享设置。团队文档保存“需要的 Java major 与来源”，不保存某位开发者的 C:\... 或 /Users/...。企业 CA 与代理也要分别进入 IDE JVM、语言服务器 JVM 和构建工具的信任链，不能假定其中一层成功就全链路成功。
先用 Wrapper 证明项目，再让 Spring Tools 加能力
选择一个已有 Spring Boot 仓库，不用 Initializr 新项目替代真实验证。先在仓库根执行正式 Wrapper：
./mvnw test
# 或
./gradlew testWindows 使用对应 .cmd 或 .bat。保存 Java 路径、Wrapper 版本、依赖源和退出码。CLI 失败时先修仓库、网络或凭证；Spring Tools 不应该通过私有 classpath 或全局仓库把错误藏起来。
在 Eclipse 中从聚合 pom.xml 或 Gradle 根导入同一工作树，不复制源码进 workspace。等待 JDT、m2e/Buildship 与 Spring language server 完成初始工作，再比较 Problems、Java Language Server/Spring 日志和构建控制台。项目 JDK、active profile、generated sources 与 Wrapper 必须和终端一致。
Spring Tools 识别项目后，Boot Dashboard 应显示可运行的 Boot 应用。没有显示时先确认它真的是受支持的 Maven/Gradle Java 项目，Spring Boot 依赖和 main class 在当前 module，并检查语言服务器是否健康；不要先给项目手工添加未知 nature 来制造图标。
运行验证必须穿过真实端口
从 Boot Dashboard 或受控 Launch Configuration 启动应用，观察控制台里的 Java、profile、端口与启动完成日志。项目有健康入口时，用回环地址进行最小验证：
curl --fail --max-time 5 http://127.0.0.1:8080/actuator/health这里的端口和路径只是无凭证示例。真实项目应调用仓库定义的本地验证入口；若没有 Actuator，不要为了 IDE 验收临时把敏感 endpoint 暴露给共享网络。预期结果是 HTTP 成功，进程身份与 Dashboard 一致，日志中没有端口回退或 profile 误选。
再在一个确定会执行的方法设置断点，通过 Debug 启动并触发请求。断点命中后检查源码行、线程和 class 来源，随后正常停止，确认 Java 进程与监听端口消失。关闭编辑器窗口不等于停止应用；团队的 Launch 入口必须明确 stop 语义。
共享 .launch 只存 project、main class、相对 working directory 和无秘密默认参数。数据库口令、云 token、生产 profile、内网地址和个人目录由本地环境或受控 secret 工具注入。Boot Dashboard 是操作入口，不是凭证存储和生产运维台。
故意破坏 language server JRE，比删 workspace 更有信息
在可回退环境中，把 Spring language server 指向一个不满足其运行要求的 JRE，同时保持项目 toolchain 不变。重新启动相关 language server。预期现象是 Wrapper 仍能测试、普通项目构建可能仍正常，而 Spring 配置补全、bean 导航或 Dashboard 出现明确失败；Error Log 和 language server 日志应给出进程启动或 class version 证据。
恢复正确 JRE 后重启语言服务器，同一 workspace 应重新获得 Spring 能力，Git 工作树保持干净。这个反例证明三套 Java 的边界真的被观测到。若团队只能通过删除 .metadata 恢复，就尚未找到根因。
另一个反例是用错误工作目录或错误 module 启动同名 main class。应用可能运行，却加载了不同配置文件或监听另一端口。验证时比较 PID、命令行、classpath、active profile 和 HTTP 响应，而不是只看 Dashboard 的绿色图标。
语言服务器、索引和构建模型不能混成“缓存”
Spring Tools 的专用分析、JDT 索引、m2e/Buildship model 与 Maven/Gradle dependency cache 是四类状态。Spring 标注失效但 Java 编译正常，先看 language server；依赖解析和 source folder 错误，先 refresh 构建模型；只有模型输入一致且日志指向派生状态时，才考虑重启或清理对应缓存。
Open Rewrite 等额外 reconciling 能力可能提高 CPU 或内存占用。遇到持续后台任务时先从 Progress、线程 dump、Error Log 和 Spring Tools 设置确认具体组件，再按官方 changelog 判断已知问题。随手提高全部 JVM 内存，可能只让故障更晚出现，也扩大每位开发者的资源成本。
语言服务器进程异常退出时收集：Spring Tools 与 Eclipse build、语言服务器 JRE、项目 JDK、日志、最后安装或更新的 feature、最小复现项目。若干净 workspace 同样失败，重点在产品组合；只有一个项目失败，继续比较构建模型和 Spring 版本；只有旧 workspace 失败，再调查工作区状态。
升级要一次只动一个兼容轴
Eclipse 基座、Spring Tools、IDE JVM、项目 JDK、Spring Boot、Maven/Gradle 与插件一起升级，失败后几乎无法归因。先保留旧发行包或旧 installation profile，用固定代表仓库测试新 Spring Tools：导入、CLI/IDE 测试、语言服务器能力、Dashboard 启动、HTTP、Debug、停止。通过后再扩大到其他项目。
插件安装路线可利用 p2 Installation History 回退，发行包路线可以并行保留旧目录；两者都不能替代项目代码与 workspace 的独立恢复。升级前保存未提交修改，不复制 .metadata 到新产品。必要时新建 workspace，用相同仓库与共享 Launch 对照。
卸载 Spring Tools 使用 Installed Software，重启 Eclipse 并确认 Spring feature、语言服务器进程和菜单都已移除。若整个发行包退役，确认 Git 工作树与 workspace 不在产品目录内，再删除独立安装；共享 p2 bundle pool 先查引用。账号、Marketplace 身份、代理凭证和企业证书按组织流程回收。
产品边界决定是否值得维护
Spring Tools 的价值在于 Spring Boot 项目理解、配置辅助、运行观察和语言服务器能力，而不是替 Maven、Gradle、JDK 或 Spring 本身定义项目。团队大量维护 Spring 应用、需要统一 Eclipse 入口时，这些能力有明确收益；如果仓库只偶尔包含一个简单 Boot 服务，维护独立产品组合的成本可能高于收益，应与 IntelliJ IDEA、VS Code 或纯命令行入口做代表项目验证。
选型记录要包含许可与再分发检查、Eclipse 基座、Spring Tools 安装路线、支持的 Java 组合、资源占用、插件供应链、升级 owner 与退出条件。插件与 language server 都能读取源码、环境并启动外部进程，权限不能按“编辑器功能”降级处理。
健康的退出机制是：移除 Spring Tools 后，仓库仍可用 Wrapper 构建、测试和启动；Spring 专用设置没有成为唯一事实；团队可回收插件、进程、账号与缓存。只有这条成立，Boot Dashboard 才是一个提效入口，而不是隐藏项目知识的第二套控制面。