28K Star，用 Go 写的 P2P 文件传输，为什么比 scp 还好用

原创

go
go

Go语言教程

2026年7月24日 13:04
陕西

在小说阅读器读本章

去阅读

把一份数据库备份从公司 Windows 传到家里 Mac，scp 还没敲，问题已经来了：目标机开没开 SSH？22 端口通不通？账号和密钥怎么给？机器躲在 NAT 后面又怎么连？

这种临时传文件，我一般不先碰 scp。

不是它慢，是它要求两台机器先建立一套“服务器关系”。

croc 处理的就是这个别扭点。题目里还是 28K Star，我查仓库时已经涨到 35.6K，最新版本是 2026 年 7 月 9 日发布的 v10.4.13。项目使用 Go 编写，发送文件只要一条命令。

croc send release.tar.zst

终端会生成一段短口令。接收端拿到口令后运行 croc 即可；Linux、macOS 新版建议通过环境变量传入，免得口令直接挂在进程参数里。

CROC_SECRET=\"短口令\" croc

我第一眼看这个交互就觉得对了。

临时传一个包，不应该先创建系统账号，再配公钥，再去改安全组。croc 支持 Windows、Linux、macOS，可以传目录和多个文件，传输中断后还能继续。

不过有个地方得说准。

它不是完全脱离中继的“纯直连”，更接近 relay-assisted P2P。发送端和接收端都主动连接 relay，通过短口令进入同一个会话，再使用 PAKE 协商会话密钥，传输内容端到端加密。

接收端不需要暴露 SSH 端口，也不用为了传个文件去做端口转发。

这和 scp 的差别，不在复制命令长短，而在连接模型。

scp release.tar.zst [email protected]:/srv/drop/

这行命令看着挺干净，背后默认了一堆条件：目标地址可达、sshd 正常、账号存在、目录有权限、密钥没失效。

任何一个条件不成立，都得先修环境，再谈文件传输。

croc 两端走出站连接，对临时网络、跨系统设备、家用路由器后面的机器，确实省事不少。

我比较看重的还有断点续传。

大文件已经跑了一大半，网络抖一下又从零开始，这种工具我基本不会长期留。用 Go 做可恢复写入，关键动作其实就是偏移量和分块校验：

type Block struct {
 Offset int64
 Data   []byte
 Sum    [32]byte
}

func saveBlock(dst *os.File, b Block) error {
 if sha256.Sum256(b.Data) != b.Sum {
  return fmt.Errorf(\"bad block at offset %d\", b.Offset)
 }

 if _, err := dst.WriteAt(b.Data, b.Offset); err != nil {
  return fmt.Errorf(\"write offset %d: %w\", b.Offset, err)
 }

 return nil
}

这不是 croc 的源码，只是把传输思路摊开。

文件拆成块，每块记录自己的偏移，落盘前做一次校验。连接断掉以后，接收端只需要补缺失部分，不必把前面已经写完的数据再跑一遍。

Go 写这类工具很顺手。网络连接、并发任务、文件流处理，标准库已经把难啃的地方包住了；编译完又是一个独立程序，扔到不同系统上就能跑，不需要先装一串运行环境。

公司内网不想依赖公共 relay，也能自己启动一个：