this是解决成员变量与局部变量重名时遮蔽问题的唯一可靠方式，必须显式使用this.fieldName访问被遮蔽的成员变量，否则赋值无效、状态无法更新。
成员变量和局部变量重名时，this 是唯一可靠解法
重名不是语法错误，但会导致局部变量遮蔽成员变量，结果是读不到、改不了类状态。这时候不用 this，基本等于没写那行赋值。
- Java/C# 中必须显式用
this.fieldName访问被遮蔽的成员变量；Kotlin 用this@ClassName.fieldName（仅当需要区分嵌套作用域时） - 构造函数参数名和成员变量名一致是高频场景，比如
public Person(String name) { this.name = name; }—— 不加this.就是自赋值，成员变量永远为null - IDE（如 IntelliJ）默认会提示“Field can be accessed directly”，但那是针对「未被遮蔽」的情况；一旦有同名局部变量，提示就消失，容易误判
this 和类名前缀（如 Person.this）不是一回事
普通方法里只用 this；只有在内部类访问外部类成员时，才需要带类名的限定形式，否则编译不通过。
-
this.name：当前对象的成员变量 -
Person.this.name：仅在Person的非静态内部类中，用于明确指向外部实例的name字段 - 误用
Person.this在静态方法或顶层类中会报错：non-static variable this cannot be referenced from a static context - Android 开发中常见坑：在
ViewHolder内部类里写MainActivity.this.findViewById()，其实多数情况只需itemView.findViewById()，强行用this前缀反而增加耦合
用类名作为变量前缀（如 personName）不能替代 this
命名规范解决的是可读性问题，不是作用域问题。哪怕你把参数叫 inputName、成员叫 personName，只要没用 this.personName = inputName，赋值动作依然落在局部变量上。
- IDE 自动生成的构造函数（如 Eclipse/IntelliJ 的 “Generate Constructor”）默认就用同名参数 +
this.，别手动改成不同名再省略this - Getter/Setter 中也容易漏：写
public void setName(String name) { name = name; }是典型无效代码，必须是this.name = name - Lombok 的
@Data或@Setter会自动生成带this的赋值逻辑，但前提是字段名和参数名一致 —— 它不猜意图，只按规则生成
静态方法里没有 this，重名问题换种方式爆发
静态方法不能访问非静态成员变量，所以根本不存在「遮蔽」问题；但如果你在静态方法里声明了一个和类字段同名的局部变量，又试图用类名去访问字段，就会触发编译错误。
- 错误写法：
static void print() { String name = "tmp"; System.out.println(Person.name); }—— 报错：non-static variable name cannot be referenced from a static context - 正确做法：要么把字段改为
static，要么把逻辑移到实例方法，或者传入实例引用（如print(Person p)） - 工具类中尤其要注意：不要为了“看起来统一”而给静态方法参数起和某个业务类字段一样的名字，容易误导自己后续补逻辑
这事的核心就一条：遮蔽发生时，this 不是风格选择，是作用域刚需。漏掉它，bug 不一定立刻暴露，但一定会在某个边界 case 里突然崩。
