FFFire小火1. 一次尴尬的断网事故：为什么MFC网络程序总在关键时刻"装死"
先讲一个我自己踩过的坑。几年前我在维护一个基于MFC的工业上位机程序，主要工作是和现场的PLC通过HTTP接口交换数据。某个周五下午，现场操作工一个不小心把网线踢松了，上位机界面立刻卡死，鼠标转圈，标题栏出现"未响应"，最后只能强制结束进程。重启之后数据缓存丢了，一个班次的报表全没了，被生产主管念叨了一下午。事后我翻代码，发现问题是典型的"裸奔式"网络调用——代码里到处是AfxParseURL / CHttpConnection::OpenRequest / CHttpFile::ReadString 这种API，但几乎没有任何异常防护。一旦底层WinINet出错，MFC默认的异常处理机制就会把异常抛到消息循环之外，程序直接崩溃或者挂起。
这个经历让我认识到一个问题：接触过MFC的人很多，写过MFC网络代码的人也不少，但真正把 CInternetException 用明白的人，真的不多。 这不是说大家不努力，而是这个类本身的信息比较零散——MSDN资料很全但偏查询式，中文社区里的讨论要么太浅（贴一段try-catch就算完事），要么太旧（还是VC6时代的写法）。所以我想借这篇博客，把自己从各种项目里攒下的经验和踩过的坑系统整理一遍，按"错误从哪里来"、"代码里怎么接住"、"接住之后怎么转成用户能看懂的信息"这条主线，把CInternetException讲透。
这篇文章适合谁看？如果你正在用MFC做上位机通信、局域网工具、教学管理系统这类需要联网的小体量应用，而且被"一断网就崩"折磨过，那这篇内容就是冲你来的。纯做Web后端的、做Java/C#桌面开发的朋友，技术细节不一定通用，但"网络层异常必须显式处理"这个思路同样适用。我会尽量把每个知识点都讲到"可操作"的粒度，不整虚的。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. CInternetException到底是什么：和WININET错误码的对应关系
CInternetException 是 MFC 里专门为 WinINet API 设计的一套网络异常包装。很多新人的误区是把"异常"等同于"错误码"，其实两者有关联但不完全是同一个东西。错误码是系统给出的一个数字，异常是代码流程层面的一个跳转。MFC 的设计思路是：在 WinINet 封装层内部（CInternetSession、CHttpConnection、CHttpFile 这些类的方法里），一旦底层 API 调用失败，就检查 GetLastError 并构建一个 CException 派生对象抛出来。你如果不接，程序就按默认方式处理，大概率是弹个错误对话框然后中止操作；如果你接住了，就可以描述具体的失败原因、做重试或者写日志。
2.1 继承体系和构造函数：两个DWORD里藏着关键信息
CInternetException 的继承链很简单：CException -> CInternetException。它没有自己额外的复杂成员结构，核心数据就是两个 DWORD：m_dwError 和 m_dwContext。这两个字段在构造时就被填好，之后没有专门的setter，所以捕获异常之后一定要在 catch 块内第一时间读取，别想着存个指针之后再用。
构造函数的形状是：
cpp复制CInternetException(
DWORD dwError,
DWORD dwContext = 0
);
- dwError：表示具体错误，取值分两大来源。一部分是 WinINet 的错误码（以
ERROR_INTERNET_开头，数值范围在 12000 到 12156 之间），另一部分是 MFC 自己定义的映射错误（如INTERNET_ERROR_GET_CONNECTED_STATE这类）。 - dwContext：表示错误发生的操作上下文。如果你在构造 CInternetSession 时传入了上下文 ID（通常是 AppID 或窗口句柄），这个值就是它；如果没传，默认0。它在多线程或多会话并存时用来区分是哪个操作出了问题，用处不小，但很多书上一句话带过，导致很少有人真正用起来。
我在实际项目里一般是这么设计：初始化 CInternetSession 时传入一个窗口句柄或预定义的场景ID，这样 catch 到异常之后第一件事先看 m_dwContext，就能立刻知道是"设备注册请求"挂了还是"心跳上报请求"挂了，不用再根据调用栈猜。
2.2 MFC错误码vs WinINet错误码：两条来源怎么分辨
你可能会问：既然 dwError 有两大类来源，我怎么知道当前拿到的到底是哪一类？有个土办法，先看数值范围。WinINet 错误码在 12000~12156 之间，MFC 自定义错误码则不在这个区间。当然你也可以#include <afxinet.h>，里面其实已经帮我们声明了一套常量，比如：
| 类别 | 常见示例 | 大致含义 |
|---|---|---|
| WinINet原生错误 | ERROR_INTERNET_TIMEOUT（12002） |
请求超时 |
| WinINet原生错误 | ERROR_INTERNET_NAME_NOT_RESOLVED（12007） |
DNS无法解析主机名 |
| WinINet原生错误 | ERROR_INTERNET_CANNOT_CONNECT（12029） |
无法连接到服务器 |
| WinINet原生错误 | ERROR_INTERNET_CONNECTION_ABORTED（12030） |
连接被中止 |
| MFC映射错误 | INTERNET_ERROR_GET_CONNECTED_STATE |
获取连接状态失败 |
| MFC映射错误 | INTERNET_ERROR_OPERATION_CANCELLED |
操作被主动取消 |
这里有一个容易踩坑的地方：MFC的封装在个别场景下并不会如实透传 WinINet 错误码，而是包装成自己的错误码。 比如你调用 CInternetSession::OpenURL 成功但后续读取超时，有的版本得到的 dwError 是一个 MFC 层的映射值，而 WinINet 原始错误被藏在更深的地方。遇到这种情况，单纯比较 e.m_dwError == ERROR_INTERNET_TIMEOUT 就失效了。正确的做法是：先用 e.GetErrorMessage 拿描述字符串辅助定位，再结合代码路径判断是哪一层的错误。这个"对不上号"的现象，在旧版 MFC（VC2010之前）里更明显，新版本好一些，但仍建议养成"看数值+看消息文本+看调用栈"三重确认的习惯。
3. 捕获与清理：CInternetException的正确接法
代码里最典型且错误的写法是这样的：
cpp复制try
{
CHttpFile* pFile = pConnection->OpenR