企业官网建设流程全解析

1. 数据库客户端我用过一圈，最后还是留在 DBeaver

凌晨一点被叫起来查一张订单表的状态，生产库只开了跳板机权限，本地没有图形客户端，只能靠命令行mysql -h ... -e "select ..."一行行扒——那次之后我就痛下决心，把本地常驻的数据库管理工具彻底固定下来。DBeaver 就是那之后一直留在我任务栏里的那个。它免费、跨平台、能同时接 MySQL、PostgreSQL、SQLite、Oracle、SQL Server 这些主流数据库，装一次就能覆盖我日常 90% 的活儿：连库、跑 SQL、看表结构、导数据、生成 ER 图和 DDL 脚本。

这篇内容我不打算写成那种"点下一步、点下一步"的流水账。我按自己从零装到顺手用的真实顺序来写：先讲清楚版本流派和 JDK 依赖这种装之前就必须定的东西，再上三个系统的安装实操，然后是连库时最容易踩的几个参数坑（时区、公钥、字符集），接着是把编辑器调顺手的生产力配置，最后是我这几年攒下来的排错清单。数据库管理工具这个品类里，付费的、免费的、Web 版的我都用过，DBeaver 不是最快的、也不是最好看的，但它是我唯一敢推荐给新人的——因为它的错误提示足够具体，新人能自己看懂。

关键词先摆在这儿方便你对号入座：DBeaver、DBeaver 安装、DBeaver 使用教程、DBeaver 下载、数据库管理工具、DBeaver 怎么创建数据库、DBeaver 字体大小设置。如果你是刚学 SQL 的学生、转行做后端的初学者、做数据核对的产品运营，或者需要同时维护好几种数据库的运维，这篇基本能让你少走一大段弯路。

1.1 免费工具的边界在哪里

先把预期说清楚，免得你装完觉得"怎么和想象的不一样"。DBeaver 有两个大分支：Community（社区版）和Ultimate（商业版）。社区版是免费开源的，遵循 Apache 2.0 许可，关系型数据库这一块功能给得非常足——SQL 编辑器、结果集网格、ER 图、数据导入导出、DDL 生成、数据传输，全都在。Ultimate 是商业授权，主要多了 NoSQL 支持（MongoDB、Cassandra、Redis 这类）、部分高级导出格式、以及一些企业级集成能力。

也就是说：只要你打交道的对象是 MySQL、PostgreSQL、MariaDB、SQLite、SQL Server、Oracle 这些关系型库，社区版完全够用，不需要花钱。我见过有人为了导出 Excel 去买了授权，结果发现自己其实用 CSV 再转一下就完事了。商业版有试用期，想体验可以试，但别把它当必需项。至于网上那些来路不明的"授权文件"，我的建议很直接：别碰，来源不明的东西塞进一个能连生产库的客户端里，风险和你自己承担不起的后果成正比。

社区版还有一个被低估的优点：它是纯 Java 写的，配置、驱动、工作区全都在本地文件里，可以整体打包拷走。换电脑的时候，我把配置目录一拷，几十个连接配置全回来了，连驱动都带着，这一点比很多"账号绑云端"的工具舒服。

1.2 它到底适合谁：三类人的真实用法差异

同一款工具，不同角色用出来的姿势差别特别大，我把常见的三类人分开说，你可以直接跳到自己那一段。

写业务的后端开发：核心诉求是"改表结构 + 调试 SQL"。他们最常用的是 SQL 编辑器里的 Ctrl+Enter 单条执行、结果集里的行内编辑、以及右键表 → Generate SQL → DDL。我建议这类人一定要开手动提交（Manual Commit），不然一次手滑 update 全表就直接生效了。

做数据分析/数据核对的同学：诉求是"查得快 + 导得出来"。他们会重度依赖结果集右上角的过滤器、排序，以及 Data Transfer 导出 CSV。对他们来说关键是别把几百万行一次性拉进界面，否则内存直接爆。

运维和 DBA：诉求是"多库同时管 + 权限要收紧"。他们需要的是连接分组、颜色标记（生产库标红）、只读连接、以及会话管理（看当前连接、正在执行的 SQL）。我会在第 7 章专门讲怎么用配置把"误操作"这件事的概率压下去。

三类人共同的一点是：都要先把它装起来，而且都要面对同一个前置问题——Java 环境。

2. 装之前先定两件事：版本流派和 JDK 依赖

