很多团队的入口不是服务器本身，而是 JumpServer 这样的堡垒机。所有 SSH 流量先经过它，审计、授权、会话记录都在那里完成。
用浏览器打开 JumpServer 的 web terminal 也能干活，但一天下来会遇到不少摩擦：复制粘贴偶尔丢内容、断线之后会话就没了、文件传输要另开一套工具、标签和分屏跟本地终端完全是两套体验。
所以在做 Docklark 的时候，我很早就把 JumpServer 场景当成一等公民来验证。
先验证什么
第一件事不是堆功能，而是把最基础的链路跑通。此前版本在真实设备上验证过三件事：直接 SSH 连接服务器、通过 JumpServer 登录、以及访问到堡垒机后面的目标主机。这三条链路通了，才谈得上体验。
取舍一：SFTP 和监控绑定在入口连接
Docklark 的 SFTP 文件传输和资源监控，绑定在 SSH 入口那条连接上，也就是客户端真正认证和控制的那条 SSH2 连接。
看起来「顺着」嵌套会话走到最终目标机更智能，但我选择了不跟随：
- 嵌套 SSH 或 JumpServer 资产菜单里的目标切换，是远端 shell 里的行为，客户端无法可靠感知
- 强行跟随意味着不断在新连接上重新认证，出问题时用户说不清自己到底在操作哪台机器
- 绑定入口连接，SFTP 和监控复用同一条已认证连接，行为可预期
宁可让用户多一步显式选择，也不要客户端猜。这是整个设计里我最不后悔的一个决定。
取舍二：连接复用要独占且可预检
每条连接独占一条 48 字节的 SSH 短复用路径，SFTP 和监控共享这条已认证连接。本地复用套接字在启动辅助通道前先做预检：路径、目录、归属、权限、套接字是否存在，逐项区分失败原因。
这些检查很啰嗦，但堡垒机环境里路径和权限问题最常见，把失败原因讲清楚，比弹一句「连接失败」有用得多。
取舍三：不自动回退重新认证
辅助通道（SFTP、监控）启动失败时，Docklark 不会悄悄回退去重新认证。自动回退在测试环境里看起来更顺滑，但在生产环境里意味着流量可能绕过预期的路径，也意味着用户以为在用一条连接，实际是两条。
失败就留在窗口里讲清楚原因，点击刷新可以重试。慢一点，但诚实。
还在继续
这些取舍都还随着开发在打磨。Docklark 的完整进展和发布状态放在 项目页，欢迎关注。