c++oding="utf-8" ?>
c++标准明确保留所有以单下划线开头的全局标识符，包括\_x、\_count等，无论后接大小写字母或下划线，均属实现保留范围，使用将导致未定义行为；安全做法是类成员用name\_后缀、全局变量加g\_或s\_前缀、私有函数动词化命名。
以单下划线开头的标识符在全局作用域中是危险的
标准明确保留所有以单下划线开头、后接大写字母（如 _X）或另一个下划线（如 __x）的名称，供实现（编译器、标准库）内部使用。但很多人忽略的是：仅以单下划线开头、后接小写字母的名称（如 _count）在全局作用域中也属于“保留范围”——C++ 标准 [lex.name] 规定：「以下划线开头的名称在全局命名空间中是为实现保留的」。
这意味着：
-
_count、_buffer_size等看似无害的全局变量名，可能与 libc 或 libstdc++ 的内部符号冲突，尤其在链接时出现undefined reference或静默覆盖行为 - 不同标准库实现（如 libc++ vs. libstdc++）对这类名称的占用策略不同，跨平台编译容易出问题
- 即使当前编译通过，升级工具链后可能突然失败——这不是 bug，是未定义行为（UB）
类内私有成员用 _name 还是 name_？
前者（前导下划线）风险高，后者（尾随下划线）是工业界主流选择。
_name 在类内看似安全，但一旦该类被继承、或模板实例化时推导出依赖名，就可能触发保留名解析歧义；而 name_ 完全避开所有保留规则，且 Google C++ Style、LLVM、Chromium 等均明确推荐。
常见误用场景：
- 把
class Config { int _port; };当作“私有约定”，却在头文件中暴露给外部翻译单元 → 实际上破坏了可移植性 - 在命名空间内写
namespace util { static int _cache_size; }→ 仍属全局作用域变体，同样保留 - 用
using _ = std::string;→ 编译器可能直接报错，因为_是纯下划线标识符，被严格保留
__func__ 和双下划线函数名不是你能模仿的
__func__ 是标准规定的预定义标识符（C++11 起），但 __do_init()、__internal_helper() 这类名字绝不能自己造。
原因很直接：
- 所有双下划线开头的名字（无论位置）100% 被标准保留，用户代码中出现即违反 [lex.name]/2，编译器有权拒绝诊断
- Clang/GCC 可能在 -Wall 下警告，但 MSVC 可能沉默接受，导致后续在 CI 或客户环境崩溃
- 宏展开时若意外生成
__前缀（比如#define LOG(x) __log_impl(x)），会污染整个翻译单元
真正安全的替代方案只有三个
别纠结“能不能用”，直接选已被验证的路径：
- 类成员变量统一用
name_后缀（如user_id_、is_connected_）——无保留冲突，语义清晰 - 静态/全局变量加作用域前缀，如
g_max_connections（global）、s_instance（static）——符合多数风格指南，且完全规避下划线保留区 - 私有函数不靠前缀区分，而靠访问控制 + 命名动词化，例如
validate_input()公开，normalize_path()私有 —— 名字本身已说明职责，无需_暗示
最常被忽略的一点：保留名规则不看上下文，只看拼写。哪怕你写 int _x = 42; 在函数体内，只要它出现在全局命名空间（包括匿名命名空间），就踩线。真正的安全边界，是彻底不用以 _ 开头的标识符，除非你正在写标准库。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
