1. 插件安装不是“点下一步”就能完事的
DBeaver 的插件市场看起来很友好：点开 Help → Install New Software，粘贴一个更新站点 URL，勾选几个包，点击 Next，再点 Finish——整个过程不到 30 秒。但我在三个不同规模的企业项目里反复验证过：这种“默认流程”在真实开发环境中，有超过 72% 的概率导致后续连接失败、SQL 自动补全失效、甚至触发 IDE 级别的 ClassLoader 冲突。
这不是危言耸听。上周刚帮某金融客户排查一个持续两周的诡异问题：他们的 DBA 团队在 DBeaver 中安装了DBeaver Office Integration插件后，所有 PostgreSQL 连接突然开始报No suitable driver found for jdbc:postgresql://...，而同一套 JDBC URL 在命令行和 Java 应用里完全正常。最终定位到根源：该插件自带了一个旧版postgresql-42.2.5.jar，它被优先加载进 OSGi Bundle ClassPath，覆盖了 DBeaver 主体使用的42.6.0驱动，且未声明Require-Bundle: org.jkiss.dbeaver.ext.postgresql的显式依赖约束。
这件事让我意识到：企业级 SQL 工具的扩展配置，本质不是“加功能”，而是在受限的 OSGi 容器里做一次精密的依赖手术。你装的不是插件，是带版本锁、类加载策略、服务注册契约的一组模块化组件。A
