折腾了一夜filezilla上传geo文件终于通了，别踩这些坑

昨晚搞到凌晨三点，头发都快掉光了。主要是为了把那个GeoServer的配置文件和那个该死的GeoTIFF数据上传到服务器上去。之前一直觉得FTP工具也就是那样，随便传传文件呗，直到今天遇到这个filezilla上传geo文件的问题，我才发现，细节这东西，真的能要命。

说实话，刚开始我是用WinSCP的，毕竟那个界面看着清爽，拖拽就行。但是这次项目比较急，客户那边非要特定的权限配置，我就换了FileZilla。结果一上传，傻眼了。小文件没问题，几个KB的XML或者txt，嗖嗖的就传完了。可一旦涉及到那个几GB的geo文件，也就是那个地理空间数据文件，传输就卡在那儿不动了。进度条像蜗牛爬，然后直接断开连接。我以为是网络波动，重启路由器，换网线，折腾半天，最后发现是服务器端的被动模式配置有点小偏差，加上FileZilla的默认设置没调对。

这里有个真实的坑，很多新手容易忽略。就是关于“被动模式”和“主动模式”的选择。对于geo这种大文件，尤其是涉及大量二进制数据的，主动模式经常会被防火墙拦截。我当时就是死磕主动模式，传了半小时，最后超时。后来我把FileZilla设置里的传输模式改成了“被动”，并在服务器端检查了端口范围。注意啊，服务器防火墙必须开放这些端口，不然你本地连上了，数据流却过不去。我查了阿里云的安全组规则，发现之前为了省事，只开了21端口，其他端口全关了。这就是典型的“省事儿办大事”心态，结果把自己坑了。

还有个细节，关于文件名的编码问题。我的geo文件里有些中文注释，或者路径里带了特殊符号。第一次上传后，服务器上的文件乱码，GeoServer根本读不出来，报错说找不到数据源。我当时那个急啊，以为是文件损坏，重新下载了本地文件再传，还是不行。后来在FileZilla的设置里，把字符集从UTF-8改成了GBK，或者反过来试了一下，才搞定。这一步真的不起眼，但极其关键。如果你做的是国内的项目，服务器环境又是Windows Server，这个编码问题简直就是噩梦。

再说说速度。很多人抱怨FileZilla慢，其实不是软件慢，是你没开多线程。在设置-连接-FTP里，把最大并发连接数调到5或者10。对于单个大文件，这招不管用，但对于上传一个包含几百个小geo文件的文件夹，效果立竿见影。我那次传一个包含500个.shp文件的目录，单线程传了四十分钟，开了多线程，大概十分钟就搞定了。这时间差，对于赶工期的程序员来说，就是救命稻草。

另外，断点续传功能一定要开。昨晚我传那个2GB的tif文件，传到90%的时候，突然断网了。要是没开断点续传，我得从头再来，那心态真的会崩。FileZilla的断点续传机制还算靠谱，重新连接后，它会自动识别已上传的部分，继续往下传。不过要注意，有些老旧的FTP服务器对断点续传支持不好，可能会报错。如果遇到这种情况，只能先关掉续传，重新上传。

最后，权限问题。上传完文件，别忘了检查文件权限。有时候上传成功了，但权限是644，而GeoServer需要755或者更严格的权限才能读取。我在服务器上用chmod命令改权限的时候，差点把整个目录权限都搞乱了，还好有备份。所以，上传前最好先在本地测试一下，或者在测试环境先跑通流程。

总之，filezilla上传geo文件这事儿，看着简单，里面门道不少。别指望一次成功，多查日志，多试设置。网络环境、服务器配置、软件设置，任何一个环节掉链子，都能让你抓狂。希望这些踩坑经验能帮到你，少走弯路。毕竟，时间就是金钱，头发也是。