WebService传图片，通过最笨的服务办法是把图片塞进SOAP消息里。但那是器图2010年的玩法了。现在正经做，通过都是服务让WebService返回一个图片的URL，客户端拿到地址后再自己去下载。器图别急着反驳，通过先听我把话说完。服务

上周我接手一个老项目，器图对方系统是通过Java写的，部署在Tomcat上，服务接口文档写得跟天书似的器图。需求很简单——移动端要显示服务器上的通过头像。我第一反应是服务直接调接口拿二进制流，结果对方架构师在电话里笑了：“你直接GET /image/{ id}不就行了？器图”我愣了两秒，然后意识到自己把简单问题复杂化了。

具体怎么操作？第一步，服务端写个REST接口，返回JSON格式的数据，里面包含图片的完整URL。比如这样：
{ "code":0,"data":{ "url":"http://192.168.1.100:8080/img/avatar/123.jpg"}}
客户端拿到这个URL，用HTTP请求去下载图片。就这么简单。但有几个坑得提前踩。

第一个坑是跨域。如果你的WebService部署在A域名，图片放在B域名，浏览器会拦截。别想着用CORS硬刚，直接让服务端把图片和接口放同一个域，省事。第二个坑是图片缓存。服务器返回的URL如果带时间戳，比如 ?v=20240615，客户端就不会拿旧缓存。这个细节很多新手会忽略，但实际体验差距巨大。

有人会问，那非要用SOAP怎么办？老项目里确实还有SOAP协议的WebService。这种情况下，服务端可以把图片转成Base64字符串，塞进XML的某个节点里。但我要泼盆冷水——一张2MB的图片转成Base64后大概变成2.7MB的字符串，SOAP本身有XML解析开销，传输效率低到离谱。我见过某银行系统这么干，一个图片请求耗时3秒多，用户早把App关了。

再补充个实战技巧。如果图片是动态生成的，比如验证码，别存临时文件，直接在服务端内存里生成图片，然后通过输出流写到HTTP响应中。客户端用 ImageIO.read(url) 或者Android的 Glide 库都能直接加载。但注意，这种接口不能加缓存，每次请求必须重新生成。

最后说个我踩过的真实教训。有次图片URL的域名用的是内网IP，结果外网用户全部加载失败。后来改成配置中心动态获取域名，问题才解决。所以记住，URL里的域名一定要是可配置的，别写死。测试环境用localhost，生产环境用正式域名，这种低级错误最容易在联调时爆发。

回到开头那句话——WebService传图片，核心就一个字：让客户端自己来拿。服务端只负责告诉客户端“图片在哪儿”，而不是把图片嚼碎了喂过去。这样既减少网络开销，又便于做CDN加速和图片压缩。你要是还在纠结怎么把图片流嵌入到SOAP头里，趁早醒醒，时代变了。