你在公司传项目资料，或者给客户发设计稿时，有没有遇到过对方打开文件提示“损坏”或“无法解压”的情况？明明本地是好的，一上传就出问题。这其实是文件在传输过程中出了岔子。FTP虽然用得久，但默认并不自带完整性验证，想保证文件原封不动，得靠一些实际手段。
为什么文件会“悄悄”变坏？
网络不稳定、传输中断、硬盘写入错误，甚至中间代理服务器的处理异常，都可能导致文件某个字节被篡改。看起来只是小概率事件，但一旦发生，压缩包打不开、视频播放卡顿、代码编译失败，问题就来了。
最实用的方法：上传前后比对哈希值
真正靠谱的方式，是上传完文件后，对比服务器上和本地的哈希值。常用的是MD5或SHA-256。比如你在本地执行：
md5sum project.zip得到一串像 d41d8cd98f00b204e9800998ecf8427e 的值。然后登录FTP服务器，在命令行或通过脚本查看远程文件的MD5：
md5sum /path/on/server/project.zip两边一致，说明文件没变。现在很多FTP客户端也支持自动校验，比如FileZilla的“传输完成后验证文件”功能，勾上就行。
启用二进制模式传输
很多人忽略的一点是传输模式。FTP有ASCII和二进制两种模式。文本文件用ASCII还行，但图片、压缩包、可执行文件必须用二进制模式，否则换行符可能被自动转换，文件就坏了。大多数现代客户端默认是二进制，但如果你用脚本或老工具，记得显式设置：
binary在FTP命令行里输入这句，确保后续传输都是原始字节流。
搭配校验文件一起传
批量传文件时，可以生成一个 checksums.md5 文件，内容是所有文件的哈希：
md5sum *.zip > checksums.md5上传这个文件到服务器，对方下载后运行：
md5sum -c checksums.md5系统会自动逐个检查，哪个文件有问题一眼就知道。这在做数据备份归档时特别有用，相当于给整批文件上了“健康证明”。
考虑用更安全的替代协议
如果对完整性要求高，其实可以直接换SFTP或FTPS。它们在加密传输的同时，底层使用更可靠的连接机制，出错概率更低。而且像SFTP基于SSH，本身就有数据完整性保护，不需要额外校验也能放心。
说到底，FTP本身简单轻量，但安全和完整得自己补。不管是加哈希校验，还是换协议，关键是在重要数据面前多走一步，别让“应该没问题”变成“怎么又坏了”。