MFC HTTP文件上传实战：WinINet、multipart与工作线程详解

简介：MFC框架下实现HTTP/HTTPS上传的完整示例工程，面向需要基于WinInet进行网络文件传输的C++开发人员，重点解决文件选择、服务器地址配置和上传进度展示等界面与协议衔接问题。压缩包共49个文件，以头文件（h）、源文件（cpp）、Visual Studio工程文件（sln/vcxproj）为主，另含可运行的exe及调试所需的pdb、idb等文件，整体大小约73.09MB，便于直接打开工程查看代码和运行效果。该资源已有567人学习，代码中封装了PostFormData等关键类，演示了MFC对话框下调用WinInet接口实现POST上传的流程，包括SSL设置、请求构造、错误处理及UI更新，适合作为学习MFC网络编程和HTTP协议在实际项目中落地的参考。

1. 打开文件、填上服务器地址、点上传：MFC里最朴素的HTTP上传工具怎么做

做过Windows桌面工具的人，多半遇到过这种需求：生产线上把报表传回服务器、终端机把日志文件定时上送、或者给一个十年前的MFC老程序加一个“把导出文件发给中心”的功能。这个标题其实就是一套已经标准化了的需求——文件选择、服务器地址配置、HTTP/HTTPS上传，三者合一落到MFC界面上。它解决的是“不让使用方记任何命令行、不装额外运行时，双击就能把文件传到指定服务端”这件事，适合做内部工具、工控机客户端、遗留系统集成。技术路线很成熟：WinINet/WinHTTP是系统自带接口，CFileDialog选文件，编辑框配地址，一条主链路下来几乎没有第三方依赖。

2. 先搭界面：文件选择、服务器地址与配置记忆

2.1 用CFileDialog做文件选择：单文件与多文件的两种写法

MFC里选文件的标准做法是CFileDialog，这个封装直接走Windows通用对话框，不需要自己画文件列表。标题里的“文件选择”看起来是个小功能，但落地时有两个决策点：只允许选一个文件还是多个文件，以及选完文件之后路径怎么存、下次打开要不要记住上次的目录。

先看单文件的选择写法：

// 单文件选择：pFileName 接收完整路径 CString SelectSingleFile(const CString& strTitle) { CFileDialog dlg(TRUE, // TRUE = 打开文件 _T("*.*"), // 默认扩展名，仅作初始过滤 NULL, OFN_FILEMUSTEXIST | OFN_HIDEREADONLY, _T("所有文件 (*.*)|*.*|日志文件 (*.log)|*.log||"), AfxGetMainWnd()); dlg.m_ofn.lpstrTitle = strTitle; // 对话框标题 if (dlg.DoModal() == IDOK) { return dlg.GetPathName(); // 返回完整路径 } return _T(""); }

OFN_FILEMUSTEXIST强制用户只能选真实存在的文件，适合上传场景，避免选了路径之后读文件才报错。OFN_HIDEREADONLY隐藏“只读”复选框，减少无意义输入。GetPathName()返回的是磁盘绝对路径，后续传给上传函数直接使用即可。

多文件选择会稍微绕一点。CFileDialog 构造后要手动加OFN_ALLOWMULTISELECT标志，同时缓冲区大小默认只有_MAX_PATH，文件多或者路径长时会截断，这是个老坑。需要自己扩容缓冲区：

// 多文件选择：返回 CStringArray，元素为完整路径 CStringArray SelectMultiFiles(const CString& strTitle) { CStringArray arrFiles; CFileDialog dlg(TRUE, NULL, NULL, OFN_FILEMUSTEXIST | OFN_HIDEREADONLY | OFN_ALLOWMULTISELECT, _T("所有文件 (*.*)|*.*||"), AfxGetMainWnd()); // 关键：扩容缓冲区，否则文件多时静默截断 const UINT nBufSize = 32768; dlg.m_ofn.lpstrFile = new TCHAR[nBufSize]; dlg.m_ofn.nMaxFile = nBufSize; dlg.m_ofn.lpstrFile[0] = _T('\0'); dlg.m_ofn.lpstrTitle = strTitle; if (dlg.DoModal() == IDOK) { POSITION pos = dlg.GetStartPosition(); while (pos != NULL) { arrFiles.Add(dlg.GetNextPathName(pos)); } } delete[] dlg.m_ofn.lpstrFile; return arrFiles; }

