简介这份教程面向在 Windows 平台使用 VS2008 开发 ZeroMQ 应用的初学者围绕订阅与发布模式给出可运行的简单项目代码和配套说明帮助读者快速理解 ZeroMQ 的编译、工程配置与基本通信流程。压缩包共31个文件约4.25MB包含10个头文件、4个cpp源文件、3个dll与3个lib库文件以及vcproj工程文件、sln解决方案、ReadMe和doc说明文档覆盖从库文件引入到服务端、客户端示例搭建所需的主要材料。已有490人学习下载适合作为入门练习与课堂示例参考。读者可从中获得ZeroMQ库的VS2008工程配置参考、订阅发布服务端与客户端示例源码、头文件与动态/静态库文件以及工程说明和操作文档便于对照搭建环境、运行示例并排查常见配置问题也可在此基础上扩展自己的消息通信小项目。1. 一套还在跑的老上位机系统编译链锁死在 VS2008升级框架的路走不通最后是用 ZeroMQ 的订阅发布模型把采集端和显示端拆开的采集进程只管往端口上喊显示进程爱连不连谁崩了都不拖累对方。这份实例讲的就是这件事在 Windows VS2008 下怎么落地ZeroMQ 的 PUB/SUB 两端怎么建、VS2008 工程怎么配 libzmq、订阅前缀过滤怎么用、消息为什么一上来就丢。适合手上有 VS2008 老工程、又需要进程间或跨机解耦通信的开发者如果只是想找个新项目练手直接上新版 VS 加包管理器会更省事。这套东西的价值不在技术新而在于守着旧工具链把事办成——很多产线上的机器不让换编译器这才是真需求。2. 环境与工程骨架把 libzmq 塞进 VS2008 解决方案VS2008 对应的是 VC9 工具集没有 NuGet 包管理器生态也没有现代 CMake 的默认支持所以 ZeroMQ 的引入方式得自己选。这一步选错后面全是链接错误。2.1 三种拿到 libzmq 的方式与选型第一种是官方预编译包解压后目录结构大致是include/zmq.h、include/zmq_utils.h、lib/libzmq-v90-mt-版本号.lib、bin/libzmq.dll。文件名里的v90就是 VC9mt表示它是用多线程静态运行时/MT编出来的如果带gd后缀则是 Debug 版。这种方式最省事缺点是运行时库被钉死了你的工程如果用的是 /MD链接期就会撞车。我一般先拿它做连通性验证跑通再考虑换。第二种是用 CMake 从源码生成 VS2008 工程。这里有个坑较新版本的 CMake 已经不再生成 VS2008 工程了得挑一个还认Visual Studio 9 2008这个生成器名字的老版本。生成之后可以自己改ZMQ_STATIC选项、改运行时库、去掉不需要的加密和曲棍球曲线加密支持。适合需要静态链接进 exe、不想带 dll 的场合。第三种最粗暴把src目录下所有.cpp直接拖进解决方案新建一个静态库项目把include加进来编出一个自己的zmq_static.lib。好处是源码在手调试能进去坏处是编译选项得自己对齐漏一个宏就编不过。我在需要改协议细节或者排查底层行为时会选这条。选型上给个直白结论只做业务接入用第一种要发单文件 exe用第二种要读源码或改源码用第三种。2.2 VS2008 工程属性逐项配置假设你用第一种方式把 ZeroMQ 解压到解决方案目录下的third_party\zeromq。右键项目 → 属性按下面的表逐项填注意配置下拉框要分别对 Debug 和 Release 各配一遍VS2008 不会自动同步。配置位置值作用C/C → 常规 → 附加包含目录$(SolutionDir)third_party\zeromq\include让#include zmq.h能找到头文件链接器 → 常规 → 附加库目录$(SolutionDir)third_party\zeromq\lib让链接器找到 .lib链接器 → 输入 → 附加依赖项libzmq-v90-mt-版本号.lib声明要链接的库C/C → 代码生成 → 运行时库多线程(/MT) 或 多线程调试(/MTd)必须与 lib 的编译方式一致C/C → 预处理器 → 预处理器定义ZMQ_STATIC仅静态库时需要关掉__declspec(dllimport)运行时库这一栏是最容易翻车的地方。预编译包名字里的mt就是 /MT 的意思你的工程如果留着 VS2008 默认的 /MD链接时会报一堆LNK2005 已经在 xxx.obj 中定义看着像库重复本质是 CRT 冲突。要么把工程改成 /MT要么去找 /MD 版本的库二选一别想着用/NODEFAULTLIB硬压压下去运行期释放内存照样出事。还有一点Debug 配置要用带gd后缀的库Release 用不带gd的。混用不会立刻崩但调试信息对不上断点进去看到的是汇编排查起来很痛苦。2.3 最小连通性验证工程在写任何业务代码之前先建一个空的控制台工程编译下面这段能打印出版本号就说明头文件和库都通了。/* verify_zmq.c —— 只验证编译链接链路不涉及任何通信逻辑 */ #include stdio.h #include zmq.h int main(void) { int major 0, minor 0, patch 0; /* zmq_version 是纯函数不需要创建上下文适合做第一步验证 */ zmq_version(major, minor, patch); printf(libzmq version: %d.%d.%d\n, major, minor, patch); /* 顺便验证上下文能不能创建失败时把错误码打出来 */ void *ctx zmq_ctx_new(); if (ctx NULL) { printf(ctx create failed, errno%d, msg%s\n, zmq_errno(), zmq_strerror(zmq_errno())); return 1; } zmq_ctx_destroy(ctx); printf(ctx create/destroy ok\n); return 0; }zmq_version的三个参数都是出参传地址进去函数内部填值这是 C 接口的常规写法。zmq_ctx_new返回的是void *ZeroMQ 刻意不暴露上下文结构体所有句柄都用void *传递这样 ABI 稳定换版本不用重编调用方。zmq_errno()拿的是当前线程的错误码zmq_strerror把它转成可读字符串这两个配合着用比直接猜为什么返回 NULL高效得多。如果这段编不过问题一定在 2.2 的表格里先回去核对附加包含目录和附加依赖项别急着往下写。如果编过了但运行时报找不到 libzmq.dll把bin目录下的 dll 拷到 exe 同目录或者在项目属性 → 调试 → 工作目录里指到 dll 所在路径。3. 发布端拆解从 ctx 创建到多帧消息的完整链路发布端的职责很单一建一个 PUB 套接字bind 到一个地址然后不停地发。但不停地发这四个字里藏着几个参数配错了要么内存涨、要么退出卡死。3.1 上下文、套接字与绑定地址ZeroMQ 的上下文context是线程间共享的 I/O 线程池容器一个进程里通常只建一个所有套接字都从它派生。套接字本身不是线程安全的但不同线程可以用不同套接字共用同一个上下文——这条规则决定了后面二次开发时的线程模型。下面这段是发布端的初始化部分我加了 3.x 和 4.x 的兼容分支因为老工程里经常遇到手上 dll 是 3.2 但头文件是 4.x 的情况。#include stdio.h #include string.h #include zmq.h #ifdef _WIN32 #include windows.h #define SLEEP_MS(ms) Sleep(ms) #else #include unistd.h #define SLEEP_MS(ms) usleep((ms) * 1000) #endif /* 3.x 用 zmq_init/zmq_term4.x 改成 zmq_ctx_new/zmq_ctx_destroy 这里按头文件里的版本宏做一次分流避免老 dll 上跑新 API */ static void *ctx_create(void) { #if defined(ZMQ_VERSION_MAJOR) (ZMQ_VERSION_MAJOR 4) return zmq_ctx_new(); #else return zmq_init(1); /* 参数是 I/O 线程数1 对大多数场景够用 */ #endif } static void ctx_destroy(void *ctx) { #if defined(ZMQ_VERSION_MAJOR) (ZMQ_VERSION_MAJOR 4) zmq_ctx_destroy(ctx); #else zmq_term(ctx); #endif }zmq_init(1)里的 1 是 I/O 线程数。这个值不是越大越好它只影响网络收发业务逻辑还是在调用线程里跑。机器上 PUB 端只有一个连接、QPS 不高的时候1 个线程绰绰有余如果订阅端多、消息量大可以调到 2 到 4再往上收益递减。绑定地址用tcp://*:5556星号表示监听所有网卡。如果只写tcp://127.0.0.1:5556本机订阅端能连上跨机就连不上而且不会有任何报错提示——这是排查跨机通信问题时的第一个检查点。3.2 主循环定时发送与多帧消息PUB 端的发送循环有个反直觉的地方zmq_send在 PUB 套接字上永远不阻塞没有订阅者的时候消息直接被丢掉返回值照样是成功。所以你不能靠返回值判断有没有人收到这是 PUB/SUB 模型的设计前提不是 bug。int main(void) { void *ctx ctx_create(); if (ctx NULL) { printf(ctx create failed: %s\n, zmq_strerror(zmq_errno())); return 1; } void *pub zmq_socket(ctx, ZMQ_PUB); if (pub NULL) { printf(socket failed: %s\n, zmq_strerror(zmq_errno())); ctx_destroy(ctx); return 1; } /* 发送高水位每个订阅者最多缓存 1000 条待发消息超了就丢最老的 */ int sndhwm 1000; zmq_setsockopt(pub, ZMQ_SNDHWM, sndhwm, sizeof(sndhwm)); /* 退出时不等未发完的消息0 表示立即丢弃默认是 -1 会一直等 */ int linger 0; zmq_setsockopt(pub, ZMQ_LINGER, linger, sizeof(linger)); if (zmq_bind(pub, tcp://*:5556) ! 0) { printf(bind failed: %s\n, zmq_strerror(zmq_errno())); zmq_close(pub); ctx_destroy(ctx); return 1; } int seq 0; for (;;) { char topic[32]; char payload[128]; /* 第一帧放主题前缀订阅端靠它做过滤没有这一帧过滤就失效 */ _snprintf(topic, sizeof(topic), market.tick); /* 第二帧放真实数据实际项目里这里换成序列化后的结构体 */ _snprintf(payload, sizeof(payload), {\seq\:%d,\price\:%d.%02d}, seq, 100 seq % 10, seq % 100); /* ZMQ_SNDMORE 表示后面还有一帧接收端要用循环读到 more 为 0 */ int rc zmq_send(pub, topic, strlen(topic), ZMQ_SNDMORE); if (rc 0) { printf(send topic failed\n); break; } rc zmq_send(pub, payload, strlen(payload), 0); if (rc 0) { printf(send payload failed\n); break; } seq; SLEEP_MS(500); } zmq_close(pub); ctx_destroy(ctx); return 0; }_snprintf是 VS2008 里的写法标准 C99 的snprintf在 VC9 的 CRT 里没有直接用会报未声明。这也是为什么这段代码放到新编译器上要注意——新版 MSVC 反而推荐snprintf_snprintf被标了弃用。同一份代码跨工具链时这类 CRT 差异比 ZeroMQ 本身的问题还多。多帧消息的语义要理解清楚ZMQ_SNDMORE标记这条消息还有后续帧接收端一次recv只拿到一帧必须循环读到不带 more 标志的那一帧才算收完一整条。如果发送端发了多帧但接收端只读一帧剩下的帧会留在缓冲区里下一条消息读到的就是上一条的残留——这种错位在调试时表现为数据偶尔串了很难定位。3.3 优雅退出与资源释放顺序释放顺序必须是zmq_close(socket)→zmq_ctx_destroy(ctx)反过来会阻塞。zmq_ctx_destroy会等待所有套接字关闭如果还有套接字开着它会一直等下去表现就是程序卡在退出这一步。ZMQ_LINGER设成 0 是关键。默认值 -1 表示无限期等待未发送的消息发完如果订阅端已经断了这些消息永远发不出去zmq_close就永远不返回。生产环境里我一般统一设 0宁可丢几条也不要进程退不掉——进程退不掉会被运维当成挂死比丢消息严重得多。发送循环里判断失败就break然后走统一的清理路径不要在每个错误分支里重复写 close/destroy那样很容易漏掉一个。C 语言没有 RAII只能靠纪律。4. 订阅端拆解前缀过滤、接收循环与超时控制订阅端比发布端复杂的地方在于它要决定我要什么还要处理暂时没有的情况。前者是过滤后者是超时。4.1 订阅过滤的生效时机ZMQ_SUBSCRIBE设置的是一个字节前缀不是正则也不是通配符。传空字符串表示订阅全部传market.表示只收以这七个字节开头的消息。匹配发生在发布端的第一帧上所以发布端必须把主题放在第一帧顺序不能反。设置订阅和建立连接的先后顺序有讲究。4.x 之后的版本允许先 connect 再 setsockopt但老版本和某些边界情况下connect 之后立刻来的消息会因为订阅还没生效而被丢弃。稳妥写法是一律先setsockopt再connectvoid *ctx ctx_create(); void *sub zmq_socket(ctx, ZMQ_SUB); /* 先声明要什么再建立连接避免连接建立初期的消息被过滤掉 */ const char *filter market.; zmq_setsockopt(sub, ZMQ_SUBSCRIBE, filter, (int)strlen(filter)); /* 接收超时 1000ms让 recv 有返回的机会否则会一直阻塞 */ int rcvtimeo 1000; zmq_setsockopt(sub, ZMQ_RCVTIMEO, rcvtimeo, sizeof(rcvtimeo)); /* linger 同样设 0防止退出卡死 */ int linger 0; zmq_setsockopt(sub, ZMQ_LINGER, linger, sizeof(linger)); if (zmq_connect(sub, tcp://127.0.0.1:5556) ! 0) { printf(connect failed: %s\n, zmq_strerror(zmq_errno())); }ZMQ_SUBSCRIBE的第四个参数是长度用strlen算出来就行别写死数字。有人图省事写sizeof(filter)那会把字符串结尾的\0也算进前缀里结果就是一条都收不到而且不报错。多个前缀可以多次调用zmq_setsockopt叠加不是覆盖。比如既想收market.又想收alert.就设两次。这个特性在做多主题分发时很有用不用在业务层再写一遍字符串判断。4.2 接收循环与消息生命周期接收端必须用zmq_msg_t而不是裸缓冲区因为消息长度不固定ZeroMQ 内部做了内存管理。每次循环都要zmq_msg_init和zmq_msg_close配对漏掉 close 就是内存泄漏——而且这个泄漏很隐蔽短时间跑看不出来跑一天内存曲线就上去了。int running 1; while (running) { zmq_msg_t part; /* 第一帧主题 */ zmq_msg_init(part); int n zmq_msg_recv(part, sub, 0); if (n 0) { zmq_msg_close(part); if (zmq_errno() EAGAIN) { continue; /* 超时没有消息继续下一轮 */ } printf(recv failed: %s\n, zmq_strerror(zmq_errno())); break; } char topic[64] {0}; int tlen n (int)sizeof(topic) - 1 ? n : (int)sizeof(topic) - 1; memcpy(topic, zmq_msg_data(part), tlen); int more zmq_msg_more(part); /* 必须在 close 之前取 */ zmq_msg_close(part); if (!more) { /* 发布端只发了一帧说明格式不对跳过 */ continue; } /* 第二帧负载 */ zmq_msg_init(part); n zmq_msg_recv(part, sub, 0); if (n 0) { char payload[256] {0}; int plen n (int)sizeof(payload) - 1 ? n : (int)sizeof(payload) - 1; memcpy(payload, zmq_msg_data(part), plen); printf([%s] %s\n, topic, payload); } zmq_msg_close(part); }zmq_msg_more必须在zmq_msg_close之前调用close 之后这块内存就还给池子了再取标志位读到的是脏数据。这个顺序错误不会崩溃只会让帧判断随机出错属于最难查的一类问题。zmq_msg_recv返回的是字节数不是状态码判断成功要用 0。返回 -1 时看zmq_errno()EAGAIN是超时设了ZMQ_RCVTIMEO才会有ETERM是上下文被销毁EINTR是信号中断。把这几个分支分开处理比笼统地 break 要好排查。4.3 用 zmq_poll 做可控超时ZMQ_RCVTIMEO只能控制单次 recv 的阻塞时长如果业务上要既等消息又定时做别的事用zmq_poll更合适。它支持同时等多个套接字还能设一个毫秒级的超时返回 0 表示超时、正数表示有事件、负数表示出错。zmq_pollitem_t items[1]; items[0].socket sub; items[0].fd 0; /* 用 socket 时 fd 必须置 0 */ items[0].events ZMQ_POLLIN; items[0].revents 0; while (running) { int rc zmq_poll(items, 1, 200); /* 200ms 一轮 */ if (rc 0) { printf(poll failed: %s\n, zmq_strerror(zmq_errno())); break; } if (rc 0) { /* 超时这里可以插入心跳检查、状态上报之类的定时任务 */ continue; } if (items[0].revents ZMQ_POLLIN) { /* 有数据走上面的接收逻辑 */ } }zmq_pollitem_t数组的长度和超时单位要记清楚超时是毫秒不是微秒。fd字段在用套接字的时候必须清零忘记清零在某些版本上会导致 poll 立即返回表现为 CPU 占用 100% 的死循环。这套结构还有个好处退出标志可以在 poll 超时的分支里检查不用依赖信号或者强制 kill。running变量在 Windows 下如果被别的线程改要加volatile否则 Release 编译可能被优化进寄存器循环读不到新值。5. 踩坑排查编译链接、端口占用与订阅丢消息的高频故障这一章是我自己在 VS2008 ZeroMQ 组合上真实撞过的几类问题按现象、原因、解决三段写。每条都能直接对号入座。5.1 链接期报 LNK2019 无法解析的外部符号现象代码里明明#include zmq.h了编译通过链接报LNK2019: 无法解析的外部符号 _zmq_ctx_new或者一堆zmq_send、zmq_socket都找不到。原因三种可能。一是附加依赖项里的 lib 名字写错了比如把libzmq-v90-mt-版本号.lib写成了libzmq.lib而目录里根本没这个文件二是平台对不上工程是 Win32 但引用了 x64 的 lib或者反过来三是头文件和 lib 版本差太多头文件是 4.x 的声明了zmq_ctx_new链接的却是 3.x 的库那个库里只有zmq_init。解决先把附加依赖项和实际文件名逐字对一遍注意别把尖括号或引号带进去。然后确认解决方案平台和 lib 的位数一致VS2008 的配置管理器里 Win32 和 x64 是两套独立配置改了一边另一边不会跟着变。最后用dumpbin /exports libzmq-xxx.lib | findstr zmq_ctx_new确认这个符号到底在不在库里在就查路径不在就换库。5.2 程序启动就崩溃提示找不到 libzmq.dll现象双击 exe 或者 F5 调试弹窗无法启动此程序因为计算机中丢失 libzmq.dll或者调试时直接退出码 -1073741515。原因链接用的是导入库.lib运行时还需要对应的 dll。dll 不在 exe 同目录、不在系统 PATH、也不在调试工作目录里加载器就找不到。VS2008 的默认调试工作目录是项目目录不是输出目录这一点跟后来的 VS 版本不一样很多人栽在这。解决最稳的办法是把 dll 拷到 exe 生成目录Debug/Release 各一份或者在项目属性 → 调试 → 工作目录里填$(OutDir)。不要往 System32 里塞换台机器又得重来。如果要做单文件分发就回到第 2 章选静态链接方案把ZMQ_STATIC定义上链接静态库彻底摆脱 dll。5.3 订阅端启动后收不到前几条消息现象先起订阅端再起发布端订阅端能收到消息但如果先起发布端、过几秒再起订阅端订阅端从第一条开始就能收到。看着像先启动的反而正常很反直觉。原因这就是常说的慢连接器问题slow joiner。PUB 端 bind 之后SUB 端 connect 需要时间完成 TCP 握手和订阅注册这段时间里发布端发的消息会被直接丢弃——PUB 端不知道有谁在订阅也不知道订阅者是否就绪。TCP 连接建立不等于订阅生效中间还有一个订阅消息回传的过程。解决三条路。一是接受它PUB/SUB 本来就是尽力而为语义丢几条不影响的场景比如行情推送的增量快照不用管。二是加延时订阅端 connect 之后Sleep(200)再做业务粗暴但有效。三是做应用层握手订阅端连上后通过一个 REQ/REP 通道给发布端发我准备好了发布端收到之后再开始发业务消息——多一个套接字但能保证不丢。我在要求一条都不能少的项目里用的是第三种代价是发布端要多维护一个 REP 套接字和一份就绪列表。5.4 退出时进程卡死任务管理器结束才能关现象点关闭按钮或者按 CtrlC窗口没了但进程还在任务管理器里显示无响应必须结束进程。原因zmq_close在ZMQ_LINGER默认为 -1 的时候会等待所有待发消息发送完毕。订阅端已经断开的情况下这些消息永远发不出去close 就一直阻塞。另一个可能是zmq_ctx_destroy在还有套接字没关闭时被调用它同样会等。解决在创建套接字之后立刻设ZMQ_LINGER 0不要等到退出时才设。然后检查所有退出路径确保zmq_close在zmq_ctx_destroy之前执行且每个套接字只 close 一次。如果有多个线程各自持有套接字要等所有线程退出后再销毁上下文顺序错了照样卡。5.5 跨机连不上本机一切正常现象同一台机器上发布端和订阅端跑得好好的换到两台机器就完全收不到消息也没有任何报错。原因zmq_bind的地址写成了tcp://127.0.0.1:5556只监听回环网卡外部流量根本进不来。ZeroMQ 不会因为绑在回环上而报警它认为这是合法配置。解决把 bind 地址改成tcp://*:5556订阅端 connect 到发布端的实际 IP。改完还连不上就查防火墙Windows 防火墙默认会拦入站连接第一次 bind 时可能弹过一次允许对话框点了取消就再也不会弹了得去允许程序通过防火墙里手动加。多网卡的机器还要确认订阅端连的 IP 是发布端真正监听的那张网卡。6. 二次开发把实例改造成可配置的多主题分发模块原始实例是硬编码的地址、主题和发送间隔拿去做实际项目第一件事就是把这些抽出来。我的做法是加一个 ini 配置文件用 Windows 自带的GetPrivateProfileString读不引入任何第三方依赖——老项目最怕加库加一个就得连带一串。; pub.ini —— 发布端配置 [pub] bindtcp://*:5556 hwm2000 interval_ms200 topicsmarket.tick,market.depth,alert.risk读取部分用一个小的结构体承接注意GetPrivateProfileString的缓冲区长度参数是字符数不是字节数在 Unicode 配置下别算错。struct PubConfig { std::string bindAddr; int hwm; int intervalMs; std::vectorstd::string topics; }; bool LoadPubConfig(const char *iniPath, PubConfig cfg) { char buf[512] {0}; GetPrivateProfileStringA(pub, bind, tcp://*:5556, buf, sizeof(buf), iniPath); cfg.bindAddr buf; cfg.hwm GetPrivateProfileIntA(pub, hwm, 1000, iniPath); cfg.intervalMs GetPrivateProfileIntA(pub, interval_ms, 500, iniPath); /* 主题用逗号分隔逐个切出来发布时轮询发送 */ GetPrivateProfileStringA(pub, topics, market.tick, buf, sizeof(buf), iniPath); std::string all(buf); size_t pos 0; while (pos all.size()) { size_t comma all.find(,, pos); if (comma std::string::npos) comma all.size(); std::string one all.substr(pos, comma - pos); if (!one.empty()) cfg.topics.push_back(one); pos comma 1; } return !cfg.topics.empty(); }第二个改造点是把上下文和套接字包成 C 类用析构函数保证释放顺序。C 版本里手动 close 的写法在加了两三个套接字之后极容易漏构造函数建、析构函数关异常路径也能覆盖到。类里不要做拷贝构造把拷贝构造和赋值运算符声明为 private 且不实现这是 VS2008 时代标准的防拷贝写法比 C11 的 delete兼容性好。第三个改造点是加序列号做丢包统计。发布端在负载里带上自增 seq订阅端维护一个期望值收到时比对差值累加到丢包计数里每分钟打印一次。这个指标比任何日志都直观——如果丢包率一直是 0说明链路稳如果启动阶段有一波那就是 5.3 的慢连接器不用怀疑别的地方。第四个改造点值得单独提如果需要在运行时知道谁订阅了什么可以把 PUB 换成 XPUB。XPUB 会把订阅消息本身也当成一条消息投递给发布端格式是首字节1表示订阅、0表示退订后面跟前缀。拿到这个就能做动态主题管理比如某个主题没人订阅就不生成数据省掉不必要的计算。代价是发布端多了一个接收循环复杂度上去了量不大的场景没必要。验证方法很简单起两个订阅端一个订阅market.一个订阅alert.再起发布端轮询发三种主题看两边是不是各自只收到自己的。如果两个订阅端都收到了全部消息说明前缀设置没生效回去检查zmq_setsockopt的长度参数是不是传成了sizeof。我在这种老工具链项目上踩过一次最冤的坑改完配置读取之后本地跑得好好的拷到现场机器上就是连不上查了半天发现现场 ini 是用记事本另存的带了 UTF-8 BOMGetPrivateProfileString读第一节的名字时前面多了三个不可见字节整节都读不到全部走了默认值。从那以后我每次读 ini 之前都先检查文件头三个字节是 BOM 就跳过去再解析这个小检查后来救了我至少三次。希望帮到你。本文还有配套的精品资源点击获取