为何部分Windows API常量存在别名？以MessageBox图标常量为例

如果你用过Windows的MessageBox API，肯定会发现有些图标常量明明是同一个值，却有好几个名字——比如MB_ICONEXCLAMATION和MB_ICONWARNING指向同一个0x00000030L，MB_ICONINFORMATION和MB_ICONASTERISK是同一个值，还有MB_ICONSTOP、MB_ICONERROR、MB_ICONHAND这仨也是完全等价的。微软搞这种设计，其实背后有几个很实际的原因：

• 历史兼容性优先：Windows API已经存在几十年了，早期版本里这些常量是按照当时的图标样式命名的（比如MB_ICONEXCLAMATION对应感叹号图标）。后来微软意识到用偏向语义的命名（比如MB_ICONWARNING）更合理，也更能适应未来变化。但如果直接删掉旧命名，依赖它的老程序会直接崩溃——这对Windows这种极度注重向后兼容的系统来说绝对不能接受，所以干脆保留旧命名作为别名，让新老代码都能正常运行。

• 提升代码可读性与语义准确性：语义化命名比描述视觉的命名更靠谱。比如MB_ICONWARNING明确表示这是警告用途，不管Windows后续把图标改成什么样（比如从感叹号换成别的警示符号），这个常量的语义不会变；而MB_ICONEXCLAMATION绑定了当时的图标样式，哪天图标更新了，这个名字就显得名不副实了。提供别名让开发者可以选择更清晰、更具前瞻性的命名，同时也不强迫大家放弃已经习惯的旧写法。

• 适配不同开发者的习惯：不同开发者可能从不同文档、教程或前辈经验里学到不同命名。比如老程序员可能习惯用MB_ICONHAND，新开发者更熟悉MB_ICONERROR。提供别名能满足不同群体的使用习惯，降低学习和迁移成本，这也是微软API设计里常用的人性化考虑。

小提示：建议优先使用MB_ICONWARNING、MB_ICONINFORMATION和MB_ICONERROR这类通用语义命名的常量，而非描述具体图标的命名——因为Windows不同版本中图标的视觉样式可能会变化，后者的命名会和实际显示的图标脱节，可靠性更低。

内容的提问来源于stack exchange，提问作者user90726