Lcobucci/JWT 中 Builder 方法的不可变性优化与静态分析支持

在 Lcobucci/JWT 5.0 版本中，Builder 类被重构为不可变(immutable)实现，这一架构变更虽然提升了代码的安全性和可预测性，但也带来了静态分析工具无法自动检测的问题。本文将深入分析这一变更的技术背景、影响及解决方案。

不可变 Builder 的设计原理

传统的 Builder 模式通常采用可变(mutable)实现方式，每个方法调用都会修改内部状态。而 Lcobucci/JWT 5.0 采用了不可变实现，每个方法调用都会返回一个新的 Builder 实例，原始实例保持不变。这种设计具有以下优势：

1. 线程安全性：多个线程可以安全地共享 Builder 实例
2. 可预测性：方法调用不会产生副作用
3. 更易于调试：每个状态变更都对应一个新实例

静态分析工具的局限性

由于 PHP 语言本身缺乏对纯函数(pure function)的内置支持，静态分析工具如 PHPStan 无法自动识别 Builder 方法的不可变特性。这导致开发者可能会忽略方法返回值，错误地认为方法会修改原始实例：

$builder = new Builder();
$builder->issuedBy('issuer'); // 错误：返回值未被使用
$token = $builder->getToken(); // 这里使用的是原始builder，不是修改后的

解决方案：@pure 注解

通过为 Builder 方法添加 @pure 注解，我们可以显式告知静态分析工具这些方法的特性：

1. 无副作用：不会修改对象状态
2. 引用透明：相同输入总是产生相同输出
3. 返回值必须使用：方法的返回值包含了所有变更

/**
 * @pure
 * @return self
 */
public function issuedBy(string $issuer): self {
    $new = clone $this;
    $new->issuedBy = $issuer;
    return $new;
}

最佳实践建议

1. 升级到 Lcobucci/JWT 5.0+ 版本时，确保所有 Builder 方法调用都使用了返回值
2. 在项目中配置 PHPStan 或 Psalm 等工具，启用返回值检查规则
3. 对于自定义 JWT 构建逻辑，遵循相同的不可变模式实现
4. 在团队文档中明确记录这一变更，避免混淆

通过这种显式的注解方式，我们既保持了不可变设计的优势，又为开发者提供了更好的工具支持，使得代码质量检查更加全面和可靠。