连接是 WorkBuddy 从单机玩具变成生产工具的分水岭。前两篇把安装和工作台配置讲清楚了这一篇聚焦连接篇让 WorkBuddy 能读数据库、连服务器、调接口、跑远程命令。毕竟 WorkBuddy 再聪明如果拿不到数据和外部能力它就只能在本地自娱自乐。这篇尤其适合已经搭好 WorkBuddy 工作台、但一直被“连不上”“容易断”“连接工具配不明白”困扰的读者。我会按真实业务中接系统的顺序来写先讲连接设计的底层逻辑再逐个拆解数据库、SSH、HTTP、本地模型、Skill 与移动设备的连接方法最后附一份常见故障排查速查表。内容偏实操可以直接照着配。1. 连接前先理清WorkBuddy 连接层设计与网络检查清单1.1 为什么 WorkBuddy 一定要有一层“连接管理”WorkBuddy 这类数字员工工作台本质是一个调度中枢。它负责理解任务、拆解步骤、调用资源。但资源不会自己跑到它面前来MySQL 在独立服务器上Redis 在另一台机器生产环境的 API 需要 token远程主机只能通过 SSH 登录。没有统一连接层每个技能都各自写死地址和密码问题会非常多。最直接的安全问题是凭据散落各处其次是连接无法复用同一个数据库连接会被多个任务反复创建销毁第三是故障定位难到底是网络不通、认证失败还是服务端超时没人知道。所以成熟的连接管理应该具备三个能力连接配置与业务逻辑分离WorkBuddy 的 Skill 里只写“用哪个连接名”不写 IP 和密码。连接状态可视化每个连接的健康状态、最近调用时间、错误码都要能看到。凭据加密存储密码、Token 不能明文躺在配置文件里。这一点类比到日常生活就是接线板与每家各拉电线的区别。集中管理后新增一个数据库只需要在连接中心配置一次所有 Skill 都能共享某个连接挂了也只需要在连接中心重启不需要逐个改任务。1.2 WorkBuddy 支持哪几类连接以及适用场景根据实际使用场景可以把连接分成四类数据连接包括 MySQL、PostgreSQL、达梦、Oracle、SQL Server 等数据库以及 Redis、Kafka、MongoDB 这类中间件。远程主机连接SSH、SFTP、远程桌面用于执行命令、传输文件、管理服务器。HTTP/API 连接RESTful API、WebSocket用于调用第三方系统、问卷接口、企业微信机器人等。设备与端侧连接USB 调试、蓝牙、局域网服务用于手机、传感器、打印机等硬件设备。连接类型典型场景默认端口注意点数据连接读取业务数据、写入结果、同步报表3306/5432/5236注意驱动版本、时区、SSL远程连接执行巡检命令、部署脚本、拉取日志22/3389优先密钥认证别用弱密码HTTP 连接调用大模型 API、企业系统接口80/443注意鉴权方式和超时时间设备连接手机投屏、蓝牙外设、扫码枪视设备而定USB 驱动和权限一般情况下一个生产级 WorkBuddy 实例至少会配置 1-2 个数据库连接、1 个 SSH 远程主机和若干 HTTP API 连接。初学者最容易犯的错误是贪多一上来就想把所有系统都接入结果每个连接都没调通。我的建议是先打通一条端到端链路比如“数据库读到数据 - WorkBuddy 处理 - 调用 Webhook 通知”再把连接类型扩展。1.3 连接配置前的网络检查清单不少人直接在 WorkBuddy 界面里填 IP 和密码报错了才开始怀疑配置。其实连接问题一大半出在网络层。配置前先花五分钟做三层检查第一目标地址可达吗用 ping 测试基础连通性。ping 不通说明 IP、路由或防火墙有问题。第二目标端口通吗很多服务器禁 ping但端口可能正常建议用 telnet 或 nc。例如测试 MySQLtelnet 192.168.1.100 3306 # 或者 nc -vz 192.168.1.100 3306看到 Connected to 说明端口通。第三本机到目标之间有没有安全组或防火墙规则。云主机通常还需要在控制台放行对应端口本地服务器则检查 iptables、ufw 或 Windows 防火墙。注意数据库和 SSH 端口不要直接暴露到公网。WorkBuddy 与目标服务尽量处于同一内网或专线网络这是最稳的部署姿势。这段网络检查我每次都会做因为能省下后面 80% 的排错时间。2. 数据连接实操数据库、Redis 与 Docker 容器到底怎么连2.1 用 WorkBuddy 连接 MySQL/达梦数据库的完整步骤数据库是连接篇的重头戏。以 WorkBuddy 某个“数据查询” Skill 为例它需要先定义一个数据源连接。连接参数通常包括连接名称mydb_prod数据库类型MySQL 或 达梦主机地址192.168.1.100端口MySQL 用 3306达梦默认 5236数据库名/模式order_db用户名和密码业务专用账号别用 root 或 SYSDBA如果使用 JDBC 类驱动MySQL 的 URL 一般是jdbc:mysql://192.168.1.100:3306/order_db?useUnicodetruecharacterEncodingutf8serverTimezoneAsia/Shanghai达梦数据库稍微特殊一点它的驱动类名和 URL 格式容易记错jdbc:dm://192.168.1.100:5236/order_db?compatibleModemysql驱动类名是 dm.jdbc.driver.DmDriver依赖达梦的 DmJdbcDriver jar 包。很多第一次接触达梦的人会卡在“找不到驱动”这一步其实把对应版本的 jar 放到 WorkBuddy 的 lib 或插件目录、并在连接配置里指定驱动即可。如果用 Navicat 这类图形化客户端连达梦参数完全一致只是在选择驱动时选 DM 驱动即可。先用客户端连通再回 WorkBuddy 配置是最稳妥的验证方式。实操中有三个高频问题第一是时区问题MySQL 8 以上 serverTimezone 必须显式指定否则报 CST 时区识别错误第二是字符集建议统一使用 utf8mb4特别是表里存了表情符号第三是权限业务账号只需要最小权限比如只读账号给 SELECT 就行别用管理员账号跑日常查询。2.2 Redis 连接操作与图形化工具选择Redis 在 WorkBuddy 里的角色很明确做缓存、做临时队列、做分布式锁。连接配置一般只需要四个参数host、port、db index、密码。默认端口 6379db 默认 0密码可以为空但生产环境必须设置 requirepass。命令行验证用 redis-cliredis-cli -h 192.168.1.100 -p 6379 -a yourpassword ping返回 PONG 说明连接正常。WorkBuddy 里配置 Redis 连接后可以把它封装成一个 Skill比如“读取缓存键”输入键名返回值。图形化连接工具方面我建议先用轻量的别一上来就装全家桶。常见的有Redis Desktop ManagerRDM老牌界面清晰适合看 key 和 TTL。Another Redis Desktop Manager开源免费跨平台连接管理比 RDM 更好用。redis-cli命令行适合脚本和快速验证。实操心得连接 Redis 时最容易忽略的是 db index。本地 Redis 默认有 16 个 db如果 WorkBuddy 连的库和业务实际使用的库不一致查出来的数据永远是空的。还有一点Redis 6 以后默认开启了 ACL老版本客户端可能因为用户名默认是 default 而连不上。连接参数里要显式加上用户名 default或者在服务器端给 WorkBuddy 单独建一个用户并授权。2.3 Docker 内部服务怎么连接以 iServer 连达梦为例连接问题在容器环境里会加倍。特别是 Docker 里跑的 iServer 想连另一个容器里的达梦数据库很多人直接写 localhost结果死活连不上。原因很简单localhost 在容器里指容器本身不是宿主机更不是另一个容器。解决思路有三种同 docker-compose 网络直接使用服务名作为 host。比如达梦服务名是 dm8iServer 连接地址就写 dm8:5236。跨容器默认 bridge 网络让两个容器加入同一个自定义网络。docker network create app-net然后在运行容器时用 --network app-net 指定。宿主机访问容器使用宿主机 IP 加映射端口比如 192.168.1.100:5236。排查容器连接时第一步不是改 WorkBuddy而是先确认容器网络和端口映射docker inspect container_id | grep -A 20 NetworkSettings docker logs container_id --tail 200如果确认服务正常但还是连不上就进入目标容器里用 nc 测试docker exec -it container_id bash nc -vz dm8 5236容器环境还有一个隐蔽坑部分镜像默认没有安装 telnet、nc 等网络工具测试前可能要先 apt install 一下或者用 docker exec 进入应用容器后通过应用日志判断连接状态。2.4 连接池、连接复用与超时参数设置加了连接之后还有一个绕不开的性能问题连接复用。WorkBuddy 如果每次执行 Skill 都新建数据库连接性能会很差。以 MySQL 为例每次建连需要 TCP 握手、鉴权、字符集协商耗时可能几十到几百毫秒。对交互式任务还能忍对批处理任务就是灾难。解决方法是使用连接池。WorkBuddy 这类平台底层通常会集成 HikariCP 或类似连接池组件你需要关心的参数有几个maximumPoolSize最大连接数建议根据数据库 max_connections 设置为 5-20。minimumIdle最小空闲连接数生产环境设为 2-5。connectionTimeout获取连接超时默认 30 秒内部系统建议 3-5 秒避免请求长时间挂起。maxLifetime连接最大生命周期建议小于数据库 wait_timeout。idleTimeout空闲回收时间。HTTP 连接同样讲究复用。WorkBuddy 调用外部 API 时尽量开启 keep-alive在 HTTP 头里设置 Connection: keep-alive避免每次请求都重建 TCP 连接。如果调用量大可以在客户端配置连接池比如 Java 的 HttpClient 连接池、Python requests 的 Session 复用。import requests session requests.Session() session.headers.update({Connection: keep-alive}) resp session.get(http://api.internal/health) print(resp.status_code)这个例子虽然简单但背后就是连接复用。WorkBuddy 的 HTTP 节点如果支持自定义请求头务必保留 keep-alive。3. 远程连接与文件传输SSH 免密、VS Code 和 XFTP 实战3.1 快速搞定 SSH 免密登录WorkBuddy 远程执行命令不卡壳SSH 连接是最常用的远程通道。WorkBuddy 要执行远程巡检命令、拉日志、部署脚本都离不开 SSH。最省事的配置是密钥认证省去每次输密码而且比密码更安全。生成密钥对ssh-keygen -t ed25519 -C workbuddy-automation -f ~/.ssh/workbuddy_ed25519一路回车会在 ~/.ssh 下生成私钥 workbuddy_ed25519 和公钥 workbuddy_ed25519.pub。然后把公钥放到目标服务器ssh-copy-id -i ~/.ssh/workbuddy_ed25519.pub user192.168.1.200如果服务器不支持 ssh-copy-id手工追加也行cat ~/.ssh/workbuddy_ed25519.pub | ssh user192.168.1.200 mkdir -p ~/.ssh cat ~/.ssh/authorized_keys然后在 WorkBuddy 的 SSH 连接配置里认证方式选密钥指定私钥路径或粘贴私钥内容。注意私钥文件权限必须设置为 600否则 SSH 客户端会直接拒绝使用。检查方法ls -l ~/.ssh/workbuddy_ed25519如果不是 -rw-------执行 chmod 600。密钥配置好之后还建议在 config 里加一段连接别名提升日常操作效率Host prod-server HostName 192.168.1.200 User ubuntu IdentityFile ~/.ssh/workbuddy_ed25519 ServerAliveInterval 60ServerAliveInterval 60 表示每 60 秒发一次心跳防止长时间空闲后连接中断这个参数对 WorkBuddy 的长任务尤其重要。3.2 VS Code Remote-SSH 与 XFTP 的配合使用调试阶段不可能只用 WorkBuddy总要亲自登录服务器看看。推荐组合是 VS Code Remote-SSH 连服务器写脚本XFTP 传文件WorkBuddy 负责定时调度。VS Code 装好 Remote-SSH 插件后按 F1 输入 Remote-SSH: Connect to Host选择或输入 SSH 连接目标它会在本地打开一个远程窗口编辑、终端、调试都直接跑在远程。第一次连接会自动在服务器上安装 vscode-server如果网络差可能要等一会。这种模式下WorkBuddy 的 SSH 连接配置和 VS Code 的 SSH 配置可以共用同一个 ~/.ssh/config避免维护两套地址。XFTP 用于 SFTP 文件传输。新建会话时协议选 SFTP端口 22填好用户名密码或密钥。日常操作中我喜欢先把服务器上的日志下载到本地分析再通过 XFTP 把 WorkBuddy 的脚本上传到服务器。这里有个小技巧SFTP 传输大文件时如果速度很慢可以检查双方网卡速率或者切换为主动模式/被动模式试试。Windows 自带终端也可以直接用 SSH 命令连接远程服务器ssh ubuntu192.168.1.200不过 Windows 的 OpenSSH 客户端密钥目录默认为 C:\Users\用户名.ssh\注意把密钥放对位置或者用 -i 显式指定。3.3 Ubuntu SSH 连不上的系统排查思路用户最容易遇到的是 Ubuntu SSH 无法连接。现象通常有三种连接超时、拒绝连接、认证失败。对应排查思路完全不同。连接超时大概率是网络层问题。检查目标 IP 是否可达、22 端口是否开放云主机还要看安全组规则。本地防火墙可以用 ufw status 查看如果启用了 ufw执行sudo ufw allow 22/tcp拒绝连接一般说明 sshd 没启动或没监听。先确认服务状态systemctl status sshd sudo systemctl enable --now sshdUbuntu 上服务名可能是 ssh 而不是 sshd注意区分。查看监听端口ss -tlnp | grep :22如果啥都没有说明 sshd 没起来或者监听在其他端口。认证失败重点看用户名、密码、密钥是否匹配。配置文件 /etc/ssh/sshd_config 里几个关键项要检查PermitRootLogin prohibit-password PasswordAuthentication yes PubkeyAuthentication yes改完配置记得重启sudo systemctl restart sshd。排错技巧用 ssh -vvv userhost 查看详细握手日志它会明确告诉你卡在哪一步比如 Connection timed out 还是 Permission denied (publickey,password)。这一步能让排查效率翻倍。3.4 远程桌面与局域网共享的几个典型坑除了 SSH日常运维还经常用远程桌面连接 Windows 主机。Win 上执行 mstsc输入 IP 即可如果连不上先确认远程桌面服务是否开启、防火墙 3389 端口是否放行。Windows 防火墙高级设置里入站规则要允许“远程桌面”。局域网共享这块容易出问题的两个错误码连接共享打印机时报 0x0000057以及提示内存不足。0x0000057 通常和凭据有关删除旧的共享凭据再重连cmdkey /list cmdkey /delete:目标地址然后重新访问共享打印机。提示内存不足时先看系统的 Print Spooler 服务是否正常再把 C:\Windows\System32\spool\PRINTERS 下的残留文件清理掉重启服务。这类问题虽然看起来跟 WorkBuddy 无关但 WorkBuddy 经常要自动触发打印或扫描任务把局域网打印通道修好自动化流程才不会断在中途。4. HTTP 接口与本地模型连接从鉴权到 ERR_SSL_VERSION 排查4.1 HTTP API 连接配置与会话保持HTTP API 是 WorkBuddy 与企业系统集成最通用的姿势。第三方系统大多提供 REST 接口配置一个 HTTP 连接即可调用。连接配置通常包含基础地址https://api.example.com鉴权方式无、Bearer Token、Basic Auth、自定义 Header默认超时连接超时 3 秒、读取超时 30 秒是否启用 Keep-Alive如果接口需要登录后才有数据WorkBuddy 的 HTTP 节点最好支持会话保持机制先调用登录接口拿到 Cookie 或 Token再带着 Cookie/Token 请求业务接口。这里涉及“开启会话连接”的概念其实就是把 SessionID 保存并复用。实操里我会这样设计在 WorkBuddy 里建一个“登录获取 Token”的 Skill执行后把 Token 写入临时存储下游接口请求从存储里读取 Token 加到 Authorization 头。这样 Token 过期时只需要重新执行登录 Skill其他流程不用改。4.2 本地大模型怎么连进 WorkBuddy很多人在 WorkBuddy 里想接本地部署的大模型热词里提到的 Hermes、Ollama 这类都属于本地模型服务。以 Ollama 为例它默认启动在 11434 端口提供 OpenAI 兼容接口WorkBuddy 只需要按 OpenAI API 格式配置。一个典型配置Base URLhttp://localhost:11434/v1API Key随便填Ollama 默认不校验模型名hermes3 或 qwen2.5:7b如果 WorkBuddy 和 Ollama 在同一台机器用 localhost 就行如果是局域网内的另一台机器则用对方 IP比如 http://192.168.1.50:11434/v1。连接本地模型最常遇到的坑有三个第一Ollama 默认只监听 127.0.0.1跨机器访问需要在启动时指定 OLLAMA_HOST0.0.0.0或者修改环境变量后重启服务。第二模型上下文长度和 WorkBuddy 超时设置不匹配长文本任务经常报 timeout需要把 HTTP 读取超时调大。第三本地 GPU 显存不足导致推理慢这是硬件问题不是连接问题注意区分。实操心得本机连接一切正常换到别的机器连不上九成是服务监听地址问题。用 ss -tlnp | grep 11434 确认监听地址如果显示 127.0.0.1:11434外部机器必然连不上。4.3 ERR_SSL_VERSION_OR_CIPHER 到底怎么回事在浏览器里访问局域网设备比如管理后台地址 192.168.2.1提示“此站点的连接不安全使用不受支持的协议 ERR_SSL_VERSION_OR_CIPHER”这个报错经常让新手一头雾水。本质是浏览器和服务端协商 TLS 版本或加密套件失败。老设备只支持 TLS 1.0/1.1 或旧加密算法而新版浏览器默认关闭了这些弱协议。出现这种情况最安全的处理方式是升级设备固件让服务端支持 TLS 1.2 以上。如果是自研服务调整 Nginx 配置ssl_protocols TLSv1.2 TLSv1.3; ssl_ciphers HIGH:!aNULL:!MD5;开发环境下想临时绕过可以在浏览器高级设置里勾选“允许使用旧版 TLS”但生产环境千万别这么干属于用安全换一时的便利。如果是 WorkBuddy 网页版访问本地服务时报这个错还需要确认访问协议是否一致内网服务如果只支持 HTTP就不要在 WorkBuddy 里把地址写成 https反之服务端强制 HTTPS用 http 访问也会出现类似“不受支持的协议”提示。4.4 localhost 访问与专用 WiFi 的几个奇怪现象还有一个常见场景电脑连了公司专用 WiFi 后localhost 反而访问不了本机服务。听起来很诡异但原因通常有三个。第一是系统网络设置中残留了异常网关配置导致 localhost 流量没有按预期走本机回环地址处理方法是在网络设置里把本机回环流量恢复默认确保它不经过任何中间节点。第二是防火墙某些安全软件会把本机回环地址也拦截把对应进程加入白名单。第三是 hosts 文件被修改localhost 没有解析到 127.0.0.1。另一类问题是连上 WiFi 后浏览器提示“需要操作没有 Internet打开浏览器并连接”。这其实是 WiFi 门户认证页常见于酒店、商场、公司访客网络。打开浏览器访问任意地址会自动跳转到认证页面登录后才能通网。WorkBuddy 如果部署在这种网络环境里要特别小心认证过期后对外连接会全部中断所以生产环境不要用这类网络。5. Skill 与终端联动WorkBuddy 自定义指令和手机/蓝牙设备连接5.1 把连接能力封装成 WorkBuddy Skill连接配好只是第一步真正发挥作用要靠 Skill。WorkBuddy 的 Skill 机制允许你把“连接 操作 返回格式”打包成一个可复用的能力。我推荐先做几个基础 Skill数据库查询器输入 SQL返回表格数据。远程主机命令执行器输入命令返回标准输出。API 健康检查器输入 URL返回状态码和响应时间。下面是一个数据库查询 Skill 的伪代码结构def execute_sql(query: str, connection: str mydb_prod): conn get_connection(connection) try: with conn.cursor() as cursor: cursor.execute(query) rows cursor.fetchall() return {status: ok, rows: rows, count: len(rows)} except Exception as e: return {status: error, message: str(e)}这里 connection 参数用连接名而不是 IP 和密码好处是如果数据库迁移只需要在连接管理器里改一个地方。自定义指令推荐方面给 Skill 起名要直接触发词要明确。比如“查用户数”“跑巡检”“发通知”。在 WorkBuddy 里配置自定义指令时我会在描述里写清楚指令触发条件、需要哪些参数、输出格式。越具体越好。一个模糊的指令描述会导致 AI 频繁误解。5.2 Android 手机连接 WorkBuddy 做端侧联动移动端联动是 WorkBuddy 场景里很加分的一环。最常见的是 Android 手机通过 USB 调试连接让 WorkBuddy 识别设备并执行截图、点击、读取通知等操作。用 Android Studio 连接小米手机前需要先开启开发者选项设置 - 我的设备 - 全部参数 - 连续点击 MIUI 版本 7 次然后在更多设置里打开“开发者选项”和“USB 调试”。连接后命令行验证adb devices如果看到 devic 状态说明连接成功。如果显示 unauthorized需要在手机弹窗上允许调试。如果显示 offline拔掉 USB 重新插并重启 adbadb kill-server adb start-server小米手机还有个额外开关在开发者选项里打开“USB 安装”和“USB 调试安全设置”否则 adb 命令可能没有权限。WorkBuddy 把 adb 封装成连接后可以自动完成“获取设备列表”“截屏并保存到指定目录”“模拟点击”等操作适合做 App 自动巡检、UI 测试。5.3 蓝牙设备连接与重置以 GT4Pro 为例蓝牙设备的连接原理和前面说的 TCP 完全不同但 WorkBuddy 同样可以通过系统蓝牙接口去联动。以常见的 GT4Pro 手环/穿戴设备为例配对失败时最有效的一招是重置蓝牙连接缓存。标准步骤大概是手机设置里找到该设备选择取消配对重启手机蓝牙重新搜索并配对配对时保持设备靠近手机并确保设备处于可被发现模式。如果依旧失败恢复设备出厂设置再试。连接成功后可以通过厂商 SDK 或第三方库读取设备数据。热词里提到的 pythonmiio 连接小米网关也是类似道理通过局域网协议与设备通信。这个时候 WorkBuddy 的角色是调度器定时去读取数据再对接入数据库或推送通知。注意硬件设备连接不像软件服务那么可靠建议在 WorkBuddy 的 Skill 里加自动重连与失败告警逻辑比如连续拉取不到数据就触发通知。6. 连接故障速查中断、慢启动、打印机与局域网经典问题6.1 连接中断与 WorkBuddy 启动慢的原因分析连接中断是生产环境最影响体验的问题。成因通常有三类。网络层防火墙空闲断连、WiFi 休眠、运营商 NAT 超时。遇到这种启用心跳保活。SSH 配置 ServerAliveIntervalTCP 层可以设置 SO_KEEPALIVEHTTP 层则依赖 keep-alive。服务层数据库 wait_timeout 过短、连接池回收不及时。解决办法是让连接池的 maxLifetime 小于服务端 wait_timeout比如服务端 wait_timeout28800 秒连接池 maxLifetime 设 1800 秒提前在服务端回收前断开并重建。WorkBuddy 启动非常慢别急着怪软件。先看启动日志里有没有大量连接超时。如果 WorkBuddy 启动时要连接多个数据源或外网服务而某些目标不可达启动过程会被阻塞到超时。解决方案是开启懒加载把非关键的连接放到首次使用时创建或者把不可达的连接暂时禁用。6.2 局域网共享与打印机连接错误速查前面已经提到共享打印机 0x0000057 和内存不足的常见解法这里整理成速查表。现象可能原因解决方向连接提示 0x0000057凭据冲突或网络路径不可用cmdkey /delete 后重新认证提示内存不足无法打印打印缓存文件残留停止 Spooler清空 spool\PRINTERS重启服务能找到打印机但无法连接驱动不匹配重装对应型号驱动x64/x86 要一致报错 0x000002e4打印机服务未启动或离线检查设备电源、网络、Print Spooler6.3 连接排查方法论与常用命令排查连接问题最忌讳瞎试。我自己的流程是先画出链路图从 WorkBuddy 到目标服务之间有哪些节点然后从最近的一跳开始逐层验证。常用命令:# 连通性 ping host # 端口 telnet host port nc -vz host port # 路由 traceroute host # 查看本机监听 ss -tlnp netstat -antp # HTTP 调试 curl -v http://host:port/health # 抓包 tcpdump -i eth0 port 3306 -nn每一条命令都有自己的用途。ping 看基础连通telnet/nc 看端口curl 看应用层协议tcpdump 看网络包细节。遇到“WorkBuddy 里连不上但命令行能连上”优先怀疑 WorkBuddy 所在进程的网络命名空间或网络转发配置这类问题很隐蔽。6.4 一套通用的连接自检流程最后分享一个可以直接抄的自检流程确认目标服务确实在监听ss -tlnp 或 netstat。确认端口可达telnet 或 nc。确认鉴权信息正确用客户端工具连一次。确认 WorkBuddy 的配置项与客户端一致host、port、库名、用户名、密码。看 WorkBuddy 的错误日志把报错粘贴到搜索优先看时间戳和 Caused by。如果是间歇性失败检查超时参数和连接池配置。这套流程解决了我遇到的大部分连接问题。每一条背后都有实际踩坑的教训比如第 4 条很多人本地用 root 连没问题WorkBuddy 里用了只读账号却漏了库名导致一直报 table not found看起来像权限问题实际是配置问题。说实话连接这块没有什么玄学。我在实际项目中踩过最多的坑不是技术多难而是顺序不对上来就改配置不先做网络检查连不上就怀疑 WorkBuddy不去看目标服务的日志。把链路拆开一段一段验证问题基本十分钟内能定位。如果你想在 WorkBuddy 里把连接管理做好我有一个建议把常用的连接测试命令沉淀成一个 Skill比如“端口检测”输入主机和端口自动 telnet 并返回结果。这样以后再遇到“连不上”不用手工敲命令直接让 WorkBuddy 自己先给自己做个体检。这算是我最近最满意的一个小技巧省了不少事。