企业官网建设流程全解析

很多人第一次接触 Windows 网络编程，就是被这几个函数领进门的：InternetOpen、InternetOpenUrl、InternetReadFile、InternetCloseHandle。这四件套是 WinINet 提供的最朴素的 HTTP 请求方案，不怎么讲究 REST 规范，也谈不上优雅，但就是能用，而且稳定得让人感动。早些年做桌面升级模块、数据拉取、下载安装包，我都是靠它们在 Windows 原生环境里直连 HTTP/HTTPS 服务，不引第三方库，不打包 DLL，编译完一个 exe 就能跑。

说句实话，如果你只是想快速实现一个"给我把某个 URL 的内容取回来"的功能，没有高并发、没有复杂 Header、不需要断点续传，那么这套 API 依然是最短路径。但前提是你要踩对参数、读对返回值、管好句柄，否则一个看似简单的下载功能，能让你调试三天三夜。这篇文章就围绕这四个函数，把它们的前因后果、参数细节、完整示例和我在实际项目中踩过的坑，一次说清楚。

1. 先搞明白这四个函数在整条链路上分别扮演什么角色

1.1 为什么这套古董 API 至今还有用

WinINet（Windows Internet API）从 Windows 95 时代就存在了，到今天依然是系统自带的网络接口。它的定位是应用层协议库，专门处理 HTTP、FTP、Gopher（后者基本作古）等协议。有人说技术选型就该选 WinHTTP 或者 libcurl，这话没错，但也要看场景。WinINet 最大的优势是免部署、随系统走，而且对外部代理和系统 IE 配置天然兼容，在政企内网、需走系统代理的环境里特别省心。

我维护过的几个工具类程序里，有些要跑在完全离线、只有内网代理的机器上，用 libcurl 你需要额外处理 NTLM 代理、证书库、动态库依赖；换成 WinINet 反而简单，因为访问类型用INTERNET_OPEN_TYPE_PRECONFIG的时候，它会自动读注册表里面 IE 的代理配置。所以，哪怕它接口古老，在特定场景下它还是那个"开箱即用"的答案。而我们今天要讲的这四个函数，正是 WinINet 里最核心的"快速请求链路"，相当于一条最带流量的主干道。

1.2 四个函数的调用顺序和职责划分

这四个函数构成了一组完整的"打开会话 → 打开 URL → 读取数据 → 清理"生命周期，缺一不可，顺序也不能乱。

InternetOpen是第一步。它负责创建一个全局的会话句柄（HINTERNET），你可以把它理解成"应用程序和网络层之间的一根管道"。这根管道的配置包括用户代理字符串、网络访问方式、代理设置等。后续的所有网络操作都要挂在这个会话下面，所以它就像是整栋楼的大门钥匙。

InternetOpenUrl是第二步。它接收InternetOpen返回的会话句柄，再加上一个 URL 字符串和一些标志位，然后向服务器发起请求，如果成功就返回一个"请求句柄"。这个句柄代表一条已经建立的 HTTP 连接，里面包含了服务器的响应状态、响应头、正文数据入口等信息。

InternetReadFile是第三步，也是最需要耐心的一步。它负责从这个请求句柄中分批读取响应正文。为什么是"分批"？因为 HTTP 响应数据是流式的，长度可能是几 KB，也可能是几 GB，你不可能要求 API 一次把全部数据都塞进内存。所以正确姿势是给一个缓冲区，每次读一部分，循环读到最后，直到读完为止。

InternetCloseHandle是收尾动作。它释放第二步返回的请求句柄和第一步创建的会话句柄。虽然进程退出时系统会自动清理，但在长期运行或频繁请求的服务里，你不主动关闭，句柄数会持续上涨，最终导致系统资源耗尽，程序行为变得诡异。

你只要把这个调用序列理解成"开门 → 进楼 → 一层层搬东西 → 锁门走人"，这四个函数的协作关系就永远不会搞混。

2. 参数拆解：每个参数都可能埋着雷

2.1 InternetOpen 的参数细节与选型建议

函数原型是这样的：

HINTERNET InternetOpenW( LPCWSTR lpszAgent, DWORD dwAccessType, LPCWSTR lpszProxyName, LPCWSTR lpszProxyBypass, DWORD dwFlags );

