1. 本地文件传到 Linux 服务器先搞清楚你到底要哪种传法很多人在刚开始接触 Linux 服务器时第一个卡住的环节不是装系统、不是配环境而是“我电脑上这个文件到底怎么扔到服务器上去”。Windows 习惯了拖拽复制到了 Linux 这边突然发现连图形界面都未必有整个人就懵了。先说清楚这个场景是什么你本地有一台电脑Windows、macOS 或者另一台 Linux远端有一台 Linux 服务器可能是云服务器也可能是内网机房里的物理机。你现在需要把本地文件传输到服务器上可能是传一个安装包、传一份配置文件、传一批日志、甚至传整个网站目录。这个操作是 Linux 运维里最基础、最高频的需求之一没有传文件的技能后面部署环境、配置服务、迁移数据全都无从谈起。适合谁来参考我觉得只要你是以下三类人之一这篇内容都值得看完第一类是刚接触 Linux 服务器的学习型选手折腾了个云服务器练手需要把本地写好的网页、脚本传到服务器上跑起来。第二类是日常做运维、做部署的工程师经常要在本地和服务器之间倒腾配置文件、上传发布包想找到更高效、更稳的传法。第三类是纯粹被某个具体问题卡住的人比如 scp 连不上、rsync 没安装、传大文件传到一半断掉你也能在后面的排查部分找到对应的解法。这篇文章我会把传输工具一个个拆开讲从最基础的 scp 开始到 rsync 做增量同步再到 lrzsz 这种“反人类但关键时刻救命”的工具最后补上免密登录配置和常见错误排查。每一条我都会告诉你为什么这么用、坑在哪里、实际工作中怎么选。2. 先分清这几种传输方式别一上来就乱用命令把本地文件传到 Linux 服务器核心就两条路径一种是通过 SSH 协议传输另一种是走独立的文件传输协议。搞清楚这两种路径的区别你才知道什么时候用哪个工具。2.1 SSH 系工具scp、rsync、sftp 都是同一套通道SSH 是 Linux 服务器上几乎必然开启的远程管理通道默认端口 22。scpSecure Copy、rsync、sftp 这三个工具底层依赖的都是 SSH 通道也就是说只要你能 SSH 登录服务器这三个工具理论上都能用不用额外装什么服务端。这一点特别重要。你在本地执行ssh root服务器IP如果能正常登录那么scp、rsync、sftp大概率都能通因为它们用的是同一套认证机制、同一套端口、同一套网络链路。反过来如果你连 SSH 都登不上那这三个工具也全都会失败。所以遇到传输问题时先测 SSH 能不能连这是最快的排错思路。我拿日常运维举例改了一版 Nginx 配置想传到服务器上替换用 scp 一条命令搞定要同步整个站点目录里面有几百个文件用 rsync 能只传有变动的那些图形界面习惯的人用 WinSCP 这类 SFTP 客户端本质还是走的 SSH 通道只是包了一层图形界面。2.2 独立的文件传输协议FTP/SFTP、WebDAV 这些是另一条路还有一类方式是走独立的文件传输协议最常见的是 FTP 和 SFTP这里说的 SFTP 指的是 FTP over SSH和 SSH 自带的 sftp 子系统是两个概念但日常使用中很多人混着叫实际 WinSCP 走的就是 SSH 的 SFTP 子系统不需要额外装 FTP 服务端。如果服务器上装了 vsftpd 这类 FTP 服务端或者配置了 Nginx/Tengine 的 WebDAV 模块那么你也可以通过 FTP 客户端、HTTP 上传等方式传文件。这类方式的优势是不需要对方服务器开放 SSH 端口或者业务方只给了你一个 FTP 账号只能走这条路。劣势是多搭一套服务、多一个暴露面、多一层认证管理不太符合“能少装就少装”的运维习惯。我个人建议默认优先用 SSH 系工具。原因很简单——你反正在管理服务器SSH 必然开着那就在这条链路上解决传输问题不要再额外开 FTP 之类的端口。开端口意味着增加被扫描、被爆破的风险面能不开就不开。除非是给非技术同事提供文件交换渠道否则没必要单独部署 FTP。2.3 冷门但救命的方案lrzszsz/rz还有一种方式我要单独拎出来说因为它和上面所有方式都不太一样lrzsz。这个工具做的事情是“在 SSH 会话里直接传输文件”不需要额外端口不需要 SFTP 协议它走的还是 SSH 通道但是是把文件编码后通过终端会话传递。具体来说在服务器上装了 lrzsz 之后你在 SSH 终端里执行sz 文件名文件就会被传回本地在你本地 SSH 工具确认的下载目录里在 SSH 终端里执行rz会弹出本地文件选择框把文件从本地上传到服务器当前目录。听着很神奇对吧我第一次用的时候也觉得这是个黑魔法。它的原理其实是rz 命令进入接收模式后终端客户端比如 Xshell、SecureCRT、FinalShell会配合弹窗双方通过 ZMODEM 协议在终端会话里传文件。这个工具什么时候用最典型的场景是你只有一台装了 SSH 终端的电脑服务器处于一个特别受限的环境——比如它只能通过跳板机中转本地网络又不能直接访问服务器的 22 端口但你通过跳板机已经连上了 SSH 会话。这时候 scp、rsync、sftp 全都不好使因为链路不通sz/rz 就成了唯一能走的通道。不过它有个硬伤我先说清楚rz/sz 会因为终端环境不稳定导致传输中断传大文件超过 1GB几乎必断二来它会占用终端会话传文件期间你没法执行其他命令三来 Windows 自带的终端工具、某些纯命令行环境不支持 ZMODEM 弹窗需要 Xshell、SecureCRT 这类客户端配合才可以。所以我给它的定位很明确应急工具不是主力工具。3. 实操落地scp、rsync 从使用到免密一条龙前面讲清楚了理论这部分直接上手操作。我按“最常用的操作、参数解释、为什么这么写”的顺序来确保你照着敲就能出结果。3.1 scp 命令最直接的传法scp 的语法比 cp 命令多一个远程主机信息其他逻辑一模一样。先看最基础的用法# 从本地上传到服务器指定用户名和IP scp /local/path/file.txt root192.168.1.100:/root/ # 从服务器下载到本地把位置调换即可 scp root192.168.1.100:/root/file.txt /local/path/第一条命令的意思是把本地/local/path/file.txt文件传到 IP 为 192.168.1.100 的服务器上放在/root/目录下登录用户是 root。执行后系统会提示你输入 root 用户的密码输完就开始传输。这里有个小细节值得解释一下为什么命令里要写root因为 scp 默认使用本地当前用户名去登录远程主机。如果你本地用户名是zhangsan不写root它会尝试用zhangsan去登录服务器大概率报 Permission denied。所以要显式指定远程登录用户名。常用参数我列一下参数作用我的注释-r递归传输整个目录传文件夹必须加不加会直接报错-P 端口指定 SSH 端口大写 P如果服务器改了默认 22 端口必须用这个-p保留文件的修改时间和权限小写 p传配置文件时推荐加上避免时间戳变化引发服务重载判断异常-C传输时启用压缩传文本类配置、日志时效果好传已压缩的包tar.gz、zip反而更慢-i 密钥文件指定私钥路径免密登录时用到后面细说实操场景举例我今天要把本地配置好的nginx.conf传到服务器的/etc/nginx/目录同时保留文件原有的权限和时间戳scp -P 22 -p /home/zhangsan/nginx.conf root192.168.1.100:/etc/nginx/这里-P 22其实可以省略因为 22 是默认端口。我只是为了演示写法。如果你的服务器改了 SSH 端口比如改成 22022那必须是scp -P 22022用小写-p是没用的这一点很多人栽过跟头大写 P 表示端口小写 p 表示保留属性千万别搞混。再补充一个传目录的场景。我要把本地整个dist目录前端构建产物传到服务器的/var/www/html/下scp -r -P 22022 /home/zhangsan/dist/* root192.168.1.100:/var/www/html/注意我这里的写法是dist/*而不是dist。区别在于dist/*只传目录里的内容远程目录后面接的路径就是内容该在的位置dist会连目录本身一起传过去远程会变成/var/www/html/dist。这个差别非常容易踩坑特别是你明明想把 dist 下面的文件直接放到 web 根目录结果传完发现多了层嵌套。我建议在传目录的时候先想清楚远程路径结构再决定写目录还是目录/*。3.2 rsync增量同步才是真正的工作主力scp 能用但遇到“改了一两个文件要重新传整个目录”的场景就笨了。rsync 的优势在于它支持增量传输只传送有变化的部分而且支持断点续传、支持--delete保持两端目录完全一致。在大目录、频繁更新、或者服务器带宽有限的情况下rsync 要比 scp 高效得多。基本语法和 scp 几乎一样# 把本地的 site/ 目录推到服务器上的 /var/www/site/ rsync -avzP /home/zhangsan/site/ root192.168.1.100:/var/www/site/参数逐个拆开解释参数作用为什么重要-a归档模式等价于递归保留权限保留时间保留软链接等同步目录时几乎必加保证目标文件属性不丢失-v输出详细信息看传输过程、统计信息排查问题时有用-z传输时压缩传文本、代码效果显著传压缩包没用-P等同--partial --progress保留部分传输的文件 显示进度条传大文件断了能续传--delete删除远程端多余的文件让两端目录完全一致但用不好会误删文件要谨慎我先举一个日常最常用的场景本地开发的网站根目录需要完整同步到测试服务器。我要保证服务器上的文件和本地完全一致包括删掉的旧文件也要在服务器上同步删除rsync -avzP --delete /home/zhangsan/site/ root192.168.1.100:/var/www/site/注意这里有个非常关键的斜杠细节site/末尾有斜杠表示“同步该目录下的内容”如果没有末尾斜杠写成site表示“把 site 这个目录本身同步过去”效果类似 scp 里目录和目录/*的区别但 rsync 的规则更严格。我再强调一次--delete是双刃剑。它保证了两端一致但如果你写错了源路径比如源路径本来就不存在或为空rsync 会把服务器上该同步目录下的文件全删光。我就见过同事在发布脚本里因为路径变量写错把线上目录清空过。所以如果你刚开始用 rsync建议先不加--delete跑一次看输出确认源路径无误、预期文件列表正确之后再把--delete加上。稳妥起见线上操作前可以先加-n做试跑dry-run输出模拟结果但不实际执行rsync -avzP --delete -n /home/zhangsan/site/ root192.168.1.100:/var/www/site/-n这个参数是干跑模式dry run它会列出“如果执行会做哪些事”但实际不会传输任何数据。第一次配套--delete时强烈建议先干跑一次这不是多此一举这是防止翻车的最便宜的手段。rsync 还有一个在传超大文件时很实用的场景断点续传。scp 传大文件传到一半网络断了只能从头再来。rsync 因为加了-P--partial已经传完的部分会保留在目标位置下次再执行同样的命令它会从断点位置继续。我传过一个 40GB 的数据库备份文件中途断了两三次每次重新执行同一个 rsync 命令就能续上最终完整传完这是 scp 做不到的。3.3 免密登录配置让脚本自动化成为可能如果只是偶尔手动传一次文件每次输密码也无所谓。但你要是想写自动化脚本、定时任务cron、或者 CI/CD 发布流程每次都要求输密码就不现实了。这时候需要配置 SSH 免密登录。配置的原理很简单把你本地电脑的公钥放到服务器的authorized_keys文件里之后 SSH 登录时服务器用公钥验证你的身份本地再用私钥配合完成认证整个过程不需要输密码。具体操作步骤如下第一步在本地生成密钥对如果已经有了可以跳过ssh-keygen -t rsa -b 4096 -C your_emailexample.com执行后会有几个交互提示问你保存路径默认~/.ssh/id_rsa直接回车用默认、问你设置 passphrase建议直接回车留空否则每次使用还得输密码自动化又白搭了。最终会生成两个文件id_rsa私钥必须保存好不要泄露和id_rsa.pub公钥要放到服务器上。第二步把公钥上传到服务器。最省事的方式是使用ssh-copy-id命令ssh-copy-id -p 22 root192.168.1.100这个命令会自动把本地公钥追加到服务器的 root 用户的~/.ssh/authorized_keys文件里还会自动处理好目录权限。执行时输一次密码之后就免密了。第三步验证免密是否生效ssh root192.168.1.100正常应该直接进入服务器终端不再询问密码。到这里scp、rsync 也就一并免密了。再执行scp或rsync时不需要输入密码这对写自动化脚本至关重要。有些服务器没有ssh-copy-id命令特别是精简安装的服务器系统需要手动处理。这时候可以这样做在本地读取公钥内容然后登录服务器手动创建/追加# 本地执行查看公钥内容 cat ~/.ssh/id_rsa.pub把输出的内容复制然后 SSH 登录服务器执行mkdir -p ~/.ssh chmod 700 ~/.ssh echo 粘贴你复制的公钥内容 ~/.ssh/authorized_keys chmod 600 ~/.ssh/authorized_keys这里面的权限设置不是强迫症——SSH 服务端对.ssh目录和authorized_keys文件的权限有严格要求.ssh目录必须 700authorized_keys文件必须 600。如果权限过宽比如.ssh是 755不少 Linux 发行版的 SSH 服务会认为不安全直接拒绝加载这个公钥导致免密配置失败。我遇到过好几次都是因为这个原因排查了半天最后就是一个 chmod 的事。手动配置完后在本地测试免密登录是否生效。如果没生效优先检查服务器端/etc/ssh/sshd_config里的PubkeyAuthentication是否为yes以及AuthorizedKeysFile是否指向了正确的路径。一般发行版默认都是开着的但遇到精简定制的系统就要注意了。4. 批量传输、目录同步、定时任务把脚本自动化搞起来单次手动传输学会之后接下来就是如何把流程固化成可重复执行的东西。这也是本地文件传 Linux 服务器从“会用命令”走向“能干活”的关键一步。我分享几个我实际工作中沉淀下来的做法。4.1 写一个同步脚本固化发布流程以我常用的网站发布为例我本地有一个项目目录构建后生成dist/需要同步到生产服务器的/var/www/html/并且要求删除服务器上多余的文件、保留文件权限、传输时压缩。这个命令我不会每次都手敲而是写成一个脚本#!/bin/bash # sync_to_prod.sh # 用法./sync_to_prod.sh # 功能将本地构建产物同步到生产服务器 rsync -avzP --delete \ -e ssh -p 22022 \ /home/zhangsan/project/dist/ \ root192.168.1.100:/var/www/html/这里我加了-e ssh -p 22022意思是让 rsync 通过 SSH 通道连接时额外指定端口。如果服务器 SSH 端口不是默认的 22rsync 默认不会自动识别必须通过-e参数把端口传进去。这个点要特别注意因为 rsync 没有像 scp 那样提供显式的大写-P参数来指定端口。脚本写好后赋予执行权限以后每次发布只需要跑这一行命令chmod x sync_to_prod.sh ./sync_to_prod.sh脚本输出的每一行都会显示哪些文件被传输、速度、文件大小最后会有传输统计。我通常会花几秒时间扫一眼有没有意外删除的文件列表确认无误后再去做下一步的服务重载操作。再进一步你可以把“同步文件”和“远程执行命令”结合起来。比如同步完配置文件后紧接着需要重载 Nginx这可以用 SSH 的远程执行功能实现# 同步后远程执行 nginx -s reload ssh -p 22022 root192.168.1.100 nginx -s reload一个脚本里既有传输又有远程命令整个发布流水线就串起来了。这也是本地传输文件这个操作最常见的升级方向从“传个文件”变成“一键发布”。4.2 定时同步定时任务与增量备份再举一个常见的应用场景每天把服务器上的数据备份拉回本地。这个方向是反向传输但思路完全一样只是源和目标的顺序反过来。假设服务器上有一个每天由业务系统生成的日志目录/data/app/logs/我希望每天凌晨自动同步到本地备份盘。可以配置本地的 cron 定时任务crontab -e在编辑器里加一行0 2 * * * /home/zhangsan/scripts/pull_logs.sh /home/zhangsan/logs/pull_logs.log 21其中/home/zhangsan/scripts/pull_logs.sh的内容是#!/bin/bash rsync -avzP \ -e ssh -p 22022 \ root192.168.1.100:/data/app/logs/ \ /home/zhangsan/backup/logs/这里没有加--delete因为备份场景我不希望服务器上如果暂时少了某个日志本地备份也跟着删掉保留更多历史总是更安全。每天凌晨 2 点执行一次配合免密登录整个过程无人值守。这种做法的好处是rsync 只传增量每天的带宽消耗极小而且服务器端文件没变化时几乎不产生任何流量。你不需要担心“服务器上有 100GB 数据是不是每天都要传 100GB”——不会的rsync 的增量机制决定了它只传差异部分。这也是为什么 rsync 在备份场景中地位不可替代。4.3 批量分发文件的思路for 循环加 rsync还有一个高频场景是批量分发配置文件到多台服务器。比如你管理着 5 台应用服务器每次改完某个配置文件需要同时同步到这些机器。手动一台台 scp 效率太低可以写一个简单的 for 循环#!/bin/bash # 批量分发 /etc/app.conf 到多台服务器 SERVERS192.168.1.101 192.168.1.102 192.168.1.103 192.168.1.104 192.168.1.105 for IP in $SERVERS; do echo 同步到 $IP ... scp -P 22022 /etc/app.conf root${IP}:/etc/app.conf if [ $? -eq 0 ]; then echo OK: $IP 同步成功 else echo FAIL: $IP 同步失败请检查网络或免密配置 fi done这段脚本里的$?是上一条命令的返回值0 表示成功非 0 表示失败。用这个可以做一个简单的错误标注脚本跑完扫一眼哪些机器失败再单独处理。这是运维中“批量操作”最小、最朴素的实现。当然生产环境中服务器多了之后建议用 Ansible 这类自动化运维工具来做分发但原理其实是相通的底层照样走 SSH照样是文件传输。5. 常见问题与排查技巧实录再稳定的工具用久了也总会遇到问题。这部分我把这几年攒下的踩坑经历整理成查错手册每一条都是真实发生过的比看错误文档有用。5.1 Permission denied (publickey,password) 认证失败这是最常见的问题。报这个错的原因有很多层排查顺序很重要第一步确认远程用户名是否写对。常见错误是用了zhangsanIP但服务器上根本没这个用户或者服务器上用的是另一个用户名。在 scp/rsync 命令里写root还是deploy决定了你用谁的密钥去验证。第二步确认本地是否使用了正确的密钥。用了免密配置后就容易忽略这一点可能本地默认找的是~/.ssh/id_rsa但当初配免密时用的是一对独立生成的部署密钥。需要通过ssh -i /path/to/private_key -p 22022 rootIP手动指定密钥来验证是否能登录成功。第三步如果确认密钥没问题就检查服务器端配置。看/etc/ssh/sshd_config里的PasswordAuthentication是否为yes。有些服务器出于安全考量关闭了密码登录只允许密钥但你本地还没配置好密钥两边就对不上了。第四步检查authorized_keys的权限归属。这个文件必须属于登录用户本人不能是 root 或者其他用户。我遇到过文件内容完全正确但所属用户不对的情况SSH 直接不认因为安全机制不允许用户去使用别人拥有的授权文件。5.2 scp: /usr/bin/scp: No such file or directory这个报错很容易让人误以为命令不存在实际原因也分几种。一种是本地执行环境里确实少了 openssh-clients 这个包。这类情况常见于精简版 Linux 桌面系统或容器环境里需要补装# CentOS/RHEL 系 yum install -y openssh-clients # Debian/Ubuntu 系 apt install -y openssh-client另一种是远程服务器上的 scp 不可用。较新版本的 OpenSSH 默认不启用 SFTP 子系统时会连带影响 scp或者服务器上没有安装 openssh-clients但这种情况比较少见。判断方法很简单本地执行scp报错先看是本机还是远程的问题——如果命令刚输完立刻报 No such file大概率本机缺少命令如果输完密码之后才报那可能是远程端的问题。5.3 Connection refused / Connection timed out 连接失败这个错误和认证无关属于网络层问题。Connection refused通常意味着目标端口没开常见原因是服务器上的 SSH 服务没启动或者端口不对。Connection timed out则意味着网络不可达常见原因是防火墙拦截、跨网段路由不通、或者云服务器的安全组没有放行 22 端口。我在云服务器上碰到过最典型的场景新买一台云主机安全组默认只放行了 80/443 端口SSH 的 22 端口没开从本地 telnet 测试端口不通但服务端 sshd 实际是正常运行着的。排查时不要直接盯着服务器内部看先在本地测一下端口通不通telnet 192.168.1.100 22如果卡住不动或提示无法连接说明网络层就被拦住了这时候去查防火墙、安全组、路由不必先折腾 sshd 配置。如果 telnet 能连通再考虑认证层面的问题。5.4 传输大文件时中断、速度慢、磁盘占满scp 传大文件中断后不能续传这个痛点前面已经说过用 rsync 加-P解决。但如果你用 rsync 依然慢那就要分析慢的原因了。先看是不是带宽瓶颈用iperf3这类工具测一下本地到服务器的实际带宽如果带宽本身就只有 1-2MB/s那传输慢是物理限制调什么都没用。如果带宽充足但 rsync 慢可能是压缩率不匹配——传已经压缩过的文件tar.gz、zip、mp4时不要加-z强行压缩反而增加 CPU 消耗和等待时间。还有一个被忽视的问题磁盘空间不足。 rsync 传输时会先在目标目录写临时文件如果服务器的目标磁盘分区快满了rsync 会中途报No space left on device。这个问题不是网络问题但报错时很容易让人往网络方向排查。检查目标磁盘空间df -h /var/www/如果剩余空间不足先清理旧文件或者换目标路径。另外如果你用了--partial参数中断时会留下临时文件这些文件占着磁盘空间如果不清理下一次重试时报 No space 的概率更大。所以断点续传虽然是好功能但也意味着你要定期清理残留的半成品文件。5.5 中文文件名乱码与编码问题本地是 Windows服务器是 Linux传带中文文件名的文件过去后显示乱码这本质上是两端字符编码不一致的问题。Linux 默认使用 UTF-8Windows 的中文环境默认使用 GBK/GB18030传输过程并不会做编码转换于是文件名里中文部分的字节被“解释”错了。我给出的实际处理建议很简单优先避免中文文件名。服务器上的文件命名统一用英文、数字、下划线、横线养成这个习惯能规避掉 90% 的编码类问题。如果确实有大量中文文件名的文件必须传输建议先打包再传传到服务器后再解压比如在本地压缩成 zip 时使用 UTF-8 编码Windows 10 以上的资源管理器右键压缩默认就是 UTF-8服务器端用unzip -O utf-8解压或者用 7z 工具指定编码解压。如果你用的是云服务器和本地电脑都有完善的 UTF-8 环境比如 macOS、现代 Linux 桌面这个问题基本不存在。5.6 传输后文件权限不对服务起不来scp/rsync 传文件过去后有时候会遇到“文件明明在但服务就是启动失败”的情况。最常见的原因是权限不对比如配置文件所属用户应该是nginx结果传过去后是rootnginx 启动时读取配置文件就报权限错误。解决分两步传输时用-p保留权限属性scp 和 rsync 的-a都会保留或者传输完成后显式修正属主和权限chown nginx:nginx /etc/nginx/nginx.conf chmod 644 /etc/nginx/nginx.conf这是一个很重要的习惯传输文件本身不是终点传输后检查属主、权限、SELinux 上下文如果启用的话、以及服务是否能正常读取这些都要纳入操作流程。我见过很多新手传完文件就以为完事了结果服务起不来又到处排查最后发现只是权限少了个读位。6. 个人经验补充用顺手的组合与日常习惯聊到最后我分享一下我个人实际使用的组合套路。日常工作中我几乎不用 scp 做批量或同步操作主力就是 rsync因为它的增量同步、断点续传、目录镜像能力太适合“频繁更新部分文件”的运维场景了。scp 我只在极简单的一次性单文件传输时使用比如临时传一个小配置文件。lrzsz 我则是在服务器网络受限、只有跳板机中转的情况下才亮出来平时根本不碰。图形界面方面我推荐所有 Windows 用户在桌面上保留一个 WinSCP 或者 FinalShell 的图标。WinSCP 走的是 SFTP 协议跟服务器上的 SSH 服务天然兼容不需要额外安装任何东西拖拽式操作特别适合新手上手。FinalShell 则集成了终端和文件管理左边是本地目录右边是服务器目录文件拖拽可以直接完成上传下载还能在打开 SSH 终端的同时管理文件对刚入门的朋友特别友好。不过我也要提醒一句图形工具适合小批量、交互式操作真正涉及自动化、定时同步、批量分发的时候命令行和脚本才是王道。最后再分享一个小技巧每次做大规模传输之前先查看一下目标目录的磁盘空间检查一下远程路径是否写对再用-n干跑一下 rsync。这三件事加起来花不到 30 秒但能避免 90% 以上的低级失误。我踩过的坑——传错目录导致覆盖了线上文件、--delete误删了整个目录、远程路径少打了一个斜杠导致文件被传到了错误的位置——全部可以用这 30 秒的操作来避免。谨慎不是胆小是对生产环境的敬畏。