go标准库不支持ftp，应使用github.com/jlaffaye/ftp等成熟库；需注意pasv模式、私有ip处理、目录预创建、路径斜杠规范及流式下载避免oom。
Go 标准库不支持 FTP，别白费劲写 net/ftp
Go 官方标准库至今（1.22+）没有提供 FTP 客户端实现，net 包里压根没有 ftp 子包。你搜到的所谓“原生 FTP 支持”基本是误传或混淆了 FTPS/FTPS over TLS 的概念。硬要自己基于 net.Conn 从零解析 FTP 协议响应（比如 220、331、150 等状态码 + PASV 模式端口解析），不仅极易出错，还会在主动/被动模式切换、IPv6、防火墙穿透等场景直接卡死。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 用社区成熟库：
github.com/jlaffaye/ftp（最常用，维护活跃，支持 AUTH TLS） - 若需 FTPS（显式 TLS），确认服务端支持
AUTH TLS命令，并在连接后立刻调用Conn.AuthTLS() - 避免用
github.com/dutchcoders/go-ftp—— 已归档，不支持 Go module，且无 PASV 模式自动 fallback
连接时卡住或报 dial tcp: i/o timeout
FTP 协议分控制连接（默认 21 端口）和数据连接（PASV 或 PORT 模式动态分配），超时往往发生在数据连接阶段，而非登录环节。常见原因是客户端没正确处理 PASV 响应里的 IP 和端口，或服务端返回了内网 IP（如 192.168.x.x）导致客户端连不上。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 强制启用被动模式：
ftp.Dial("example.com:21", ftp.DialWithTimeout(10*time.Second))，该库默认走 PASV - 若服务端返回私有 IP，在 Dial 后立即设置
conn.SetPassiveHost("your-public-ip") - 调试时加日志：
conn.SetDebug(os.Stdout)，看 PASV 响应是否含异常 IP 或端口为 0 - 企业环境注意：某些 FTP 服务（如 Pure-FTPd）需额外配置
PureFTPd -p指定被动端口范围，并在防火墙放行
Upload 失败报 553 Could not create file 或空文件
这不是权限问题就是路径/模式理解偏差。FTP 的 STOR 命令不自动创建父目录，且路径分隔符必须是 /（即使 Windows 服务端也认斜杠）。更隐蔽的是：Upload 方法底层用的是 io.Copy，如果传入的 io.Reader 已被读过一次（比如 bytes.Buffer 已被 buf.Bytes() 调用过），第二次上传就会传空内容。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 确保目标路径的父目录已存在，用
conn.MakeDir逐级创建，不要依赖Upload自动建目录 - 上传本地文件时，用
os.Open每次新建 reader，别复用bytes.Buffer或strings.Reader实例 - 路径统一用正斜杠：
"/upload/test.txt"，别用"\upload\test.txt" - 检查服务端是否开启写权限：Pure-FTPd 需
-E参数；vsftpd 需write_enable=YES
下载大文件内存暴涨或速度极慢
Download 方法默认把整个文件读进内存再返回 []byte，对百 MB 级文件直接 OOM。另外，未设置缓冲区大小时，底层 io.Copy 默认用 32KB 缓冲，小缓冲在高延迟链路上会显著拖慢速度。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 永远用流式下载：
conn.Retr("/remote/file.zip")返回io.ReadCloser，直接 pipe 到os.File或gzip.NewReader - 自定义缓冲区提升吞吐：
io.CopyBuffer(dst, src, make([]byte, 1（1MB buffer） - 别忽略
Close()：rc, err := conn.Retr(...); defer rc.Close()，否则 TCP 连接不释放，后续操作可能卡住 - 若需断点续传，该库不支持；得自己发
REST命令 +conn.Cmd组合实现，复杂度陡增
FTP 协议本身的非状态性、双连接模型和响应解析歧义，决定了它比 HTTP 客户端难搞得多。真正容易被忽略的，是 PASV 模式下服务端返回的 IP 是否可达——这问题在线上 NAT 环境里几乎必现，但本地开发测不出来。