新手最容易在这里翻车。很多人下载完双击运行，弹出一个"Java 未找到"或者干脆一闪而过，就以为是自己电脑有问题。其实不是，是你下的是需要自备 JDK 的那个版本。所以装之前，先花两分钟把下面两件事定了，后面能省掉半小时。

2.1 Community 与 Ultimate 的功能分水岭

我用一张表把差异说清楚，方便你做决定。注意版本迭代很快，具体功能以你下载那天的官方说明为准，这里给的是稳定不变的大方向。

结论很简单：第一次装，直接下 Community，别犹豫。等你真的遇上"必须连 MongoDB 又要用同一个客户端"这种需求，再考虑升级也不迟。

2.2 免安装版、安装包版、包管理器版怎么选

同一个 Community 版，官方一般会提供好几种分发形态。选错了不一定报错，但会给你后面的维护添麻烦。

• 安装包版（Windows 的 .exe/.msi、macOS 的 .dmg）：通常自带 Java 运行时，双击装完就能用。新人首选，最省事。
• 免安装版（zip / tar.gz）：体积小、绿色、可以塞进 U 盘或者共享盘。但它不带 JDK，必须自己先装好 Java 并配好JAVA_HOME。
• 包管理器版：Windows 用 Winget，macOS 用 Homebrew，Linux 用 Snap 或发行版仓库。好处是升级一条命令搞定，适合把开发机当长期阵地的人。

提示：如果你不确定自己下的是哪种，看体积。带 JRE 的安装包通常两三百 MB 起，纯 zip 包往往只有几十到一百多 MB。体积明显偏小的那个，就是要自备 Java 的。

关于 Java 版本：较新的 DBeaver 主线版本一般要求JDK 17 或更高，个别更新版本会往上提。你要是准备走免安装版路线，最稳的做法是先装一个 LTS 版本的 JDK（17 或 21），配好环境变量，再去解压 DBeaver。装完之后在命令行敲java -version，能打出版本号，说明环境没问题。

3. Windows / macOS / Linux 三平台安装实操

这一章是纯操作，但每一步我都会说清楚为什么这么做，因为这些细节直接决定了你后面会不会遇到"启动慢""界面糊""连不上库"。

3.1 Windows：安装包 vs zip 解压版

走安装包（推荐）：去官网下载页选 Community 的 Windows 安装包，双击，一路默认。唯一需要留意的是安装路径不要放在中文目录下，也不建议放桌面。带中文或者空格的路径，偶尔会让工作区文件和日志出问题，这种坑排查起来极其难受，不如一开始就避开。建议放C:\Tools\dbeaver或者直接用默认的 Program Files。

走 zip 解压版：解压到一个固定目录后，先确认 Java。如果你已经装了 JDK 17，但双击dbeaver.exe还是提示找不到 JVM，有两种解法：

1. 设置系统环境变量JAVA_HOME指向 JDK 目录，Path里加上%JAVA_HOME%\bin。
2. 在 DBeaver 安装目录下新建或编辑dbeaver.ini，把 JVM 路径写死。

第二种方式更可靠，因为它是针对这个客户端生效的，不会影响你机器上其他 Java 项目。dbeaver.ini的样子大概是这样：

-vm C:\Program Files\Java\jdk-17\bin\javaw.exe -startup plugins/org.eclipse.equinox.launcher_1.6.400.v20210924-0641.jar --launcher.library plugins/org.eclipse.equinox.launcher.win32.win32.x86_64_1.2.400.v20211117-0650 -vmargs -Xmx2048m

注意-vm必须写在-vmargs前面，顺序错了不生效，这是 Eclipse 系启动器沿袭下来的老规矩，我第一次配的时候就在这儿卡了半天。

3.2 macOS：dmg 与 Homebrew

图形化路线就是下载.dmg，拖进"应用程序"，首次打开会提示"来自身份不明的开发者"，去"系统设置 → 隐私与安全性"里放行一次即可。

命令行路线我更推荐给长期使用者：

brew install --cask dbeaver-community

这条命令的好处是版本更新极其省心，以后brew upgrade就跟着升了。需要注意一点：macOS 上的配置目录在~/Library/DBeaverData，和 Windows 完全不同，备份的时候别找错地方。

另外 Mac 用户常遇到的一个问题是"界面字体发虚"。这通常和 Java 对高分屏的缩放处理有关，解决办法在启动参数里加-Dswt.autoScale=200（具体倍数看你的屏幕，可以试 150/200），加在dbeaver.ini（或者应用程序包内的配置文件）里。

