静态方法不能使用 $this，所有依赖必须显式通过参数传递；参数应类型明确、命名直白、避免万能数组；超4–5个参数或强耦合参数需重构为dto或实例方法。
静态方法里不能用 $this，所以所有依赖都得靠参数传进来
PHP静态方法运行在类的上下文之外，$this 不可用，意味着你无法在方法内部访问实例属性、调用非静态方法，或者隐式依赖当前对象状态。所有外部数据——不管是配置、上下文、还是业务实体——都必须显式通过参数传递。
常见错误现象：Fatal error: Using $this when not in object context，往往是因为误把本该是实例方法的逻辑写成了 static，又在内部用了 $this->xxx。
- 如果需要访问数据库连接、日志实例、请求上下文等，别想着“从某处自动拿”，老老实实加参数，比如
public static function process(array $data, PDO $pdo, LoggerInterface $logger) - 避免在静态方法里 new 一个新实例再调用其方法来“绕开”参数传递——这会让依赖不透明、测试困难、且可能掩盖设计问题
- 参数命名要直白，比如不用
$input，而用$userRecord或$configArray，因为没有上下文辅助理解
static 方法的参数类型声明和默认值和普通方法一致，但要注意 null 合理性和调用方控制力
PHP 7.1+ 支持参数类型声明（如 string、int、array）和默认值（包括 null），静态方法完全支持，语法无差异。但关键在于：调用方无法通过继承或重写改变参数行为，所以每个参数的设计责任全在定义者身上。
容易踩的坑：public static function format(?string $text = '') 看似稳妥，但 '' 和 null 在业务语义上常不等价，而调用方一旦传了 null，就可能触发意料外的分支。
立即学习“PHP免费学习笔记（深入）”；
- 优先用明确的默认值，比如
= 'default'而非= null，除非null是合法且有明确定义的业务状态（如“未指定语言”） - 如果参数可选，考虑拆成两个方法：一个带完整参数，一个封装常用默认值调用前者，例如
sendEmail()内部调用sendEmailInternal($to, $subject, $body, 'text/plain') - 数组参数慎用
array $options = []，容易演变成“万能参数”。真要灵活，建议用对象（如SendOptions）或至少做键名校验
传对象进静态方法时，注意是传值还是传引用，以及是否修改原对象
PHP 中对象变量本质是句柄（handle），传参默认是“传对象引用的副本”，即：你在静态方法里改对象属性，会影响原始对象；但若在方法内重新赋值（如 $obj = new SomeClass()），不会影响调用方的变量。
典型问题场景：工具类中有个 public static function normalize(User $user)，结果里面写了 $user->setName(trim($user->getName())) —— 这直接改了传入的 $user 实例，调用方可能完全没预料到。
- 如果静态方法职责是“转换/生成新数据”，应避免修改入参对象，必要时 clone 或构造新实例返回
- 如果确实要修改原对象（比如批量初始化），文档和方法名必须清晰表达副作用，例如叫
populateDefaults(User $user)而不是normalize(User $user) - 标量类型（
int、string）和数组默认按值传递，不用担心，但大数组传参会有性能开销，可考虑传&$array引用（需明确写&，且调用方必须配合）
静态方法参数太多？说明它可能不该是静态的，或该被拆解
超过 4–5 个参数的静态方法，基本意味着职责过重或抽象层级错了。静态方法本该是轻量、无状态、高复用的工具函数，不是业务流程入口。
真实报错信号：Too many arguments 不是 PHP 报的，而是人读代码时皱眉的那一刻。
- 检查是否把多个逻辑塞进一个方法，比如
generateReport($startDate, $endDate, $format, $includeSummary, $timezone, $language, $cacheTTL)—— 应拆成配置对象 + 执行方法 - 如果参数之间强耦合（比如
$host和$port总是一起出现），提取为一个 DTO 类，如ConnectionConfig - 最后再问一次：这个方法真的不需要任何实例状态？有没有可能只是图省事加了
static，其实它该属于某个服务类的实例方法？
静态方法的参数表面是语法问题，实际是接口设计的缩影——它暴露了你对“谁负责提供什么”“什么该被封装”“什么该被显式表达”的判断。越想省参数，越容易在后期补更多注释、更多 if 分支、更多难以 mock 的测试。
