c++标准库不支持ftp，因std::net仅提供socket底层设施、std::filesystem仅处理本地路径，而ftp需手动实现协议交互；libcurl是最稳妥方案，system调用风险高且不可控。
C++ 标准库不提供 FTP 支持，直接调用 FTP 客户端必须依赖第三方库或系统命令
为什么不能用 std::filesystem 或 std::net（C++23）传 FTP 文件
C++23 的 std::net 仅定义底层 socket 基础设施，未实现任何应用层协议；std::filesystem 只能操作本地路径，对 FTP URL（如 ftp://user:pass@host/path）完全无感知。试图用 fopen("ftp://...") 会直接失败——C 库不解析 FTP 协议。
- 常见错误现象：
fopen返回nullptr，errno通常是ENOENT或EINVAL，不是网络错误 - 根本原因：FTP 是独立协议，需手动实现命令交互（USER/PASS/RETR/STOR）、响应解析、PASV/PORT 模式切换、ASCII/binary 模式控制
- 性能影响：自己手写易出错，比如忽略 227 响应中的端口解析逻辑，导致数据连接失败；不处理超时和重试，传输大文件时极易卡死
libcurl 是最稳妥的 C++ FTP 方案
libcurl 是 C 接口但完全兼容 C++，支持 FTP/FTPS/SFTP，线程安全，自动处理 PASV、重试、TLS、代理等细节。Windows/macOS/Linux 均有预编译包，CMake 可直接 find_package(CURL)。
- 关键配置项：
curl_easy_setopt(handle, CURLOPT_URL, "ftp://user:pass@host/file.txt")必须带完整凭证和路径 - 上传必须显式设
curl_easy_setopt(handle, CURLOPT_UPLOAD, 1L)，否则默认 GET - 下载到内存？用
CURLOPT_WRITEFUNCTION+CURLOPT_WRITEDATA；存本地文件？直接设CURLOPT_WRITEDATA为FILE*（注意用"wb"模式打开） - 容易踩的坑：
libcurl默认启用CURLOPT_SSL_VERIFYPEER，若 FTPS 服务器证书无效，需设0L（仅测试环境），生产环境应配CURLOPT_CAINFO
用 system() 调用命令行 FTP 工具风险极高
虽然 system("ftp -s:script.txt") 看似简单，但实际不可控：脚本路径含空格会崩、密码明文写入磁盘、无法捕获具体错误码（只返回 0/非0）、不同系统 ftp 命令参数不一致（Linux vs Windows）。
立即学习“C++免费学习笔记（深入）”；
- 常见错误现象：脚本执行后进程卡住，
system()长时间不返回——因为 ftp 命令在等待交互输入 - Windows 的
ftp.exe不支持 TLS，Linux 的ftp（来自 netkit-ftp）已多年未维护，lftp或curl命令更可靠但需额外安装 - 参数差异：
lftp -c 'set ftp:ssl-force true; open ftps://u:p@h; get /f'和curl -u u:p ftps://h/f -o f行为也不完全一致（比如重定向处理） - 安全红线：绝不能拼接用户输入进
system()字符串，否则直接命令注入
FTP 主动模式（PORT）在 NAT 后基本不可用
绝大多数家用路由器、云主机防火墙会拦截 PORT 模式下客户端主动开放的随机端口。libcurl 默认用 PASV（被动模式），但某些老旧 FTP 服务器禁用 PASV，此时必须手动关掉：curl_easy_setopt(handle, CURLOPT_FTP_USE_EPSV, 0L)，再配合 CURLOPT_FTP_PORT 指定本地接口。
- 典型表现：连接控制通道成功（220），但
RETR时卡住，最终超时——其实是数据连接根本没建立 - 调试方法：加
curl_easy_setopt(handle, CURLOPT_VERBOSE, 1L)看实际交互，重点关注 227 响应里的 IP 和端口是否可达 - 兼容性影响：某些企业 FTP 服务器要求强制 PORT，此时需确保客户端机器有公网 IP 或路由器做端口映射，普通开发机几乎做不到
FTP 协议本身的复杂性（控制/数据双通道、模式切换、状态同步）远超 HTTP，哪怕用 libcurl 也要仔细验证每个返回码，别只看 curl_easy_perform() 是否返回 CURLE_OK——它可能成功发了命令，但服务器返回了 550（文件不存在）却被忽略。
