静态方法必须用类名调用，不能用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 代码添加注释、修改注释、审查注释、整理注释格式，或要求按照代码注释规范处理 Java 文件时，使用本技能。本技能用于统一生成和维护 Java 类注释模板、按 Git 对比 release 判断版本号、补充每行代码上方中文块注释、调整注释空行规则，并保持 Java 文件 UTF-8 无 BOM 编码。典型触发场景包括：补充类注释、更新 @version、检查 @author 来源、整理行尾注释、把注释放到代码上一行、检查注释是否符合规范、构建前检查 Java 注释风格。
- 适合场景：字符串处理、数值计算、对象判空、简单转换（如
LocalDateTime.toInstant()） - 不适合场景：DAO操作、HTTP请求封装、Spring Bean获取（
ApplicationContext.getBean()这种反模式除外） - 性能上静态方法调用确实略快（无虚函数表查找），但差异微乎其微，别为这点优化牺牲可测性
单元测试时静态方法难 mock，提前考虑可测试性
JUnit + Mockito 默认无法 mock 静态方法。如果你写了FileUtils.copyFile()这种静态工具调用，又想在测试里验证它是否被调用、或让它抛异常，就会卡住。得升级到Mockito 3.4.0+ 并用mockStatic()，还要求运行在支持字节码增强的环境（比如JUnit Jupiter + mockito-inline）。
立即学习“Java免费学习笔记（深入）”；
- 更轻量的替代：把逻辑抽到普通类里，通过构造函数注入，测试时直接传mock
- 如果坚持用静态，至少保证它纯函数式（相同输入永远相同输出），这样单元测试只需验证行为，不用mock
- 特别注意日志、时间、随机数这类“伪纯函数”——
System.currentTimeMillis()每次调用值都不同，静态方法里用它会让测试不稳定
