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