推荐使用 github.com/freddierice/go-ftp@v0.4.0 快速启动安全、稳定的 FTP 服务器，它支持基础命令、PASV 模式和文件系统后端，避免手动实现 FTP 双通道协议的高风险与复杂性。
用 github.com/freddierice/go-ftp 快速启动一个可工作的FTP服务器
Go 标准库不提供 FTP 服务器实现，直接手写协议层风险高、易出错。推荐用轻量、维护活跃的第三方库 github.com/freddierice/go-ftp（注意不是已归档的 goftp 主分支），它支持基本命令（USER、PASS、LIST、RETR、STOR）、被动模式（PASV）和文件系统后端。
实操建议：
- 执行
go get github.com/freddierice/go-ftp@v0.4.0（v0.4.0 是当前兼容 Go 1.20+ 的稳定版，新版本有 breaking change） - 基础启动只需 10 行代码：定义用户凭证、设置根目录、调用
ftp.ListenAndServe - 默认监听
21端口，但开发时建议改用高位端口（如2121），避免 sudo 权限和端口冲突 - 该库不支持 TLS（FTPS），若需加密，得自己套一层
tls.Listener并处理 AUTH TLS 流程——多数内部工具场景其实不需要
为什么不能直接用 net/http 或自建 TCP server 模拟 FTP
FTP 协议本身是双通道：控制连接（文本命令）+ 数据连接（二进制传输）。手动解析 PORT/PASV、处理 CRLF 换行、同步多连接状态、应对客户端重连/超时，极易引入竞态或挂起连接。常见错误现象包括：
- 客户端卡在
227 Entering Passive Mode后无响应（数据端口未正确开放或 NAT 映射失败） -
LIST返回空列表或乱码（未按 RFC 3659 格式输出目录项，或未处理时区/权限字段） - 上传大文件时连接中断（缺少分块读写、缓冲区未设限、未处理
ABOR命令） - 多个并发 LIST 请求导致目录扫描阻塞主线程（库默认单 goroutine 处理控制流，数据连接需独立 goroutine）
这些不是“能写出来”的问题，而是“写对成本远高于引入成熟库”的问题。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
立即学习“go语言免费学习笔记（深入）”；
配置用户权限和文件系统隔离的关键参数
该库通过 ftp.NewServer 的 Options 控制行为，核心是 Auth 和 Driver。不要假设默认就是安全的：
-
Auth必须显式传入函数，返回ftp.User结构；空密码或通配符用户名（如"*"）等于裸奔 -
Driver推荐用ftp.NewFileDriver，但务必检查rootPath参数是否为绝对路径且存在——相对路径会静默失败，日志也不报错 - 若需限制用户只能访问子目录（chroot），必须在构造
FileDriver前用filepath.Join拼接好完整路径，并确保 OS 用户对该路径有读写权限（Linux 下注意 SELinux 上下文） - 上传文件时默认覆盖同名文件，如需禁止覆盖，得包装
FileDriver.WriteTo方法加os.Stat判断
调试连接失败和被动模式不通的排查顺序
本地测试通了，部署到服务器就连接超时？重点查这三处：
- 确认防火墙放行了控制端口（如
2121）和 PASV 端口段（如50000-50100），iptables或云厂商安全组都要配 - 服务端
PASV响应中的 IP 地址必须是客户端能路由到的地址（比如不能是127.0.0.1或内网 IP），需设置Server.Addr为外网 IP 或域名 - 客户端是否启用了主动模式（PORT）？某些 FTP 客户端（如 FileZilla）默认用 PASV，但企业网络可能屏蔽高位端口，此时需强制客户端切回 PORT 模式并开放对应端口
- 用
telnet your-server 2121手动发USER anonymous和PASS，看是否返回230—— 这步能快速区分是认证问题还是网络问题
最常被忽略的是 PASV 响应里 IP 和端口的拼接逻辑：库会把 Server.Addr 解析成 IP，但如果你绑定了 0.0.0.0:2121，它可能取到容器内网 IP 而非宿主机地址。这时候必须硬编码 Server.Addr = "your.public.ip:2121"。
