最常用且可控的方式是用switch或if-else按整型用户等级（1：普通，2：VIP，3：SVIP）做条件判断，需类型断言、默认兜底、严格in_array、SQL层CASE WHEN过滤、缓存键含等级维度。
PHP中用switch或if-else实现等级分流逻辑
直接按用户等级决定能看什么视频，最常用也最可控的方式就是条件判断。别用模糊的“权限系统”套话，先跑通核心分支逻辑再说。
常见错误是把等级字段当字符串硬比对，比如$user['level'] === 'vip'，但数据库里可能存的是整数2或枚举值'premium'，导致永远进不到case里。
- 统一用整型等级（如
1：普通，2：VIP，3：SVIP），避免字符串歧义 - 查库后立刻做类型断言：
$level = (int)$user['level']; - 默认兜底逻辑必须存在，比如未登录用户或等级异常时返回空列表或提示
switch ($level) {
case 3:
$videoIds = getVideosByTag('exclusive');
break;
case 2:
$videoIds = array_merge(
getVideosByTag('vip'),
getVideosByTag('public')
);
break;
default:
$videoIds = getVideosByTag('public');
}
用in_array()快速匹配多等级共享资源
有些视频不是“独享”，而是“某几个等级都能看”，比如广告片对所有等级开放，纪录片只对2和3开放——这时候硬写多个if太啰嗦，用数组+in_array()更干净。
注意别漏掉类型严格比较。如果$level是字符串'2'，而$allowedLevels是[2, 3]，in_array($level, $allowedLevels)会返回true（PHP弱类型自动转换），但这是隐患，应显式转成同类型。
立即学习“PHP免费学习笔记（深入）”；
- 始终用
in_array($level, $allowedLevels, true)开启严格模式 - 配置表里把“可见等级”存成JSON数组，读出来后
json_decode($row['allowed_levels'], true) - 避免在循环里反复调用
in_array()，可提前构建$canWatch[$videoId] = true映射表
MySQL联查时用CASE WHEN在SQL层过滤
如果视频量大、等级规则固定，把分配逻辑下推到数据库，比PHP循环判断更省资源。特别是首页瀑布流要一次拉10条不同等级的视频时，靠PHP筛容易超时或OOM。
典型翻车点：在WHERE里写level >= :user_level看似简洁，但实际业务中往往不是线性关系（比如SVIP能看A/B/C，VIP只能看B/C，普通只能看C），纯数值比较会越权。
- 用
CASE WHEN构造布尔列：CASE WHEN u.level IN (2,3) AND v.tag = 'vip' THEN 1 WHEN u.level = 1 AND v.tag = 'public' THEN 1 ELSE 0 END AS can_view - 查询时加
AND can_view = 1（需包装成子查询或使用HAVING） - 给
videos.tag和users.level建联合索引，否则CASE再快也救不了全表扫描
缓存策略必须区分user_level维度
很多人把视频列表整个缓存成video_list_home，结果VIP用户刷出普通用户的内容，或者缓存过期后没按等级重建——根本原因是没把user_level作为缓存键的一部分。
另一个坑是用Redis的SET存视频ID列表，但不同等级的列表互相覆盖。比如cache:videos:2和cache:videos:3必须隔离。
- 缓存键格式强制包含等级：
"videos:list:{$level}:{$page}" - 更新视频时，要批量删掉所有等级相关的缓存：
cache:videos:*:*（用SCAN+DEL） - 不要用
serialize()存数组再unserialize()，改用json_encode()/json_decode()，避免PHP版本升级导致反序列化失败
等级分配看着简单，真正上线后最麻烦的不是逻辑写不对，而是缓存没拆开、SQL没走索引、等级字段类型不一致这三件事。盯住这几个点，比堆功能重要得多。
