ThinkPHP前后端分离数据不更新的核心原因是多层缓存叠加及请求路径绕过框架逻辑导致缓存失效机制失灵，涉及数据库字段缓存、OPcache、Redis、反向代理和浏览器缓存五类问题。
ThinkPHP 前后端分离场景下数据不更新，核心问题不是“缓存没清”，而是多层缓存叠加 + 请求路径绕过框架逻辑导致缓存失效机制失灵。前后端分离通常意味着接口由 ThinkPHP 提供（如 /api/user），前端走 AJAX 或 Vue/React 调用，此时模板缓存、HTML 静态缓存基本无关，但数据库字段缓存、OPcache、Redis 缓存、反向代理缓存和浏览器缓存反而更易被忽略。
检查数据库字段缓存是否锁定旧结构
前后端分离项目常频繁调整 API 返回字段（比如新增 avatar_url），但 ThinkPHP 默认在生产环境缓存表结构，导致 Db::name('user')->field('id,name,avatar_url') 仍按旧字段列表查询，甚至报错或静默丢弃新字段。
- 开发阶段直接关闭：在
config/database.php中设'fields_cache' => false - 上线后若需性能优化，每次执行 SQL 变更（如
ALTER TABLE user ADD avatar_url VARCHAR(255)）后，必须运行：php think clear或手动删runtime/schema/下对应表的缓存文件 - 代码中可主动刷新：
\think\facade\Db::clearCache()（全库）或\think\facade\Db::table('user')->getFieldsType()（单表）
确认接口响应是否被 OPcache 或反向代理缓存
前后端分离时，/api/xxx 接口返回 JSON，但 Nginx 的 fastcgi_cache 或 Cloudflare 可能把它当成静态内容缓存了——表现为改了控制器逻辑、加了 dump() 也不输出，连日志都不写。
- 查 Nginx 配置：搜索
fastcgi_cache、fastcgi_cache_valid 200 10m等，临时注释并nginx -s reload - 查 PHP OPCache：确保
opcache.validate_timestamps = 1（开发必开），否则改完接口代码也不生效；可临时加opcache_reset();到入口或独立路由 - 验证方式：用 curl 加唯一参数测试，如
curl "http://localhost/api/user?_t=123456"，若带参数变、不带不变，就是代理层缓存
排查 Redis / 文件缓存中的业务数据未更新
前后端分离常用缓存存储接口结果（如 cache('api_user_list', $data, 3600)），但更新时若只改数据库不删缓存，前端永远拿不到新数据。
立即学习“PHP免费学习笔记（深入）”；
- 避免“写数据库就完事”：用户资料更新后，必须同步清除对应缓存键，例如
cache('api_user_'.$uid, null)或Cache::tag('user_api')->clear() - 标签清除要严谨：用
Cache::tag('user_api')->set('profile_'.$uid, $data)写入，才可用Cache::tag('user_api')->clear()批量清理；拼错标签名（如大小写、冒号）会完全失效 - 调试实招：在接口开头加
dump(cache('api_user_list'));，看读到的是不是预期值，比猜更准
前端请求被浏览器强缓存干扰
浏览器对 GET 接口默认启用缓存，尤其 Chrome 对 /api/list 这类无参数路径缓存极深，哪怕后端已改，F5 刷新也无效。
- 后端统一加响应头（推荐）：
header('Cache-Control: no-store, no-cache, must-revalidate, max-age=0'); - 前端 fetch 时禁用缓存：
fetch('/api/user', { cache: 'no-store' }) - 快速验证法：在 URL 后加时间戳参数，如
/api/user?t=1722347760，若此时数据更新，说明就是浏览器缓存问题
