企业官网建设流程全解析

如果你经常要把本地文件传到 Linux 服务器，或者把服务器上的日志拉到本地，一定会遇到 rz 这个命令。rz 是 lrzsz 软件包里的上传命令，基于 ZMODEM 协议，必须配合支持该协议的终端工具使用。很多命令大全里会把它和 scp、sftp 放在一起，但实际用起来差异很大。下面按实际落地顺序拆一遍：先确认它解决什么问题，再安装、跑通、调参，最后说清楚哪些场景别用它。

我一直觉得 rz 属于那种“看着简单，但容易踩坑”的命令。最大的坑就是很多人执行 rz 之后半天没反应，或者传完不知道文件去了哪。本文不会只列参数，我会把安装、基本用法、目录位置、大小限制和排查链路一起讲清楚。

1. 先用一句话理解 rz：它解决的是“本地文件怎么进服务器”的问题

1.1 rz 到底是什么，和 scp、sftp 的差异在哪

rz 不是服务器上的独立服务，而是 lrzsz 软件包里的一个命令。它使用 ZMODEM 协议，在已经建立 SSH 会话的终端里，把你本地的文件传输到服务器当前目录。简单理解就是：你在服务器上敲一个 rz，终端会弹出一个本地文件选择窗口，选中文件后开始传输。

很多人会把 rz、scp、sftp 放在一起比较。它们确实都能传文件，但使用方式不一样。

scp 是从本地命令行发起的，比如你在自己电脑的终端里执行一条 scp 命令，把本地文件推送到服务器。它适合脚本自动化，也适合大文件。但你得先记住服务器地址、用户名、目标路径这些信息，写出来比较长。

sftp 是交互式文件传输工具，进入之后可以浏览服务器目录、上传下载。它比 scp 更适合临时查看远程目录，但多了一步交互。

rz 的思路是反过来的。你先已经登录到服务器，然后直接在服务器上执行 rz，文件从本地流向服务器。它不需要再指定 IP、端口、用户名，因为当前 SSH 会话已经替你完成了身份认证。

所以 rz 最适合的场景是：你已经登录服务器，临时要传一个小文件进去，比如配置文件、Java 的 jar 包、脚本、日志。这种情况就不用退出当前会话，也不用写一长串 scp 参数。

在“Linux 命令大全”里，rz 和 scp 经常被放在一起，但真实项目里它们不冲突。我的做法是小文件用 rz，大文件或自动化用 scp/rsync。

1.2 rz 上传的文件去哪了，很多新手都找错了

每次遇到有人说“rz 上传的文件不在服务器上”，我第一反应就是让他先pwd。

rz 的默认工作目录是执行命令时所在的当前目录，不是 /root，不是 /tmp，也不是某个固定路径。如果在 /home/app 目录下执行 rz，上传的文件就在 /home/app；如果在 /var/log 下执行，上传的文件就在 /var/log。

正确流程应该是：

cd /data/upload rz

先切换到你真正想放置文件的目录，再执行 rz。上传完成后，用ls -l确认文件大小和时间，用md5sum核对文件内容是否和本地一致。

还有个容易忽略的问题：如果当前目录已经存在同名文件，rz 可能直接覆盖，也可能提示你选择，这取决于终端工具和 lrzsz 版本。很多初始化安装场景里，旧配置就是这样被新文件不知不觉覆盖掉的。所以上传前先看一眼目录内容，比较稳妥。

2. 先检查环境：rz 不是所有 Linux 都自带的命令

2.1 安装 lrzsz：各发行版包管理器命令

很多 Linux 最小化安装默认不带 lrzsz。运行时会出现rz: command not found。

先检查：

which rz

有输出说明已经安装，没有输出说明需要装。不同发行版安装命令不同。

CentOS、RHEL 系列：

yum install -y lrzsz

Ubuntu、Debian 系列：

apt-get update && apt-get install -y lrzsz

安装完继续验证：

which rz

能显示 /usr/bin/rz 这类路径就说明安装成功。

为什么第一步要确认环境？因为 rz 无法独立工作，它依赖 lrzsz 包、终端协议支持、当前会话三个条件。很多问题看起来是命令用错了，实际上是环境没准备好。

2.2 终端必须支持 ZMODEM，不是所有 SSH 工具都行

rz 能不能弹出文件选择窗口，取决于你的 SSH 终端工具是否支持 ZMODEM 协议。

Xshell、SecureCRT、MobaXterm、FinalShell 等常见终端工具，默认或通过配置支持 ZMODEM。你在这些工具里登录服务器后执行 rz，终端会识别到 ZMODEM 上传请求，弹出本地文件选择框。

但不是所有终端都支持。Windows 自带的 OpenSSH 客户端、部分纯命令行环境，或者某些网页版终端，执行 rz 后很可能没有任何反应，甚至直接卡住。这不是 rz 命令坏了，而是协议没有载体去响应。

