这里主要是这样的Qt写了一个服务端，在开发环境下，没出现任何问题，但在生产环境下，就出现问题了。

使用Fiddler的简单抓了下包：

发现Body只有27045，而请求里面确是这样的。

这里就很有意思了。

这里的Qt服务端，在发送完数据后，会主动和客户端断开连接。不像其他的web服务器，需要等客户端来断开连接。

这里用curl请求会有报错：

transfer closed with 25527 bytes remaining to read

大体上的意思就还有这么多位的数据没读，通道就被关闭了。

在Qt服务端关于关闭的代码是这样的：

tcpSocket->write(HttpResponse::message(json->toJson()).toUtf8());
tcpSocket->waitForBytesWritten();
tcpSocket->disconnectFromHost();

并且这个tcpSocket->write的返回值，也是正确的，说明的确把要发送的数据送到了网卡中让其发送。并且waitForBytesWritten也是返回true的。

个人感觉主要的问题就是tcpSocket->waitForBytesWritten()，可能是Qt的一个BUG，我这里用的是5.5.1

感觉这里Qt做的没有我想象中的那样。

这里的解决办法有3个：

①数据分包发送，有些web服务器会把发送的数据分成几个包发送给客户端。这种方式就能解决上面的问题。

②简单修改下代码逻辑，比如改成了这样的：

qint64 writeSize = tcpSocket->write(HttpResponse::message(json->toJson()).toUtf8());
qDebug() << "writeSize: " << writeSize;

if(!tcpSocket->waitForBytesWritten(10 * 1000)){

    qDebug() << "error:" << tcpSocket->errorString();
}

if(!tcpSocket->waitForDisconnected(10 * 1000)){

    tcpSocket->disconnectFromHost();
}
delete json;
delete tcpSocket;

③加一个waitForDisconnected()如下：

tcpSocket->disconnectFromHost();
tcpSocket->waitForDisconnected();

建议优先用第三种，不行就再考虑第一种和第二种。