3.3 Linux：tar.gz 与发行版仓库

Linux 上最省事的当然是仓库：

sudo snap install dbeaver-ce

如果你的环境没有 Snap，那就用 tar.gz：

# 解压到 /opt sudo tar -xzf dbeaver-ce-*-linux.gtk.x86_64.tar.gz -C /opt # 建个软链接方便命令行启动 sudo ln -s /opt/dbeaver/dbeaver /usr/local/bin/dbeaver

这么做的原因是：直接解压到/opt便于集中管理，软链到/usr/local/bin之后你在任何目录敲dbeaver都能起来。如果你还想让它出现在应用菜单里，就得自己写一份.desktop文件丢到~/.local/share/applications/，这个属于锦上添花，不影响使用。

Linux 下有个别发行版的 GTK 版本比较老，会出现控件错位、下拉框弹不出来的情况。遇上这种，优先把系统的 GTK 相关库更新一下，比折腾 DBeaver 本身有效。

3.4 首次启动必须确认的三个设置

第一次打开，DBeaver 会问你工作区目录。这个目录请选一个固定的、路径里没有中文和空格的文件夹。它会放你的连接配置、查询历史、驱动缓存。以后想备份或者迁移，直接拷这个目录就行。

然后是内存参数。默认的-Xmx往往偏保守，你查一张几百万行的表就可能卡住或者直接 OutOfMemory。我一般直接提到 2048m 或 4096m，改的就是前面dbeaver.ini里的那行-Xmx2048m。机器内存 16G 以上，给 4096m 完全没压力。

第三个是编码。国内环境里，老项目用 GBK 甚至 GB2312 的还不少。这个不用在全局改，在具体连接的驱动属性里设更精准，后面第 4 章会讲。

4. 建第一个连接：MySQL、PostgreSQL、SQLite 的驱动与连接串细节

到这一步你已经能打开主界面了。接下来就是所有人都会问的第一个问题：DBeaver 怎么创建数据库？这里要先纠正一个概念——DBeaver 本身不是一个数据库，它只是客户端。你得先有一个数据库服务在跑，然后在 DBeaver 里"新建连接"去接上它。接上之后，才是"在连接里右键新建数据库"这件事。

4.1 MySQL 8.x 连接为什么老报时区错

点左上角那个插头图标（New Database Connection），选 MySQL，填主机、端口（默认 3306）、用户名密码、数据库名。点"Test Connection"之前，先去Driver properties标签页加上两个参数，能省掉 80% 的初学者报错：

那个时区报错特别典型：MySQL 8 默认驱动版本较新，如果服务端的time_zone是个它不认识的字符串（比如中国标准时间），驱动就直接抛异常。allowPublicKeyRetrieval=true则是 MySQL 8 默认的caching_sha2_password认证方式导致的，客户端需要在首次连接时取公钥。这两个参数在本地开发环境加上是安全的，生产环境请按你们的安全规范来，尤其是 SSL 那一项不要随手关。

还有一个细节：驱动文件是第一次连接时才下载的。如果你的网络环境受限，下载可能会失败或者卡住。这时可以先点 "Driver properties" 下面那个 "Download/Update" 按钮手动触发，看报错信息再判断。如果实在下不来，可以从 Maven 仓库手动拿到对应版本的 JDBC 驱动 jar，然后在驱动设置里指定本地文件路径。

4.2 PostgreSQL 的 schema 显示与连接参数

PostgreSQL 的默认端口是 5432，默认超级用户postgres，默认库也叫postgres。这几项填完一般就能连上。但新手最常见的困惑是："我连上了，为什么看不到我建的表？"

原因是 PG 的层级比 MySQL 多一层：库（database）→ 模式（schema）→ 表。默认只显示public模式，如果你建表时没指定，表就在public里；如果建在别的 schema 下，就得在连接的设置里勾上Show all databases / 显示所有模式之类的选项。另外 PG 默认连的是一个具体数据库，想切库得另建连接或者在导航器里展开。

顺带说一句，PG 的大小写规则是个大坑：不加引号的标识符会被折叠成小写，你写CREATE TABLE OrderItem(...)，实际建出来的表叫orderitem。所以要么全小写加下划线（order_item，我强烈推荐），要么老老实实加双引号并承受以后每次都要加引号的痛苦。这跟 DBeaver 没关系，是 PG 本身的行为，但在客户端里看到的表名会让人一脸懵。

