静态方法只能访问静态成员，因属类加载时存在，而实例成员需对象创建后才存在；需访问实例数据应传入对象参数，否则应改为实例方法。
静态方法不能直接访问非静态成员变量或实例方法，这是Java编译期就强制拦截的错误。核心原因很明确：静态方法属于类，启动于类加载时；而非静态成员属于对象，诞生于new之后。没有对象，就没有this，也就无从定位要操作的是哪个实例的变量或方法。
明确访问边界：只允许“静态→静态”，禁止“静态→非静态”
这是最基础也最关键的规则，必须形成条件反射：
- 静态方法中，只能调用其他静态方法、访问静态变量
- 静态代码块里，同样不能出现
this、实例变量名或实例方法名 - main方法是静态的，所以你在里面写
printName()（没加obj.前缀）一定会报错：Non-static method cannot be referenced from a static context
需要访问实例数据？把对象“送进来”而不是“找过去”
不推荐在静态方法内部new一个新实例去访问——除非是无状态、轻量、可复用的工具类（如new SimpleDateFormat()）。更合理、更清晰的做法是让调用方把对象传进来：
- 把实例作为参数传入静态方法，例如：
public static void logUser(User u) { System.out.println(u.getName()); } - 这样逻辑职责分明：静态方法负责通用处理，对象状态由调用者负责准备和管理
- 避免了静态方法“偷偷创建对象又随意丢弃”的副作用，也利于单元测试和复用
检查设计意图：这个方法真的该是static吗？
如果一个静态方法反复需要访问实例字段、频繁创建对象、或者逻辑明显依赖对象当前状态（比如account.getBalance()、user.isActive()），那它大概率不该是静态的：
- 把它改回实例方法，去掉
static修饰符，是最自然、最符合面向对象的设计 - 强行保留
static再绕路访问，往往暴露的是职责错位——把本该属于对象的行为，硬塞进类级别的工具方法里 - 反例：写一个
static void saveToDb()却要传入id、name、email一堆参数，不如直接做成user.save()
警惕“伪静态调用”陷阱
语法上允许用对象引用调用静态方法，比如obj.staticMethod()，但这只是编译器的宽容写法，实际执行仍按ClassName.staticMethod()解析：
- 这种写法容易误导人，让人误以为该方法和
obj的状态有关 - 同理，不要在静态方法里写
this.xxx——编译直接失败，因为this根本不存在 - IDE通常会标黄警告，建议统一使用
ClassName.method()格式，语义更干净
