当方法与实例关系不大时，也就是当你希望摆脱实例化的限制直接使用类中的一个方法或属性时，可以定义为 static。
此外在效率上：
类名访问静态方法 > 实例访问静态方法 > 实例访问非静态成员方法

但是，过多地定义静态方法或属性无疑会对类的封装性和安全性造成一定影响。

btw，如果属性与实例的关系几乎为0时，建议定义为 const 常量。

在一个类里面，不变的一些东西可以使用static，比如，数据库链接的dsn，还有比如你问题中提到的会员菜单。

我一般不排斥业务代码用静态方法/属性，但框架/公共的代码还是要极力避免静态方法和属性的(少数如工厂方法的情况可以排除)，因为这涉及

• 扩展性 调用方写死类名意味着要改变行为几乎只能改类的代码，无法通过继承来override
• 可测试性 静态方法/属性 在测试的时候往往会对插桩造成困难
• 耦合度 特制static属性可以被外部修改的时候，会大幅度提升耦合度。 public static的属性有修改行为的话和全局变量几乎只有名字的区别，灾难程度是一样的