起因：
前几天遇到的问题，才有时间记录，需求：本地生成xml形式的字符串以参数形式用post方法传送到对方的固定接口；
这个需求写的时候感觉很容易，本地测试的时候，也觉得很简单就过了，然后和对方联调的时候，稀里哗啦调了N久，
中间对方换了人接手，稀里哗啦又调了N久，对方改代码，稀里哗啦又又调了N久，最后上线了，发现接口对不上，，，
经过：
问题最开始只是乱码问题，无非就是UTF-8和GBK之间的转换，我们这边统一的UTF-8的编码，对方是GBK。对面改为
了UTF-8，联调以正确结束；然后对面换人改代码，说要GBK的，我们发了UTF-8的，他们能解析，然后说头部编码格式
要改为GBK，好奇他们居然可以解析的情况下，应要求做出了一个挺low的决定，替换字符串，将UTF-8换为GBK。【其实
这的时候就有点歪了，以至于后面调的比较吃力，当时应该和对方反复确认一下的】。说是没问题，那就上线了，，，，
然后13call，说乱码又出现了，，，
前辈们得知有问题后，第一时间支援，开始分析，才发现，最开始的测试是错的，我用eclipse启动tomcat服务器，这时候用
的是eclipse的编码模式，应该生成war包放在tomcat下启动才能模拟真实的环境，然后我们在不修改环境的情况下各种尝试
编码转换，然后对方说收到了不是乱码的数据，天真的我以为就可以收尾了
对方马上提出，收不到参数的那个字段，这里面用的HttpClient的post方法发送，如下↓
CloseableHttpClient client = HttpClients.createDefault();
HttpPost post = new HttpPost("URL");
List<NameValuePair> formparams = new ArrayList<NameValuePair>();
formparams.add(参数);
UrlEncodedFormEntity uefEntity;
uefEntity = new UrlEncodedFormEntity(formparams, "GBK");
post.setEntity(uefEntity);
HttpResponse response2 = client.execute(post);
debug的时候post之前，参数都是有值的，一到post就为null了，浓浓的诡异感飘然而起，前辈当机立断，换方法
我们换用了HttpURLConnection方法，如下↓
URL postUrl = new URL(URL);
HttpURLConnection connection = (HttpURLConnection) postUrl.openConnection();
connection.setDoOutput(true);
connection.setDoInput(true);
connection.setRequestMethod("POST");
connection.setUseCaches(false);
connection.setInstanceFollowRedirects(true);
connection.setRequestProperty("Content-Type", "application/x-www-form-urlencoded");
connection.connect();
DataOutputStream out = new DataOutputStream(connection.getOutputStream());
String content = "参数=" + URLEncoder.encode(参数, "GBK");
out.writeBytes(content);
收尾了。。。。。
总结：
前辈说，HttpURLConnection是基本的方法，HttpClient是基于HttpURLConnection的封装，基于“简单的问题用
复杂的方法，复杂的的问题用简单的方法”原理，我们回归原始，，，，
为前辈的机智点赞，记住--生成war包放在tomcat下启动来模拟真实的环境，好奇为什么定接口的时候不用json，以后
我商讨的方案，力争用json，后期好保养，