FTP上传XML失败主因是服务端配置与客户端认证不匹配，应优先用lftp支持TLS/SSL及断点续传，中文名需重命名或改SFTP，定时任务须设绝对路径和环境变量，大文件推荐SFTP或HTTP PUT。
FTP上传XML文件时连接失败或权限拒绝
常见现象是脚本执行后报错 530 Login authentication failed 或 550 Permission denied。这通常不是XML本身的问题，而是FTP服务端配置和客户端认证方式不匹配。很多现代FTP服务器（如vsftpd、Pure-FTPd）默认禁用匿名登录，且要求显式启用TLS/SSL；而老式脚本常用 ftp 命令行工具，它不支持加密传输，容易被拒。
- 优先改用
lftp：它原生支持FTP/FTPS/SFTP，自动处理被动模式和证书验证，命令简洁：lftp -c "set ftp:ssl-force true; open ftp://user:pass@host; put /path/to/file.xml" - 避免在命令行里硬编码密码——用
lftp的~/.netrc文件存凭据，格式为：machine host login user password pass，并确保该文件权限为600 - 如果目标服务器只开放SFTP（更安全），就别折腾FTP协议了，直接用
scp或sftp：例如scp file.xml user@host:/remote/path/
Python脚本上传XML时中文路径或文件名乱码
Linux/macOS下用 ftplib 上传含中文的 file.xml，服务器上文件名变成 ???.xml，本质是FTP协议本身不带字符编码声明，ftplib 默认按Latin-1编码发送文件名，遇到UTF-8字节流就解错。
- 最稳方案：上传前重命名XML文件为纯ASCII名（如用UUID或时间戳），并在XML内容里保留原始业务标识字段
- 若必须传原名，可尝试在连接后手动设置编码（仅部分FTP服务器支持）：
ftp.voidcmd('OPTS UTF8 ON')，再调用ftp.storbinary(...)，但成功率取决于服务端是否实现RFC 2640 - 绕过FTP协议层：用
paramiko库走SFTP通道，它天然支持UTF-8路径：sftp.put(localpath, remotepath)，remotepath可直接写/data/订单_2024.xml
定时任务中XML上传失败但日志没报错
用 cron 跑Python或Shell脚本上传XML，看似执行成功，但服务器上找不到文件——大概率是环境变量缺失导致FTP客户端找不到配置，或当前工作目录不对，相对路径失效。
- Shell脚本开头强制指定路径：
cd /absolute/path/to/xml/dir || exit 1，所有文件操作用绝对路径，比如/home/user/data/report.xml - 在cron中显式加载环境：
0 2 * * * cd /path && . ~/.bashrc && python3 upload.py >> /var/log/upload.log 2>&1 - 关键操作后加校验：上传完立刻用
lftp或curl检查远程文件是否存在且大小非零，例如：lftp -c "open ftp://u:p@h; ls -l /remote/file.xml" | grep -q "file.xml" && echo ok
大XML文件上传中断后无法续传
一个200MB的 export.xml 传到87%断开，重新运行脚本又从头开始，浪费带宽和时间。FTP协议本身不支持断点续传，除非客户端和服务端都启用REST命令并配合二进制模式。
-
lftp自动支持断点续传，只要加-c参数：lftp -c "open ftp://u:p@h; put -c /local/export.xml"，它会先发SIZE查远程已传长度，再用REST接着传 - Python
ftplib需手动实现：先用ftp.size(remotepath)获取已传字节数，再用fp.seek(already_sent)跳过本地文件开头，最后ftp.storbinary(..., fp, rest=already_sent) - 真正省心的做法是换协议：SFTP（via
paramiko）或HTTP PUT（如Nginx WebDAV），它们对大文件和中断更友好
上传逻辑本身不难，难的是服务端协议支持、环境一致性、以及中断后的状态确认。别假设“连上了就能传”，每次换服务器都要重新验证认证方式、路径权限、编码行为和断点能力。
