php用户登录验证不能只靠$_session赋值，因其跳过密码哈希校验（必须用password_verify）、忽略账号状态检查（如禁用/未验证）、未防会话固定（需session_regenerate_id(true)），且缺乏安全会话初始化（如httponly/secure cookie）。
PHP 用户登录验证为什么不能只靠 $_SESSION 赋值？
直接给 $_SESSION['user_id'] = $id 就算“登录成功”，这是最常见也最危险的起点。它不校验密码哈希、不检查账号状态（是否被禁用/邮箱未验证）、不生成防重放的会话标识，攻击者可能通过 session fixation 或共享服务器上的会话文件窃取登录态。
真正可用的登录验证必须包含三步：凭证核对 → 状态检查 → 安全会话初始化。其中 password_verify() 是唯一推荐的密码比对方式，绝不能用 == 或 md5()。
- 查库时用预处理语句防止 SQL 注入：
$stmt = $pdo->prepare("SELECT id, password_hash, is_active FROM users WHERE email = ?") - 查到用户后，先确认
$row['is_active'] === 1再调用password_verify($input_pw, $row['password_hash']) - 验证通过后，立刻调用
session_regenerate_id(true)销毁旧会话 ID，避免 fixation - 设置
session_set_cookie_params(['secure' => true, 'httponly' => true, 'samesite' => 'Lax'])（PHP 7.3+）
如何让 PHP 的 session_start() 不在每次请求都写磁盘？
默认 session.save_handler = files 会导致高并发下 I/O 瓶颈，且多台 Web 服务器无法共享会话。更麻烦的是，如果在 session_start() 后修改了 $_SESSION 但没显式调用 session_write_close()，脚本结束前 session 文件会一直被锁住，后续 AJAX 请求可能阻塞。
- 生产环境优先改用 redis：在
php.ini中设session.save_handler = redis和session.save_path = "tcp://127.0.0.1:6379?auth=xxx" - 若仍用 files，务必在输出 HTML 后、执行耗时操作（如发邮件、调外部 API）前加
session_write_close() - 不要在
__destruct()或 shutdown function 里读写$_SESSION—— 此时会话可能已被关闭 - 检查
session.gc_maxlifetime是否与你的 token 过期逻辑一致（比如 JWT 设了 2 小时，但 session 却 24 小时才回收）
为什么用 password_hash() 生成的密码不能直接存进 VARCHAR(32)？
password_hash('abc', PASSWORD_ARGON2ID) 输出长度可达 96 字符，而老教程常教人用 VARCHAR(60) —— 这只够存 bcrypt 结果。一旦你升级算法或换主机（不同 PHP 版本默认算法不同），注册就会失败并报错 Invalid salt 或静默截断哈希值。
- 数据库字段至少设为
VARCHAR(255)，兼容 bcrypt / Argon2 / 将来可能的新算法 - 永远用
PASSWORD_ARGON2ID（PHP 7.2+）或PASSWORD_DEFAULT，别硬编码PASSWORD_BCRYPT - 插入前不做任何 trim() 或 strtolower() 处理 —— 密码大小写敏感是基本要求
- 如果迁移旧系统，需在登录时检测哈希前缀：
if (strpos($hash, '$2y$') === 0) { ... }，对旧哈希触发 rehash
忘记密码流程中，reset_token 字段该怎么设计？
只存一个 VARCHAR(64) 的随机字符串远远不够。token 泄露、重复使用、长期有效，任何一个都会导致账户失控。关键是把 token 当作一次性的、带上下文的临时凭证，而不是“密码重置链接”的代名词。
- 数据库字段至少包含：
reset_token（BINARY(32) 存sodium_crypto_randombytes(32)）、reset_expires_at（DATETIME）、reset_used（TINYINT(1) DEFAULT 0） - 生成 token 时用
sodium_crypto_randombytes()，绝不用rand()或uniqid() - 发送邮件后，立即在 DB 中更新
reset_used = 0和reset_expires_at = DATE_ADD(NOW(), INTERVAL 1 HOUR) - 验证时必须同时满足：
reset_used == 0ANDreset_expires_at > NOW()，任一失败即清空该记录
真正的难点不在代码怎么写，而在于所有环节都要假设“网络不可信、用户设备已中毒、日志可能被拖库”——比如重置页不显示原邮箱，提交新密码后强制退出所有其他会话，这些细节漏掉一个，前面加密再严也没用。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
