服务器之间传文件的几种方式：scp、sftp、rsync

一个 2G 的压缩包传到八成断线了，换哪个工具重来最省事？把 scp、sftp、rsync 各自的脾气讲清楚，这类问题就不用再纠结。 先说 scp 语法最短：scp local.tar.gz deploy@192.168.1.10:/tmp/，反过来写就是下载。适合一次性传单个文件或小目录。弱点是全量复制，断了只能从头再来，属性也不保留，传完的文件属主变成目标用户。另外新版本 OpenSSH 的 scp 底层已改走 SFTP 协议，新老版本混用时偶尔有兼容差异。 再说 sftp 交互式界面，连上之后像 FTP 一样用 put、get 上传下载，ls、cd 切目录，适合人肉浏览着挑文件传。常见的图形化文件工具大多基于 SFTP 协议，填上登录信息就能用，非技术同事也能上手。 rsync 才是同步场景的主角 它对比源与目标，只传有差异的部分：第一次是全量，第二次起可能只传几 MB。断点续传靠 -P，限速靠 --bwlimit=5000（单位 KB/s，白天跑大同步不占满带宽）。海量小文件的大目录，增量优势更明显，重跑一次只补差额。-a 还能把权限、属主、时间戳原样带过去，目录迁移后权限不散架。 提速还有个维度：单个大文件先 gzip 再传，常比 rsync -z 的流式压缩更省时；几百个小文件则先打包成单个压缩包再传，免掉逐个建连接的开销。 对比结论 临时传一两个文件，scp 最快手上见；交互式挑文件、给非技术同事用，sftp 合适；目录备份、定时同步、大文件怕断线，一律 rsync。三条命令都基于 SSH，密钥免密配好后，脚本里一样顺畅。 顺带一个高频笔误：scp 指定端口是大写 -P（scp -P 2222），rsync 走 -e "ssh -p 2222"，两边大小写不一致，抄命令时最容易栽在这里。 回到开头的问题：断在八成的那 1.6G，scp 只能重头再来，sftp 部分客户端支持续传，rsync -P --partial 则明确保住已传部分接着收尾。要省流量，答案很明显。