Yii2 中实现 URL 页面级独占访问控制（单用户锁定机制）

本文介绍如何在 yii2 框架中实现“同一 url 仅允许一名已登录用户实时访问”的独占锁机制，通过服务端状态管理（如缓存+心跳+超时清理）替代简单 session 标记，确保浏览器意外关闭、页面跳转或网络中断等场景下锁能及时释放。

在开发后台管理系统或在线协同编辑这类功能时，我们常常会遇到一个棘手的问题：如何确保某个特定的编辑页面（比如 `/post/update?id=123`）在同一时间只被一位用户操作？

简单粗暴地用 Session 标记一下？这招看似方便，实则埋下了大坑。想想看，如果用户编辑到一半，直接关了浏览器标签，或者网络突然中断，那个标记着“正在编辑”的 Session 并不会自动消失。结果就是，这个页面会被一直“锁死”，其他用户再也无法进入，直到 Session 过期——这体验可就太糟糕了。

问题的核心在于，服务端必须能实时感知用户是否真的还在这个页面上活跃操作，而不是仅仅知道他登录过。这就需要一套更聪明的机制。

1. 定义唯一资源锁键名

首先，得给我们要保护的资源（也就是那个URL）起个独一无二的名字，作为锁的标识。通常，我们会结合控制器、动作和关键参数来生成。

$resourceId = 'post_update_' . (int) Yii::$app->request->get('id'); // → 'post_update_123'
$lockKey = 'url_lock_' . md5($resourceId);

2. 在控制器操作前检查并加锁

接下来，在用户试图进入编辑页面（例如 `PostController::actionUpdate()`）时，我们就得先检查这把“锁”。

public function actionUpdate($id)
{
    $lockKey = 'url_lock_post_update_' . (int)$id;
    $currentUser = Yii::$app->user->id;

    // 先看看锁被谁拿着，并且这个锁30秒后会自动失效（防止死锁）
    $lockedBy = Yii::$app->cache->get($lockKey);

    if ($lockedBy !== false && $lockedBy != $currentUser) {
        // 锁被别人占着，那就友好地提示一下，并跳转
        Yii::$app->session->setFlash('error', '该内容正由其他用户编辑中，请稍后再试。');
        return $this->redirect(['index']);
    }

    // 顺利拿到锁（或者锁是空的），把自己的ID放进去，设置30秒有效期
    Yii::$app->cache->set($lockKey, $currentUser, 30);

    // 关键一步：通知前端开始“心跳”保活（后面会讲）
    return $this->render('update', ['model' => $model]);
}

这里用到了 Yii2 的 Cache 组件（推荐配置成 Redis 或 Memcached），它天然支持设置过期时间（TTL），是我们实现自动释放锁的基石。

3. 前端心跳保活（防止误释放）

锁是加上了，但用户可能在页面里编辑很久，30秒到了锁不就自动没了吗？所以，我们需要前端页面定期向服务器“报平安”，告诉服务器：“我还在呢，别把锁收了”。

4. 后端心跳与释放接口（SiteController）

前端的心跳和释放请求，需要后端对应的接口来处理。

public function actionKeepAlive()
{
    if (!Yii::$app->user->isGuest) {
        $lockKey = Yii::$app->request->post('lock_key');
        // 收到心跳，就把对应锁的过期时间重置为30秒后
        Yii::$app->cache->set($lockKey, Yii::$app->user->id, 30);
    }
}

public function actionReleaseLock()
{
    if (!Yii::$app->user->isGuest) {
        $lockKey = Yii::$app->request->post('lock_key');
        // 保险起见：只有当前用户是锁的持有者时，才允许释放
        if (Yii::$app->cache->get($lockKey) == Yii::$app->user->id) {
            Yii::$app->cache->delete($lockKey);
        }
    }
}

⚠️ 注意事项与最佳实践

方案看似清晰，但魔鬼藏在细节里。有几个关键点必须把握好：

• 彻底告别 Session 存锁：牢记，Session 的生命周期不等于页面活跃期。它无法解决跨标签页、浏览器崩溃等场景的锁释放问题，分布式环境下更是力不从心。
• TTL 时长是门艺术：30秒是个经验值，平衡了响应性和容错性。设太短，心跳压力大且容易误释放；设太长，用户离开后锁占用时间过久。需要根据实际业务网络环境调整。
• 锁键必须全局唯一：确保你的锁键生成规则能精确到具体资源。避免 `post/update?id=123` 和 `user/update?id=123` 因为ID相同而产生冲突。
• 前端要做优雅降级：心跳可能因为网络问题失败。一旦失败，前端应该提示用户“连接已断开，编辑内容可能无法保存”，并禁用提交按钮，引导用户刷新或重新进入。
• 高并发场景的进阶考量：在极端高并发下，检查锁和设置锁的两个操作可能不是原子的。如果追求极致可靠，可以考虑利用 Redis 的 `SET key value EX 30 NX` 这类原子指令来实现，这可能需要你自定义或扩展 Yii2 的 Cache 组件。

总的来说，这套“缓存锁 + 心跳续期 + 超时兜底”的组合拳，真正做到了“用户在线即独占，用户离开即释放”。它既保证了协同操作时的数据安全，又避免了因意外情况导致的资源长期锁死，在后台编辑、在线考试、限量抢购等需要强互斥控制的场景中，是一个非常稳健的解决方案。