很多人第一次在 FinalShell 里整理服务器，都是先把连接一条条建完，再回头想「分个组吧」。会话分组看上去只是左侧树形目录里的一个文件夹，实际牵扯到命名、层级、配置导出和多人协作。下面这几个想当然的做法，是踩坑最集中的地方。
误区一：把分组当成给连接打个标签
最常见的误解，是以为分组和备注、颜色一样，只是给连接贴个标记，一条连接可以同时属于「生产」和「数据库」两个分组。实际在连接管理器里，分组是实打实的目录层级：一条连接只存在于一个位置，拖到别的分组，原位置就不再保留。
这意味着两件事。第一，别指望用分组表达「多维度属性」，环境、用途、负责人这些交叉信息，更适合写进连接名称或备注里。第二，动手之前先想清楚：你分类的主线到底是环境（生产、测试、开发），还是业务（Web、数据库、缓存），还是按客户或项目分。主线只能选一条，混着用，后面必然出现「这条到底放哪」的纠结。
误区二：顺序搞反，先建一堆空分组
有人喜欢先把分组骨架搭好，再往里填连接；也有人反过来，先建几十条连接，最后再分组。两种都不算错，但顺序不对会带来额外返工。
更稳妥的做法是：先建三到五条连接，确认命名规则和分类主线，再建分组并归类。原因是，空分组没有任何信息量，你很难预判真实连接长什么样；而先堆一堆连接再分，往往要反复拖动几十次，还容易漏。
具体操作上，在连接管理器的空白处右键新建分组，或者选中一条已有连接，用右键菜单里的「移动到分组」把它挪进去，比自己摸索拖动更稳。连接建好后再改分组，比建之前纠结半天效率高得多。
误区三：觉得层级越细越专业
我见过最夸张的一份连接树：五层目录，最底层每个分组只放一台机器。结果每次展开要点四次，找人还得先回忆分类逻辑。
对绝大多数个人和中小团队，两层就够：第一层是环境或项目，第二层是用途。三层是上限，再深就该考虑用命名前缀加搜索来代替。连接搜索框其实比翻目录快得多，把「生产-订单-01」这样的信息写进名称，输入几个字就能定位，没必要为了目录好看牺牲点击次数。
误区四：分组名随手起，以为改起来没成本
分组名不只是显示用的文字。它会影响三件事：导出配置文件里的结构、团队里其他人的肌肉记忆，以及重新导入时按名称匹配的结果。
几条实操建议：
- 统一前缀，比如 01_生产、02_测试，靠数字控制排序，不依赖手动拖动
- 不要用斜杠、冒号、问号等符号，避免导入导出时被当作分隔符处理
- 同一套命名规则要在团队内说清楚，谁都不许临时加「新建文件夹」
- 分组名里带上负责人或项目简称，比只写「服务器」有用得多
误区五：删掉分组，里面的连接还在
这是最容易造成损失的一条。删除分组时如果里面还有连接，很多人默认「连接会退回根目录」。操作前一定先确认当前版本的实际行为，稳妥做法是先把连接移出去，再删空分组。
同样，从别人那里导入配置之前，先把自己现有的连接导出备份一份。分组名重复时，导入过程可能出现合并、覆盖或重复项，事后清理比事前备份麻烦十倍。
误区六：以为分组只影响外观
分组还影响批量操作。选中一个分组做批量命令、批量打开，会作用于组内全部连接，所以在生产分组里放一台测试机，是个很危险的习惯。建议把「临时」「待确认」这类连接单独放一个分组，定期清理，别让它们混进正式分组里。
一套能直接照做的分组流程
- 第一步，先在纸上写分类主线，只选一条
- 第二步，建两到三个顶层分组，用数字前缀排序
- 第三步，建立第一批连接，命名时带上环境、用途、序号
- 第四步，把连接拖进对应分组，顺手检查有没有放错
- 第五步，导出一次配置做备份，之后每次大改前重复这一步
- 第六步，三个月后回看一次，把不再使用的连接和空分组清掉
会话分组这件事，难点从来不在操作本身，而在动手之前有没有想清楚分类规则。规则定得简单、稳定、可执行，后面加机器、换同事、迁移配置都会轻松很多。