问题（简而言之）是：
我们目前的解决方案太慢了。
- Symfony安全组件在每个页面浏览量上重新加载用户。
- 用户是从我们自己的访问慢速外部 API 的用户提供程序加载的。
我们想到的第一个想法是：
我们可以将来自外部 API 的信息缓存在本地数据库或内存缓存中。
我的问题：
- 是否有任何捆绑包可以帮助我们实现这一目标？
- 我们应该处理我们自己的用户提供程序中的所有缓存吗？ 将需要
- 缓存的用户放入 doctrine 实体并使用链提供程序首先从 doctrine 加载它们是否是一个更好的主意？在这种情况下，我们如何处理有限的用户对象的生存期？
- 如何不缓存任何内容，而只是编写我们的提供程序刷新函数，以便仅在上次重新加载发生太久时才重新加载用户？
关于如何有效地做到这一点还有其他想法吗？
干杯
丁满
缓存
和链式提供程序都不是"完美"的解决方案，因为您必须实现在外部提供程序发生更改（例如更改密码）时使用户无效的逻辑。如果我理解正确，这将要求您经常检查 API。似乎您必须以一种或另一种方式在性能和频繁检查更新之间做出妥协。
话虽如此，我假设您已经有一个通过 API 读取用户的自定义用户提供程序，我认为添加缓存作为依赖项没有任何问题，或者在您的 UserProvider 旁边创建第二个 CacheApiUserProvider，因此您可以在缓存后端遇到问题时在它们之间切换。我认为不需要额外的捆绑包，但您可能想寻找缓存包。
我不明白您在 （3） 中建议的链式提供程序会如何帮助您，因为您只会有相同的限制，即经常检查外部提供程序中的更改，就像缓存一样。如果我必须选择，我会使用 CachedProvider，因为它几乎是您要做的，更复杂的链提供程序只会隐藏您首先要解决的问题并混淆未来的维护者（简而言之：保持简单）。
根据 API 提供的内容，您可能能够在后台运行一个 worker ，它会自动从 API 获取新用户和对现有用户的更改，并将其移动到（本地）数据库，但在这种情况下，我不会费心设置链式提供程序，而只是依靠数据库来保持最新。