企业官网建设流程全解析

用 WinSCP 的人，多半不是因为它多好用，而是因为 Windows 上一直没遇到更顺手的。我用了它大概八九年，从早期的 4.x 一直用到 5.x，界面几乎没变过：左边本地、右边远端，双栏拖拽，稳得像块砖。问题在于场景变了。我现在的日常是 Windows 台式机加一台 macBook，中间还要连 Ubuntu 的测试机、树莓派、几台客户内网的跳板机，WinSCP 只在 Windows 上存在，一旦换机器，会话列表、密钥路径、编码设置全部要重来一遍。去年给一个客户排障，它的生产机是 CentOS，日志目录里全是一堆 GBK 文件名，WinSCP 那边编码选项改了三次还是花屏，我临时换了一个开源的 SSH 客户端——就是这篇要聊的主角 electerm，一次就拖下来了。

这篇文章写给三类人：一是长期用 WinSCP、想换但怕迁移成本太高的运维和老后端；二是在 Windows、macOS、Linux 之间来回切，受够了会话配置不同步的开发者；三是需要图形化 SFTP 又要顺手用终端的人。electerm 在 GitHub 上开源，走的是 SSH 客户端加 SFTP 图形界面的路子，跨三平台，配置能同步，终端和文件面板放在同一个窗口里。下面我会把它拆开讲清楚：它凭什么替掉 WinSCP、哪些地方它反而更弱、迁移时踩过哪些坑，以及我长期使用后沉淀下来的配置习惯。

1. 我在什么场景下决定放弃 WinSCP

1.1 不是 WinSCP 变差了，是我的工作方式变了

先把话说在前头，WinSCP 到今天依然是一个非常合格的工具，它对 SFTP、SCP、FTP、WebDAV 的支持相当完整，脚本化和命令行参数在 Windows 批处理里几乎是最好用的那一档，我到现在还有几个自动化任务在用它。真正让我动摇的是三个很具体的使用摩擦。

第一个是平台绑定。WinSCP 只有 Windows 版本。我的工作流是白天在 Windows 上写代码、跑编译，晚上在 macBook 上继续看日志和改配置。这两台机器上要维护两套连接信息，一旦服务器密码改了就得到处同步。有人说那就装虚拟机，我试过，为了连一台内网机器开一个虚拟机，这个开销放在 2025 年实在说不过去。

第二个是终端和文件的割裂。WinSCP 内置了一个终端，但那个终端的能力跟专业工具差得比较远：没有像样的多标签分屏、没有关键字高亮、没有方便的复制策略。我以前的固定动作是 WinSCP 管文件、Xshell 或 PuTTY 管命令，两个窗口来回 Alt+Tab，粘一段路径都要切两次。这个动作一天重复几十遍，累积起来就是实打实的时间损耗。

第三个是多机操作的效率问题。我手上有六台规格一致的测试机，改完一个配置文件要同步到六台上。WinSCP 的"同步浏览"能做到，但同屏输入命令这种需求它没有。而这个需求在换环境、批量改 hosts、批量看服务状态的时候出现得非常频繁。

1.2 我挑替代品的六条硬指标

踩过一次坑之后，这次换工具我没有直接搜"最好的 SSH 客户端"，而是先列了自己的硬指标，再拿工具去对。这套办法推荐给所有准备换工具的人，因为它能防止你被宣传页上那些炫酷截图带偏。

按这六条筛下来，能同时满足前三条的其实不多。很多外观很漂亮的 SSH 客户端是闭源的，用起来不错但数据都存在厂商服务器上，导出选项藏得很深；还有一些只做终端不做 SFTP，文件操作还得回到命令行用 scp，反而更麻烦。

提示：选这类工具时，优先确认"会话数据存在哪里"。存在本地文件里的，出问题能自己修；只存在云端并且不能导出的，那你的连接信息实际上不完全归你管。

1.3 候选名单和淘汰理由

我当时列了四个候选：electerm、WindTerm、Tabby，还有继续留在 WinSCP 加 PuTTY 的组合。淘汰过程大致是这样的。

