JavaWeb服务器之间互传文件，间互件最直接的传文办法是走HTTP协议。别想复杂了，间互件就是传文A服务器发一个POST请求，B服务器接收文件流，间互件就这么简单。传文我见过不少团队一上来就上消息队列、间互件上FTP集群，传文结果查日志的间互件时候发现连文件都没传过去，纯属自找麻烦。传文

拿实际场景说。间互件假设你有两台Tomcat，传文一台跑订单服务，间互件一台跑图片处理。传文订单服务生成一个临时文件，间互件得扔给图片服务去处理。最简单的写法，用HttpClient发个multipart请求，几行代码搞定。接收方用Servlet的标准上传接口就能接住。这套方案的好处是，两边都不用装额外的中间件，防火墙也只要开80端口。但有个坑——文件大的时候，HTTP连接超时你得设长一点，不然传一半断了你都不知道。

要是文件特别大，比如几个G的视频文件，HTTP那套就有点吃力了。这时候可以考虑走底层Socket，自己定义个简单的传输协议。先发文件名长度，再发文件名，再发文件大小，最后一股脑把字节流推过去。接收方按约定好的格式解析，写进磁盘。这种方式的优点是你完全掌控传输过程，能加断点续传、能算MD5校验。代价是代码量上去了，出错的可能性也多了。我之前帮人排查过一个Socket传输问题，折腾了半天才发现是对方机器上缓冲区设得太小，大文件传着传着就卡死了。

还有一个容易忽略的点——服务器之间的网络环境。别以为内网就绝对可靠。我在生产环境遇到过交换机端口半双工的问题，导致两台机器传文件时速度忽快忽慢。所以传文件代码里最好加个超时重试机制，别一条道走到黑。另外，有些云环境的安全组规则只允许特定端口通信，你要是图省事用了个冷门端口，可能直接被防火墙拦了，连报错信息都看不到。

再说个偏门但有用的办法——利用共享存储。比如两台服务器挂载同一个NFS或者SMB目录。A服务器把文件写进共享目录，B服务器定时去扫，发现新文件就处理。这本质上不算“传”，但业务上效果一样。好处是代码几乎不用写，坏处是你得保证共享存储本身的高可用，不然存储挂了，两台机器一起瞎。

选择哪种方案，核心看文件大小、传输频率、还有你对实时性的要求。小文件、低频次，HTTP足够；大文件、低频次，Socket稳妥；高频次、大量小文件，那不如直接上消息队列，把文件内容转成Base64塞进消息里，虽然浪费点带宽，但胜在简单。我自己干过最傻的一件事，是把几百个几百KB的小文件用HTTP逐个传，结果握手开销比传输时间还长，后来改成打包成zip一次性传，速度快了十倍不止。

最后提醒一句，传完文件一定要校验。别信TCP的可靠性，应用层该做的校验不能省。文件大小对上了不算完，最好再比一下MD5或者SHA-1。我见过因为磁盘满导致写了一半文件但返回成功的情况，那叫一个坑。写代码时多留个心眼，生产环境才不会半夜把你叫起来。