4.3 SQLite：为什么我建议单独建一个连接

SQLite 是文件型数据库，一个.db或.sqlite文件就是一个库。在 DBeaver 里新建 SQLite 连接，让你选文件路径，选完就能用。

我建议给每个 SQLite 文件单独建一个连接，并且给连接起一个能看懂的名字（比如app-local-test.db），而不是把所有 sqlite 文件都挂在一个连接下。原因有两个：一是 SQLite 的并发写入很弱，多个连接同时写同一个文件容易database is locked；二是文件型库经常随手放，命名清晰能防止你误操作到别的项目的库。

如果你只是临时想打开一个.db文件看看内容，DBeaver 完全够用了，不用再装别的轻量工具。真要说轻量，SQLiteStudio 和 DB Browser for SQLite 也确实很轻，但既然 DBeaver 已经装了，多装一个反而占地方。

5. 把 DBeaver 调到顺手：字体、补全、格式化与主题

装完能连库只是及格线，真正决定你每天用着爽不爽的，是接下来这十几项配置。我按"最值得改"的顺序排。

5.1 字体大小与高 DPI 缩放

DBeaver 字体大小设置是被问得最多的一个问题，因为它分了两个地方：

• 界面字体：Window → Preferences → User Interface → Appearance → Colors and Fonts，里面有一项 "Main Font"，改这个能影响菜单、导航树、对话框。
• SQL 编辑器字体：Window → Preferences → Editors → SQL Editor → Font，改这个只影响写 SQL 的区域。

我自己的组合是：界面 12pt，编辑器 14pt，等宽字体（Consolas / JetBrains Mono / Menlo 都行）。SQL 编辑器用等宽字体不是为了好看，是为了对齐——多行SELECT的字段能整齐地排成一列，肉眼扫起来快很多。

高分屏（2K/4K）下如果界面元素特别小或者特别糊，两个办法：一是前面说过的-Dswt.autoScale，二是 Windows 上右键 exe → 属性 → 兼容性 → 更改高 DPI 设置 → 勾选"替代高 DPI 缩放行为"。两者选一个就行，同时改容易叠加出错。

结果集网格的字体是另一个独立的设置项（Data Editor 相关），很多人只改了编辑器字体，发现查出来的数据还是小字，就是漏了这一处。顺便，网格的行高也可以调，默认偏紧凑，长时间看数据容易串行，我一般加两三个像素。

5.2 自动补全和模板

DBeaver 的补全默认是开着的，Ctrl+Space手动触发。它有个挺聪明的行为：会读当前连接的元数据，所以你输入表名前几个字母，它会列出来，并且把字段也带出来。这个功能在表多、字段名长的时候能省下大量敲键盘的力气。

需要注意的是，补全依赖元数据缓存。你刚在别处新建了一张表，DBeaver 里看不到，右键连接 →Refresh刷新一下（快捷键F5）就出来了。

模板（Templates）这个功能知道的人不多但很实用：可以把常用的查询骨架存成模板，比如"按时间范围分页查询"、"查看表占用空间"，以后用缩写就能展开。我自己存了几个，主要是各种统计 SQL，省得每次都翻笔记。

5.3 SQL 格式化器的坑

Ctrl+Shift+F是格式化 SQL 的快捷键，但它默认的格式风格比较"奔放"——会把一些关键字换行。建议去Preferences → Editors → SQL Editor → Formatting里把这几项定一下：

• Keyword case：统一成大写（个人偏好，团队里统一更重要）。
• Indent：缩进宽度，我习惯 2 或者 4。
• Line width：一行最大宽度，默认值偏窄，容易把长字段列表拆得很难看。

还有一个容易忽略的点：格式化会改动你光标所在的位置，如果你在改一段很长的 SQL 中间按了格式化，光标可能会跳到别的地方。习惯做法是先全选整段再格式化，改完再定位。

另外 DBeaver 支持多条 SQL 一起执行（Alt+X执行整个脚本），也支持只执行光标所在的那一条（Ctrl+Enter）。这两个键一定要分清楚，尤其在脚本里有DELETE或者UPDATE的时候。我自己习惯是：写的时候用Ctrl+Enter一条条试，确认没问题再用Alt+X跑整段。

6. 日常高频操作：建库建表、数据导入导出与数据传输

前面都是准备工作，这一章才是每天真正在用的部分。

6.1 可视化建表 vs 手写 DDL

