改名是最稳妥的解法，其他方式要么治标不治本，要么引入新风险；编译器报 declaration of 'x' shadows a parameter 是风格警告，提示局部变量遮蔽参数导致语义模糊，需用 -Wshadow 启用，首选语义化改名，禁用警告或加 [[maybe_unused]] 无效。
直接改名是最稳妥的解法，其他方式要么治标不治本，要么引入新风险。
为什么编译器要报 declaration of 'x' shadows a parameter
这不是语法错误，而是编译器在提醒你：函数参数 x 在函数体内被同名局部变量遮蔽了。C++ 名字查找从内向外，一旦在当前作用域找到 x，就不会再去找参数那个 x。这容易导致逻辑误读或维护困惑——比如你以为在读参数值，实际读的是局部变量；或者后续想修改参数值却忘了它已被遮蔽。
- 该警告默认不启用，需显式加
-Wshadow（GCC/Clang）或/Wall（MSVC）才触发 - cppcheck 的
shadowArgument检查器也覆盖同一类问题，但更早、更严格 - Java/JavaScript 允许遮蔽，C++ 把它当作风格隐患，默认不放行
三种处理方式的适用边界
别一上来就加 [[maybe_unused]] 或 #pragma，它们完全不解决遮蔽问题，只是掩盖警告。
-
改名：首选。把局部变量改成
value、result、tmp_x等语义明确的名字，既消警告，又提升可读性 -
直接赋值：如果本意就是覆盖参数值，删掉重新声明，直接写
x = getValue();—— 这不会触发遮蔽，且生命周期清晰 -
作用域隔离：极少数场景（如循环中临时复用名字），可用花括号限定局部变量作用域：
{ int i = 0; /*...*/ }，让遮蔽只发生在小范围内
哪些“修复”其实是陷阱
这些操作看似让警告消失，但没解决本质问题，甚至埋下隐患：
立即学习“C++免费学习笔记（深入）”；
- 用
[[maybe_unused]]标记局部变量 —— 它只对“未使用变量”警告有效，对-Wshadow完全无效 - 加
#pragma GCC diagnostic ignored "-Wshadow"—— 全局禁用，会漏掉真正该修的遮蔽点 - 在派生类里用同名函数遮蔽基类函数后，以为只是“重载”，实际是整个重载集被隐藏 —— 这属于
Name Hiding，和参数遮蔽是不同机制，得用using Base::func;解决
遮蔽问题难在它不报错、不崩溃，但会让代码意图模糊。最易被忽略的是：循环变量（如 for (int i = 0; ...)）撞上函数参数 i，这种地方往往藏在几十行之后，靠肉眼很难发现。用 cppcheck --enable=shadowArgument 扫一遍，比手动排查快得多。