GetNextPathName内部会处理“目录 + 多个文件名”两种返回格式，不用自己解析，这是MFC对比纯Win32 API的便利点。这里有个容易被忽视的细节：lpstrFile指向的缓冲区在DoModal()期间必须保持有效，所以不能直接在栈上构造后就释放，我习惯用new[]分配并在对话框关闭后delete[]。多选模式下返回的文件在CStringArray里，后续可以逐一遍历上传。

2.2 服务器地址配置区：编辑框、URL合法性校验与注册表记忆

服务器地址配置是标题里另一个明确要求。通常做法是放一个静态文本加一个编辑框，旁边留“保存配置”的按钮。控件排布可以直接在对话框资源编辑器里画，运行起来就是标准的MFC窗口，不需要额外代码。但地址本身必须校验，否则用户填了个192.168.1.10:8080或者漏了协议头，上传阶段才报错，体验就很差。

我在界面里一般放三个控件：CComboBox用于协议选择（HTTP / HTTPS），一个CEdit用于填地址和端口，一个“测试连接”按钮作为可选动作。地址框里让用户填完整URL，比如http://192.168.1.10:8080/upload，校验用 WinINet 自带的InternetCrackUrl最省事：

// 校验URL是否合法，并拆出协议、主机、端口、路径 BOOL ValidateServerUrl(const CString& strUrl, CString& strHost, INTERNET_PORT& nPort) { if (strUrl.IsEmpty()) { AfxMessageBox(_T("服务器地址不能为空")); return FALSE; } URL_COMPONENTS uc = { 0 }; uc.dwStructSize = sizeof(URL_COMPONENTS); uc.lpszHostName = NULL; uc.dwHostNameLength = 1; // 先探测需要多大缓冲区 uc.lpszUrlPath = NULL; uc.dwUrlPathLength = 1; // INTERNET_FLAG_NO_CANONICALIZE：不自动转义，保持原样 if (!InternetCrackUrl(strUrl, (DWORD)strUrl.GetLength(), INTERNET_FLAG_NO_CANONICALIZE, &uc)) { AfxMessageBox(_T("URL格式不正确，请检查是否缺少 http:// 或 https://")); return FALSE; } // 第二次调用获取真实数据 CString strHostBuf; CString strPathBuf; uc.lpszHostName = strHostBuf.GetBuffer(uc.dwHostNameLength + 1); uc.dwHostNameLength = uc.dwHostNameLength + 1; uc.lpszUrlPath = strPathBuf.GetBuffer(uc.dwUrlPathLength + 1); uc.dwUrlPathLength = uc.dwUrlPathLength + 1; if (!InternetCrackUrl(strUrl, (DWORD)strUrl.GetLength(), INTERNET_FLAG_NO_CANONICALIZE, &uc)) { strHostBuf.ReleaseBuffer(); strPathBuf.ReleaseBuffer(); return FALSE; } strHostBuf.ReleaseBuffer(); strPathBuf.ReleaseBuffer(); strHost = strHostBuf; nPort = uc.nPort; return TRUE; }

第一次InternetCrackUrl传空缓冲区是为了探测长度，第二次才真正填充数据。uc.nPort在URL里没写明端口时，WinINet 会自动补 80 或 443，这个特性省得自己判断协议。校验通过后，把完整地址保存到注册表，下次启动直接带出来。保存位置用HKEY_CURRENT_USER\Software\你的程序名，不需要管理员权限：

