Hyperf是运行在常驻内存协程环境中的全新架构体系，核心在于理清“谁启动、谁调度、谁通信、谁持久”四角色；启动由bin/hyperf.php入口经bootstrap.php初始化中枢完成；src按能力中心化组织，Controller仅负责请求响应，业务逻辑交由Service封装；配置全由config/autoload驱动；通信依赖协程非阻塞I/O与连接池。
Hyperf不是“升级版PHP-FPM”，而是一套运行在常驻内存协程环境中的全新架构体系。理解它，关键不在记目录，而在理清“谁启动、谁调度、谁通信、谁持久”这四个角色。
启动入口：从 bin/hyperf.php 到 bootstrap.php
项目启动命令 php bin/hyperf.php start 看似简单，实际会依次执行：
- 加载 bin/hyperf.php —— 命令行入口，解析参数并调用框架启动器
- 执行 bootstrap.php —— 真正的初始化中枢，注册自动加载、容器、事件循环、配置管理等核心服务
- 最终拉起 Swoole 或 Swow 服务器进程，进入协程事件循环
你不需要改 bootstrap.php，但得知道：所有自定义初始化逻辑（如全局上下文预设、连接池预热）都应通过 服务提供者（ServiceProvider） 注入，而非硬写在这里。
核心分层：src 目录不是“MVC三件套”，而是“能力中心化”
Hyperf 的 src/ 结构按职责而非传统分层组织：
- Controller：只做请求接收与响应组装，不处理业务；依赖注入的服务对象才承担领域逻辑
- Service（建议手动建）：封装可复用的业务能力，比如 UserService、OrderProcessor
- Model / Repository：ORM 层或数据访问抽象，与数据库强关联，但不直接暴露给 Controller
- Aspect / Listener / Command：分别对应 AOP 切面、事件监听、CLI 工具——它们是解耦和扩展的关键支点
没有强制目录名，但推荐按功能边界建目录，例如 src/Order 下放 OrderService、OrderRepository、OrderPaidListener 等，保持领域内聚。
配置驱动：config/autoload 是“系统说明书”，不是“开关列表”
Hyperf 所有行为都由 config/autoload/ 下的 PHP 或 YAML 文件定义，常见且关键的有：
- app.php：设置应用模式（dev/prod）、时区、异常处理器、扫描路径等基础行为
- http-server.php：控制 Swoole HTTP 服务端口、进程数、静态资源、超时等
- database.php：不只是数据库连接，还定义了连接池大小、读写分离、默认查询选项
- redis.php 和 cache.php：明确区分 Redis 实例用途（缓存/队列/锁），避免混用导致连接池争抢
生产环境务必开启 注解缓存（annotations.scan.cacheable => true），否则每次请求都会重复解析注解，性能断崖式下跌。
通信机制：协程 + 连接池 = 非阻塞高并发的底层保障
Hyperf 的高性能不来自“写得快”，而来自“等得少”。它的通信模型特点是：
- HTTP 请求、Redis 操作、MySQL 查询、HTTP 客户端调用，全部走协程非阻塞 I/O
- 每个组件（DB、Redis、HTTP Client）自带连接池，默认启用；池大小需按压测结果调整，不能盲目堆大
- 协程间不共享可变状态，如需传递数据，用 Hyperf\Utils\Context::set/get 存取当前协程上下文
- 切忌在协程中调用 sleep()、file_get_contents()、pdo->query() 等同步阻塞函数，会卡死整个 Worker 进程
初学者最容易踩的坑，就是把 FPM 下的“顺序思维”直接搬进协程环境——记住：在 Hyperf 里，等待不是暂停，而是让出 CPU 给其他协程继续跑。
