单个类方法数无硬性上限，但超7个需警惕职责扩散；判断是否该拆分的3个信号是：public方法频繁调用同组private方法、某方法仅在特定场景使用、多方法重复相同参数组合。
单个类的方法数没有硬性上限，但超过7个就该警惕职责扩散
PHP本身不限制类中方法数量，__construct、__destruct、__get等魔术方法也计入总数。真正的问题不是“能不能放”，而是“放了之后是否还能一眼看出这个类到底负责什么”。当一个类有12个方法，其中5个处理用户状态、4个做日志记录、3个在拼接API URL，它已经不是“类”，而是一个功能杂货铺。
判断方法是否该拆出的3个信号
以下情况出现任意一条，就该把部分方法抽成新类或Trait：
-
public方法里频繁调用另一个private方法组（比如validateInput、normalizeData、sanitizeOutput连续出现），说明这组逻辑自成体系 - 某个方法只在特定场景下被调用（如仅在命令行脚本中使用的
exportToCsv），和Web请求流程完全无关 - 方法参数列表重复出现相同组合（如
$userId、$timezone、$locale在4个方法里都作为前三个参数），暗示它们共享上下文，适合封装为独立对象
实际项目中更值得关注的不是数量，而是调用关系
一个含9个方法的类，如果其中7个都只被handle调用，而handle又只被外部调用一次，那它本质是1个入口+8个私有工具；但若这9个方法被6个不同控制器分散调用，且彼此间几乎没有依赖，那就等于把6个职责强行塞进一个命名空间里。
可快速检查：grep -r '->methodName' app/ | wc -l 统计每个方法的实际调用频次和位置，比数方法个数更有意义。
Trait不是万能解药，滥用反而增加理解成本
看到“方法太多”就下意识加use Loggable, Cacheable, Exportable，容易让类变成一堆行为拼贴。关键看这些Trait是否：
- 在多个不相关的类中复用（比如
Loggable同时用于UserService和PaymentGateway） - 内部方法之间强耦合（如
Cacheable::cacheKey()和Cacheable::invalidate()必须配套使用） - 不依赖宿主类的具体属性（即不用访问
$this->config或$this->db等非公共状态）
否则，不如直接新建一个CacheManager类，由原类通过构造函数注入——职责清晰，测试也方便。
真正难的不是决定“放几个方法”，而是每次新增方法时，能否三秒内说出它和已有方法的边界在哪。边界模糊的地方，就是下次重构的起点。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