// 保存服务器地址到注册表，key为HKEY_CURRENT_USER void SaveServerUrl(const CString& strUrl) { HKEY hKey = NULL; DWORD dwDisposition = 0; LONG lRet = RegCreateKeyEx(HKEY_CURRENT_USER, _T("Software\\FileUploadTool"), 0, NULL, 0, KEY_WRITE, NULL, &hKey, &dwDisposition); if (lRet == ERROR_SUCCESS && hKey != NULL) { // 以UTF-16写入，REG_SZ即宽字符字符串 RegSetValueEx(hKey, _T("ServerUrl"), 0, REG_SZ, (const BYTE*)(LPCTSTR)strUrl, (DWORD)(strUrl.GetLength() + 1) * sizeof(TCHAR)); RegCloseKey(hKey); } } // 读取时用RegQueryValueEx，注意先探测长度再读 CString LoadServerUrl() { CString strUrl; HKEY hKey = NULL; if (RegOpenKeyEx(HKEY_CURRENT_USER, _T("Software\\FileUploadTool"), 0, KEY_READ, &hKey) == ERROR_SUCCESS) { DWORD dwSize = 0; RegQueryValueEx(hKey, _T("ServerUrl"), NULL, NULL, NULL, &dwSize); // 拿到大小 if (dwSize > 0) { LPTSTR pBuf = strUrl.GetBuffer(dwSize / sizeof(TCHAR)); RegQueryValueEx(hKey, _T("ServerUrl"), NULL, NULL, (BYTE*)pBuf, &dwSize); strUrl.ReleaseBuffer(); } RegCloseKey(hKey); } return strUrl; }

GetBuffer分配的缓冲区大小严格按dwSize / sizeof(TCHAR)计算，注册表返回的dwSize包含结尾的\0字节数。这个写法比用CString::LoadFile或自定义INI更稳，而且注册表方案在域环境下还能跟随用户配置漫游。除了地址，文件选择对话框的初始目录也可以存注册表，下次打开直接定位到上次的目录，省得一层层点进去。

3. 传输层选型与multipart拼包

3.1 为什么选WinINet而不是MFC的CInternetSession或libcurl

MFC自带CInternetSession和CHttpFile，老教程里常用来做HTTP GET/POST，但标题需求是上传文件，这就有个现实问题：CHttpFile对 multipart/form-data 的支持基本为零，要自己拼报文体，而它又包了一层很厚的封装，拼完数据还要受制于它的句柄管理方式。我试过用CInternetSession做文件上传，最后为了控制超时和读取响应，还是要拿底层HINTERNET句柄，等于白绕一圈。所以干脆直接用WinINet API，中间不做MFC封装。

libcurl 功能确实强，支持断点续传、连接复用、SSL各种细节，但MFC工程引入它要把CURL源码或预编译库接进VS项目，链接配置对新手是麻烦事。如果目标是“在MFC框架下快速做出一个自用的上传工具”，WinINet是系统自带的，不会有运行时分发问题。WinINet 在服务端API调用的场景下有一个天然好处：默认集成IE的代理设置，公司内网开了代理时，InternetOpen传INTERNET_OPEN_TYPE_PRECONFIG就能自动走代理，省一层配置。代价是它自带HTTP连接池，长连接保持行为不完全由自己控制，上传大文件时要留意连接被服务端回收的情况。

3.2 手拼multipart/form-data：格式、boundary与文件名编码

HTTP上传文件，绝大多数服务端接口（比如Java的Servlet、Python的Flask/FastAPI、Nginx+后端）都按 multipart/form-data 解析。这个格式本身不复杂，核心是一个随机boundary字符串把各部分分隔开。自己在MFC里拼包，等于把浏览器的行为复刻一遍，控制力最强。

拼包前先明确两个参数：name是服务端接口约定的表单字段名，很多后端写死成file，要跟对方确认；filename是服务端保存收到的文件名，如果不想让服务器看到本地磁盘路径，这里可以只传文件名部分。正文长度需要精确计算，否则服务端报文解析会错位。

