ftpserverlib是Go生态中唯一开箱支持FTP断点续传的库，因其将REST命令自动映射为io.ReadWriteSeeker.Seek调用，而ftpd不支持REST、ftpserver需手动实现协议逻辑；它要求显式配置被动端口范围、publichost设为公网地址，并依赖文件系统返回支持Seek的io.ReadWriteSeeker，且客户端必须主动发送REST命令才能触发续传。
ftpserverlib 是目前 Go 生态中唯一能开箱支持断点续传（REST 命令）且无需魔改的 FTP 服务库。其他主流选项如 ftpd 完全不支持 REST，ftpserver（gh_mirrors/ftp）虽功能强但断点续传需手动实现协议层逻辑——这远超“语言学习技巧”能覆盖的范围。
你不需要靠“记忆命令顺序”或“类比 HTTP 分块上传”来推导 FTP 断点逻辑，而是直接依赖库对 RFC 959 的合规实现。关键在配置和文件系统适配。
为什么 ftpserverlib 是唯一可行选择
它把断点续传封装进 FileSystem 接口的 OpenFile 方法中，只要返回的 io.ReadWriteSeeker 支持 Seek，REST 就自动生效。而 ftpd 返回的 io.ReadWriteCloser 不含 Seek，根本无法响应 REST；ftpserver 虽有 fs.File 接口，但需自行解析 REST 参数并跳转偏移，等于重写传输核心。
-
ftpserverlib：调用Stor/Retr时，客户端发REST 1024→ 库自动调Seek(1024, io.SeekStart) -
ftpd：收到REST直接返回502 Command not implemented（无 handler） -
ftpserver：需在自定义File实现里监听SetPosition调用，且要处理并发写入冲突
ftpserverlib 启动时必须设置被动端口范围
断点续传依赖稳定的数据连接。主动模式（PORT）在 NAT/防火墙后必然失败，而 ftpserverlib 默认启用被动模式（PASV），但若不显式配置 passivetransferportrange，它会随机绑定端口——这些端口大概率未开放，导致客户端卡在 Entering Passive Mode 后无响应。
- 必须指定连续端口段，例如
start: 2122, end: 2130 - 对应防火墙需放行
2122-2130TCP 端口（不只是 21） -
publichost必须填公网 IP 或可解析域名，不能是127.0.0.1，否则 PASV 返回的地址不可达
文件系统必须返回 io.ReadWriteSeeker
ftpserverlib 的断点续传能力完全取决于你提供的 FileSystem 实现。用 afero.OsFs{} 可以直接支持，但要注意：
- Linux 下普通文件天然支持
Seek，没问题 - Windows 上 NTFS 文件也支持，但某些网络挂载盘（如 SMB/CIFS）可能返回
io.ErrSeeker - 若用内存文件系统（如
afero.MemMapFs），需确认其File实现嵌套了bytes.Buffer（支持Seek），而非裸[]byte - 自定义
FileSystem时，OpenFile返回的File必须同时实现io.ReadWriteSeeker，缺一不可
客户端必须发送 REST 命令，且服务端日志要验证
断点续传不是“自动开启”的功能，它依赖客户端行为。常见误区是以为只要服务端支持，下载中断后重试就会续传——实际必须由客户端显式触发 REST。
立即学习“go语言免费学习笔记（深入）”；
- 使用
goftp客户端时，调Download方法会自动检测本地文件长度并发送REST - 用
curl ftp://...默认不发REST，需加--continue-at - - FileZilla 默认启用断点续传，但需在“传输设置”里勾选“对 FTP 服务器启用断点续传”
- 检查服务端日志是否出现
REST 12345日志行，没这条就说明客户端根本没发，服务端再强也无用
ftpserverlib + afero.OsFs + 正确的 PASV 配置，才是最短路径。 
