Symfony Validator 在 FrankenPHP worker 模式下校验失效，因单例验证器复用导致请求上下文残留；修复需每次 validate() 中通过 $context->getRequest() 获取当前请求，避免构造时缓存 Request。
Symfony 验证器在 FrankenPHP 环境下校验失效，**不是验证器本身坏了，而是请求生命周期被常驻化后，部分依赖请求上下文的验证逻辑没被重置**。尤其当你开启 worker 模式时，ValidatorInterface 实例复用、RequestStack 未及时切换、或 ConstraintValidator 中缓存了上一个请求的 Request 对象，都会导致校验结果错乱（比如始终返回 isValid = true，或错误地复用旧的 context）。
为什么 Symfony Validator 在 FrankenPHP worker 模式下会“记住”上一个请求？
Symfony 的默认验证器服务是单例（validator），在 worker 常驻进程中不会随请求销毁。而某些自定义约束验证器（尤其是继承 ConstraintValidator 并手动保存 $this->request 或 $this->context 的）会在第一次请求后把状态留在实例属性里，后续请求直接读取旧值。
常见诱因包括：
- 在
validate()方法外提前把$context->getRequest()赋值给$this->request，且未在每次validate()开头重置 - 使用
RequestStack::getCurrentRequest()获取请求，但RequestStack在 worker 模式下未被正确清空（尤其在非标准入口如frankenphp-worker.php启动时） - 验证器中调用了
$context->buildViolation()后未立即->addViolation()，而是延迟执行，导致上下文绑定到错误请求
如何快速确认是不是 worker 生命周期污染？
临时关闭 FrankenPHP 的 worker 模式，只用普通 CGI 模式跑一次验证——如果此时校验恢复正常，基本可锁定是常驻内存导致的状态残留。
立即学习“PHP免费学习笔记（深入）”；
操作方式：修改 Caddyfile，移除 php_worker 指令，或启动时加 --no-worker 参数（取决于你用的是二进制直启还是 Docker）。然后用 curl -v http://localhost/your-form-submit 多次提交不同数据，观察验证行为是否一致。
如果 CGI 模式下正常、worker 模式下异常，下一步就该检查验证器实现和容器作用域。
修复自定义 ConstraintValidator 的三个关键点
不要假设验证器实例是“干净”的——在 worker 模式下它大概率不是。必须显式隔离每次请求的上下文。
- 把所有请求相关状态（如
$this->request、$this->user、$this->tokenStorage）移到validate()方法内部，而不是构造函数或属性中 - 避免在验证器中直接依赖
RequestStack；改用$context->getRequest()（它由当前验证上下文提供，更可靠） - 若必须访问全局服务（如
Security或TokenStorage），确保它们本身支持请求作用域（Symfony 5.4+ 默认启用requestscope，但需确认你的服务定义没写成singleton）
示例修复前（危险）：
class MyCustomValidator extends ConstraintValidator
{
private Request $request;
public function __construct(RequestStack $stack)
{
$this->request = $stack->getCurrentRequest(); // ❌ 错！只在构造时取一次
}
public function validate($value, Constraint $constraint): void
{
// 后续全用 $this->request，但它是上个请求的
}
}
修复后（安全）：
class MyCustomValidator extends ConstraintValidator
{
public function validate($value, Constraint $constraint): void
{
$request = $this->context->getRequest(); // ✅ 每次都取当前请求
if (!$request) {
return;
}
// ...
}
}
别漏掉框架层的隐性依赖
有些验证逻辑看似不碰请求，实则间接依赖。比如：
- 使用
@Assert\NotBlank(groups={"api"})+Validation::createValidatorBuilder()->enableAnnotationMapping()->setConstraintValidatorFactory(...)手动构建验证器时，未传入新的RequestContext - 在控制器中手动调用
$validator->validate($data)，但$validator是从容器直接拿的，而容器在 worker 中未刷新作用域 - Symfony 的
Form组件在 worker 下可能复用旧的ResolvedFormType缓存，导致验证器绑定错乱（尤其当 form type 依赖Request构建时）
最稳妥的做法：在 worker 入口脚本（如 frankenphp-worker.php）中，每次处理新请求前，显式调用 $container->reset()（如果使用 Symfony 6.2+ 的 ResettableServiceInterface）或至少重置 RequestStack 和 ValidatorInterface 相关服务。
真正难调试的从来不是报错，而是“看起来没报错却总不对”——FrankenPHP 的 worker 模式让这类状态污染变得隐蔽。只要记住一点：**任何被复用的 PHP 对象，都不再天然拥有“本次请求”的上下文，必须显式获取、显式清理。**