WindTerm 我很喜欢，它是 C/C++ 写出来的，启动快、内存省，在老旧笔记本上体验明显更好，串口和 Telnet 支持也扎实。它的短板在于图形化 SFTP 的交互细节，拖拽和右键菜单的顺手程度跟 WinSCP 那条成熟路线还有距离，而且界面风格偏"工程化"，主题定制余地小一些。

Tabby 界面是这几个里最现代的，插件体系设计得干净，配置和配色方案都很漂亮。但它的重点在终端本身，SFTP 文件管理需要依靠额外能力补足，对我这种"一半时间在拖文件"的人来说不够直接。

WinSCP 加 PuTTY 的组合继续用其实也能过，成本是每天多切换几十次窗口，以及每次换设备都要重建一遍会话。

最后留在 electerm 上的理由说起来有点土：它的窗口布局最接近 WinSCP。左边一棵会话树，右边上面是终端标签、下面是 SFTP 双栏，操作习惯基本不用改，迁移那天的适应期不到一小时。对一个要天天用八九个小时的工具来说，这个"不用重新学"的价值比多几个炫酷功能高得多。

2. electerm 拆开看：它凭什么同时管好终端和文件

2.1 一个 Electron 外壳里装了什么

electerm 是拿 Electron 做的桌面外壳，界面用前端技术栈渲染，终端部分用的是 xterm.js 这类成熟方案，SSH 和 SFTP 的协议实现靠的是 Node 生态里的 ssh2 库。这个技术选型直接决定了它的性格：优点和缺点都来自同一处。

说它为什么能同时做好终端和文件面板，得回到 SSH 协议本身。很多人以为 SFTP 是"另一个协议、另一个端口"，其实不是。SFTP 是 SSH 之上的一个子系统，它和你在终端里敲命令用的 shell 会话，共用同一条 TCP 连接，只是各自占一个独立的 channel。所以你连上一台机器，同一条加密隧道里可以同时跑着：一个 shell 会话、若干个 SFTP 文件操作、还有你需要时开的端口转发。这三条通道互相隔离又共享底层连接，任何一条断了不会把另外两条带崩。

理解这一点之后，electerm 的布局就很好解释了：左边那棵树是连接配置，右侧上半部分的终端标签对应 shell channel，下半部分的双栏对应 SFTP 子系统。它们不是两个软件拼在一起，而是同一个连接上的两个视图。这也是它比"WinSCP 管文件 + 另一个终端工具管命令"更高效的根本原因——省掉的不是一次点击，而是一次完整的重连和一次身份认证。

Electron 的代价也在这里。它自带一整个浏览器内核，一个空窗口的内存占用就是好几十兆起步，开十几个会话之后跟一个原生应用比会明显更吃资源。我在 16G 内存的台式机上完全没有感觉，在 8G 的旧笔记本上能接受但不轻松，在 4G 的机器上就会有点难受。这条取舍你要提前想清楚：换来的是跨平台一致性和更快的功能迭代速度，付出的是内存。

2.2 和 WinSCP、WindTerm、Tabby 的横向对照

下表是我自己实测后的总结，版本不同细节会有差异，具体能力请以各自仓库当前说明为准。

从表里能看出一个清晰的定位：electerm 是这几个里"终端和文件两条腿最均衡"的那个。它没有任何一项是绝对第一——文件管理不如 WinSCP 成熟，终端性能和内存不如 WindTerm，界面和插件生态不如 Tabby——但它也没有明显短板，而且跨平台和配置同步这两点直接命中了我最痛的地方。

2.3 安装与首次启动要留意的几个细节

安装包在它自己的 GitHub 仓库 Release 页面，按系统选对应的产物。我列一下我实际用过的几种方式，以及每种方式需要注意什么。