// 构造multipart/form-data报文体并上传 BOOL UploadViaWinINet(const CString& strServerUrl, const CString& strFilePath, CString& strResponse) // 返回值：服务端响应文本 { // 1. 读取文件内容，文件不大时一次性读入 CFile file; if (!file.Open(strFilePath, CFile::modeRead | CFile::shareDenyWrite)) { AfxMessageBox(_T("无法打开文件，可能被占用")); return FALSE; } ULONGLONG nFileSize = file.GetLength(); BYTE* pFileData = new BYTE[(size_t)nFileSize]; file.Read(pFileData, (UINT)nFileSize); file.Close(); // 2. 生成随机boundary CString strBoundary; strBoundary.Format(_T("----WebKitFormBoundary%04d%04d"), rand() % 10000, rand() % 10000); // 3. 从完整路径里拆出文件名（只取最后一段） CString strFileName = strFilePath; int nPos = strFileName.ReverseFind(_T('\\')); if (nPos >= 0) strFileName = strFileName.Mid(nPos + 1); // 4. 拼header段 CString strHeader; strHeader.Format(_T("--%s\r\n") _T("Content-Disposition: form-data; name=\"file\"; filename=\"%s\"\r\n") _T("Content-Type: application/octet-stream\r\n\r\n"), strBoundary, strFileName); CStringA strHeaderA = CStringA(strHeader); // 5. 拼结尾段 CString strTail; strTail.Format(_T("\r\n--%s--\r\n"), strBoundary); CStringA strTailA = CStringA(strTail); // 6. 总长度 = header + 文件 + tail ULONGLONG nContentLength = strHeaderA.GetLength() + nFileSize + strTailA.GetLength(); DWORD dwContentLength = (DWORD)nContentLength; HINTERNET hInternet = InternetOpen(_T("MFCUpload/1.0"), INTERNET_OPEN_TYPE_PRECONFIG, NULL, NULL, 0); if (hInternet == NULL) { delete[] pFileData; return FALSE; } // 7. 用INTERNET_FLAG_SECURE走https，服务端要求http就传0 HINTERNET hConnect = InternetConnect(hInternet, GetHostFromUrl(strServerUrl), GetPortFromUrl(strServerUrl), NULL, NULL, INTERNET_SERVICE_HTTP, 0, 0); if (hConnect == NULL) { InternetCloseHandle(hInternet); delete[] pFileData; return FALSE; } // 8. 构造请求：POST + UploadPath HINTERNET hRequest = HttpOpenRequest(hConnect, _T("POST"), GetPathFromUrl(strServerUrl), NULL, NULL, NULL, INTERNET_FLAG_SECURE, 0); if (hRequest == NULL) { InternetCloseHandle(hConnect); InternetCloseHandle(hInternet); delete[] pFileData; return FALSE; } // 9. 设置Content-Type和Content-Length CString strContentType; strContentType.Format(_T("multipart/form-data; boundary=%s"), strBoundary); HttpAddRequestHeaders(hRequest, _T("Content-Type: ") + strContentType, (DWORD)-1L, HTTP_ADDREQ_FLAG_REPLACE | HTTP_ADDREQ_FLAG_ADD); // 10. 发送请求+分块写body BOOL bSend = HttpSendRequestEx(hRequest, NULL, 0, dwContentLength, 0); if (bSend) { DWORD dwWritten = 0; // 先写header段 InternetWriteFile(hRequest, strHeaderA.GetBuffer(), strHeaderA.GetLength(), &dwWritten); strHeaderA.ReleaseBuffer(); // 再写文件内容 DWORD dwFilePos = 0; while (dwFilePos < (DWORD)nFileSize) { DWORD dwChunk = min(4096, (DWORD)nFileSize - dwFilePos); InternetWriteFile(hRequest, pFileData + dwFilePos, dwChunk, &dwWritten); dwFilePos += dwWritten; } // 最后写tail段 InternetWriteFile(hRequest, strTailA.GetBuffer(), strTailA.GetLength(), &dwWritten); strTailA.ReleaseBuffer(); } // 11. 结束请求并读取响应文本 BOOL bEnd = HttpEndRequest(hRequest, NULL, 0, 0); if (bEnd) { CHAR szBuf[1025] = { 0 }; DWORD dwRead = 0; while (InternetReadFile(hRequest, szBuf, 1024, &dwRead) && dwRead > 0) { szBuf[dwRead] = 0; strResponse += CString(szBuf); // 注意此处假定响应是文本 dwRead = 0; } } InternetCloseHandle(hRequest); InternetCloseHandle(hConnect); InternetCloseHandle(hInternet); delete[] pFileData; return bEnd; }

