用用户流程图检查注册到下载的完整体验

先别急着画流程图。注册到下载这条链路，真正的难点不在页面跳转，而在状态切换：注册后是否自动登录，登录态多久失效，无权限用户看到什么，下载请求由谁校验。任何一个环节判断错，用户就会卡在“明明点了按钮却没反应”的处境里。流程图的价值，是把这些状态变化提前摆到桌面上，而不是把页面名称连成一条好看的线。

先分清路径，再谈优化

检查这条链路，第一步不是打开编辑器，而是把用户分成几类：访客、刚注册的用户、已登录但权限不足的用户、权限过期的用户。每一类人走完注册到下载的路径，结果应该完全不同。访客看到下载按钮，要么被引导去注册，要么被明确告知需要登录；刚注册的用户如果系统没有自动登录，就应该看到登录页而不是直接跳回下载页——很多项目在这里断掉，用户注册完以为自己已经登录，点下载又被弹回登录页，来回两次就放弃了。

判断标准很简单：把每条路径的终点写出来。访客的终点是注册页还是登录提示，注册成功后的终点是下载页还是个人中心，VIP用户下载时如果权限校验失败，是看到错误提示还是被静默拦截。写不清楚的地方，就是需要补流程图的地方。

权限校验要放在服务端

下载功能最容易出的问题，是前端隐藏了下载按钮就以为安全了。实际上，只要接口地址暴露，任何人都能直接构造请求。权限判断必须放在服务端，而且不能只判断“是否登录”，还要判断“是否有权下载这个文件”。

一个常见的错误是只校验登录状态，不校验资源归属。假设页面里有一个下载按钮，点击后请求 download.php?file=xxx，服务端只检查了 isset($_SESSION['user_id'])，那么任何一个登录用户都可以把 file 参数改成其他文件的名字，直接下载本不该访问的内容。正确的做法是，在服务端先确认文件与当前用户的权限关系，再决定是否输出文件流。

```php
// 下载前必须校验：用户已登录 + 该资源对当前用户可见
session_start();
if (empty($_SESSION['user_id'])) {
header('Location: login.php?redirect=download.php?id=' . (int)$_GET['id']);
exit;
}

$resourceId = (int)$_GET['id'];
$userId = (int)$_SESSION['user_id'];

// 查询资源状态与可见范围，而不是直接拼接文件路径
$stmt = $pdo->prepare('SELECT file_path, is_vip_only FROM resources WHERE id = ? AND status = 1');
$stmt->execute([$resourceId]);
$resource = $stmt->fetch();

if (!$resource) {
exit('资源不存在或已下架');
}

if ($resource['is_vip_only'] && !checkUserIsVip($userId)) {
exit('该资源仅对VIP用户开放');
}

// 通过校验后再发送文件
header('Content-Type: application/octet-stream');
header('Content-Disposition: attachment; filename="' . basename($resource['file_path']) . '"');
readfile($resource['file_path']);
```

这段逻辑里有两个容易漏掉的地方。一是 $_GET['id'] 必须做整型转换，否则可能引入注入风险；二是文件路径不要直接由用户参数拼接，应该先查数据库拿到真实路径，再判断权限。如果资源表里没有 is_vip_only 这样的字段，说明权限模型还没建完整，这时候先补数据结构，再写下载逻辑。

注册后的登录态处理

注册接口写完，要立刻确认一件事：注册成功后，用户到底处于什么状态。有的系统注册后直接写入 session，用户不需要再登录一次；有的系统注册后跳转到登录页，要求用户用刚设置的密码登录。两种做法都可行，但必须前后端一致。

最容易出问题的是“注册成功但 session 没写”的半吊子状态。用户填完表单，看到“注册成功”的提示，跳转到下载页，点击下载时又被要求登录，而用户并不知道自己其实还没登录。检查方法很直接：注册完成后，在当前页面打印当前用户 ID，如果为空，说明 session 没有写入，需要回到注册处理逻辑里补上登录操作。

另一个常见问题是注册时只校验了密码长度，没有校验邮箱格式或用户名唯一性。数据库里如果已经存在相同用户名，注册接口会报错，但用户看到的可能是笼统的“注册失败”，不知道是用户名被占用还是密码太短。处理办法是在注册逻辑里分步校验，每项失败返回不同的提示信息，让用户知道该改哪里。

下载请求的异常分支

下载不是只有“成功”一种结果。文件不存在、文件被删除、磁盘权限不足、用户下载中途断网，这些情况都要有对应的表现。很多项目只处理了成功分支，文件不存在时直接输出空白页，用户以为是自己操作错了，反复点击，服务端日志里全是 404 或 500。

检查下载接口时，至少要看四个分支：文件存在且有权下载，文件存在但无权下载，文件不存在，文件存在但读取失败。前两种返回明确的提示页或 JSON 错误信息，后两种记录日志并给出“文件已失效，请联系管理员”之类的反馈。如果下载量较大，还要考虑是否记录下载日志，方便日后排查是谁在什么时间下载了哪个文件。

下载日志不需要复杂，一张表记录用户 ID、资源 ID、下载时间和 IP 就够了。排查问题时，这张表能帮你快速确认是权限配置错了，还是某个用户反复触发下载导致服务端压力过大。

检查清单与验收方法

改完代码，按下面的顺序过一遍，能覆盖大部分断点。先清空浏览器缓存和 Cookie，以访客身份访问下载页，确认按钮状态和提示文案；再注册一个新账号，观察注册成功后是否自动登录，能否直接下载；退出登录，用刚注册的账号登录，再走一遍下载流程；找一个无权限的资源，确认服务端返回的是明确提示而不是空白页；最后查看服务端日志，确认没有 PHP 报错或 SQL 异常。

如果项目里已经有用户体系，还要测试重复注册、密码错误、账号被禁用这些边界情况。注册时用过的邮箱再次注册，应该提示“邮箱已被注册”；密码连续输错多次，是否触发锁定或验证码——这些不是流程图里必须画的，但实现时不能漏。

流程图画到“下载成功”不是终点。下载完成后用户要做什么，是打开文件还是跳转到感谢页，文件命名是否包含用户 ID 或订单号，这些细节影响的是用户对这次体验的记忆。把流程图停在“下载完成”，等于只检查了前半程。

最后留一条退路：每次改动前备份原文件和数据库结构，记录改动前后的行为差异。这样即使新方案有问题，也能在几分钟内回滚到可用状态，而不是对着报错日志重新猜。