[[maybe_unused]]必须置于声明最前，因它是声明组成部分而非修饰符；适用于函数参数、变量、类型别名、结构化绑定等，禁用于模板参数、lambda捕获和返回类型。
直接用 [[maybe_unused]] 是最合理的方式，前提是编译器支持 C++17 且属性位置写对；否则 fallback 到 __attribute__((unused)) 或 (void)var; 是常见补救手段，但语义和作用域完全不同。
为什么 [[maybe_unused]] 必须放在声明最前面
它不是“修饰符”，而是声明的一部分，编译器只在解析声明时检查该属性。写错位置等于没写：
-
[[maybe_unused]] int x = 42;✅ 正确 -
int [[maybe_unused]] x = 42;❌ GCC/Clang 拒绝（语法错误），MSVC 可能容忍但不保证 -
int x = 42; [[maybe_unused]]❌ 完全无效，编译器根本不会关联到x
结构化绑定里也一样：auto [a, [[maybe_unused]] b, c] = t; 才能只忽略 b。
[[maybe_unused]] 能用在哪些地方
它覆盖的场景比多数人以为的更广，但有明确边界：
- 函数参数：适配回调、信号槽、虚函数重写等强制签名场景
- 局部/全局/静态变量：包括
static const int [[maybe_unused]] Default = 0; - 结构化绑定中的单个元素：如上例
- 类型别名：
using [[maybe_unused]] Handle = void*;（合法但少见） - 不能用于：模板参数、lambda 捕获列表、返回类型、
typedef（语法不允许）
注意：它不改变变量生命周期或优化行为，纯属编译期元信息。
兼容性差时怎么 fallback
如果项目需支持 GCC [[maybe_unused]] 会被静默忽略——你看着没警告，其实是失效了，不是成功了。
- 跨编译器宏封装常见写法：
#define MAYBE_UNUSED [[maybe_unused]]+ 条件编译 fallback 到__attribute__((unused)) - 函数体内临时变量可用
(void)var;，但它必须出现在函数体中，不能用于类成员或命名空间变量 - 避免用
#pragma GCC diagnostic ignored "-Wunused-variable"全局屏蔽——会掩盖真正的问题
最易被忽略的一点：[[maybe_unused]] 对 “已赋值但未读取” 类警告（如 -Wunused-but-set-variable）同样有效，但老式 (void)var; 不行——它只管“未使用”，不管“设而不用”。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