第一个参数lpszAgent是用户代理字符串。别随手填个空字符串，很多服务器会直接拒绝没有 UA 的请求，或者返回压缩、限速等差异化响应。通常我会填类似Mozilla/5.0 (Windows NT 10.0; Win64; x64)或者MyApp/1.0 (+http://example.com)，你自己构造一个固定 UA 也行，只要格式不太离谱，服务器就会拿你当正常客户端。

第二个参数dwAccessType是网络访问类型。有四个可选值：

• INTERNET_OPEN_TYPE_PRECONFIG：使用系统注册表里的 IE 代理配置，最省心。
• INTERNET_OPEN_TYPE_DIRECT：直接连接，不经过代理。
• INTERNET_OPEN_TYPE_PROXY：使用下方指定的代理服务器。
• INTERNET_OPEN_TYPE_PRECONFIG_WITH_NO_AUTOPROXY：类似 PRECONFIG，但跳过自动代理脚本。

如果你跑在公网环境，DIRECT最省事；如果你要访问内网资源或者某些办公网络，PRECONFIG更靠谱。我个人的经验是：默认首选PRECONFIG，出了问题再切DIRECT，这样能兼容大多数用户网络。

第三个和第四个参数分别指定代理服务器和绕过代理的地址列表，仅在dwAccessType为INTERNET_OPEN_TYPE_PROXY时才有意义。注意，如果你用了PRECONFIG，这里应该传NULL，让系统自己判断。很多人在这里传了非空值，结果行为变得怪怪的。

最后一个参数dwFlags是功能开关。常见的是INTERNET_FLAG_ASYNC（异步模式），如果你只想写同步阻塞的简单代码，这里传 0 即可。如果设置了INTERNET_FLAG_ASYNC，你就必须设置回调函数来接收异步事件，代码复杂度上几个台阶，新手建议绕行。

注意：InternetOpen返回的句柄也有可能失败，返回NULL。拿到之后务必立即用GetLastError()检查错误码，常见的错误如ERROR_INTERNET_INTERNAL_ERROR等，这是后续排查的第一步。

2.2 InternetOpenUrl 的关键标志位

InternetOpenUrl的原型是：

HINTERNET InternetOpenUrlW( HINTERNET hInternet, LPCWSTR lpszUrl, LPCWSTR lpszHeaders, DWORD dwHeadersLength, DWORD dwFlags, DWORD_PTR dwContext );

第一个参数就是InternetOpen返回的会话句柄，没什么好说的。第二个参数是完整 URL，可以是http://或https://开头的地址，也支持 FTP 地址。第三个和第四个参数是附加请求头。比如你想发送自定义的Accept-Language: zh-CN，就可以把字符串传进来，然后长度用-1表示自动计算（函数原型里dwHeadersLength传-1L表示 lpszHeaders 以 \0 结尾）。

第五个参数dwFlags是重头戏，很多疑难杂症都在这里。常用值如下：

• INTERNET_FLAG_RELOAD：强制从服务器获取，而不是用缓存。适用于希望拿到最新数据的场景。
• INTERNET_FLAG_NO_CACHE_WRITE：不把响应数据写入缓存。
• INTERNET_FLAG_SECURE：使用安全连接（TLS/SSL），访问 HTTPS 时这个标志必须带上。别以为 URL 是https://系统就知道，WinINet 在旧版本里真的会让你吃"无法连接"的哑巴亏。为了兼容性，建议访问 HTTPS 时显式加上INTERNET_FLAG_SECURE。
• INTERNET_FLAG_NO_AUTO_REDIRECT：禁止自动重定向（HTTP 301/302）。如果你不设这个标志，WinINet 默认会帮你自动跟随重定向，最多重定向几次。这个行为大多是好事，但如果你要记录中间跳转的 URL 或者要处理特定重定向逻辑，就要禁用自动重定向。
• INTERNET_FLAG_KEEP_CONNECTION：使用 keep-alive 连接。对单个下载请求意义不大，但对多次请求复用连接有明显性能提升。

最后一个参数dwContext用于异步模式的上下文回调值。同步模式下传 0 即可。

调用成功返回一个请求句柄，失败返回NULL。这里有个经验：拿到请求句柄后，不要急着猜是不是 404，先用HttpQueryInfo查询一下 HTTP 状态码，因为InternetOpenUrl即使收到 404 或 500，也可能会正常返回一个句柄，只是内容为空。你必须在业务层面判断这个状态码是否满足预期。

2.3 InternetReadFile 的循环读取逻辑

InternetReadFile的原型：

BOOL InternetReadFile( HINTERNET hFile, LPVOID lpBuffer, DWORD dwNumberOfBytesToRead, LPDWORD lpdwNumberOfBytesRead );

它的设计目的是"读一块，处理一块"，所以你需要一个固定大小的缓冲区，通常是 4KB 或 64KB。每次调用，它会把最多dwNumberOfBytesToRead字节的数据填充到lpBuffer，同时通过lpdwNumberOfBytesRead告诉你实际读到了多少字节。

返回值是TRUE只代表调用成功，不代表数据读完了。判断是否读尽，看*lpdwNumberOfBytesRead是不是 0。所以循环结构一般长这样：

char buffer[4096]; DWORD bytesRead = 0; do { BOOL ok = InternetReadFile(hRequest, buffer, sizeof(buffer), &bytesRead); if (!ok) { // 处理错误 break; } if (bytesRead > 0) { // 写文件或者处理 buffer 里的数据 } } while (bytesRead > 0);

注意这个循环里，bytesRead == 0且返回TRUE表示正常读完；InternetReadFile返回FALSE表示出错，此时要用GetLastError()拿错误码。虽然这函数逻辑很简单，但我在实际代码审查里见过很多人只读一次就直接认为拿到了全部内容，结果文件总是缺尾巴，就是一个典型的理解偏差。

2.4 InternetCloseHandle 的"传递性"陷阱

InternetCloseHandle很简单，就一个参数，把句柄扔进去就行。但它有个容易忽略的特点：关闭一个父句柄时，WinINet 会递归地关闭它的所有子句柄。比如你直接关闭InternetOpen返回的会话句柄，那么所有基于它创建的请求句柄都会被同时关闭。这听起来很省事，但也有风险。

如果你在一个多线程程序里共用同一个会话句柄，其中一个线程调用了InternetCloseHandle关闭会话，其他线程还在用子句柄读数据，就会引发访问冲突。我的建议是：遵循最稳的秩序，先关闭InternetReadFile用的请求句柄，再关闭InternetOpenUrl返回的句柄，最后关闭会话句柄。也就是说，按照创建顺序的逆序来关闭。虽然代码多两行，但思路清楚，排查问题也容易。

3. 完整示例：用四个函数实现一个 HTTP 下载器

3.1 准备阶段：工程配置与初始化

以下示例基于 C++ / Win32 API，控制台程序即可，不需要 MFC。你需要包含头文件，并链接wininet库：

#include <windows.h> #include <wininet.h> #include <stdio.h> #pragma comment(lib, "wininet.lib")

第一步是调用InternetOpenW创建会话。我通常写成一个小封装：

HINTERNET hSession = InternetOpenW( L"MyDownloader/1.0 (Windows)", INTERNET_OPEN_TYPE_PRECONFIG, NULL, NULL, 0); if (!hSession) { wprintf(L"InternetOpen failed, error = %lu\n", GetLastError()); return 1; }

这里访问类型我用的是INTERNET_OPEN_TYPE_PRECONFIG，让系统代理配置生效。如果你的程序确定只走直连，可以改成INTERNET_OPEN_TYPE_DIRECT。注意lpszAgent不要出现非 ASCII 字符，避免某些服务器解析出错。

接着设置一个可选的超时时间。WinINet 没有专门的超时参数，必须通过InternetSetOption来设置：

DWORD timeout = 10000; // 10 秒 InternetSetOption(hSession, INTERNET_OPTION_CONNECT_TIMEOUT, &timeout, sizeof(timeout)); InternetSetOption(hSession, INTERNET_OPTION_SEND_TIMEOUT, &timeout, sizeof(timeout)); InternetSetOption(hSession, INTERNET_OPTION_RECEIVE_TIMEOUT, &timeout, sizeof(timeout));

这个步骤不写也不会挂，但写上之后体验完全不同，否则就算服务器没响应，你的程序也会傻等很久。InternetSetOption不光能设超时，还能设置各种底层参数，后面问题排查部分我会再提。

3.2 打开 URL 并逐块读取数据

现在开始请求一个 URL，把一个文件下载到本地。核心流程如下：

const wchar_t* url = L"https://example.com/file.bin"; const wchar_t* outputPath = L"C:\\temp\\file.bin"; HINTERNET hRequest = InternetOpenUrlW( hSession, url, NULL, 0, INTERNET_FLAG_RELOAD | INTERNET_FLAG_SECURE | INTERNET_FLAG_NO_CACHE_WRITE, 0); if (!hRequest) { // 注意，这里不能直接关 hSession，否则其他句柄会被连带关闭 wprintf(L"InternetOpenUrl failed, error = %lu\n", GetLastError()); InternetCloseHandle(hSession); return 1; }

打开成功后，还要验证 HTTP 状态码。查询状态码用HttpQueryInfo：

DWORD statusCode = 0; DWORD statusSize = sizeof(statusCode); BOOL ok = HttpQueryInfoW( hRequest, HTTP_QUERY_STATUS_CODE | HTTP_QUERY_FLAG_NUMBER, &statusCode, &statusSize, NULL); if (ok && statusCode >= 400) { wprintf(L"HTTP error: %lu\n", statusCode); InternetCloseHandle(hRequest); InternetCloseHandle(hSession); return 1; }

为什么这里要多一步状态码检查？前面说过，InternetOpenUrl不会因为 404 就简单粗暴地返回NULL，它照样能建立 "连接"，然后返回一个内容为空或错误页面的句柄。如果直接读，你会把一段错误页 HTML 当成正常数据下载下来，要是图片文件就直接打不开了。所以，业务层校验 HTTP 状态码是必须的。

接下来就是创建文件、循环读取、写盘：

HANDLE hFile = CreateFileW( outputPath, GENERIC_WRITE, 0, NULL, CREATE_ALWAYS, FILE_ATTRIBUTE_NORMAL, NULL); if (hFile == INVALID_HANDLE_VALUE) { wprintf(L"CreateFile failed, error = %lu\n", GetLastError()); InternetCloseHandle(hRequest); InternetCloseHandle(hSession); return 1; } char buffer[8192]; DWORD bytesRead = 0; DWORD totalBytes = 0; BOOL readOk = TRUE; while (readOk) { readOk = InternetReadFile(hRequest, buffer, sizeof(buffer), &bytesRead); if (!readOk) { wprintf(L"InternetReadFile failed, error = %lu\n", GetLastError()); break; } if (bytesRead == 0) { break; } DWORD bytesWritten = 0; BOOL writeOk = WriteFile(hFile, buffer, bytesRead, &bytesWritten, NULL); if (!writeOk || bytesWritten != bytesRead) { wprintf(L"WriteFile failed, error = %lu\n", GetLastError()); readOk = FALSE; break; } totalBytes += bytesRead; }

注意这里的bytesRead是实际读取的字节数，绝对不能直接用sizeof(buffer)作为写入长度，否则末尾会发生越界读。

等循环结束，统一收尾：

CloseHandle(hFile); InternetCloseHandle(hRequest); InternetCloseHandle(hSession); if (readOk) { wprintf(L"Download complete, total bytes = %lu\n", totalBytes); return 0; } return 1;

这个例子足够你跑通一个完整的下载流程。实际项目中你可以在while循环里加上进度回调、断点续传、计算哈希等逻辑，但核心骨架就是上面的样子。

3.3 一个隐蔽的细节：缓冲区大小怎么选

有人觉得缓冲区越大下载越快，于是直接开一个 1MB 的数组。实测下来确实能减少InternetReadFile的调用次数，但并非越大越好，因为 WinINet 内部还有自己的分段缓冲机制，你再大它也只会按固定块给你。太大的缓冲区还会导致每个线程的栈内存占用飙升，尤其是在多线程下载任务里。我常用的经验值是 8KB ~ 64KB。8KB 在绝大多数场景下已经足够，代码也简单。如果你追求极致性能，16KB 或 32KB 也行，但超过 64KB 之后的收益几乎可以忽略。

还有个影响速度的因素是InternetReadFile的读取粒度。它可能会根据网络包大小一次只给你几 KB，即使你的缓冲区是 64KB。所以你没法控制每次实际读多少，只能保证循环没问题。想要更细腻的控制，一个是调InternetSetOption里的INTERNET_OPTION_RECEIVE_BUFFER_SIZE，另一个就是直接上更底层的 WinHTTP 或者异步 socket。对于普通下载需求，默认配置即可。

4. 实战中躲不过去的问题和排查指南

4.1 HTTPS 连不上的常见原因

WinINet 的 HTTPS 支持依赖系统的证书库和 Schannel。最常见的几个失败表现，以及我的排查顺序：

第一，忘了加INTERNET_FLAG_SECURE。这个在前面反复强调过，先自查。

第二，证书无效或过期。如果目标站点用的是自签名证书，或者安装链不完整，InternetOpenUrl会直接失败，错误码通常是ERROR_INTERNET_SECURITY_CERT_PROBLEM。在企业内网常遇到这种坑，一种临时方案是设置INTERNET_OPTION_SECURITY_FLAGS，忽略特定的证书错误。但注意，这只是开发调试用，生产环境这么干等同于裸奔，慎之。

第三，TLS 版本不匹配。WinINet 在旧版 Windows 上默认可能只使用 TLS 1.0，而现在很多服务器只支持 TLS 1.2 或 1.3。此时请求很可能直接失败，错误码时好时坏。解决办法是先更新操作系统补丁，或者通过注册表启用更新的 TLS 版本。如果你的软件只跑在较新的 Windows 10/11 上，这个问题一般不会遇到。

我还遇到过一种诡异情况：同一个 HTTPS URL，浏览器能开，程序连不上。查到最后是系统里的证书信任列表出了问题。你可以用certmgr.msc查看根证书，确认目标站点的证书链是否完整。如果只是个别用户环境出问题，让用户重置一下证书默认值即可，这属于环境问题而不是代码问题。

4.2 下载卡住不动或者速度极慢

先排除服务器自身限速。如果不是服务器问题，多半出在超时设置和缓冲策略上。

我最开始写下载器时发现，某些大文件下载到一半会突然停住几十秒，然后才继续。后来用Process Explorer看线程状态，发现线程卡在了InternetReadFile里。原因就是接收超时时间太长，RST 包到达后系统在等缓冲区里的余数。于是我把INTERNET_OPTION_RECEIVE_TIMEOUT设置成一个适中的值，比如 15 秒，超时后主动重试，整体稳定性提升了不少。

另一个被很多人忽略的点是代理。走代理下载时，如果代理服务器不稳定，InternetReadFile也可能长时间阻塞。排查方法是先用INTERNET_OPEN_TYPE_DIRECT直连试试，如果直连飞快、走代理卡顿，那就是代理的问题，别折腾代码了。

4.3 句柄泄漏：从几十到几百

WinINet 的句柄是内核句柄，如果只开不关，用GetProcessHandleCount或者任务管理器能看到句柄数飙升。常见的泄漏场景是：多个 URL 循环下载，但只在循环外关闭了会话句柄，或者开一个 URL 后忘记关闭请求句柄。

我的习惯是写一个 RAII 风格的句柄封装类，析构时自动调用InternetCloseHandle，这样即使中途抛异常，句柄也能释放。如果你用的是 C，最简单的方式就是"函数开头申请，函数所有出口统一关闭"。

这里还有一点：虽然你调用了InternetCloseHandle关闭句柄，如果该句柄还有未完成的重定向或异步操作，可能不会立即释放完。所以在调试时看到句柄数没有立刻下降，不代表泄漏，稍等片刻或排除其他线程占用后再确认。多线程环境千万别共享同一个会话句柄后由多个线程各自关闭，这几乎必然导致崩溃或者重复关闭。

4.4 如何获取更详细的错误信息

光靠GetLastError()返回的数值往往不够，比如ERROR_INTERNET_HTTP_TO_HTTPS_ON_REDIRECT这种错误码看着就一头雾水。WinINet 还有一个函数叫InternetGetLastResponseInfo，可以拿到服务器返回的原始响应头。当你的请求被服务器拒绝时，响应头里会有HTTP/1.1 403 Forbidden等关键信息，能帮你判断是认证问题还是访问权限问题。

示例用法：

DWORD errorCode = 0; char buffer[1024]; DWORD bufferLen = sizeof(buffer); InternetGetLastResponseInfo(&errorCode, buffer, &bufferLen); // buffer 里就是完整的服务器响应头

在实际项目里，我会把这段响应信息打进日志文件，比单纯的错误码有用得多。

另外，建议在调试时打开 WinINet 的详细日志。它在旧版系统里可以通过注册表InternetSettings下的EnableLog开启，但不同系统版本路径略有差异。更通用一点的做法是，用代理抓包工具（比如 Fiddler）观察请求链路，看看InternetOpenUrl实际发出了什么请求、服务器回了什么。因为 WinINet 会自动带很多默认头，你发出去的请求和你想的可能完全不一样。

4.5 重定向、Cookie 和额外的 Header 处理

虽然InternetOpenUrl会自动处理重定向，但它不保证保留所有请求头，而且如果重定向到新的 URL，它内部会重新发起请求。如果你在原始请求里塞了一些自定义 Header，比如Authorization，重定向后这些 Header 是否还会带上？WinINet 的行为是，默认情况下内部重定向不会再带自定义 Header。这就很尴尬，很多开发者会遇到：请求一个地址，服务器 302 跳转，然后认证信息丢了，结果下游返回 401。

解决办法有两个：一是关闭自动重定向，自己处理301/302响应，在代码里读取Location头，再手动调用InternetOpenUrl访问新的 URL，并把自定义 Header 原样带上；另一个是使用更完整的HttpOpenRequest+HttpSendRequest系列函数，它们提供了对重定向和请求头的精细控制。这也是我在后续项目里逐渐迁移到HttpOpenRequest的原因，但作为简单的单点下载，InternetOpenUrl依然够用。

Cookie 的问题类似。InternetOpenUrl会自动管理会话 Cookie，但如果你需要发送持久化 Cookie，最好在 Header 参数里手动加Cookie: xxx。我做过一个需要登录态的下载器，就是用这种方式硬塞 Cookie 字段，反而避开了 Cookie 管理的一堆琐事。

5. 把这段经验沉淀成你自己的工具函数

既然这四个函数用法固定，我强烈建议你封装成一个简洁的辅助函数，以后任何项目都可以直接复用。下面是一个简化版的设计思路，不是完整代码，但骨架足够清晰：

// 下载一个 URL 到本地文件，成功返回 true bool DownloadUrlToFile(const std::wstring& url, const std::wstring& outputPath) { bool result = false; HINTERNET hSession = InternetOpenW(L"MyDownloader/1.0", INTERNET_OPEN_TYPE_PRECONFIG, NULL, NULL, 0); HINTERNET hRequest = NULL; HANDLE hFile = INVALID_HANDLE_VALUE; if (!hSession) goto cleanup; hRequest = InternetOpenUrlW(hSession, url.c_str(), NULL, 0, INTERNET_FLAG_RELOAD | INTERNET_FLAG_SECURE | INTERNET_FLAG_NO_CACHE_WRITE, 0); if (!hRequest) goto cleanup; // 检查 HTTP 状态码 DWORD status = 0; DWORD size = sizeof(status); HttpQueryInfoW(hRequest, HTTP_QUERY_STATUS_CODE | HTTP_QUERY_FLAG_NUMBER, &status, &size, NULL); if (status >= 400) goto cleanup; hFile = CreateFileW(outputPath.c_str(), GENERIC_WRITE, 0, NULL, CREATE_ALWAYS, FILE_ATTRIBUTE_NORMAL, NULL); if (hFile == INVALID_HANDLE_VALUE) goto cleanup; char buffer[16384]; DWORD read = 0; while (InternetReadFile(hRequest, buffer, sizeof(buffer), &read) && read > 0) { DWORD written = 0; if (!WriteFile(hFile, buffer, read, &written, NULL) || written != read) { goto cleanup; } read = 0; } result = true; cleanup: if (hFile != INVALID_HANDLE_VALUE) CloseHandle(hFile); if (hRequest) InternetCloseHandle(hRequest); if (hSession) InternetCloseHandle(hSession); return result; }

你一定会注意到goto cleanup这种老式写法。放在这里非常合身，因为清理路径只有一条，不用在每个错误分支重复写关闭代码。如果你觉得goto不优雅，也可以用作用域化对象封装句柄，核心思路都一样：保证所有出口都清理干净。

封装完成后，你的下载逻辑就变成一行调用。但不要就此止步，建议在这个基础上扩展三个能力：下载进度回调、HTTP 状态码区分、大文件的断点续传。进度回调本质上就是把InternetReadFile循环里读取的字节数累加，再除以总长度（通过Content-Length头获取）。断点续传则需要你在 Header 参数里增加Range: bytes=xxx-，然后判断服务器返回的是 206 而不是 200，这部分用InternetOpenUrl也能做，但逻辑稍多，进阶后可以考虑转向HttpOpenRequest。

根据我个人经验，这四个函数组合出的下载器，哪怕写到最复杂，也只适合中小文件的整体拉取。如果文件特别大，或者对并发有要求，我应该会直接选择专门 HTTP 客户端库。但在那些不允许引入第三方依赖、必须一个 exe 打天下的项目里，这套 WinINet 的"四段式"流程依然是我最信的方案。每次重新用起这几个函数，都像是在跟老交情打招呼，规则简单，但稳定可靠。希望这篇文章能帮你把它们的脾气摸透，少走我当年走过的弯路。