推荐不继承 entityrepository，而是定义普通服务类并注入 entitymanagerinterface 或 userrepository；需在容器中注册服务、避免 getrepository() 动态调用以确保 phpstan 类型推断准确。
自定义 Doctrine 仓库类的基本写法
Doctrine 默认为每个实体生成一个 EntityRepository 实例，但业务逻辑复杂时，你需要自己的仓库类。标准做法是继承 Doctrine\ORM\EntityRepository，并确保在实体映射中明确指定该类：
- 创建仓库类，例如
App\Repository\UserRepository，继承EntityRepository - 在实体的注解、YAML 或 XML 映射中设置
repositoryClass，如：@ORM\Entity(repositoryClass="App\Repository\UserRepository") - 仓库类中可添加自定义方法，比如
findActiveUsers()，内部使用$this->createQueryBuilder()或原生 DQL
在自定义仓库中注入服务（如文件上传器）
Symfony 2.7+ 支持直接在仓库构造函数中注入依赖，但需注意：Doctrine 不会自动调用带额外参数的构造函数。必须通过 Symfony 的 DI 容器显式配置服务，否则会报错“Too few arguments”。
- 定义仓库类时保留父类两个必需参数（
EntityManager和ClassMetadata），再追加你的依赖，例如FileUploader $uploader - 在
services.yaml中将仓库声明为服务，并使用bind或内联参数传递依赖：App\Repository\UserRepository:<br> arguments:<br> $em: '@doctrine.orm.default_entity_manager'<br> $class: 'App\Entity\User'<br> $uploader: '@App\Service\FileUploader'
- 确保实体映射仍指向该类，Doctrine 会跳过自动实例化，改由容器提供实例
与 Symfony 服务容器深度集成（推荐方式）
比起手动管理仓库生命周期，更现代、更安全的做法是**不继承 EntityRepository，而是直接定义普通服务类**，并在其中注入 EntityManagerInterface 或具体仓库实例。
- 新建服务类，如
App\Repository\UserRepositoryService，不继承任何 Doctrine 类 - 在构造函数中接收
UserRepository $userRepository（类型提示明确）或EntityManagerInterface $em - 方法中调用
$userRepository->customMethod()或$em->getRepository(User::class)->... - 该方式天然兼容 PHPStan/PSALM —— 类型完全可推断，无需注解或扩展
配合 PHPStan 消除“未定义方法”误报
即使你写了 UserRepository 并设置了 repositoryClass，PHPStan 默认仍把 $em->getRepository(User::class) 当作 EntityRepository，导致调用自定义方法时报错。
- 最有效解法：避免调用
getRepository()，改为直接依赖注入UserRepository类型参数 - 确保该仓库已在容器中注册为服务（Symfony 自动完成，前提是类名匹配且启用 autowire）
- 如必须动态获取，可用 PHPDoc 注解临时提示：
/** @var UserRepository $repo */<br>$repo = $em->getRepository(User::class);
- 不建议依赖
phpstan-doctrine扩展来“猜”返回类型——它对自定义repositoryClass支持有限，稳定性不如显式注入