这个流程最容易翻车的地方是HttpSendRequestEx的dwContentLength参数。它必须等于整个包体长度（header + 文件 + tail），多一字节少一字节都会让服务端解析失败或超时等待。另一个是InternetWriteFile的返回值是“本次写入的字节数”，不等于你要写入的字节数，所以循环里必须用dwFilePos += dwWritten，不能假设一次写完。文件数据用min(4096, ...)分块，避免一次性把整个大文件塞给底层网络栈。

3.3 HTTPS上传与证书处理：INTERNET_FLAG_SECURE和证书错误路径

标题明确提到“http或者https”，在设计上就是地址栏给用户两个选择。走HTTPS时HttpOpenRequest要带上INTERNET_FLAG_SECURE标志，同时默认端口会变成443。这一步做了之后，最常见的现象是内网自签名证书时报ERROR_INTERNET_SEC_CERT_DATE_INVALID（12045）或者ERROR_INTERNET_SEC_CERT_CN_INVALID（12037），程序直接弹错，上传中断。

这是因为WinINet默认对HTTPS证书做严格校验，而内网服务器的证书往往是自签的、主机名对不上或已过期。生产环境我的处理原则是：校验不能全关，但内网工具可以容忍特定错误。做法是给HttpOpenRequest追加几个忽略标志：

// 自签名内网证书：只在上传工具里加，生产环境不要效仿 DWORD dwSecureFlags = INTERNET_FLAG_SECURE; // 允许证书名称与主机名不一致 dwSecureFlags |= INTERNET_FLAG_IGNORE_CERT_CN_INVALID; // 允许证书日期已过期 dwSecureFlags |= INTERNET_FLAG_IGNORE_CERT_DATE_INVALID;

命令行工具和无界面服务绝不建议这样写，等于把HTTPS的边界撕掉一半。但在机房内网、设备证书常年不更新的场景下，这是同事之间传文件的工具，安全威胁模型远低于公网，加了反而能正常干活。如果服务器证书确实有问题，更体面的做法是让运维把证书导入Windows根证书存储区：certmgr.msc→ 受信任的根证书颁发机构 → 导入，这样代码里一点特殊标志都不用加。

4. 让界面不卡：工作线程、进度上报与取消

4.1 上传为什么必须离开UI线程

MFC程序的UI线程靠消息循环活着。如果直接在“上传”按钮的OnBnClicked里跑HttpSendRequestEx加InternetWriteFile，那么从点击到最后传输完成，整个窗口的消息泵被卡住，拖动窗口、点取消按钮全部无效。文件小时只有一两秒的“假死”，大文件时Windows会直接标注“未响应”，用户第一反应是杀进程，血泪经验。

更麻烦的是WinINet的InternetOpen句柄和线程模型有限制：同一个HINTERNET句柄不建议跨线程并发使用。常见做法是在工作线程里重新InternetOpen，这样请求、连接、句柄都在线程内自洽，主线程只通过消息接收结果。MFC里建工作线程的标准工具是AfxBeginThread。

4.2 工作线程与PostMessage进度上报

上传线程不需要返回线程句柄，也不需要等待，AfxBeginThread默认立即启动。启动后线程不能直接操作界面控件，只能通过PostMessage向主窗口投递自定义消息，让主窗口去更新进度条。

