机智的娜娜带了一圈新项目，日志这块居然成了第一个卡点。项目用C++写Windows桌面客户端，VS开发，日志方案原本是printf加OutputDebugString混着来，查问题的时候恨不得把DBGVIEW的滚动条拉断。后来换成了glog，整个排查路径清晰了不止一个级别。这篇就把在VS的C++工程里接入glog的完整过程写下来，从选方案到配置，从编译踩坑到日常调参，基本照着做就能跑起来。
先说清楚glog是干什么的。它是Google开源的C++日志库，功能很直接：分级日志、条件日志、崩溃时的栈信息输出、日志按大小分片。对一个C++桌面项目来说，这几个能力基本覆盖了绝大部分日志需求。尤其对于长期运行、需要在用户机器上排查问题的Windows程序，日志要是做不好，出了问题只能干瞪眼。
我折腾下来最大的感受是：glog的引入本身不难，难的是在VS的C++项目里把库文件、宏定义、运行库这些零碎配置一次性配对。很多人卡住不是因为glog复杂，而是被MSVC的工程配置坑了，所以下面会把选型、配置、校验、实战调优一路讲透。
1. 在动手之前，先搞清楚glog到底替你干了什么
1.1 为什么C++项目需要一个像样的日志库
有人会问：我自己写个宏，格式化一下OutputDebugString不就行了？小项目确实可以，但一旦项目超过两万行、模块超过三个、需要追查的问题出现在客户机器上，自己造轮子的日子就不好过了。日志需要解决的其实是一组问题：日志分级、日志回滚、崩溃时留证据、性能损耗可控。你写一个宏解决不了所有问题，写了十几个宏之后，这个"日志系统"本身就成了需要维护的负担。
glog天然就把这套东西做好了。它把日志分成INFO、WARNING、ERROR、FATAL四个级别。其中FATAL级别会直接终止程序，这个特性非常关键：程序跑挂了，日志里必然有一条FATAL记录，而且还能配合崩溃信号处理打出调用栈。对于线上问题排查，这套东西的价值远超自己写的临时方案。
1.2 glog的日志格式和使用手感
很多第一次用glog的人，看到日志输出会一愣：
txt复制I20240720 14:30:00.123456 1234 main.cpp:10] hello glog
格式从左到右拆开看：I代表INFO级别，后面是年月日时分秒微秒，再后面是线程ID，然后是源文件名和行号，中括号后面才是真正的日志正文。这个格式初看有点啰嗦，但排查多线程问题的时候非常有用，文件行号直接定位，连IDE断点都不用加。
写日志的语法和流式输出很像：
cpp复制LOG(INFO) << "user login, user_id=" << user_id << ", ip=" << ip;
LOG(WARNING) << "config file missing, use default config";
LOG(ERROR) << "db connection failed, errno=" << errno;
这种流式写法最大的好处是不用操心格式化字符串和参数类型匹配，int、double、std::string直接往里扔，类型安全，也不容易写错占位符。
对于一个C++项目来说，开发效率、排障效率、稳定性，这三样glog都能照顾到。接下来重点就是怎么把它装进VS工程里。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 引入glog的三条路线：vcpkg、源码编译、NuGet到底怎么选
2.1 三条路线的横向对比
把glog接进VS的C++工程，不是只有一种办法。我分别试过vcpkg、源码编译、NuGet三种方式，它们各有各的适用场景。
| 引入方式 | 上手难度 | 可控性 | 适合场景 |
|---|---|---|---|
| vcpkg | 低 | 中 | 喜欢用包管理、希望VS自动感知库路径 |
| 源码编译 | 中高 | 高 | 需要修改glog源码、需要自定义构建选项 |
| NuGet | 低 | 低 | 快速实验、临时项目、不想装vcpkg |
2.2 vcpkg是当下最顺手的路子
如果项目是单机开发、没有特别奇怪的构建要求，vcpkg是目前最省心的方案。它在Windows下首次安装可能要花点时间，但后续的库版本升级、依赖管理都是自动的。尤其在VS里配合打开CMake工程或者MSBuild工程，基本能做到"装完库直接能用"。
vcpkg装的不只是glog本身，还会把它的依赖一并解决。glog在Windows下依赖gflags，虽然现在glog 0.6+对gflags的依赖已经弱化了，但vcpkg帮你把这些都处理清楚，省得手动找库的时候发现少了一个传递依赖，编译出来一堆莫名其妙的错误。
2.3 源码编译适合需要改库源码的情况
源码编译适合什么情况？举几个真实场景：某些公司内部的构建服务器不允许联网拉取第三方依赖；或者你打算魔改glog的日志格式，比如把时间戳格式改成特定样式的需求；再或者你需要在日志系统底层叠加一个内部的上报SDK。这些场景下，从源码编译是唯一可控的方案。
2.4 NuGet方案只建议用来快速验证
NuGet在VS里一条命令就能装glog，但它有几个现实问题：包版本通常落后于上游、可选的静态/动态库形态比较受限、出了问题不好定位。我建议把它定位成"临时写个小Demo验证glog语法"的工具，不太建议直接用在正式交付项目里。因为正式打包时你会突