java中局部变量同名会静默覆盖成员变量，导致setter无效、getter返回默认值；应检查方法内是否有同名声明，启用ide的“field shadowed”检查，并在setter中使用this.name = name避免赋值错误。
成员变量被局部变量同名覆盖，怎么一眼看出来
Java里一旦在方法内声明了和成员变量同名的局部变量，编译器不会报错，但成员变量就“不可见”了——所有对该名字的读写都落在局部变量上，成员变量实际被静默屏蔽。最典型的症状是：调用 setter 后 get 仍返回默认值（比如 0、null），或者对象状态始终没变。
排查时别只盯逻辑，先扫一眼方法体里有没有和成员变量重名的形参或 int x、String name 这类声明。IDE 通常会把被隐藏的成员变量标灰或加波浪线（如 IntelliJ 的 “Field ‘xxx’ is shadowed”，但默认可能不开启）。
- 用 IDE 开启 “Shadow field” 检查（IntelliJ：Settings → Editor → Inspections → Java → Naming conventions → Field can be shadowed）
- 在 getter/setter 中加断点，观察
this.name和name的值是否一致 - 搜索整个类中所有
name =形式赋值，确认左边是否带this.
setter 方法里参数名和成员变量同名，为什么 this. 不可省略
这是最常踩的坑：写 public void setName(String name) { name = name; } 看似合理，实则毫无作用——右边的 是参数，左边的 <code> 是参数自己，根本没碰成员变量。Java 不支持像 Python 那样自动绑定，必须显式用 <code>this.name 指向当前实例的字段。
省略 this. 的后果不是编译失败，而是逻辑失效，且单元测试容易漏掉（因为没改状态，但没抛异常）。
立即学习“Java免费学习笔记（深入）”；
- 强制使用
this.name = name;，哪怕参数名不同也建议保持统一风格 - 用 Lombok 的
@Setter可规避手写错误，但得清楚它底层仍是生成this.field = field; - 如果真想用无前缀参数名，可用下划线区分：如成员变量叫
name，参数叫name_，但团队需约定且 IDE 补全会变弱
构造函数参数与成员变量同名，this. 同样不能少
构造函数里犯同样错误更隐蔽：成员变量初始化失败，对象一创建就是脏状态。例如 public Person(String name) { name = name; } 导致 this.name 始终为 null，后续任何依赖它的逻辑都会出问题。
尤其在链式构造（一个构造函数调另一个）或字段较多时，漏写 this. 几乎无法靠肉眼发现，只有运行时行为异常才暴露。
- 所有构造函数中对成员变量的赋值，必须写
this.field = param; - 启用编译器警告：javac 加
-Xlint:all会提示 “assignment to self”，但默认不启用 - 用 record 或 Builder 模式可绕过手写构造函数，但 record 字段是 final，不适用需要后期修改的场景
静态方法里访问成员变量？直接编译报错
静态方法没有 this，所以连“忘记写 this.”的机会都没有——只要在 static 方法里直接写成员变量名，javac 就会报 non-static variable xxx cannot be referenced from a static context。这不是隐藏，是硬性拦截。
但有人会绕开：把成员变量改成 static，结果引发多实例状态污染；或者传 this 进去再操作，又破坏静态语义。本质是混淆了实例状态和工具逻辑的边界。
- 静态方法只处理参数、局部变量、静态字段，绝不碰非静态成员变量
- 如果静态方法确实需要操作某对象的状态，说明它本就不该是静态的，应改为实例方法
- 工具类（如
StringUtils）保持纯函数式，输入输出明确，不持有或修改任何实例状态
真正麻烦的从来不是语法报错，而是那些静默生效的覆盖——没报错，值却没存进去，等线上日志里出现 null 或 0 才回头翻代码，而问题就藏在那一行没加 this. 的赋值里。
