静态方法必须用类名调用，不能用this或实例对象；属于类本身，不可访问this/super及非静态成员；static须位于返回类型前，不可与abstract共存；适用于无状态工具逻辑，但难mock，影响可测试性。
静态方法必须用类名调用，不能用this或实例对象
Java里静态方法属于类本身，不是某个对象的。所以哪怕你写在实例方法里，也不能用this.methodName()去调用它——编译直接报错：non-static method cannot be referenced from a static context。常见错误是刚学完实例方法，顺手把工具类里的StringUtils.isEmpty()写成this.isEmpty()，结果连编译都过不去。
- 正确调用方式只有：
ClassName.methodName()（如Math.abs(-5)） - 静态方法内部不能访问
this、super，也不能直接调用非静态字段或方法 - 如果真需要访问实例状态，说明这个方法不该是静态的——强行塞进去只会让逻辑变脆弱
static修饰符位置不能错，且不能和abstract、final等混用
定义静态方法时，static必须放在返回类型前面，紧挨着访问修饰符。写成public void static doWork()会编译失败。另外，static和abstract天然冲突：抽象方法要子类实现，而静态方法连继承都绕过，根本没法重写；static和final倒是可以共存，但final在这里没实际意义——静态方法本来就不能被重写。
- 合法写法：
public static String formatTime(long ms) - 非法写法：
public void static parse()、abstract static void init() - 接口中从Java 8起允许
static方法，但必须有方法体，不能是抽象的
静态方法适合做无状态工具逻辑，不适合管理资源或依赖上下文
像Objects.requireNonNull()、Arrays.asList()这类方法，输入确定、输出确定、不改全局状态、不读配置、不连数据库——这才是静态方法该干的事。一旦你发现方法里开始new线程、读System.getProperty()、操作ThreadLocal、或者要传一堆context参数进来，那它大概率不该是静态的。
分析 Java Spring Boot 后端 Controller 代码，自动生成 Markdown 格式的接口文档。当用户说“生成 Java 接口文档”、“生成 API 文档”、“从 Spring 代码生成文档”时触发。
- 适合场景：字符串处理、数值计算、对象判空、简单转换（如
LocalDateTime.toInstant()） - 不适合场景：DAO操作、HTTP请求封装、Spring Bean获取（
ApplicationContext.getBean()这种反模式除外） - 性能上静态方法调用确实略快（无虚函数表查找），但差异微乎其微，别为这点优化牺牲可测性
单元测试时静态方法难 mock，提前考虑可测试性
JUnit + Mockito 默认无法 mock 静态方法。如果你写了FileUtils.copyFile()这种静态工具调用，又想在测试里验证它是否被调用、或让它抛异常，就会卡住。得升级到Mockito 3.4.0+ 并用mockStatic()，还要求运行在支持字节码增强的环境（比如JUnit Jupiter + mockito-inline）。
- 更轻量的替代：把逻辑抽到普通类里，通过构造函数注入，测试时直接传mock
- 如果坚持用静态，至少保证它纯函数式（相同输入永远相同输出），这样单元测试只需验证行为，不用mock
- 特别注意日志、时间、随机数这类“伪纯函数”——
System.currentTimeMillis()每次调用值都不同，静态方法里用它会让测试不稳定
静态方法看着简单，真正麻烦的是边界模糊：什么时候该静态、什么时候该实例、要不要拆出去、测试怎么写。这些不是语法问题，是设计判断——而判断依据，始终是“它到底属不属于这个类的状态”。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