如果你遇到这种情况，第一件事不是换参数，而是换终端，或者干脆改用 scp/sftp。

我之前在自动化脚本里尝试过 rz，发现很难落地。因为 rz 需要弹窗交互，不是纯命令行输入输出。无人值守脚本里用 rz，基本都会卡住。自动化分发场景下，更合适的还是 scp 或 rsync。

3. 从一次最简单的上传开始：先跑通再谈效率

3.1 单文件上传的最小流程

不要一上来就研究一堆参数，先走一次最简单流程。

在服务器上执行：

cd /data/upload rz

终端弹窗后，选择本地一个文件，比如 test.tar.gz，确认上传。等进度条完成，回到命令行。

然后验证：

ls -l test.tar.gz md5sum test.tar.gz

本地也计算一下 md5sum，两边一致，说明文件完整。

这个流程能跑通，说明环境没问题。后面再谈参数优化、批量上传和目录上传。

注意权限问题。如果当前用户对 /data/upload 没有写权限，rz 会失败或上传后文件不完整。可以先新建一个自己有权限的目录，或者切换到有权限的用户。

3.2 常用参数：-y、-a、-b、-e 怎么选

lrzsz 的 rz 支持一些参数，常见的有：

实际项目中，上传 jar、war、tar.gz 这类二进制文件，我一般用：

rz -b

这样可以避免文本模式对文件内容做换行符转换，防止二进制文件损坏。

不要一上来就加-y。如果你不能确定当前目录没有同名文件，-y可能会覆盖掉上一份还能用的配置或包。先用ls -l看一遍，再决定是否覆盖。

不同 lrzsz 版本对参数支持不完全一样，记不住就执行：

rz --help

以你环境里的实际输出为准。

3.3 批量上传和目录上传：rz 并不擅长传目录

rz 支持一次选择多个文件上传。但在实际使用里，多文件传输的弹窗交互并不方便，文件名排序、选中状态也不直观。

更重要的是，rz 通常不支持直接传输整个目录。如果你把一个包含多层级文件的文件夹拖进弹窗，很多终端会忽略目录结构或报错。

正确的做法是把目录打包成一个文件，再上传。

本地打包：

tar czf app.tar.gz app/

上传到服务器：

cd /data/app rz -b

服务器上解压：

tar xzf app.tar.gz

解压前先看看目标目录里已经有什么：

ls -la du -sh .

这个习惯比任何命令都重要。很多人喜欢先来一句rm -rf 旧目录，一旦路径写错，数据就没了。我在项目里会先备份：

cp -r app app.bak_$(date +%Y%m%d)

确认新包正常后，再决定是否清理旧备份。

4. 开发运维里的高频组合：rz 不是孤立命令

4.1 Java 开发、Tomcat 配置和上传 war/jar

在实际开发中，Java 后端工程师经常要把 jar 包、war 包、配置文件上传到测试或生产服务器。这时候 rz 特别常用。

比如调整 Tomcat 运行内存，项目里常会配置 setenv.sh，里面写上 CATALINA_OPTS 之类的参数。你把本地修改好的 setenv.sh 上传到服务器，覆盖旧文件后重启 Tomcat。

但要注意，文件上传成功不等于服务能启动。最近遇到过一个 case：setenv.sh 用 rz 上传后，systemctl 启动 Tomcat 失败。排查到最后才发现，文件属主是 root，而 Tomcat 服务以普通用户运行，根本没有读取权限。解决办法是调整属主和权限：

chown tomcat:tomcat /data/tomcat/bin/setenv.sh chmod 750 /data/tomcat/bin/setenv.sh

所以 rz 传完文件后，别急着重启服务。先看日志，确认权限、属主、格式都没问题。

上传 war 或 jar 包时，我建议保留一份旧包：

cp app.jar app.jar.bak

然后用 rz 上传新包，用 md5sum 做校验，再启动服务。这样出问题可以快速回滚。

4.2 配合系统信息、磁盘和目录检查

rz 上传文件之前，最好先确认服务器状态。

查看磁盘剩余空间：

df -h

查看某个目录占用大小：

du -sh /data/app

查看系统架构，确定下载的软件安装包是否对得上：

uname -m

这些命令在 Linux 命令大全里很常见，平时可能觉得简单，但真正排查问题时非常有用。

比如你本地有一个 2GB 的依赖包，rz 传到一半卡住了。先看磁盘是不是满了：

df -h

如果磁盘满了，再怎么换参数都没用。删掉不必要的文件，或者把包传到另一个盘符下。

还有个小技巧，想要把之前输入过的命令导出备份，可以用：

history > cmd_history.txt

这个在做环境交接或写操作手册时很有用。

4.3 日志排查和命令执行现场

rz 和 sz 常常配合日志排查使用。服务器上的日志文件如果太大，直接在终端里 tail 看会刷屏。这时候可以先用 sz 下载到本地：

sz /data/logs/app.log

本地用文本编辑器打开，检索关键字更方便。

