Linux系统中，如何通过命令scp/rsync来实现文件跨服务器之间的传输, 以及注意事项有哪些？全网最细！逐步操作一文详解！
为了高效地在两台服务器之间传输文件，最推荐使用 scp 或 rsync 命令。
具体使用哪条命令取决于你当前登录在哪台服务器上。
以下是最高效的执行命令（请将命令中的 [用户名] 替换为目标/源服务器的实际登录用户名，例如 root 或 mypc）：
方案一：假设我当前登录在 111.111.111.11 (源服务器)
最直接的方式是从当前服务器“推”过去。
使用 scp (简单快捷):
scp /home/mypc/king/whisper_zh/WhisperLive_zh.tar.gz [用户名]@111.111.111.12:/home/mypc/king/
使用 rsync (推荐，支持断点续传和显示进度):
rsync -avP /home/mypc/king/whisper_zh/WhisperLive_zh.tar.gz [用户名]@111.111.111.12:/home/mypc/king/
方案二：如果你当前登录在 111.111.111.12 (目标服务器)
你可以从目标服务器把文件“拉”过来。
使用 scp:
scp [用户名]@111.111.111.11:/home/mypc/king/whisper_zh/WhisperLive_zh.tar.gz /home/mypc/king/
使用 rsync:
rsync -avP [用户名]@111.111.111.11:/home/mypc/king/whisper_zh/WhisperLive_zh.tar.gz /home/mypc/king/
💡 效率提升小贴士：
- **优先使用
rsync -avP**：如果文件较大，网络不稳定时rsync可以断点续传（-P参数），避免因为网络波动导致传输失败从头再来。 - 无需额外压缩：因为你的文件已经是
.tar.gz格式（已经压缩过），所以在传输命令中不要再加-C（压缩传输）参数，否则反而会消耗 CPU 资源，拖慢传输速度。 - 权限确认：执行命令前，请确保目标路径
/home/mypc/king/在服务器 111.111.111.12 上已经存在，并且你使用的登录用户有权限响应该目录写入文件。如果目录不存在，可以先在目标服务器执行mkdir -p /home/mypc/king/。
追问：如下这个是算上传成功了吗？那这个key是不是没必要保存，只是一次性的对吗？
(base) mypc@mypc-R4900-G5:~/king/whisper_zh$ rsync -avP /home/mypc/king/whisper_zh/WhisperLive_zh.tar.gz mypc@111.111.111.12:/home/mypc/king
The authenticity of host '111.111.111.12 (111.111.111.12)' can't be established.
ED25519 key fingerprint is SHA256:VU7A5DA168>ASD.+ASD1F68AS949SDFA.
This key is not known by any other names
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
Warning: Permanently added '111.111.111.12' (ED25519) to the list of known hosts.
mypc@111.111.111.12's password:
sending incremental file list
WhisperLive_zh.tar.gz
27,300,013 100% 111.61MB/s 0:00:00 (xfr#1, to-chk=0/1)
sent 27,306,798 bytes received 35 bytes 327,027.94 bytes/sec
total size is 27,300,013 speedup is 1.00
是的，是的，目前文件已经完美上传成功了！ 从日志来看，传输非常顺利。日志里的 100% 以及最后的 sent 27,306,798 bytes... speedup is 1.00 都明确表示文件已经完整地传到了目标服务器。
关于你提到的那个 key（密钥指纹），这里有一个需要纠正的小误区：
那个 key 不是一次性的，而且你也不需要手动去保存它，系统已经替你自动保存好了。
给你简单解释一下刚才发生了什么：
- “查户口”机制： 因为你是第一次从
111.11...11连接到111.11...12，底层使用的 SSH 协议不认识这台新服务器，所以它弹出了那段The authenticity of host... can't be established.的提示，展示了目标服务器的“身份证号”（ED25519 key fingerprint），问你信不信任这台机器。 - 系统自动记录： 当你输入
yes之后，日志里紧接着有一句Warning: Permanently added '111.111.111.12' (ED25519) to the list of known hosts.。这就意味着，你的服务器已经把这个 key 永久保存在了本地隐藏文件（通常是~/.ssh/known_hosts）里。 - 以后的便利与安全： 下次你再往
111.111.111.12传文件时，系统就不会再弹这堆英文问你了，它会直接提示你输入密码。同时，如果哪天目标服务器的“身份证号”突然变了（可能是服务器被重置，也可能是遭遇了网络劫持），系统会立刻报错并阻止你连接，以此来保护你的安全。
总结： 文件传得很成功，那个 key 机制是帮你保驾护航的，系统已经自动帮你记住了，你现在可以放心去 111.111.111.12 服务器的 /home/mypc/king/ 目录下找你的文件了。
追问：如果对于python的(anaconda/miniconda)构建的虚拟环境，也能采用类似【压缩】--> 【rsync传输】 --> 【解压】 操作吗？
说实话，这的确是很符合直觉的。但是：不可行！
直接这样做的会遇到：terminals database is inaccessible 这个报错。
直接把 Conda 虚拟环境打包压缩，然后传到另一台服务器上解压——这种操作在 Conda 里是非常容易“水土不服”的。特别是咱们的路径还发生了变化（从源服务器的 /home/mypcapp/... 变成了目标服务器的 /home/mypc/...）。
⚠️ 为什么直接复制 Conda 环境会出问题？
Conda 环境并不是完全便携的。在创建环境和安装包时，Conda 会在很多脚本（比如 pip）和二进制文件里写死绝对路径。
当你把环境直接拷过去后：
clear命令内部写死了去找原来那个/home/mypcapp/...路径下的terminfo数据库，结果现在路径变成了/home/mypc/...，它自然就找不到了。- 更大的隐患：除了
clear不能用，你接下来极有可能会遇到更头疼的问题。比如用pip install安装新包时报错、装到了系统目录里，或者运行某些 Python 脚本时提示找不到解释器（因为脚本开头的#!/home/mypcapp/.../python路径已经失效了）。
💡 正确的迁移姿势（建议重做）
虽然有些临时的方案（配置 TERMINFO 环境变量）能当“创可贴”解决眼前清屏的问题，
但为了避免以后跑深度学习代码时出现各种玄学报错，强烈建议你用标准的方法重新迁移这个环境。
这里有两种正确且高效的做法：
方案一：导出配置并重新创建（最稳妥，推荐）
如果你的目标服务器（111.111.111.12）有网，这是最好的办法。
- 在源服务器 (111.11...11) 上导出环境：
conda activate whisperlive_funasr_zh
conda env export > environment.yml
- 把
environment.yml传给目标服务器：
scp environment.yml mypc@111.111.111.12:/home/mypc/king/
- 在目标服务器 (111.11...12) 上重新创建：
conda env create -f environment.yml
方案二：使用 conda-pack 专门打包（适合离线/无网环境）
如果你就是想打包传过去，必须使用专门的 conda-pack 工具，它会在解压时自动帮你修复所有写死的路径。
- 在源服务器上安装并打包：
conda install -c conda-forge conda-pack
# 将环境打包成 tar.gz
conda pack -n whisperlive_funasr_zh -o whisperlive_env.tar.gz
- 传到目标服务器：（用你已经很熟练的
rsync） - 在目标服务器上解压并修复路径：
# 创建一个目录存放新环境
mkdir -p ~/miniconda3/envs/whisperlive_funasr_zh # 替换为你实际的 conda envs 路径
# 解压进去
tar -xzf whisperlive_env.tar.gz -C ~/miniconda3/envs/whisperlive_funasr_zh
# 激活环境
conda activate whisperlive_funasr_zh
# 这一步非常关键：让 conda-pack 修复所有的路径映射！
conda-unpack
总结： 现在的这个环境因为路径写死的问题属于“半残废”状态。长痛不如短痛，我们需要用上面两种正规军的方法重新迁移一下，以绝后患！
浙公网安备 33010602011771号