核心问题是长轮询失败导致配置未及时接收或应用：需检查日志中“Long polling failed”信号、pullTimeout与proxy_read_timeout是否≥30秒、interval设为5～10、APOLLO_SERVER指向ConfigService、strict_mode=true验证namespace是否存在、listeners.php注册两个监听器，并避免@Value注入导致的假性失效。
Hyperf 3.1 接入 Apollo 后配置变更不生效，核心问题通常不在“没推”而在“没收到”或“收到但没应用”。排查需聚焦客户端行为，而非服务端配置是否修改成功。
检查长轮询是否真正工作
Hyperf 的 hyperf/config-apollo 默认启用 LONG_POLLING 模式。一旦长轮询失败（如返回 504），会退回到低频被动轮询甚至暂停监听，导致更新延迟甚至卡死。
- 查看日志中是否有
Long polling failed, will retry in X seconds—— 这是关键信号 - 确认
apollo.php中pullTimeout≤ 服务端超时（Apollo 默认 30 秒），且反向代理（Nginx/网关）的proxy_read_timeout ≥ 30 -
interval不建议设为 0 或 1；设为 5～10 更稳妥，避免 fallback 阶段高频刷请求 - 确保
APOLLO_SERVER指向 ConfigService 地址（如http://config.xxx.com），不是 Portal 或 Admin 地址
验证配置是否已加载进内存
热更新失效，很多时候是 config() 读的仍是旧快照，而非 Apollo 没推送。
- 在代码中加
var_dump(config()->get('apollo.last_sync_time'));，看时间戳是否随 Apollo 控制台变更而更新 - 直接查具体 key：
config('database.default.host')，对比 Apollo 控制台值是否一致 - 检查
listeners.php是否注册了两个必需监听器：Hyperf\ConfigApollo\Listener\FetchConfigOnBootListener（启动拉取）Hyperf\ConfigApollo\Listener\OnPipeMessageListener（Worker 间同步）
确认 strict_mode 和 namespace 是否匹配
当 Apollo 中某个 namespace（如 redis.yml）不存在、拼写错误或权限不足时，strict_mode = false 会让驱动静默跳过，不报错也不加载 —— 表现为“改了没反应”，但日志毫无提示。
- 上线前临时将
strict_mode设为true，启动时立即暴露缺失的 namespace - 核对
apollo.php中namespaces数组与 Apollo 控制台实际存在的 namespace 完全一致（注意大小写和后缀） - 确认应用启动时加载的 namespace 是目标环境（如
application或prod），而非默认的dev
排除注解/注入方式导致的假性失效
Hyperf 的 @Value 或构造函数注入字段，在 Bean 初始化后就固化，Apollo 变更不会自动刷新该字段值 —— 这不是 Apollo 的问题，而是使用方式问题。
- 不要用
@Value("${xxx}")注入到类属性并期望它动态变；应改用config('xxx')在方法内实时读取 - 若必须用注解绑定，确保所在类被
@RefreshScope包裹（Hyperf 本身不原生支持该注解，需自行适配或避免） - 检查是否误把配置写在
application.yml里覆盖了 Apollo 值（优先级：本地 yml > Apollo）
