go标准库无net/ftp包，编译会失败；真正可用的是github.com/jlaffaye/ftp，但默认pasv模式易因防火墙拦截导致list或retr卡住或eof，需禁用pasv改用port模式，并前置检查连接存活与路径存在。
Go 标准库没有 net/ftp 包，直接 import "net/ftp" 会编译失败；真正可用的是第三方库 github.com/jlaffaye/ftp，它覆盖了绝大多数生产场景下的 FTP 下载需求，但默认行为容易在防火墙、超时、路径不存在或中文名等环节出错。
为什么 ftp.Dial 连接后 List 或 Retr 总是卡住或返回 EOF
根本原因是默认启用 PASV（被动）模式，而很多内网环境或云服务器防火墙会拦截服务端发起的反向数据连接。客户端连上控制通道后，List 和 Retr 需要建立第二条数据通道，PASV 模式下服务端告诉客户端“你来连我某个高危端口”，若该端口被封，就 hang 住或 EOF。
- 先用命令行验证：运行
ftp -v your-server.com，输入账号密码后执行ls，看是否成功；失败则大概率是 PASV 不通 - 禁用 PASV：改用 PORT（主动）模式，初始化时加选项
ftp.DialWithDisabledPASV() - 注意：PORT 模式要求客户端机器能被服务端主动连回来——开发机在 NAT 后基本不可用，仅适合服务端直连客户端的私有网络
- 连接后立刻调
conn.NoOp()探活，别等到Retr才发现控制通道已断
conn.Retr 返回空文件或 panic 的常见原因
conn.Retr 返回的是 io.ReadCloser，不是数据本身；它只打开数据通道并准备读取，不保证内容完整、不自动关闭、也不校验文件是否存在。
- 下载前必须先确认路径存在：调
conn.Entry("/remote/file.txt")，返回nil才说明文件存在，否则Retr可能静默返回空io.ReadCloser -
io.Copy(dst, rc)不会关闭rc，必须显式rc.Close()，漏掉会导致后续操作复用坏连接或 fd 耗尽 - 别用
io.ReadAll(rc)处理大文件，内存爆炸；小文件也建议加defer rc.Close()+if err != nil判错 - 目标路径所在目录必须已存在，
os.Create不会自动创建父目录；用os.MkdirAll(filepath.Dir(localPath), 0755)预处理
FTP 中文路径或文件名乱码怎么办
FTP 协议本身不定义字符集，服务端按自己配置解码字节流。Linux vs Windows 服务器、vs vs Pure-FTPd 表现完全不同，Go 客户端发的原始字节，服务端可能当 ISO-8859-1 解，结果中文变 ????。
- 最稳妥方案：服务端和客户端统一约定路径用英文或 URL 编码，避免中文
- 若必须支持中文，需和服务端管理员确认其编码（如 UTF-8），并在 Go 中手动转码：用
golang.org/x/text/encoding/unicode将字符串 encode 成对应字节再传给Retr - 部分服务端（如 vsftpd）支持
OPTS UTF8 ON命令，可在Login后立即发送：conn.Cmd("OPTS UTF8 ON")，但非所有服务端支持 - 别依赖
ftp.Dial自动协商编码——它根本不做这事
FTP 协议细节多、容错差，jlaffaye/ftp 虽轻量，但每个调用背后都藏着控制通道状态、数据通道生命周期、字符编码解释权等隐性契约；写接口时最容易忽略的是“连接是否还活着”和“路径是否存在”的前置检查，这两点不补全，90% 的线上故障都源于此。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