DBeaver 允许你在导航器里右键 → New Table，用图形界面填字段名、类型、长度、默认值、注释，然后它会生成CREATE TABLE语句执行。做原型、临时表，这个方式很快；但正式的表结构，我建议还是手写 DDL 再执行。

原因有三个。第一，可视化建的字段类型选项受限于驱动映射，比如 MySQL 的datetime(3)这种带精度的写法，界面上不一定表达得出来。第二，注释、索引、外键约束这些在可视化界面里一页页翻着配，比手写慢得多。第三，也是最重要的——DDL 是需要进版本库的，你手写完存成.sql文件提交到 Git 里，别人能 review、能追溯；界面点出来的东西进不了代码库，三个月后没人知道表是谁怎么建的。

用法上我给一个折中方案：用可视化界面把字段大致列出来，然后切到 DDL 标签页，把生成的 SQL 复制出来改。这样既有界面辅助，又留下了可版本化的脚本。

6.2 导出数据的几种格式与实际差异

右键任意表或结果集 →Export Data，会走一个向导。常见格式和适用场景：

导出向导里有几个选项特别关键：Header（是否带表头）、Encoding（编码）、每一批提交的行数、是否包含列名引号。中文乱码十有八九是编码选错了，导出给 Excel 看的话，你可以选带 BOM 的 UTF-8，也可以直接选 GBK，看对方用什么软件打开。

至于 Excel（.xlsx）导出，不同版本的能力不太一样，我的常用套路是先导 CSV，再用脚本或表格软件转——这样链路透明，出问题也知道哪一步错了。

6.3 数据传输：跨库搬数据

Data Transfer是 DBeaver 里我最喜欢的功能之一。比如你要把测试库的某几张表搬到本地库，或者把 MySQL 的一张表迁到 PostgreSQL，直接右键源表 →Data Transfer→ 选目标连接和目标表，它会自动做字段映射，还能只搬结构、只搬数据、或者两者都搬。

有个细节务必注意：它默认是"追加 / 覆盖"的行为需要你确认。目标表如果已经存在，选错模式会直接把数据追进去造成重复。我在测试环境就干过一次这事，后来养成了习惯——搬之前先确认目标表是空的，或者干脆让工具新建表。

另外跨数据库类型搬数据时，数据类型需要人工核对。MySQL 的tinyint(1)搬到 PG 该用什么？unsigned怎么办？时间类型带不带时区？这些工具不会替你判断，映射完之后建议先在测试库跑一遍再上正式库。

7. 我踩过的坑：时区、乱码、驱动、大结果集与权限

这一章是我认为整篇最值钱的部分，因为下面每一条都是真金白银的时间换来的。

7.1 驱动下载失败与手动指定驱动

表现是：Test Connection 一直转圈，或者报Could not download driver。DBeaver 的驱动是从 Maven 仓库拉的，网络不通就会卡在这儿。排查顺序建议这样走：

1. 打开Preferences → Connections → Drivers，找到对应数据库的驱动，看它配置的仓库地址对不对。
2. 看驱动下的 jar 列表，是不是有"未下载"的标记，点 Download 手动触发。
3. 如果确实下不来，从 Maven 仓库手动下载对应版本的 jar（比如 MySQL 的mysql-connector-j），然后在驱动设置里Add File指定本地 jar，并把原来的远程引用删掉。

提示：驱动版本和服务端版本是会对不上的。MySQL 8 服务端配太老的 5.x 驱动，经常会冒出奇怪的认证错误。尽量让驱动版本和数据库大版本匹配，这是排错时的第一直觉。

7.2 中文乱码和关键字大小写

乱码这件事，要先分清是哪一层的乱码：

• 表里存的数据本身就是乱码：这是写入时编码就错了，客户端改不了，得从数据源头修。
• DBeaver 里显示乱码但程序读出来正常：客户端的连接编码设错了，去 Driver properties 里加characterEncoding=UTF-8，或者检查连接设置里的 Charset 项。
• 导出的 CSV 在 Excel 里乱码：导出编码问题，见 6.2。

关键字大小写则是另一个方向的坑。MySQL 在 Linux 上表名默认区分大小写（取决于lower_case_table_names配置），Windows 上默认不区分。所以在你 Mac 上跑得好好的 SQL，部署到 Linux 服务器上可能就报"表不存在"。这类问题的最佳解法是统一用小写加下划线的命名规范，从根上绕开。

7.3 大结果集把界面卡死怎么办

