社保系统还在用FTP传文件——不是落后是银行就认这个文章目录社保系统还在用FTP传文件——不是落后是银行就认这个一、银行和社保之间唯一稳定的通道二、目录约定就是接口三、文件名的日期编码四、编码中文目录名在FTP上的处理五、文件上传的三步标准动作六、回盘文件的轮询模式七、为什么不换掉FTP八、一个容易被忽略的连接细节九、结语一、银行和社保之间唯一稳定的通道做社保系统有一个绕不开的环节和银行打交道。养老金的发放、医保费用的代扣、社保费的代缴——这些钱的流动社保系统算好金额生成批量文件传给银行执行。银行执行完了再生成回盘文件社保系统读回来更新状态。这事怎么传REST API那是互联网公司的做法。银行的要求很简单FTP传文件。十几年前是这个现在还是这个。不是社保系统不想换是银行的报文交换系统——特别是代发代扣系统——底层就是基于文件交换的。各家银行的银企直连接口最底层的通道要么是Socket报文要么是FTP文件。FTP反而是最通用、最稳定的一种。所以社保系统里一定有一个FTP工具类。我们的叫FtpUtil。二、目录约定就是接口银行端的FTP目录结构是约定好的两边协商好之后就固定了FTP根目录/ ├── hnftpbank/ 社保→银行的根目录 │ └── tobank/ 社保上传文件给银行 ├── tocsi/ 银行→社保的根目录银行上传回盘文件社保往tobank里放文件银行从里面取银行往tocsi里放回盘文件社保轮询读取。这个命名看起来很朴素但它解决了两个问题不需要额外的通知机制。银行处理完一个文件往tocsi里放回盘——社保程序每隔几分钟去扫一次有文件就取回来处理天然实现了异步解耦。社保不需要等银行处理完银行也不需要等社保来取。文件在目录里躺着谁需要谁去取这不是微服务不是消息队列但解耦的效果是一样的。三、文件名的日期编码FTP上的文件名通常带日期比如20260521.txt。这不是随便取的——银行文件名有严格的编码规范通常包含日期、批次号、业务类型代码。社保这边在上传时也按同样的规则生成文件名银行扫描时按规则解析。文件名本身就是协议的一部分——它告诉对方这是什么类型的数据、哪一天、第几批。四、编码中文目录名在FTP上的处理有一个看似不起眼但踩过坑的细节FTP服务器上可能有中文目录名。我们的CreateDirecroty方法里有这样一行StringsubDirectorynewString(remote.substring(start,end).getBytes(GBK),ISO-8859-1);FTP协议默认用ASCII或ISO-8859-1传输路径信息。中文目录名必须先用GBK编码成字节再以ISO-8859-1透传否则FTP服务器不认识这个目录。为什么会有中文目录有的银行FTP服务器是Windows搭建的他们自己建目录时用了中文名。社保这边就得适配。这不是技术问题是对接现实问题的妥协。五、文件上传的三步标准动作ftpClient.setFileType(FTPClient.BINARY_FILE_TYPE);// ①设二进制模式CreateDirecroty(ftpClient,pathname);// ②确保目录存在ftpClient.storeFile(fileName,inputStream);// ③写入文件三步走每一步都有坑。设二进制模式如果不设FTP默认是ASCII模式对于含中文或二进制的文件内容会被篡改。批量报盘文件里每一行都有金额字段差一个字节就是财务事故。确保目录存在银行FTP的目录不一定是事先建好的。有时银行换了运维人员、迁移了服务器目录就不见了。CreateDirecroty会逐层检查并创建——这个防御性检查在生产环境里救了不止一次。写入文件最需要注意的不是写入本身而是写入完成后的校验。文件传上去了不等于银行能正确解析。我们的做法是上传后调用银行的校验服务Verifier确认文件的格式通过银行的规则校验。主动模式 vs 被动模式——被防火墙决定的参数。FTP有两种数据传输模式区别在于谁连谁主动模式PORT被动模式PASV谁发起数据连接服务器主动连客户端客户端主动连服务器防火墙友好度差——服务器要穿透客户端防火墙好——客户端出站连接通常放行典型场景双方都在内网、无防火墙跨网段、有防火墙/NAT社保和银行之间通常不在同一个网络里。银行FTP服务器在银行内网社保系统在政务网。中间隔着银行端的防火墙、政务网的防火墙。主动模式下银行服务器要反向连社保客户端的某个随机端口——这个端口大概率被政务网防火墙拦了。所以社保对接银行的FTP几乎只能用被动模式。反过来如果社保这边自己搭FTP服务器让医院上传文件——社保的服务器在内网医院在外网——也是被动模式。因为医院端不知道社保防火墙开了哪些端口。代码里这一行看似不起眼但在跨网段场景下决定了能不能连通ftpClient.enterLocalPassiveMode();// 被动模式让客户端主动发起数据连接没这一行防火墙一拦连接超时、文件传一半断开、debug 时只看到Read timed out——根本想不到是模式不对。六、回盘文件的轮询模式银行处理完代发代扣后生成回盘文件放到tocsi目录。社保系统的做法启动定时任务 → 每10分钟扫 FTP/tocsi/ → 发现新文件 → 下载到本地 → 解析入库定时任务只做一件事ftpClient.changeWorkingDirectory(/tocsi);FTPFile[]filesftpClient.listFiles();for(FTPFilef:files){ftp.downloadFile(ftpClient,/tocsi,f.getName(),localpath);}简单到什么程度没有消息队列没有回调接口就是扫目录 下载 处理。但这套机制在十多年的运行中从来没出过问题——它简单到你没什么地方可以出错。七、为什么不换掉FTP这个问题被反复问过。答案分两层技术层可以换。把FtpUtil换成SftpUtil走SSH或者换成HTTP文件上传。封装一下上层业务代码不用改。业务层不能换。因为银行端的接口是固定的。社保和银行的对接协议银企直连接口在合同中写死了FTP的IP、端口、目录结构、文件名规则。要换就得和银行重新谈合同——这个成本远超技术替换本身。所以FTP不是选出来的最优解是在现有约束下唯一不需要重新谈判的方案。这个方案运行了十几年。八、一个容易被忽略的连接细节FTP连接不频繁——每天几次到几十次——但每次连接都很关键。代码里做了这些事ftpClient.setControlEncoding(UTF-8);// 控制通道编码ftpClient.connect(host,port);ftpClient.login(username,password);intreplyCodeftpClient.getReplyCode();if(!FTPReply.isPositiveCompletion(replyCode)){thrownewutilException(connect failed...);}检查replyCode这一步最容易漏。很多FTP工具类连上了就直接操作不检查登录是否成功。如果FTP服务器配置变了、密码过期了、网络不通——没有这个检查程序会直接走到下一步然后抛出一个莫名其妙的异常。加上replyCode检查问题定位从怎么文件传不上去变成了FTP登录失败。九、结语FTP在2026年看是古老的。但银行和社保之间的文件交换十几年来一直是这个模式。技术的先进和落后在政务系统里不是先后关系是谁说了算的关系。银行说FTP社保就FTP。社保说要用Socket报文银行就Socket。不是选择最好的技术是选择对方接受的技术。FTP的落后恰恰是它的优势足够简单、足够稳定、所有银行都支持。一条社保基金的发放链路从18年前跑到今天中间换过数据库、换过应用服务器、换过前端框架——但FTP那部分从来没动过。