• Windows：直接用安装包，装完会在开始菜单创建快捷方式。不喜欢安装的可以下便携版，解压即用，配置文件会写在程序目录旁边，拷贝到 U 盘就能带走整套会话。
• macOS：下载对应架构的 dmg。第一次打开如果提示来源限制，在"系统设置 - 隐私与安全性"里放行即可。注意 M 系列芯片和 Intel 芯片的包不是同一个。
• Linux：官方会给 AppImage、deb、rpm 等几种形式。AppImage 需要先给可执行权限，用chmod +x之后双击；如果你在公司环境里不方便用 AppImage，选 deb 或 rpm 走包管理器更省心。

# AppImage 形式的启动方式 chmod +x electerm-*-linux-x86_64.AppImage ./electerm-*-linux-x86_64.AppImage # 如果提示缺少 FUSE sudo apt install -y libfuse2

第一次启动后我建议先做两件事：一是进设置把界面语言切成中文（如果版本支持），二是把字体换成你习惯的等宽字体。默认字体在很多环境下渲染中文会比较糊，换成更合适的等宽字体之后，终端里看ls -l的对齐会舒服很多。

注意：便携版和安装版的配置目录不一样。如果你一开始用便携版，后来换成安装版，会发现会话全没了，别慌，把配置目录里的文件手动拷过去就行。反过来也一样。

3. 把 WinSCP 的日常操作搬到 electerm

3.1 会话书签与旧配置的导入

WinSCP 的会话存在注册表或者 ini 文件里，electerm 用的是自己的 JSON 配置。两者格式不通，所以别指望一键导入，实际最省事的路径是重录一遍。听起来麻烦，但我手上二十多个会话，录完花了不到二十分钟，而且录的过程顺手把一批过期条目清理掉了。

录入的时候有几个字段值得认真填，不要图快：

• 名称：用"环境-用途-机房"这种结构，比如prod-web-sh-01、test-db-bj-02。会话一多，模糊命名会让你每次都要点开看一眼 IP 才敢连。
• 端口：非 22 的端口一定要显式填。我见过有人在测试环境里被改成了 2222，连接失败排查了半小时才发现是端口。
• 认证方式：优先用密钥。密码方式能用，但每次都要输，而且密码会以可解密的形式存在本地配置文件里。
• 编码：这个字段后面单独说，先记住它有。

另外它支持读取 OpenSSH 风格的 config。如果你本来就维护着~/.ssh/config，在里面写好的 Host 别名、端口、用户名、密钥路径，可以被识别进来，省掉一部分重复录入。对于需要跨跳板机的场景，config 里的写法是这样的：

Host jump HostName 10.0.0.10 User ops Port 22 IdentityFile ~/.ssh/id_ed25519 Host inner-db HostName 172.16.8.21 User dba ProxyJump jump

这段配置的意义是：你只需要把inner-db加进客户端，它会自动先连jump，再由jump转到内网机器，你不用手动开两次连接。这套写法在 OpenSSH 生态里是通用的，会写一次，以后换任何客户端都能复用。

3.2 双栏文件管理：拖拽、权限、外部编辑器

SFTP 面板的基本操作跟 WinSCP 高度一致：从本地区域拖到远端区域就是上传，反过来就是下载，右键能新建目录、重命名、删除。真正值得讲的是三个容易被忽略的能力。

第一是权限修改。右键文件属性，可以像 WinSCP 那样用勾选框改权限，也可以直接输入八进制数字。这里有个很实际的场景：往服务器上传一个部署脚本，上传后因为没有执行位而跑不起来，直接右键勾上执行权限比回到终端敲chmod快得多。记住那个八进制对照关系就够了：读是 4、写是 2、执行是 1，755 表示属主可读写执行、同组和其他人可读可执行。

第二是外部编辑器。双击一个文本文件，选"用外部编辑器打开"，它会下载到临时目录、调用你系统默认的编辑器。你在编辑器里改完保存，切回客户端，它会检测到文件变化并自动回传。这个功能我用来改 nginx 配置和一堆 yaml，比在终端里开 vim 舒服得多，尤其是需要大段粘贴的时候。

注意：外部编辑器走的是"下载到临时文件再上传"的路径，所以它一定会有一次时间差。如果你在编辑期间别人也改了同一个文件，后保存的会直接覆盖前者。生产环境的配置改动前，先复制一份备份是基本纪律。

