核心问题: 你是否经常需要在处于不同网络、无法开放端口的电脑之间传文件？
RepoDaily 采用评分
RepoDaily 将该项目的采用分评为 90/100（强）：分数来自文章来源、安装路径、生产风险、差异化、许可证清晰度以及 AI/Agent 适配度。
包含 4 个来源、覆盖 3 类来源；如有 RepoDaily 独有模块，会进一步提高证据分。
检测到 5 个工作流步骤、4 个下一步动作，以及 5 个命令/安装信号。
趋势热度为 +737 stars；如内容中有 release、issue 或维护信号，会提高维护可信度。
采纳风险标记为 low，并包含 5 条安全说明与 4 条跳过条件。
2 个机会视角、4 个替代方案，以及 3 个类型化模块支撑差异化判断。
文章中包含许可证来源或许可证表述。
文章正文和元数据中检测到 2 个 AI/Agent 相关信号。
项目概览
croc 是一个用 Go 编写的命令行文件传输工具，允许任意两台电脑通过公共中继交换文件和文件夹。发送方运行 `croc send`，获得一个简短的接收码，将码分享给接收方——接收方在自己的机器上运行 `croc`，输入码，文件即刻送达。双方都不需要开放端口、配置防火墙规则或搭建本地服务器。中继只负责建立连接；实际传输内容通过 PAKE（密码认证密钥交换）进行端到端加密，中继运营方无法读取传输中的文件内容。
croc 与 scp、rsync 或云盘上传的区别在于，它把一整类麻烦压缩到了一个二进制文件里。用 scp 你需要 SSH 凭据和一个可达的 IP 地址；用 rsync 你需要同样的前提再加上一堆参数；用云存储你需要账号、浏览器和上传再下载的往返过程。croc 在单个可执行文件中处理了所有这些问题：支持 Windows、Linux 和 macOS，支持多文件和文件夹传输，支持断点续传，IPv6 优先并回退到 IPv4，还能通过 Tor 等代理路由流量。
go.mod 中的模块路径 `github.com/schollz/croc/v10` 表明该项目已经历十个主版本迭代，反映了在传输协议、中继逻辑和命令行接口方面多年的打磨。代码库依赖了同一作者的多个库：`schollz/pake/v3` 负责密钥交换，`schollz/peerdiscovery` 负责局域网发现，`schollz/cli/v2` 负责命令行框架。它还引入了 `golang.org/x/crypto` 提供核心加密原语，以及 `skip2/go-qoline` 生成二维码——暗示存在面向手机扫码的接收流程。Go 1.25.0 的工具链要求说明项目紧跟 Go 最新版本。
README 顶部有醒目的赞助横幅，明确写道项目的未来取决于社区支持。MIT 许可证覆盖全部代码，默认中继由维护者运营，但用户可以通过 Docker 或独立二进制文件自建中继。对于想把 croc 作为日常工具的人来说，可持续性的问题不在代码质量，而在于中继的托管成本和维护者的精力——赞助横幅把这个顾虑公开化而非隐藏起来。
为什么现在变热
- 本期 737 星标、排名第 11，反映出开发者对零配置、不经由美国云厂商的文件传输工具的关注
- 几乎所有平台一条命令即可安装：Homebrew、Scoop、Winget、Chocolatey、pacman、dnf、portage、Nix、Conda、Termux、FreeBSD pkg，以及 curl 安装脚本
- 基于 PAKE 的端到端加密意味着中继无法解密传输内容——大多数基于浏览器的文件分享服务无法做出同样承诺
- 内置断点续传，网络中断不会导致大文件从头重传
- IPv6 优先、IPv4 回退，并支持 Tor 代理，覆盖 NAT 或审查环境下的连通性问题
- Docker 镜像发布在 docker.io/schollz/croc，relay 模式让自建私有中继只需一条 `docker run` 命令
解决什么问题
- 基于 SSH 的传输（scp、sftp、rsync）要求可达 IP、密钥管理，通常还需要端口转发——在一端处于运营商级 NAT 或酒店网络时全部不可用
- 云存储分享需要双方都有账号、浏览器上传、分享链接和单独的下载步骤——向同事发一个 500 MB 日志文件过于繁重
- Snapdrop 等浏览器工具要求两台设备在同一局域网，且不保证端到端加密
- 大多数临时传输工具不支持断点续传，网络抖动后只能完整重传
工作原理
- 发送方在本地运行 `croc send path/to/file`，croc 生成一个简短随机接收码（如 `4231-some-words`）并显示出来。
- croc 连接到中继服务器并执行 PAKE 密钥交换，发送方和接收方在不传输密钥本身的情况下推导出共享会话密钥。
- 接收方在任意另一台电脑上运行 `croc`，输入接收码，PAKE 握手完成——后续所有文件数据被端到端加密。
- 文件数据经过中继流转，但中继只能看到密文。如果传输中断，croc 可以从断点续传而非重新开始。
- 默认情况下 croc 使用维护者运营的中继，但用户可以通过命令行参数或环境变量指向自建中继，完全掌控网络路径。
产品演示与界面预览
安装与命令入口
- 快速安装（任意 OS）：`curl https://getcroc.schollz.com | bash`
- macOS：`brew install croc`（Homebrew）或 `sudo port install croc`（MacPorts）
- Windows：`scoop install croc`、`choco install croc` 或 `winget install schollz.croc`
- Linux 发行版：`pacman -S croc`（Arch）、`dnf install croc`（Fedora）、`emerge net-misc/croc`（Gentoo）、`nix-env -i croc`（Nix）
- 移动端和 BSD：Termux（Android）和 FreeBSD 上 `pkg install croc`
- Conda/pixi：`pixi global install croc` 或 `conda install --channel conda-forge croc`
- Docker（POSIX shell）：一个 shell 函数封装了 `docker run --rm -it --user "$(id -u):$(id -g)" -v "$(pwd):/c" docker.io/schollz/croc "$@"`
- NixOS：在 configuration.nix 的 `environment.systemPackages` 中添加 `pkgs.croc`
通过 Docker 自建中继
已发布的 Dockerfile 以 `golang:1.25-alpine` 为构建阶段，最终产出 `alpine:latest` 镜像并以 `USER nobody` 运行——对于面向网络的中继服务来说，非 root 默认配置是合理的。镜像暴露了五个 TCP 端口：9009、9010、9011、9012 和 9013，覆盖中继监听端口以及 croc 用于数据通道的额外端口。
CMD 为 `relay`，因此 `docker run docker.io/schollz/croc` 开箱即启一个中继。健康检查通过 `nc -z` 每 30 秒探测一次端口，超时 10 秒、重试 3 次，探测目标由 `CROC_PORTS` 或 `CROC_PORT` 环境变量决定（默认 9009）。在负载均衡器后部署时，应映射全部五个暴露端口，并确保健康检查目标被覆盖。
依赖架构解读
go.mod 中模块 `github.com/schollz/croc/v10` 声明 Go 1.25.0，并通过依赖项揭示了项目的设计。`schollz/pake/v3 v3.1.1` 实现了支撑端到端加密的密码认证密钥交换——发送方和接收方从接收码推导共享密钥，而密钥本身永远不会通过网线传输。
`schollz/peerdiscovery v1.7.6` 提供局域网设备发现能力，可能用于在同一局域网内发现 croc 实例以实现更快的本地直传（不经中继）。`schollz/cli/v2 v2.2.1` 是命令行框架（urfave/cli 的分支），`schollz/progressbar/v3 v3.19.1` 驱动传输进度条，`skip2/go-qrcode` 生成二维码——大概率用于手机扫描接收码。`magisterquis/connectproxy` 的引入与 README 中声称的 Tor 代理支持一致。
谁适合关注
适合关注
- 你需要向不同网络的人发送大文件，双方都无法开放端口
- 你想要端到端加密但不想配置 SSH 密钥或 GPG
- 你经常向处于运营商级 NAT、酒店 Wi-Fi 或企业防火墙后的机器传文件
- 你需要断点续传，不想在每次中断后从零开始
- 你想要可自建的中继，让文件流量完全不经过第三方云
可以先跳过
- 你只在已配置 SSH 的同一局域网机器间复制文件——rsync 或 scp 更高效
- 你需要在已知主机之间进行定时、自动化或批量传输——专业同步工具更合适
- 你的合规要求需要审计谁在何时下载了什么——croc 的接收码模式没有服务端记录
- 你需要细粒度访问控制、过期策略或密码保护链接——croc 是点对点模型，不是分享门户
风险与注意事项
MIT 许可证的单二进制文件，无需账号，默认中继可用自建 Docker 容器替换。主要风险在于依赖默认中继时的可用性。
- MIT 许可证（Copyright 2017-2025 Zack）不限制商业使用
- README 中未提及遥测或账号注册要求，中继源码即同一代码库
- 自建中继通过 Docker 文档化，镜像发布在 docker.io/schollz/croc
- README 明确标注项目未来依赖社区赞助，因此长期中继托管是最主要的可持续性考量
- 基于 PAKE 的端到端加密（schollz/pake/v3）意味着中继无法解密传输中的文件内容
- 可选 Tor 代理支持（magisterquis/connectproxy 依赖）允许网络层面的混淆
- Docker 镜像以 USER nobody 运行，中继进程为非 root
- 发送或接收文件均不需要注册账号
- 接收码是唯一的共享密钥——如果在传输完成前被截获，攻击者可能替代目标接收方接收文件
替代方案比较
| 方案 | 适用场景 | 代价 |
|---|---|---|
Magic Wormhole | 你想要一个成熟的、基于 Python 的同类工具，采用相同的 PAKE-over-relay 概念且贡献者更多 | 免费，MIT 许可证 |
wormhole-william | 你想要一个 Go 编写的、兼容 Wormhole 协议的客户端 | 免费，MIT 许可证 |
rsync over SSH | 两台机器都有 SSH 访问，且你需要为重复传输做高效的增量同步 | 免费，大多数 Unix 系统预装 |
Snapdrop | 两台设备在同一局域网，且你更偏好浏览器界面的 AirDrop 风格体验 | 免费，GPL-3.0 |
这个趋势说明了什么
用 croc 替代日志分享中的临时云上传
支持工程师和 SRE 经常需要向厂商或客户分享数 GB 的日志包。用 `croc send` 替代上传到 S3 再分享链接的模式，不需要创建存储桶，且自动加密传输内容。
用 `croc send` 发送一个测试日志文件，对比从发送到接收的总耗时与当前 S3 上传加链接分享的方式。
在受监管环境中自建中继
无法通过维护者运营的中继传输文件的组织，可以在自有基础设施上部署 Docker 镜像（`docker run docker.io/schollz/croc relay`），将所有中继流量保持在自己的网络边界内。
部署中继容器，映射 9009–9013 端口，用 `--relay` 将 croc 客户端指向私有中继，确认一次传输成功完成。
RepoDaily 判断
croc 解决了一个确实令人头疼的问题——在不同网络的两台机器之间传文件——并提供了干净的 PAKE 加密中继模型、单一 Go 二进制文件，以及覆盖所有主流包管理器的安装路径。MIT 许可证和可自建的 Docker 中继让采用风险保持在低水平。主要注意事项是可持续性：维护者坦诚依赖赞助，因此任何长期使用者都应考虑赞助或自建中继。