QNetworkAccessManager必须是长生命周期对象，否则pending请求被强制取消、finished信号不触发；POST JSON需手动设Content-Type并用QJsonDocument::toJson()；异步响应须先检查reply->error()；HTTPS需确保SSL证书可用。
QNetworkAccessManager 必须是长生命周期对象
它不是用完即弃的工具类，而是整个应用网络通信的中枢。创建在栈上、或作为局部变量返回，会导致请求发不出去、信号收不到——因为对象被析构后，所有 pending 请求被强制取消，finished 信号永远不会触发。
常见错误现象：QNetworkReply::OperationCanceledError 频繁出现，但没看到任何网络错误日志；或者 finished() 槽函数完全不执行。
- 正确做法：全局单例、主窗口成员变量、或
QApplication子对象（如用new QNetworkAccessManager(qApp)） - 避免在 lambda 或临时函数里 new 出来又不管生命周期
- 如果要用多实例（比如隔离认证上下文），确保每个实例独立持有，且不早于其关联的
QNetworkReply销毁
POST 发送 JSON 数据必须手动设置 header 和序列化
QNetworkAccessManager 不自动识别数据类型，setRawHeader() 和 QJsonDocument 配合是硬性步骤。漏掉 Content-Type，后端大概率返回 415 或直接忽略 body。
使用场景：调用 REST API、上传结构化参数、与 Node.js/Python 后端交互。
- 必须调用
request.setRawHeader("Content-Type", "application/json") - 用
QJsonDocument::toJson()得到QByteArray，直接传给post()，别用toString()再转回 QByteArray - 注意
QJsonDocument::Compact和PrettyPrint对调试友好但无功能差异，生产环境建议 Compact
异步响应处理要检查 reply->error() 而非只看 HTTP 状态码
HTTP 状态码（如 200、404）只是服务器返回的语义，而 reply->error() 才反映 Qt 底层是否真正完成了一次网络往返。很多“请求没反应”问题，其实是 DNS 失败、连接超时、SSL 握手失败等，此时 reply->attribute(QNetworkRequest::HttpStatusCodeAttribute) 根本无效，甚至为 -1。
常见错误现象：reply->attribute(QNetworkRequest::HttpStatusCodeAttribute).toInt() 返回 0，reply->readAll() 为空，但没打印 error 字符串。
- 务必在
finished()槽里先判断reply->error() == QNetworkReply::NoError - 再判断状态码：
reply->attribute(QNetworkRequest::HttpStatusCodeAttribute).toInt() >= 200 && ... - 错误信息用
reply->errorString()，不是reply->readAll()
HTTPS 请求在某些系统上需要显式加载根证书
Qt 默认信任系统证书库，但 Windows 上若没有安装 OpenSSL DLL，或嵌入式 Linux 没有配置 SSL_CERT_FILE，会出现 QNetworkReply::SslHandshakeFailedError，哪怕浏览器能正常打开同一地址。
性能 / 兼容性影响：不处理会导致全部 HTTPS 请求静默失败，且无法 fallback；硬编码证书路径会降低可移植性。
- 优先尝试
QSslConfiguration::defaultConfiguration().caCertificates()是否非空 - 必要时用
QSslConfiguration::setCaCertificates()加载 PEM 文件，路径用QStandardPaths::locate()查找 - 开发期可用
QSslSocket::supportsSsl()快速验证基础能力
事情说清了就结束。最常被跳过的其实是第一点——对象生命周期，它导致的问题最难 debug，因为现象分散、日志安静。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
