Protobuf 3.19.1 在 Windows 编译报 C2589：max 宏破坏 std::max

Windows C++ 项目更新到 Protobuf 3.19.1 后，编译在 google/protobuf/stubs/stl_util.h 的 std::max 附近报 C2589，提示 ( 不能出现在 :: 右侧，随后还有语法错误。若 Windows 头已经定义了函数宏 max，先检查预处理冲突，不要把它当成链接库缺失。

这里限定为头文件中的 max 宏污染。原先能编译、升级后失败，并不足以证明所有同版本项目都有问题；包含顺序、间接头文件和预编译头都会影响该宏是否可见。

std:: 限定名挡不住宏展开

Windows SDK 头文件可能定义类似下面的函数宏：

#define max(a, b) (((a) > (b)) ? (a) : (b))

预处理器处理宏时还没有进入 C++ 命名空间查找。std::max(a, b) 中的 max 仍可能展开，留下类似 std::( 的非法代码，于是编译器把错误指向 :: 后面的括号。

先核对失败位置确实是这一类调用，再检查该位置之前是否已定义 max。不要只查当前源文件是否显式包含 Windows.h：其他库头或预编译头也可能已经包含它。保留实际编译命令与头文件路径，防止检查了另一套 Protobuf 安装。

Protobuf 3.19.1 的该辅助头包含未被保护的 std::max 调用。针对这一位置的修复采用成对的内部头，在相关代码范围内暂存并取消宏，结束时恢复。不能据此把任意当前版本的 C2589 都归到同一缺陷。

优先采用包含修复的配套依赖

如果项目允许更新依赖，核对所选发行包的实际头文件是否已包含针对该位置的宏保护，并按项目兼容要求更新。补丁合并日期不等于你正在使用的发行包已包含补丁；不要只看包管理器显示“最新版”就跳过头文件路径检查。

Protobuf 的生成工具、生成代码、头文件和链接运行库也应按对应版本的兼容约定保持配套。修复这个编译错误不意味着可以把新旧运行库随意混用。更新前保留依赖锁定、构建配置及生成文件的差异，便于恢复原有组合。

项目不依赖这些宏时，在包含之前抑制定义

如果项目及相关依赖不需要 Windows 的 min、max 宏，可以让 NOMINMAX 在 Windows 头首次被处理之前生效。下面只展示包含顺序；生成头名称需替换为项目真实文件：

#ifndef NOMINMAX
#define NOMINMAX
#endif
#include <Windows.h>
#include "example.pb.h"

Windows SDK 的相关定义由 #ifndef NOMINMAX 控制。把这个宏写在 Windows 头之后，并不会撤销已经存在的 max。如果 Windows 头来自预编译头，应在生成该预编译头的配置中统一设置，并按项目流程重建相关产物，不能只改一个较晚编译的源文件。

这是项目级约定的变化。旧代码或第三方头若仍直接使用这些宏，可能转而报找不到 min、max；需要先确认依赖要求，不要全局替换所有同名标识符，也不要修改 SDK 安装目录中的公共头。

必须保留宏时，缩小兼容补丁范围

依赖旧宏的代码不能直接采用全局抑制方案。优先使用上游提供的宏保护修复；确实需要维护本地依赖补丁时，应保留补丁差异和原始版本，并检查暂存、取消和恢复是否成对，覆盖完整的相关头文件范围。

单独在某个地方写 #undef max 可能让当前编译位置通过，却影响后面的代码；另一个头也可能再次定义它。不要把这条临时定位手段当作没有副作用的永久方案。Protobuf 的内部 port_def.inc、port_undef.inc 也不是可以随意添加到应用文件中的公共配置接口。

从原失败构建入口复核

使用原来的构建配置检查 Debug、Release 和 CI 实际采用的头文件及预处理设置。应确认失败位置不再被宏展开破坏，后续依赖代码仍能编译，链接与项目测试也通过。只编译一个手写的 std::max 小例子，不能证明整个依赖链已经修好。

回退时一起恢复依赖版本、项目宏定义和相关生成产物，重新生成受影响的预编译头。这个问题不需要删除业务数据或关闭编译诊断；若准确位置没有 max 宏，再沿当前报错检查其他语法或类型问题。