第三是编码处理。这是从 WinSCP 迁移过来的人最容易卡住的地方，我放在踩坑章节详细说，这里先给结论：遇到乱码，优先怀疑远端 locale 和文件名实际编码，而不是客户端设置错了。

3.3 终端里的 Zmodem：让 rz 和 sz 重新可用

Zmodem 是老一代 Unix 玩家非常熟悉的东西。在终端里敲sz filename，文件会顺着终端的字符流传回来；敲rz，等待你把文件推上去。它的原理不是新开一个连接，而是在终端的数据流里嵌入协议帧，客户端识别到特定序列之后接管这段流，弹出文件选择框。

WinSCP 内置终端对这个支持一般，electerm 在这方面做得不错，配合服务器的lrzsz包就能用：

# 服务器端先确认装了 lrzsz which sz || sudo yum install -y lrzsz # CentOS / RHEL 系 which sz || sudo apt install -y lrzsz # Debian / Ubuntu 系 # 从服务器往本地取文件 sz /var/log/app/error.log # 从本地上传到服务器当前目录 rz -E

用rz上传时加-E是我踩坑之后养成的习惯，它对已存在的文件做覆盖时会走更稳的路径，避免传完之后目录里出现一堆带后缀的临时文件。另外要注意：rz 上传的目标目录是服务器当前所在目录，不是客户端面板里选中的目录，这个认知差会导致很多人传完之后找不到文件，以为上传失败了。

3.4 用端口转发把内网数据库接到本地客户端

这个功能是我认为所有 SSH 客户端里价值被低估最多的一个。很多内网服务的数据库端口不对外开放，但跳板机是通的。这时候不需要改任何防火墙规则，也不需要给数据库配远程访问权限，一条 SSH 隧道就够了。

原理很简单：SSH 连接本身支持开一条转发通道，把本地某个端口收到的流量加密后送到远端，再由远端帮忙转发到目标地址。配置里通常填三个值：本地端口、远端目标主机、远端目标端口。比如本地监听 13306，转发到远端网络里的172.16.8.21:3306，之后你在本机用数据库客户端连127.0.0.1:13306，就等同于连上了那台内网数据库。

几条实操经验：

• 本地端口尽量避开常用端口，别用 3306 本身，否则本机装了数据库的话会冲突。
• 隧道建立后不要关那个标签，隧道是挂在会话上的，会话断了隧道就断。
• 长时间挂着隧道时把 keepalive 打开，否则中间的网络设备会因为会话空闲把它清理掉，表现就是"用着用着突然连不上"。
• 数据库客户端记得关掉 SSL，因为链路已经由 SSH 加密，很多内网库没有配证书，开着反而报错。

3.5 多标签、分屏与关键字高亮

终端这边，我最常用的三个动作是：多标签、分屏、关键字高亮。

多标签不用多说，一台机器一个标签，按环境分组。分屏的价值在于对比，比如左边开着tail -f看日志，右边敲命令观察服务状态，不用来回切。

关键字高亮是我从专业终端工具那边带过来的习惯。给ERROR、Exception、Timeout、failed这类词配上红色，看日志的效率提升很明显——你不需要逐行读，扫一眼就能定位到异常段。同理，把success、ok、done配成绿色，批量操作的进度一眼可见。

3.6 多机同屏输入与批量操作

前面说过我有六台规格一致的测试机。这种场景下同屏输入的价值非常大：你在一个输入框里敲命令，所有被选中的会话同时执行，输出分别显示在各自的窗口里。

适用场景：批量改 hosts、批量看某个服务状态、批量下发一个脚本、批量改时区。不适合的场景同样要记住：任何会重启服务、改网络、改内核参数的操作都不要用同屏输入，一旦打错，六台同时挂掉，恢复成本是单台的六倍。我的做法是先用同屏跑只读命令看状态，确认无误之后再单台执行变更，跑通了再放开批量。

3.7 配置同步与备份

会话多起来之后，同步就成了刚需。electerm 支持把配置同步到自己的后端，也支持接别的存储方式。我的建议是：优先手动导出加版本管理，其次才是自动同步。

