连上远端后编辑卡顿，先别急着归因于网络。通常需要把“链路往返”和“远端资源占用”分开测：在卡顿正在发生的那一刻，去远端看负载和进程，同时在本地看 RTT 抖动与丢包，再用最小会话复现，最后对比纯编辑与执行命令的耗时。只有把这几组读数对上时间点，才能判断是链路延迟还是远端进程在抢资源。

判断方向：若远端 load 明显高于 CPU 核数、%wa 高或内存紧张，而 RTT 与丢包稳定，优先查远端进程；若远端负载正常，但 ping/mtr 出现持续抖动或丢包，且纯编辑也卡，优先查链路。操作上，先在卡顿时刻采样，再换最小会话和空目录复现。风险边界：ICMP 可能被限速，单次高延迟不能定论，需要多次采样并结合 SSH 与编辑器自身行为确认。

远端先看整体负载与占用最高的进程

卡顿发生时，先登录远端（或另开一个 SSH 会话），按同一时间窗口采样，不要等卡完再看。基础命令如下，注释说明读数含义：

uptime
# load average 看 1/5/15 分钟；与 CPU 核数对比，接近或超过核数表示排队明显
nproc
# 确认可用核数，容器里可能是被限制的份额

free -m
# 重点看 available、swap 使用量；swap 被大量使用会拖慢响应

top -b -n1 | head -n 20
# 看 %us、%sy、%wa、%id；%wa 高说明磁盘等待重

ps -eo pid,ppid,pcpu,pmem,stat,etime,comm `--sort`=-pcpu | head -n 15
# 按 CPU 排序，找占用最高的进程；再按内存排一次：`--sort`=-pmem

容器或 cgroup 环境下，还要看限额，比如 cat /sys/fs/cgroup/cpu.max 和 cat /sys/fs/cgroup/memory.max。远端进程抢资源不一定是 CPU，也可能是磁盘 I/O、内存回收或编译任务。读数要结合卡顿出现的时间点；如果采样时负载已回落，需要下一次卡顿再采。

测本地到远端的往返延迟与丢包

把链路质量变成可比较的数字，至少看平均 RTT、最大 RTT、抖动和丢包。先在本地执行：

ping -c 20 远端地址
ping -i 0.2 -c 100 远端地址
# 观察 min/avg/max/mdev，mdev 可当作抖动参考；-i 需要权限时用 0.5 或去掉

mtr -rwzbc 50 远端地址
# 看每一跳的丢包和延迟，判断问题在本地出口、中间跳还是远端入口

如果 ICMP 被限制，用 TCP 端口连通和耗时做替代：nc -vz -w 2 远端地址 22，或 curl -o /dev/null -s -w 'connect:%{time_connect} total:%{time_total}\n' http://远端地址:端口/。连续测试时把结果落盘，例如 ping -D -n -c 300 远端地址 | tee ping.log，再和卡顿发生的时间对照。单次 ping 高不能说明链路差，要看是否持续出现以及是否与卡顿同步。

换一个最小会话复现同样的操作

排除插件、索引和大仓库的附加因素。先关掉或暂时禁用这些可选项：文件树全量索引、语言服务与代码补全、Git blame 与 gutter、自动保存、保存时格式化、远端搜索、大仓库监视。然后在远端新建空目录，只放一个小文件，用同一编辑器的干净配置打开：

mkdir -p /tmp/comote-min && cd /tmp/comote-min
printf 'hello\n' > a.txt
# 用最小模式打开，例如 vim -u NONE a.txt 或编辑器禁用扩展后打开

操作步骤：连续输入一段短句，观察按键到字符出现的延迟；再按保存，观察保存完成时间。如果最小会话不卡，问题更可能在插件、索引或仓库规模；如果最小会话仍然卡，回到远端负载与链路读数继续排查。这个复现只用于定位，不要求一直使用最小配置。

对比纯编辑与执行命令两种操作的耗时

纯编辑看的是“按键到回显”，执行命令看的是“回车到远端进程返回输出”。在远端 shell 里做几次简单调用，例如：

for i in 1 2 3 4 5; do /usr/bin/time -f 'real %e' sh -c 'true'; done
for i in 1 2 3 4 5; do date +%s%3N; done
# 观察远端起进程和返回输出的间隔；不要在远端跑重负载任务

记录时把两类操作分开，并同步记下当时的远端负载和 RTT。可以按下面样式记录：

如果纯编辑卡而执行命令很快，优先怀疑链路抖动或客户端渲染；如果两者都卡，远端资源或磁盘更可疑；如果纯编辑不卡而执行命令慢，更多是远端调度、磁盘或进程竞争。

什么程度算链路问题、什么程度算远端资源问题

用两组读数交叉判断，而不是只看一个指标：

• 远端 load 持续高于 nproc，或 %wa 长期偏高、可用内存紧张并伴随 swap 使用，同时 RTT 和丢包较稳定：优先按远端资源问题处理，先找占用最高的进程，确认是否有编译、索引、备份等任务。
• 远端负载正常，但 ping/mtr 显示 RTT 抖动明显、丢包在连续采样中反复出现，并且纯编辑输入也同步卡：优先按链路问题处理，换时段或换网络环境复测。
• 远端负载正常、链路也正常，但只有大仓库或开启插件后卡：按编辑器附加功能或仓库规模处理，用最小会话再次对比。
• 远端负载高且链路也抖动：两者可能叠加，先降低远端负载再复测链路读数，观察卡顿是否同步变化。

判断边界需要结合环境确认：ICMP 限速会让 mtr 的中间跳丢包看起来偏高，单次采样也不足以下定论。比较可靠的做法是在卡顿发生时刻连续采样几次，并把远端负载、进程排序、RTT 抖动和丢包放在同一时间轴上对照。若降低远端负载后输入延迟明显改善，远端资源占比更大；若远端负载不变而换网络后改善，链路占比更大。