ThinkPHP文章草稿箱实现方法详解

草稿应存数据库而非缓存，因缓存易丢失；推荐与正式文章共用表，用status字段区分状态，并通过id判断新增或更新，配合服务端限频（cache锁10秒）和前端防抖（1500ms），登录态强制绑定，游客草稿需用guest_token持久化并提供手动合并入口。

草稿数据该存数据库还是缓存？

直接存数据库最稳妥，别被“临时”二字误导。ThinkPHP 的 session 或 cache 存草稿容易丢——用户换设备、清浏览器、缓存过期或服务端清理都会导致草稿消失。真实场景中，用户写 20 分钟后切屏回来看到空白，基本等于流失。

推荐做法是：草稿和正式文章共用一张表（如 article），靠字段区分状态：

• status 设为 'draft'（字符串）或 0（整型），发布时再改为 'published' 或 1
• 加 is_draft 布尔字段也行，但注意 MySQL 5.7+ 才原生支持 TINYINT(1) 当布尔用，否则查出来是数字
• 避免用单独的 draft 表——后期要合并、预览、定时清理都多一层 join 和逻辑

如何避免重复保存覆盖草稿？

用户边写边点“保存草稿”，如果每次都是 save() 全量更新，可能把中途删掉的内容又刷回来。关键是识别“谁在编辑这篇草稿”。

ThinkPHP 6+ 推荐用以下组合策略：

• 前端每次保存时带上当前草稿的 id（新增草稿则传 null 或空字符串）
• 后端判断：if ($data['id']) { Article::update($data); } else { Article::create(array_merge($data, ['status' => 'draft'])); }
• 加个 updated_at 字段自动更新，再加个 last_edit_ip 字段记录最后编辑 IP，方便排查冲突
• 不要依赖前端传来的 created_at，一律由服务端用 date('Y-m-d H:i:s') 或 time() 写入

自动保存草稿的接口怎么防抖和限频？

前端用 setInterval 每 30 秒发一次草稿请求，后端不做限制的话，用户切到别的标签页再切回来，可能瞬间触发多次请求，造成冗余写入甚至死锁。

简单有效的服务端控制方式：

• 在控制器里加基础限频：用 cache('draft_lock_' . $userId, $draftId, 10)，10 秒内只允许一次写入，命中则直接返回成功（不真写库）
• 前端也要做防抖：clearTimeout(saveTimer); saveTimer = setTimeout(submitDraft, 1500);
• 接口返回值必须包含 saved_at 时间戳，前端比对上一次响应时间，避免“以为没保存成功”而反复点
• 别用 lockTable() —— 草稿写入不是强事务场景，锁表反而拖慢其他请求

用户退出登录后草稿还能找回吗？

不能默认找回。ThinkPHP 的 session 绑定登录态，登出即销毁；cache 若用文件驱动，也随 session 清除；Redis 驱动虽可独立，但没绑定用户 ID 就没法区分。

真正可行的方案只有两个：

• 强制登录后才能写草稿（推荐）。在中间件里拦截未登录用户的 /api/draft/save 请求，返回 401
• 若真要支持游客草稿，必须用持久化手段：把草稿存在数据库，用随机生成的 guest_token（如 md5(uniqid() . $_SERVER['REMOTE_ADDR'])）关联，并存进 cookie（带 HttpOnly=false，前端能读），用户注册/登录后再把 guest_token 对应的草稿迁移到其账号下

这个迁移动作容易漏掉——比如用户先用手机号注册，又用微信登录，得在用户中心提供“合并历史草稿”手动入口，不然数据就卡在那儿了。