原因很实际。自动同步虽然方便，但会话配置里含主机地址、用户名、密钥路径，一旦同步账号出问题，等于把一份内网拓扑图交出去了。我自己的做法是每周手动导出一次配置，放进一个私有仓库，导出的 JSON 里密钥部分本来就不含私钥内容，风险可控。换机器的时候从仓库拉下来导入，十分钟搞定。

3.8 主题与字体：把每天看八小时的东西调舒服

这一节看起来像废话，但我确实认为它值得单独说。终端是每天盯八小时的东西，配色和字体的舒适度直接影响疲劳程度。几个我调过之后不再改的项：

• 字体：选一个中英文对齐都好的等宽字体，字号比默认大 1 到 2 号。默认字号在 1080p 屏幕上偏小。
• 行高：稍微调大一点，密集输出的时候更容易定位行。
• 主题：不要选纯黑底纯白字，对比度太高，长时间看眼睛累。深灰底配柔和前景色更耐看。
• 光标：改成块状，在长命令行里定位插入位置更快。

这些设置改完可以导出，跟会话一起带着走，换机器时不用重新调。

4. 迁移过程中真正让我卡住的几个问题

4.1 中文文件名乱码：问题多半不在客户端

这是我迁移第一天就撞上的坑。远端一台老服务器上的日志目录，文件名在 WinSCP 里显示正常，在 electerm 里全是方块或者问号。我一开始以为是客户端编码设置的问题，来回改了三次没解决。

后来把链路捋清楚了才明白：SFTP 协议规定文件名按 UTF-8 传输，但老服务器上创建这些文件的程序当年用的是 GBK 或者 Latin-1，文件名在文件系统里存的就是那串字节。客户端拿到字节，按 UTF-8 去解码，自然就花了。WinSCP 之所以显示正常，是它默认对非 UTF-8 做了一层容错处理。

解决路径有两条。一是客户端里把远端编码显式指成对应编码，能解决大部分显示问题；二是从根上处理，把远端环境的 locale 统一成 UTF-8，让新生成的文件名都是 UTF-8。前者是临时方案，后者才是长久之计。查远端 locale 的命令：

locale # 关注 LANG 和 LC_ALL，如果是空或者 C，就该改了 # 临时生效 export LANG=zh_CN.UTF-8 # 永久生效（Debian / Ubuntu） sudo locale-gen zh_CN.UTF-8 sudo update-locale LANG=zh_CN.UTF-8

4.2 私钥格式：从 .ppk 到 OpenSSH 的转换

如果你以前在 Windows 上用 PuTTY 生成过密钥，那私钥多半是.ppk格式，electerm 不认。反过来，如果你手上有 OpenSSH 生成的新格式私钥，有些较老的客户端也不认。这类"连接被拒绝、提示认证失败"的问题，八成是格式不匹配。

判断方法很简单，用文本编辑器打开私钥文件看开头那一行：写着BEGIN OPENSSH PRIVATE KEY的是新格式，写着BEGIN RSA PRIVATE KEY的是传统 PEM 格式，而.ppk文件开头会明确写着PuTTY-User-Key-File。

转换方式我推荐两种，按你手上有什么工具选：

# 传统 PEM 和 OpenSSH 新格式互转（会原地覆盖，先备份） ssh-keygen -p -m PEM -f ~/.ssh/id_rsa # 转成传统 PEM ssh-keygen -p -m OPENSSH -f ~/.ssh/id_rsa # 转成 OpenSSH 新格式 # 权限必须对，否则 OpenSSH 相关工具会直接拒绝加载 chmod 700 ~/.ssh chmod 600 ~/.ssh/id_ed25519 chmod 644 ~/.ssh/id_ed25519.pub

.ppk的转换需要一个专门的转换工具，或者直接用 PuTTY 自带的密钥生成器把私钥重新导出成 OpenSSH 格式。这一条看起来琐碎，但它是跨平台迁移里出现频率最高的障碍之一。