如果你负责多台服务器，想同时看多台机器的状态， rz 就不合适了。因为它需要交互弹窗。这种情况可以用 xargs -P 或 pssh 并行执行命令，但那是另一个话题。

记住一点：rz 是交互式命令，不适合无人值守脚本。脚本里要传文件，用 scp、rsync 或者自动化工具更可靠，也方便留日志和重试。

5. 传大文件或库文件容易中断？先别急着怪 rz

5.1 为什么 rz 传大文件会卡住或失败

很多人在帖子或工作群里问：“rz 传库文件老死掉”。这个现象不是偶发。

rz 基于 ZMODEM 协议，设计初衷偏向小文件、交互式传输。在会话稳定、网络质量好的情况下，传几个文件很舒服。但当文件达到几百 MB 甚至 GB 级，会暴露出几个问题。

第一，终端会话本身不稳定。SSH 会话如果因为网络波动断开，传输会直接失败。

第二，中间网络设备的限制。有些办公网络出口设备会限制长连接或大包传输，文件一大，连接就被掐断。

第三，终端软件对 ZMODEM 的实现质量不一。某些终端实现只能处理有限大小，超过阈值后表现不稳定。

中断后的文件有时看起来大小接近，但 md5 对不上。这时候如果不校验就直接解压或替换，服务会出各种奇怪问题。

所以我处理大文件时，不会把希望寄托在 rz 上。

5.2 更稳的长传方案：scp、rsync 和打包迁移

如果文件超过 100MB，或者要传整个目录，我更推荐用 scp 或 rsync。

scp 简单直接，从本地发起：

scp app.tar.gz user@server_ip:/data/app/

这个命令在本地终端执行，需要填写服务器地址和用户名。

rsync 更强的地方在于它可以断点续传，适合大文件或弱网环境：

rsync -avP app.tar.gz user@server_ip:/data/app/

-P 参数表示显示进度，并且支持断点续传。如果你只需要单次传输大文件，rsync 比 scp 更稳。

要传整个目录时，先把目录打包成 tar.gz，能减少文件数量，提高传输稳定性：

tar czf app.tar.gz app/

然后再用 scp 或 rsync 传输。

不同场景的工具选择，我习惯这样判断：

6. 常见报错与排查顺序：遇到问题按这个链路看

6.1 从现象到处理：一张表说清常见问题

rz 的问题看起来五花八门，但大部分可以归到几类。

6.2 推荐排查步骤

遇到问题不要乱猜，按顺序排查最省时间。

第一步，先确认命令存在：

command -v rz

第二步，确认当前目录：

pwd

第三步，确认磁盘空间：

df -h

第四步，确认文件是否真的到了：

ls -l

第五步，确认内容是否完整：

md5sum 文件名

第六步，看终端工具本身是否支持 ZMODEM。如果你用的终端不支持，直接换工具。

这套顺序看起来简单，但非常有效。我见过太多人上来就改参数，结果文件根本没传上去，问题出在目录不对。

7. 让 rz/sz 在项目里用得更顺手

7.1 常见配置和别名

如果你经常需要把文件传到固定目录，可以在服务器上定义别名。

比如新建一个上传目录：

mkdir -p /data/upload

然后在 ~/.bashrc 里写：

alias ru='cd /data/upload && rz -b' alias sd='cd /data/logs && sz'

保存后执行：

source ~/.bashrc

之后想上传文件，直接输入 ru 就会进入目录并启动 rz；想下载日志，输入 sd 就会进入日志目录并弹出下载窗口。

这样能给日常操作省一点时间，但不要把所有希望寄托在别名上。生产环境里传文件，最好还是用可记录、可重试的 scp 或 rsync。

另外，不要在有密码明文的地方写死自动上传逻辑。轻量交互用 rz 没问题，但可靠性要求高的场景，必须有日志、校验和回滚。

7.2 一次完整的上传发布流程示例

最后给一个我在项目里常用的发布流程，虽然不是标准答案，但能体现 rz 的合理用法。

本地先打包：

tar czf app.tar.gz app/

切换到目标目录并上传：

cd /data/app rz -b

校验文件：

md5sum app.tar.gz

备份旧目录：

cp -r app app.bak_$(date +%Y%m%d)

解压新包：

tar xzf app.tar.gz

重启服务并看日志：

systemctl restart your-service tail -f /data/logs/app.log

这套流程里，rz 只负责“把文件弄到服务器上”这个动作，其他步骤都用专门的命令。这样拆分之后，每一步都可以验证，出问题也知道卡在哪。

踩过几次之后我发现，很多问题不是 rz 命令本身不行，而是前置条件没确认：终端不支持、目录不对、磁盘满了、文件太大。遇到问题先按顺序排查，比反复换参数有效。更稳妥的做法是：小文件用 rz，大文件用 scp 或 rsync，自动化用脚本工具。把边界看清楚，rz 其实很好用。