#define WM_UPLOAD_PROGRESS (WM_USER + 100) #define WM_UPLOAD_FINISHED (WM_USER + 101) // 上传工作线程入口：pParam 指向一个包含所有参数的上下文结构体 UINT UploadThreadProc(LPVOID pParam) { CUploadContext* pCtx = (CUploadContext*)pParam; HWND hWnd = pCtx->hWnd; // 主窗口句柄，用于PostMessage CString strUrl = pCtx->strUrl; CString strFile = pCtx->strFile; // 内部重新打开Internet句柄，避免跨线程复用 HINTERNET hInternet = InternetOpen(_T("MFCUpload/1.0"), INTERNET_OPEN_TYPE_PRECONFIG, NULL, NULL, 0); // ... 这里复用 3.2 节的上传主体逻辑 ... // 上传过程中每写完一块就上报一次进度 DWORD dwFilePos = 0; while (dwFilePos < nFileSize) { DWORD dwChunk = min(4096, nFileSize - dwFilePos); InternetWriteFile(hRequest, pFileData + dwFilePos, dwChunk, &dwWritten); dwFilePos += dwWritten; // 向主窗口投递进度消息，进度百分比由主窗口计算 ::PostMessage(hWnd, WM_UPLOAD_PROGRESS, (WPARAM)dwFilePos, (LPARAM)nFileSize); } // 结束时通知主窗口 ::PostMessage(hWnd, WM_UPLOAD_FINISHED, (WPARAM)bSuccess, (LPARAM)&strResponse); delete pCtx; return 0; } // 按钮事件里启动线程 void CFileUploadDlg::OnBnClickedBtnUpload() { // 收集界面参数到上下文结构体 CUploadContext* pCtx = new CUploadContext; pCtx->hWnd = m_hWnd; pCtx->strUrl = m_strServerUrl; pCtx->strFile = m_strFilePath; // 启用取消按钮，禁用上传按钮，防止二次点击 GetDlgItem(IDC_BTN_UPLOAD)->EnableWindow(FALSE); GetDlgItem(IDC_BTN_CANCEL)->EnableWindow(TRUE); AfxBeginThread(UploadThreadProc, pCtx); }

进度消息的WPARAM传已上传字节数，LPARAM传文件总大小，主窗口在ON_MESSAGE(WM_UPLOAD_PROGRESS, ...)里相除得到百分比。这里有个性能问题：4KB一块就发一条消息，100MB文件要发两万多条消息，进度条刷新不过来。实际做法是做个节流：记录上次发送的当前进度，只有变化超过1MB或者时间超过200ms才PostMessage。消息量降下来后，进度条拖动和窗口重绘都不会抢上传线程的CPU。

4.3 取消操作：HttpEndRequest后的处理与标志位

取消上传没那么简单，不是设个m_bCancel = TRUE线程就会停。WinINet的上传请求一旦发出，InternetWriteFile会继续把数据塞给网络栈。真正的取消动作是关闭请求句柄，但直接InternetCloseHandle会导致服务端收到一个不完整的请求体，对某些后端来说会留下半截文件或占用一个连接不释放。

更稳妥的顺序是：把volatile BOOL取消标志传给线程，线程在写文件循环的开始处判断一次；如果置位，就调用HttpEndRequest结束当前请求，或者直接把请求句柄关闭，然后再清理。有一种情况比较棘手：服务端如果正在等待完整的包体，HttpEndRequest会阻塞到超时。为了响应取消操作，我一般在线程里再留一个隐藏的小技巧——设置较短的INTERNET_OPTION_RECEIVE_TIMEOUT，让取消后的等待尽快返回。

// 在循环入口处响应取消 if (pCtx->bCancel) { // 中断当前请求，服务端会收到连接重置 InternetCloseHandle(hRequest); // 通知主窗口已取消 ::PostMessage(hWnd, WM_UPLOAD_FINISHED, (WPARAM)FALSE, (LPARAM)_T("用户取消")); break; }

