原因
hyperf框架为了防止用户更新组件后，代理缓存没有更新导致启动报错。增加了以下钩子。
而init-proxy.sh脚本，会执行php bin/hyperf.php di:init-proxy命令清理代理缓存，并重新生成。
$ composer init-proxy
> init-proxy.sh
../../
runtime cleared
scanning app …
scan app completed, took 195.76692581177 milliseconds.
scanning vendor …
scan vendor completed, took 510.0839138031 milliseconds.
this command does not clear the runtime cache, if you want to delete them, use `vendor/bin/init-proxy.sh` instead.
proxy class create success.
finish!
上述演示中，我们很清楚的可以看到花费的时间，现在不足1s其实还可以接受。但如果您的模型非常多，这个时间可能会是无法忍受的一个点。比如以下情况。
$ composer init-proxy
> init-proxy.sh
../../
runtime cleared
scanning app …
scan app completed, took 3063.5998249054 milliseconds.
scanning vendor …
scan vendor completed, took 490.39006233215 milliseconds.
this command does not clear the runtime cache, if you want to delete them, use `vendor/bin/init-proxy.sh` instead.
proxy class create success.
finish!
解决办法
以下解决办法建立在正确使用 model 的基础上。比如不在 model 中使用注解。检测办法是，不排除 model 目录的情况下生成一下代理缓存，查看是否生成 model 相关的代理。
所以，我们可以主动修改hyperf框架的扫描目录，排除掉模型目录。让我们写一段逻辑，修改annotations.php。
当我们再执行命令时，就会发现时间被大大缩短。
写在最后
hyperf 是基于 swoole 4.4+ 实现的高性能、高灵活性的 php 协程框架，内置协程服务器及大量常用的组件，性能较传统基于 php-fpm 的框架有质的提升，提供超高性能的同时，也保持着极其灵活的可扩展性，标准组件均基于 psr 标准 实现，基于强大的依赖注入设计，保证了绝大部分组件或类都是 可替换 与 可复用 的。
框架组件库除了常见的协程版的 mysql 客户端、redis 客户端，还为您准备了协程版的 eloquent orm、websocket 服务端及客户端、json rpc 服务端及客户端、grpc 服务端及客户端、zipkin/jaeger (opentracing) 客户端、guzzle http 客户端、elasticsearch 客户端、consul 客户端、etcd 客户端、amqp 组件、apollo 配置中心、阿里云 acm 应用配置管理、etcd 配置中心、基于令牌桶算法的限流器、通用连接池、熔断器、swagger 文档生成、swoole tracker、blade 和 smarty 视图引擎、snowflake 全局 id 生成器 等组件，省去了自己实现对应协程版本的麻烦。
hyperf 还提供了 基于 psr-11 的依赖注入容器、注解、aop 面向切面编程、基于 psr-15 的中间件、自定义进程、基于 psr-14 的事件管理器、redis/rabbitmq 消息队列、自动模型缓存、基于 psr-16 的缓存、crontab 秒级定时任务、translation 国际化、validation 验证器 等非常便捷的功能，满足丰富的技术场景和业务场景，开箱即用。
以上就是浅谈减少hyperf框架的扫描时间的详细内容，更多关于减少hyperf框架的扫描时间的资料请关注www.887551.com其它相关文章！