注意：私钥文件权限过宽时，很多工具不是报警告，而是直接拒绝使用。我遇到过有人把私钥放在共享盘上，权限是 777，折腾了一下午也没连上，最后就是这一条。

4.3 大文件传输与断点续传

WinSCP 在大文件传输和断点续传这块做得很成熟，electerm 相对弱一些。实际表现是：几百兆的文件走 SFTP 没问题，速度也正常；但如果传到一半网络抖了，续传不一定能自动接上，有可能需要重传。

我的应对办法是把大文件操作从图形界面剥离出去，交给命令行：

# 带续传和进度显示的文件同步，比在图形界面里拖更稳 rsync -avz --partial --progress \ -e "ssh -p 22" \ ./bigdata.tar.gz ops@10.0.0.10:/data/backup/ # 参数含义： # --partial 保留中断的部分文件，下次可以接着传 # --progress 显示进度 # -z 传输时压缩，文本类文件收益明显，已压缩的包收益很小

这条建议其实超出客户端本身了：图形界面适合小文件和零散操作，大文件和批量同步交给 rsync。这两个分工明确之后，我在客户端上再也没有因为传输中断浪费过时间。

4.4 内存占用与老机器上的取舍

前面提过 Electron 的内存代价。实测下来，开五个会话加一两个 SFTP 面板，占几百兆内存是正常的，跟一个原生客户端比是明显的差距。在老机器上的取舍逻辑是这样的：如果机器内存 8G 以上，这点占用不值得纠结；如果是 4G 的老笔记本，而且你的主要需求就是终端敲命令、几乎不拖文件，那 WindTerm 这类轻量方案更合适。工具要匹配场景，不是越新越好。

4.5 会话断连与 keepalive 设置

"用着用着就断了"这件事，在跨机房、跨云的环境里几乎必然遇到。原因通常是中间的防火墙或者 NAT 设备对空闲连接有老化时间，比如 30 分钟没流量就回收会话。你的客户端以为自己还连着，实际链路已经没了。

解决办法是在 SSH 配置里打开心跳，让客户端定期发一个空包维持链路：

Host * ServerAliveInterval 30 ServerAliveCountMax 6 TCPKeepAlive yes

这段配置的意思是：每 30 秒发一次心跳，连续 6 次没有回应才判定断线，总共给了三分钟的容错。这个组合能解决我遇到的绝大部分非人为断连。

5. 长期使用下来，我固定的几个习惯

5.1 会话命名和环境隔离

会话一多，命名就是纪律。我的规则是环境-角色-位置-序号，比如prod-web-bj-03、stg-db-sh-01。同时在客户端里按环境分组，生产、预发、测试、本地分开，生产环境的组用不同颜色标识。这个颜色不是为了好看，是为了在你困得不行的时候，减少连错机器的概率。连错生产环境敲错命令，是所有运维事故里最常见的一类。

5.2 密钥管理和默认认证方式

我现在所有机器都走密钥，密码登录只在极少数老设备上保留。密钥统一放在一个固定目录，命名和会话命名规则对应，权限一律 600。同一条密钥如果用在多台机器上，一旦某台机器的环境被污染，风险会横向扩散，所以我现在倾向于按机器或者按环境分开生成密钥，虽然麻烦一点，但出了问题能精准吊销。

另外，客户端会记录会话信息到本地配置里，这意味着你的工作笔记本本身就是一个敏感载体。加密磁盘、开机口令这些基本动作该做还是要做。

5.3 什么时候我仍然会打开 WinSCP

最后说句公道话。到目前为止我有两个场景还在用 WinSCP：一是 Windows 上的批处理自动化脚本，它的命令行参数和脚本能力确实成熟，我暂时没打算改；二是极少数只提供 FTP 的老设备，WinSCP 对老协议的支持面更宽。除此之外的日常操作，无论文件还是命令，我都已经切到 electerm 上了。

工具替换不需要一刀切，也不需要仪式感。给自己两周并行使用期，把最痛的场景先迁过去，剩下的按需保留，才是成本最低的做法。我自己的并行期是十天，第十天之后 WinSCP 就只剩下那两个自动化任务了。