MFC里对取消按钮的响应，不要粗暴地在线程里搞TerminateThread，那会让网络句柄泄漏、内存来不及释放，下次上传时系统可能报句柄不足。HttpEndRequest失败返回时读一下GetLastError，如果是ERROR_INTERNET_CONNECTION_RESET，基本可以认定是主动取消导致的，不算真正意义上的网络异常，日志里要区分开。

5. MFC上传文件绕不开的5个坑：现象、原因、处理

5.1 点击上传后窗口白屏无响应

现象：点完“上传”，窗口变白，鼠标转圈，等几秒甚至几十秒才弹结果。文件稍微大一点，系统直接提示“此程序未响应”，用户当场就想杀进程。

原因：按钮事件直接调了上传函数。HttpSendRequestEx和InternetWriteFile是阻塞调用，期间UI线程的消息循环完全停摆。对话框的“确定”“取消”按钮全部失效，连重绘都被卡住。

处理：上传逻辑必须放工作线程。按钮事件里只做三件事：收集界面参数、禁掉上传按钮、AfxBeginThread创建线程。线程内部与主窗口交互一律走PostMessage，不要用SendMessage，因为后者是同步的，等主窗口处理消息时如果主窗口正忙，线程反而被卡住。

5.2 中文文件名上传后服务器收到乱码或400

现象：文件名是“测试报告.pdf”，上传后服务端日志里显示????.pdf或者接口直接返回400，文件保存失败。

原因：multipart里filename的值按Unicode直接CStringA强转，转成了系统当前代码页（中文环境是GBK），但服务端按UTF-8解析，两边对不上。文件名里的中文在HTTP头里属于非ASCII字符，有的框架严格要求RFC 2231编码，有的则看你用什么格式塞进去。

处理：两个层面解决。第一，filename放进header之前先转UTF-8，CStringA strUtf8 = CW2A(strFileName, CP_UTF8)，保证字节序列是UTF-8；第二，如果服务端对非ASCII文件名仍然挑剔，就约定好统一把文件名ASCII化——上传时把本地文件名替换成file_YYYYMMDD_HHMMSS.ext再放进multipart，原始名写在额外一个表单字段里上报。后面这种做法在实际内网系统里最省心，服务器端不用改编码逻辑。

5.3 服务器地址可达但上传超时，程序几分钟后才报错

现象：InternetWriteFile返回成功后，程序卡在HttpEndRequest或InternetReadFile上，最长要拖一两分钟才返回错误码12002。

原因：WinINet默认的接收超时时间很长，而且请求失败后还有内部重试逻辑。服务器如果只收文件不返回响应（比如某些老接口写死不吐内容），客户端会一直挂在读响应那一步。

处理：给请求句柄显式设置超时。HttpOpenRequest返回后立刻调用InternetSetOption：

// 设置连接、发送、接收三组超时，单位毫秒 DWORD dwTimeout = 30000; InternetSetOption(hRequest, INTERNET_OPTION_CONNECT_TIMEOUT, &dwTimeout, sizeof(dwTimeout)); InternetSetOption(hRequest, INTERNET_OPTION_SEND_TIMEOUT, &dwTimeout, sizeof(dwTimeout)); InternetSetOption(hRequest, INTERNET_OPTION_RECEIVE_TIMEOUT, &dwTimeout, sizeof(dwTimeout));

30秒对常规内网足够，文件特别大或跨公网时可以放宽到60秒。这里要区分连接超时和接收超时的现象：连不上是立刻弹错误，接收超时是“已经传完了但没有等到服务端回应”，日志里看到12002就知道是哪一端的问题。

5.4 HTTPS上传报错12037/12045，证书明明是合法的

现象：同样的地址，浏览器访问完全正常，程序里一传就报12045，再一查是SEC_CERT_DATE_INVALID。

