ifndef不起作用的根本原因是宏名未全局唯一，应采用PROJECTNAME_SUBDIR_FILENAME_H格式（如MYAPP_CORE_CONFIG_H），避免冲突；#pragma once虽简洁但非标准，跨平台项目仍推荐#ifndef三件套。
为什么 #ifndef 不起作用？
常见现象是头文件被多次包含后，编译报错“redefinition of class/struct/function”，说明 #ifndef 没拦住重复展开。根本原因不是语法写错了，而是宏名没做到全局唯一——比如两个不同目录下的 utils.h 都用 #ifndef UTILS_H，只要其中一个先被包含，另一个就彻底失效。
- 宏名必须能体现文件路径或项目上下文，推荐用
PROJECTNAME_SUBDIR_FILENAME_H格式，例如MYAPP_CORE_CONFIG_H - 别依赖 IDE 自动生成的简单宏名（如
CONFIG_H），尤其在模块化或子项目共存时 - 检查是否误写了
#ifdef或漏了#endif，C++ 预处理器不报错，但逻辑会断掉
#pragma once 能代替 #ifndef 吗？
可以，但有兼容性代价。#pragma once 是编译器扩展，主流编译器（Clang、GCC 、MSVC）都支持，但它不被 C++ 标准规定，极端情况下（比如某些嵌入式工具链或老版本 ICC）可能不识别。
- 如果项目只跑在现代桌面环境，
#pragma once更简洁、不易手误，且能避免宏名冲突问题 - 如果需要保证跨平台可移植性（尤其涉及第三方 SDK 或遗留构建系统），仍建议坚持
#ifndef+#define+#endif三件套 - 两者混用没意义，也不推荐——选一个并统一执行
宏名里要不要加下划线前缀或后缀？
要，但不是为了“好看”。以下划线开头的宏名（如 _CONFIG_H）属于实现保留名，C++ 标准禁止用户定义，可能和编译器/标准库内部宏冲突，导致不可预测行为。
- 宏名应全大写 + 下划线分隔，且以项目/模块名开头，例如
NETWORK_HTTP_CLIENT_H - 避免单个下划线开头、双下划线开头、或以下划线结尾（如
HTTP_CLIENT_H_），这些都踩在未定义行为边缘 - 宏名中不要出现点号、连字符、空格——预处理器只认字母、数字、下划线
模板类头文件也得加 #ifndef 吗？
必须加，而且比普通头文件更关键。模板声明和定义通常都在头文件里，一旦被多次包含，会导致多个翻译单元看到同一组模板实例化请求，链接时可能报 multiple definition 错误，尤其在启用 LTO 或某些 ODR-violating 场景下。
- 即使用了
inline或extern template，也不能跳过头文件保护——那是另一层控制机制 - 注意：模板特化本身不触发重定义，但主模板的重复声明会干扰编译器对特化的解析顺序
- 如果头文件里还内联了 constexpr 函数或 const 变量，同样依赖头文件保护来避免 ODR 违规
实际写的时候，最常被忽略的是宏名与文件物理路径的映射关系——改了文件名或挪了目录，却忘了同步更新宏名。这不是语法错误，但会让整个防护机制静默失效。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
