启动DBeaver后，点击Help → About DBeaver，第一行显示完整版本号（如26.2.0.202608151234），末尾数字为精确到分钟的构建时间戳；日志文件位于用户工作区路径下的.metadata/.log，诊断包可通过Help → Diagnostic Report导出。
怎么看DBeaver当前版本和构建时间
启动DBeaver后，菜单栏点 Help → About DBeaver，弹窗里第一行就是完整版本号（如 26.2.0.202608151234），末尾那串数字是构建时间戳，精确到分钟。这个信息必须写进反馈里——很多问题只在特定构建中复现，比如 26.2.0.202608151234 修复了 CSV 导入时 quoteChar 误判 BOM 的 bug，但 26.2.0.202607220911 还存在。
日志文件在哪？不是“log”目录里的那个
DBeaver 实际运行时的日志不存放在安装目录的 log/ 下，而是写在用户工作区（workspace）里。默认路径是：
C:\Users\[用户名]\AppData\Roaming\DBeaverData\workspace6\.metadata\.log
Linux/macOS 用户注意：AppData 是 Windows 路径，对应 macOS 是 ~/Library/DBeaverData/workspace6/.metadata/.log，Linux 是 ~/.local/share/DBeaverData/workspace6/.metadata/.log。这个 .log 文件是纯文本，最新错误总在末尾，用记事本或 VS Code 打开就能直接 Ctrl+F 搜 ERROR 或 Exception。
- 别删它，也别用记事本另存为 UTF-8 —— 记事本加的 BOM 头会让 DBeaver 下次启动失败，报
Argument not valid: content is not allowed in prolog. - 如果 DBeaver 启动失败，连 About 都打不开，就直接去上面路径找
.log，里面通常有 JVM 初始化失败、OSGI Bundle 加载中断等关键线索
导出完整诊断包：比截图有用十倍
遇到复杂问题（比如导入卡住、同步无响应、驱动下载失败），光看单个日志不够。DBeaver 内置了诊断包生成器：
菜单栏点 Help → Diagnostic Report → Export Diagnostic Report，它会打包以下内容：
-
.log文件本身 - 当前 workspace 的配置快照（
org.jkiss.dbeaver.core.prefs等） - 已加载插件列表及版本（含 JDBC 驱动 jar 名称和路径）
- 系统环境变量片段（PATH、JAVA_HOME 是否被识别）
这个 ZIP 包体积一般 2–5MB，比你手动截图十张报错窗口、再拼接三段配置更可靠。GitHub 提交 issue 时，官方维护者第一句往往就是：“请附 diagnostic report”。
遇到 “Maven artifact ‘org.p’ 无法获取” 怎么抓上下文日志
这个报错表面是驱动下载失败，但根因可能是网络代理、仓库镜像或本地 Maven 缓存损坏。光截图错误弹窗没用，得定位到具体哪一行失败：
- 打开
.log文件，搜Failed to resolve artifact org.postgresql:postgresql - 往前翻 20 行，找是否出现
Using repository: https://repo1.maven.org/maven2/—— 如果是公司内网，这地址肯定不通 - 再往上找
Proxy configuration相关行，确认 DBeaver 是否读取到了系统代理设置（有时 IE 代理开了，但 DBeaver 没继承） - 若看到
Could not transfer artifact ... No route to host，基本可断定是防火墙或 DNS 问题，不是 DBeaver 本身缺陷
真正容易被忽略的是：Diagnostic Report 里包含 m2/repository/ 的缓存状态摘要，能一眼看出驱动 jar 是否已部分下载但校验失败——这种半残状态，重试十次也没用，必须手动清空对应子目录。
