一个真实的小团队案例
去年秋天，一家做家居电商的公司要把旧云主机上的东西搬到新机房：约40GB历史日志、12万张商品图、一套跑了两年的网站程序。三个人，原计划一个晚上搞定，实际拖了三天。事后复盘，问题既不在服务器性能，也不在带宽，而在于他们从头到尾没把「服务器文件传输工具」当成一件需要选型的事——抓到什么用什么。
第一次中断：图形界面拖拽传8GB日志
- 现象：用终端自带的SFTP面板把日志目录直接拖到本地，进度走到六成卡住，重连后从零开始。
- 原因：多数图形化SFTP面板对单个大文件没有断点续传，连接一抖就得重来。
- 改法：单文件超过1GB先打包，用tar分卷，每卷500MB上下，断了只补最后一卷。
- 经验：几百KB的零散配置文件适合拖拽，几十GB的整目录不适合。工具没错，场景错了。
第二次中断：压缩包传完发现是坏的
第二天他们改用命令行上传，速度确实快了，但一个6GB的备份包传完后解压报错。排查发现是传输过程中网络闪断，文件被截断，而他们没有任何校验环节。
- 上传前后各算一次校验值，md5sum或sha256sum都行，两边对得上才算传完。
- 大文件优先选支持断点续传的方式，不要依赖“看起来传完了”。
- 传输日志留一份，出问题时能定位是哪个文件、哪一段出的事。
这一步之后，他们把服务器文件传输工具的选型标准从“界面好不好看”改成了三条：能不能续传、能不能校验、能不能看进度。
第三次中断：两个人同时写同一个目录
第三天上午，两个人同时往同一个素材目录上传，同名文件互相覆盖，一部分图片变成了旧版本。这类事故在小团队里特别常见，根子不在工具，在约定。
- 上传目录按人、按日期分开，例如 uploads/日期/姓名，避免直接写同一层。
- 覆盖前先看时间戳，或先把目标文件改名备份。
- 传完再改权限，别一边传一边调，容易中途失败留下半截文件。
复盘：把传输需求拆成三类
事后他们把日常的文件传输拆成三类场景，各自配一种工具，问题基本消失。
- 零散小文件（配置、证书、脚本）：图形化SFTP客户端，拖拽上传、双击编辑，图的是顺手。
- 大文件与整目录（日志、备份、镜像）：命令行加断点续传加校验，图的是可恢复。
- 长期定时同步（代码、素材库）：rsync增量同步，只传变化的部分，配合限速参数，避免把带宽占满影响线上业务。
六条可以直接照抄的操作建议
- 传之前先估体量：小于100MB随意，1GB以上必须先想好断了怎么办。
- 能压缩就压缩，文本类日志压缩后往往只剩原来的十分之一。
- 大目录先打包再传，别让工具去递归几万个小文件。
- 养成校验习惯，尤其是数据库备份和镜像文件。
- 高峰期给传输限速，别让一次搬迁拖垮线上访问。
- 传输完成后清理临时文件，服务器磁盘写满的后果比传得慢严重得多。
写在最后
这次搬迁最后花了三天，真正传数据的时间不到八小时，剩下的都耗在重传、排查和补救上。对普通团队来说，服务器文件传输工具没有绝对的好坏，只有匹配不匹配：小文件图顺手，大文件图稳，长期同步图省心。把这三件事分开看，再普通的工具也能传得干净利落。