<p>C++注释分//单行和/ /多行，禁止嵌套；/**/非标准但Doxygen支持；注释应解释“为什么”而非“怎么做”，避免冗余，宏内慎用注释，#if 0更安全屏蔽代码。</p>
C++单行注释用//，多行注释用/* */，但嵌套不合法
单行注释从//开始到行末结束，多行注释以/*开头、*/结尾。C++标准明确禁止/*嵌套/*——编译器会把第一个*/当作外层注释的结束，导致后续代码被意外注释掉。
- 常见错误现象：
/* /* inner */ outer */编译失败或逻辑错乱，实际只识别到第一个*/ - 使用场景：单行注释适合说明变量用途、短逻辑意图；多行注释更适合临时屏蔽大段代码（调试时）或写较长的接口说明
- 注意
//后面空格不是必须的，但加空格更易读（如// fix: handle nullptr比//fix:handle nullptr清晰）
/**不是C++标准语法，但部分IDE支持Doxygen解析
纯C++不认/**这种写法——它只是/*后跟一个*，属于普通多行注释的变体。但像VS Code、CLion等工具配合Doxygen插件时，会把/**开头的块识别为文档注释，并提取生成API文档。
- 参数差异：Doxygen识别
@param、@return等标签，但这些对编译器完全透明，删掉也不影响编译 - 容易踩的坑：误以为
/**有特殊语义，结果在没装Doxygen或没配置插件的环境里，只当它是普通注释，文档根本不出 - 性能/兼容性：无运行时开销，但过度依赖Doxygen标签会让注释和代码耦合变强，换工具链时可能丢失文档能力
注释不能放在#define宏定义中间或预处理指令之后
预处理器在编译前就处理#define、#include等指令，而注释是编译器阶段才解析的。如果在宏展开体内混入注释，可能导致宏行为异常。
- 常见错误现象：
#define LOG(x) printf("log: " #x "\n"); /* debug only */看似正常，但若宏被用在条件编译中，注释位置可能干扰预处理器判断 - 更安全的做法是把注释放在宏定义上方或下方，例如：
#define LOG(x) printf("log: " #x "\n")<br>// only enabled in DEBUG build - 特别注意：
#if 0 ... #endif是比/* */更可靠的代码屏蔽方式，因为它在预处理阶段就被剔除，不会参与词法分析
函数内部注释别解释“怎么写”，要说明“为什么这么写”
比如i++和++i在循环里效果一样，但注释写成“这里用前置递增”不如写成“避免拷贝临时对象（针对自定义迭代器）”。后者指向真实约束。
立即学习“C++免费学习笔记（深入）”；
- 容易踩的坑：注释描述代码字面意思（如
// loop from 0 to n-1），等于重复代码，维护时极易过期 - 推荐模式：用注释补全代码无法表达的信息——边界条件依据、算法选型理由、规避的已知bug编号、线程安全假设
- 示例：
// use std::vector::reserve() here to avoid reallocations during batch insert (see issue #287)
注释的生命力取决于它是否承载了代码本身无法表达的上下文。一旦你发现自己在注释里写“这个for循环遍历数组”，就该停下来想想：是不是变量名或结构可以改得更直白？或者，真正需要写下来的，其实是“为什么必须顺序遍历而不是随机访问”？