SELECT * FROM 一张两千万行的表直接按 Ctrl+Enter，运气好是等三分钟，运气不好是界面假死然后 OutOfMemory。这不是 DBeaver 菜，是任何客户端都扛不住这个量级。

我的处理原则是三条：

• 先加LIMIT。哪怕你最后真要看全量，也先用LIMIT 1000确认 SQL 逻辑对不对、执行计划好不好。DBeaver 的结果集设置里也有"最大行数"限制，可以设成默认只取 1000 行，防止手滑。
• 看数据用聚合，不要拉明细。你真正需要的是"有多少条、分布在哪些维度"，GROUP BY+COUNT就够了，不需要把明细拉出来。
• 真要全量，走导出而不是走界面。用 Export Data 直接导文件，让工具流式处理，不要塞进网格。

还有一个容易被忽略的点：连接池/会话是会被占住的。界面卡死的时候，数据库那边可能还挂着一个正在跑的查询。养成习惯，遇到卡住先看能否 Kill 会话，或者去数据库端查SHOW PROCESSLIST（MySQL）/pg_stat_activity（PG），别让一个疏忽的查询在凌晨三点拖垮业务库。

7.4 只读账号与误删数据的防护

这一条是我最想强调的。给生产环境的连接加"只读"标记，操作路径是：右键连接 → Edit Connection → 勾选 Read-only connection。勾上之后，DBeaver 会阻止你在界面上的写操作（包括网格里的行内编辑）。

再加一层：连接颜色标记。在连接设置里可以给连接指定颜色，我把生产库设成醒目的红色，开发库绿色。导航树和编辑器标签页都会带上这个颜色，视觉上就能一眼区分。这个功能看着不起眼，但它拦下过我至少两次"以为在测试库"的误操作。

第三层才是数据库侧的权限控制——用只读账号连生产库，从根上不给写权限。客户端能做的是提醒，不是保障，真正的安全边界永远在服务端。这个道理我在吃过一次亏之后才彻底明白。

8. 再往上走一步：ER 图、生成脚本、AI 助手与团队协作

基础功能用熟之后，还有几件事能让你的效率再上一个台阶。

8.1 ER 图与 DDL 导出

选中一个库或者几个表，右键 →View Diagram，DBeaver 会画出实体关系图，主外键关系会自动连上线。做新项目的表设计评审、给别人讲老系统结构，这张图比自己画的好用得多。图可以导出成图片，贴到文档里。

生成 DDL 的操作是：右键表 →Generate SQL → DDL，或者右键整个库生成全库脚本。这个功能在"把生产表结构同步到测试库""写数据库变更文档"的时候特别省事。但要注意生成的脚本里的引擎、字符集、排序规则这些，跨库搬的时候不一定通用，得手动过一遍。

8.2 关于 AI 助手的两点提醒

新版本的 DBeaver 开始集成 AI 相关的辅助能力，比如自然语言转 SQL、SQL 解释之类。用之前有两件事必须想清楚：

第一，它通常需要你配置一个模型服务的地址和密钥，这意味着你的表名、字段名、甚至部分数据可能会离开你的机器。公司内网环境、涉及用户隐私的表，这一层要格外谨慎，能不接就不接。

第二，AI 生成的 SQL 一定要自己审一遍再执行。尤其是带UPDATE、DELETE的语句，WHERE条件写错一个字段，后果是灾难性的。我的做法是：把它当"写草稿的实习生"，草稿可以要，签发权必须在自己手里。

8.3 配置迁移与团队共享

换电脑或者带新人，最省事的方式是把连接配置导出成一份文件（File → Export，选连接相关的配置项），新同事导入之后只需要补自己的账号密码。密码这块可以用主密码加密，千万不要把明文密码写进共享文件里。

团队内部如果连的是同一套开发库，还可以约定统一的连接命名规范（比如dev-mysql-main、test-pg-order），这样大家截图交流的时候不用解释"哪个是哪个"。这种小规范看着无所谓，真到十几个人协作的时候，能省掉很多沟通成本。

用了几年下来，我对 DBeaver 的评价其实很朴素：它不惊艳，但几乎没有短板，而且免费。新人上手的第一道坎永远是安装和第一个连接，把这两步跨过去，后面就是纯熟练度的问题了。最后再分享一个我自己的小习惯——每次在 DBeaver 里要执行UPDATE或DELETE之前，先把同样的WHERE条件改写成SELECT COUNT(*)跑一遍，看行数对不对得上。这个动作花三秒钟，但它救过我太多次了。