同一作用域内重复定义变量会直接触发编译错误，如c/c++的“redefinition of 'x'”、typescript的“identifier 'x' has already been declared”、java的“variable x is already defined”，这是保存时即拦截的硬性错误。
同一作用域内重复定义变量会直接触发编译错误，比如 error: redefinition of 'x'（C/C++）、Identifier 'x' has already been declared（TypeScript）、或 Java 的 variable x is already defined。这不是运行时问题，而是写完代码保存那一刻就该被拦住的硬性错误——关键在于「让工具在你敲下 = 前就预警」。
用块级作用域替代函数/全局作用域声明
很多重名问题源于把所有变量堆在函数开头或文件顶层。let 和 const（JavaScript）、auto 或带初始化的 int（C++17+）、final（Java）天然绑定到最近的 {} 块，比 var 或无初始化的 int x; 更安全。
- JS 中写
if (cond) { const data = fetch(); }，data就不会污染外层作用域 - C++ 中避免在函数顶部集中声明：把
std::vector<int> result;</int>放在真正需要它的地方，而不是函数第一行 - Java 里不用
int i;然后后面反复赋值，改用for (int i = 0; i —— 循环变量自动隔离
启用编译器/语言服务的遮蔽警告
变量名没重复，但「遮蔽」外层同名变量（shadowing）同样危险，且容易被忽略。这类问题不会直接报错，但会悄悄覆盖预期值。
- C/C++ 编译时加
-Wshadow（GCC/Clang），遇到int x; void f() { int x = 2; }就警告 - TypeScript 默认开启
no-shadow，若想强制检查嵌套函数中的遮蔽，确保"noShadow": true在tsconfig.json中生效 - ESLint 配置
no-shadow+no-redeclare，配合 VS Code 的 ESLint 插件，保存即标红
跨文件重名：靠模块导出和 extern 控制
单个文件没问题，但多个 .cpp 或 .ts 文件都定义了 const API_BASE = 'https://api.example.com'，链接或打包阶段就会失败。
- C++ 头文件中只放
extern const char* API_BASE;，定义只出现在一个.cpp文件里 - TypeScript/ESM 中，所有常量集中到
constants.ts，其他文件统一import { API_BASE } from './constants';，绝不自己再写const API_BASE = ... - Python 模块里避免
__all__漏控，导入时用from mypkg.config import DB_URL而非import mypkg.config后手动引用，减少意外覆盖
IDE 重命名必须联动更新所有引用
手动改名是最大风险点：改了声明却漏掉某处使用，留下悬空引用或静默重名。现代 IDE 的符号重命名不是可选项，是必开功能。
- VS Code 中对
userCount右键 →Rename Symbol，会同时更新同一作用域内所有引用，包括解构、类型注解、JSX 属性 - JetBrains 系列（CLion/IntelliJ）默认启用
Refactor → Rename，勾选Search in comments and strings可额外捕获硬编码字符串里的误匹配 - 禁用「仅当前文件重命名」选项——跨文件变量名一致性必须由工具保障，不能靠人眼核对
最易被忽略的是：很多人以为「只要不报错就行」，但遮蔽（shadowing）和跨文件重复定义往往在重构或合并分支后才暴露。真正的防线不在记忆规则，而在编辑器实时高亮 + 编译器警告开关全开 + 所有常量/配置强制单点定义。写完一行代码，如果 IDE 没反应，反而要多看一眼。