原因：浏览器下载了系统根证书列表做了自动化信任，而WinINet在校验时使用的根证书存储区可能没有包含新颁发的中间证书。另一种常见情况是服务器证书链里带了本地自签的根证书，这台机器没装过。

处理：先让运维确认证书链完整，缺中间证书就去服务器导出补装。如果就是为了让工具跑通，在内网场景下可以把INTERNET_FLAG_IGNORE_CERT_DATE_INVALID和INTERNET_FLAG_IGNORE_CERT_CN_INVALID加上，但要把这段逻辑用宏或配置项包起来，防止别人误以为HTTPS的证书校验是摆设。日志里务必记录GetLastError()，这样别人排查时立刻知道是证书问题而不是真的断网。

5.5 传1GB大文件内存直接爆掉

现象：文件小于几百MB没问题，超过1GB后new BYTE[nFileSize]抛异常，或程序吃掉大量内存被系统强制终止。

原因：3.2节的示例里为了演示把整个文件读进了内存。大文件场景这个做法不成立——字节数组、CString里的header和tail同时驻留内存，峰值接近文件两倍大小。

处理：改为流式上传。InternetWriteFile本身支持分块写，完全可以把CFile的对象传给线程，边读边写：

// 流式上传：不一次性读入内存 CFile file; file.Open(strFilePath, CFile::modeRead | CFile::shareDenyWrite); BYTE buffer[8192]; ULONGLONG nRemain = file.GetLength(); while (nRemain > 0) { UINT nRead = file.Read(buffer, sizeof(buffer)); DWORD dwWritten = 0; InternetWriteFile(hRequest, buffer, nRead, &dwWritten); nRemain -= dwWritten; // 以实际写入为准 } file.Close();

这里还要警惕32位程序的文件大小上限。MFC的CFile::GetLength()返回ULONGLONG，但老代码里如果用了DWORD接收，超过4GB后会溢出。做工具时如果没把握系统是64位的，建议先查sizeof(void*)和文件大小上限，或者干脆限制只传4GB以下文件。

6. 上传完怎么确认真成功了：抓包验证与日志习惯

工具做完能跑通，不代表它真的在正确地工作。我见过很多次“显示上传成功但服务器上文件是0字节”的情况，原因五花八门：服务端返回200但内容是空文件、multipart边界写得有误导致只解析出部分字段、或者进度条走完但HttpEndRequest失败被代码吞掉了。所以验证这一步我强烈建议装个Fiddler或Wireshark，手动抓一次上传请求。

Fiddler抓HTTPS需要装根证书，内网测试机上直接跑还挺有效。抓到请求后重点看三类内容：Content-Type里的boundary是否与包体一致；文件内容的起始和结束位置是否有\r\n混淆；Content-Length是否与包体实际长度吻合。这三处错一个，服务端行为都会很奇怪。另外，多看服务端日志比看客户端返回码靠谱。客户端HttpEndRequest成功只能说明“TCP层面的请求已经完整发完”，服务端业务逻辑是否成功处理，完全看HTTP状态码和响应体内容。

我习惯在上传函数返回后统一记一条日志，字段固定：

日志写进同目录下的upload.log，追加模式，不用数据库。出现“显示成功但文件不对”的情况，先查返回码是200还是201，再查响应体里服务端有没有把文件ID回传。进阶方向可以考虑做MD5秒传：上传前先传文件哈希，服务端比对已有文件就直接返回成功，省大量带宽。这个思路在MFC里实现也不难，多一次HTTP请求而已。

另外注意一点工作习惯：写线程里收到任何WinINet错误，一定要把GetLastError()转换成可读的ERROR_INTERNET_*字样记下来。这个代码在网上能搜到现成的错误映射表，但每次项目里都有人直接把数字塞日志里，排查时得翻Windows头文件才猜得到意思，等于给自己埋坑。做工具不怕代码朴素，怕的是出错时没有足够信息定位。这些日志习惯保持住，比把上传代码优化出20%的性能更有价值，希望帮到你。

本文还有配套的精品资源，点击获取