PHP配置热更新需主动检查+缓存失效+按需重载协同；opcache_invalidate()仅对已加载文件生效，路径须绝对且需验证是否在opcache_scripts中，filemtime()需配合clearstatcache(true, $path)防缓存延迟，Redis配置中心应设本地TTL短于Redis过期时间并fail-safe保留旧值。
PHP配置热更新不是“改完就生效”，而是靠主动检查+缓存失效+按需重载三步协同；直接改文件不触发重载，90%的问题出在没清OPcache或没验证文件是否真被加载过。
opcache_invalidate() 为什么调了却没用
它只对已进入OPcache的文件起效，没被加载过的文件调用等于白调。常见错误包括路径写错、相对路径未转绝对路径、或文件根本不在opcache_get_status()['scripts']列表里。
- 先确认文件是否在缓存中：
opcache_get_status()['scripts']['/abs/path/to/config.php']存在才说明已被加载 - 路径必须是绝对路径，
__DIR__ . '/config.php'比'config.php'可靠 - 调用后立刻
var_dump(opcache_is_script_cached('/abs/path/to/config.php'))验证是否真失效 - 如果 config.php 里
require了其他文件，那些文件不会自动失效，得单独调用opcache_invalidate()
filemtime() + clearstatcache() 组合为什么还是延迟生效
Linux 文件系统和 PHP 自身都有 stat 缓存，filemtime() 返回的可能是旧时间戳，尤其在高并发或 NFS 环境下更明显。
- 每次调用前必须加
clearstatcache(true, $filepath)，不能只用clearstatcache() - 避免高频轮询（如每 100ms 查一次），建议开发环境设为 1–2 秒检查间隔，生产环境改用 Redis 或 inotify 推送
- vim 编辑会先写临时文件再 rename，所以监听要覆盖
IN_MOVED_TO和IN_CREATE，不能只盯IN_MODIFY - 如果用 Docker，宿主机改文件，容器内可能因挂载方式不同导致
filemtime()不刷新，优先走 inotify 或配置中心
Redis 配置中心怎么避免本地缓存 stale
本地缓存 TTL 和 Redis 过期时间不同步，或网络抖动导致 refresh 失败，都会让配置卡在旧值上。
立即学习“PHP免费学习笔记（深入）”；
- 本地缓存 TTL 必须短于 Redis key 的过期时间，比如 Redis 设
EX 300，PHP 本地设$ttl = 20 -
refresh()失败时不要清空本地缓存，保留旧值继续用（fail-safe），同时记录 error_log - 用
hGetAll('app:config')而非单个get()，减少网络往返；但要注意 hash field 数量大时响应变慢 - 发布变更时，用
PUBLISH config:updated 'app:config'，订阅端收到后立即hGetAll()全量刷新，不依赖 TTL
inotify 监听配置文件的实际坑点
inotify 不是万能监听器，它只通知“变了”，不保证你能安全重载——尤其在多进程 FPM 下，每个 worker 都要各自 reload，否则只有部分进程生效。
- 必须手动编译安装，PHP 8.0+ 要指定
pecl install inotify-3.0.0，Alpine 需先apk add inotify-tools-dev -
inotify_init()返回的 fd 是阻塞的，别裸写while (true) { inotify_read($fd); }，要用stream_set_blocking($fd, false)+stream_select()配合事件循环 - 监听目录比监听单文件更稳，但要注意
IN_IGNORED事件：当 watch 被移除（比如进程退出），后续事件不再触发 - 每次
require_once前必须opcache_invalidate($file, true)，否则 OPcache 仍返回旧 opcode
真正难的不是“怎么触发重载”，而是“重载后状态是否一致”：DB 连接要不要重连、全局变量要不要重置、单例对象要不要重建——这些全得在重载逻辑里显式处理，没人替你兜底。
