静态方法适合无状态工具函数（如字符串处理），但禁用于需依赖注入的场景；命名须职责明确，避免大杂烩；优先考虑独立函数或di服务，而非强行静态化。
适合，但得看怎么用——静态方法本身没毛病，问题常出在设计意图和调用边界上。
静态方法做工具函数的合理场景
工具函数本质是无状态、不依赖实例生命周期的操作，比如字符串处理、数组转换、时间格式化。这类逻辑用 static 方法封装最直接，调用时不用 new，也避免了单例或全局变量的隐式依赖。
- 适合：校验类（
StringUtils::isEmpty()）、转换类（DateUtils::toTimestamp()）、编码类（JsonUtils::safeEncode()） - 不适合：涉及数据库连接、HTTP客户端、配置读取等需依赖注入或上下文的逻辑——硬塞进静态方法会导致测试困难、耦合变高
- 注意：PHP 的静态方法无法被 mock（除非用 AspectMock 或 PHP-PM 等特殊手段），单元测试时容易卡住
命名与类结构别踩这些坑
别叫 Helper 或 Utils 就完事。类名要体现职责边界，方法名要动词开头、语义明确，否则后期维护时根本猜不出 Tool::doIt($x) 到底干了啥。
- 推荐命名：如
UrlBuilder、ArrayFlattener、Base64Encoder—— 一看就知道能力范围 - 拒绝“大杂烩”：一个类里塞 30 个静态方法，最后连作者都记不清
Common::format()是格式化数字还是日期 - 私有静态属性慎用：比如缓存正则表达式，要加
private static $regexCache = [];，但得确保线程安全（PHP-FPM 下通常没问题，Swoole 长生命周期下可能出问题）
替代方案比你想象中更常用
很多所谓“工具需求”，其实更适合用独立函数（PHP 7.4+ 支持 fn()，8.0+ 支持命名函数文件）或依赖注入的服务对象。
立即学习“PHP免费学习笔记（深入）”；
- 纯函数更轻：放在
src/Functions/str.php，用require_once加载后直接调str_trim()，无类开销，IDE 补全也友好 - 需要状态或配置时：改用服务类 + DI 容器管理，比如
class DateFormatter { public function __construct(private string $timezone) {} }，静态方法根本没法传构造参数 - Composer 包已有的别重复造：
symfony/string、ramsey/uuid这些库的 API 比自己写的静态工具类更稳、文档更全、边界更清晰
真正难的不是写几个 static 方法，而是判断这个逻辑到底该“无状态裸奔”，还是“带上下文落地”，或者“交给专业包扛”。工具类写得太顺手，反而容易掩盖设计模糊的问题。
