1. 先读懂题目电影票务场景下的“用户注册”到底要交什么拿到作业清单的时候大多数人看到“用户注册”四个字第一反应是这不是最基础的功能吗前端放一个表单后端接一下数据往数据库里插一条记录结束。但这次作业的标题里带了两个关键词一个是“李白”一个是“票务、电影”。如果只是做一个通用注册模块为什么题目要特别强调电影票务场景我建议你先别急着写代码把自己代入一个真实的产品经理视角看看这个注册模块要解决什么问题。1.1 从作业标题拆出三条线索“作业1用户注册李白票务电影”严格来说这不是一个规范的标题更像是随手记的备忘。“作业1”说明这是系列任务的第一关后面大概率还有登录、选座、下单、支付等一系列模块要陆续做“用户注册”是本次要交付的核心功能“李白”大概率是评测时使用的测试账号用来模拟一个真实用户完成注册“票务、电影”则限定了业务场景意味着你做的不是通用用户系统而是一个在线电影购票平台的注册入口。把这三条线索拼起来可以还原出一个相对完整的作业需求做一个面向电影购票业务的用户注册功能让一个名叫“李白”的用户能顺利注册成功并且数据要能落到数据库里供后续登录、购票使用。这里有一条很关键的判断既然有后续作业你的注册模块就不能只是“能存一条数据”它要能被后面的登录模块、订单模块正常调用。也就是说数据表结构、接口返回值、用户唯一标识的设计都要为后面的功能留好接口。1.2 电影票务场景对注册模块的真实业务要求通用注册只需要采集账号、密码最多加个邮箱或手机号。但电影票务平台有一个明显特点用户购票后会生成电子票需要凭二维码或取票码到影院取票票上关联观影人信息另外电影票的退改签、会员折扣、影城优惠券都要绑定到具体账号上。这就决定了注册模块在采集信息时需要比通用场景多考虑几件事。第一手机号是核心主键选项。国内用户去电影院看电影取票、接收观影通知最通用的通讯方式就是手机号所以电影票务平台几乎都采用“手机号即账号”的模式。用户在注册时填手机号系统通过短信验证码确认号码归属后续忘记密码、找回账号也依赖这个手机号。用容器化的例子来类比手机号相当于一辆车的VIN码是车辆的唯一识别号而用户名更像车牌可以更换。第二可能需要预留实名信息。部分影院在购买特定场次或限制级影片时需要实名制虽然注册阶段不一定强制要求填身份证但接口设计里要给用户表的扩展字段留好余地后面做观影人管理时才能挂靠上去。第三营销属性。电影票务平台的注册页通常不会真的只放两三个输入框它还会顺手采集用户的常去城市或者发一张新人观影券诱导注册。这些属于运营向的需求不是作业必做项但如果你在页面里放一个“常用城市”选择框并把它和后端字段对应起来交代作业时就能明显多一个亮点。1.3 账号体系选型手机号为主键还是用户名为主键作业如果只要求注册很多人会习惯性地设计一张 user 表主键叫 id再加 username 和 password 两个字段。这里我给你一个建议主键用自增 id但逻辑唯一键用手机号。用户名可以填但不是必需的甚至可以允许用户不填等注册完成后再引导完善昵称。为什么不要直接用用户名做主键因为用户名无法约束唯一性你无法保证“李白”这个名字不被别人抢注而且用户改名很常见今天叫“李白”明天想叫“白也”如果用户名是主键改名的代价就是级联修改所有关联表的外键。手机号作为逻辑唯一键则稳定得多一个人可以换用户名但手机号很少换。接口设计上也要提前定好规范。注册成功后返回的 JSON 里不仅仅要返回“注册成功”的提示还应该返回用户的唯一标识比如 id 或 token这样前端才能带着这个标识进入后续流程。有的同学喜欢只返回一个布尔值 true这是给自己埋坑——下一节作业做登录时前端没有用户标识根本不知道当前操作的是谁。2. 注册模块的整体设计与技术选型很多教程讲注册功能时会把全部注意力放在“后端怎么把数据存进数据库”这一件事上但真实项目里的用户注册是一个完整的链路任何一个环节断掉注册都跑不通。2.1 一条注册请求在前后端要经历哪些环节我习惯把注册流程拆成七个环节写作业的时候逐个对照缺哪个补哪个用户在注册页填写手机号、密码、确认密码、图形验证码可能还有昵称和常用城市前端做基础格式校验重点是手机号格式、密码长度、两次密码是否一致用户点击获取短信验证码后端先校验图形验证码防止机器刷接口再调用短信服务发送验证码并把验证码以加密形式存到缓存设置有效期前端把手机号、密码、短信验证码提交到注册接口后端先校验验证码是否匹配且未过期再校验手机号是否已被注册通过校验后对密码做哈希加密生成唯一用户记录写入数据库接口返回注册成功状态、用户 id、token或写入 Session前端跳转到首页或登录页。第七个环节不是必须的但建议做。如果作业要求只做注册不做登录那么注册成功后直接跳到一个个人中心占位页也能体现流程完整性。2.2 技术栈选择与目录结构参考作业本身没有限定语言这意味着你可以选自己最熟悉的栈。我见过用 Java Spring Boot 写的有用 Python Flask 写的也有用 Node.js Express 写的甚至有人用 PHP 写原生接口。从作业完成度和后续可扩展性来看我推荐 Node.js Express MySQL 的组合理由很直接前后端都是 JavaScript表达能力强代码量少适合短时间交付MySQL 是作业和面试中最常见的关系型数据库后续做订单、场次、影院这些关联查询时也更自然。如果你有精力可以再加上一个轻量级前端比如 Vue 或 React。但如果时间紧写一个静态的 HTML 原生 JavaScript 页面也完全够用重点是把交互细节做好老师验收时主要看功能是否完整而不是框架有多花哨。目录结构可以参考下面的分层方式不要把所有代码堆在一个文件里project/ ├── public/ │ ├── register.html │ ├── register.js │ └── register.css ├── src/ │ ├── controllers/ │ │ └── userController.js │ ├── services/ │ │ └── userService.js │ ├── routes/ │ │ └── userRoutes.js │ ├── utils/ │ │ └── validate.js │ └── db.js ├── .env └── app.js这个结构看着简单却把表现层、路由层、业务层、数据层都分开了。后面做登录、订票功能时直接往对应目录里加文件就行不需要推翻重来。2.3 关键设计决策背后的理由关于密码存储这是我反复强调的一点绝对不要明文存储也绝对不要只用 MD5。明文存储意味着数据库一旦泄露所有用户的密码直接暴露MD5 虽然看起来是“加密”但彩虹表太多几分钟就能反查出弱密码。正确做法是使用加盐哈希推荐 bcrypt它内置盐值和可调工作因子运算速度天然较慢能有效抵抗暴力破解。关于短信验证码如果你没有短信服务商账号作业阶段可以用一个模拟实现后端生成验证码在控制台打印出来同时存到内存缓存里。为了防止刷接口同一个手机号要加 60 秒发送冷却。关于 Session 还是 JWT这个阶段我建议用 Session。Session 的服务端实现简单逻辑直观符合课程作业通常要求的“登录态保持”需求JWT 虽然更适合前后端分离但对新手来说密钥管理、过期时间、客户端存储位置localStorage 还是 cookie这些坑会分散你对注册主流程的注意力。3. 从零实现用户注册全流程思路理清了选型也定下来了接下来就是动手环节。我会以 Node.js Express MySQL 为例把整个过程走一遍。你不用照着抄重点是理解每一步在做什么、为什么这么做。3.1 数据库表设计与初始化脚本注册模块涉及的核心表就是用户表但为了让“票务、电影”这个业务场景落地我建议至少建两张表用户表和观影人表。注册阶段只操作用户表观影人表先建好后面做实名购票时直接关联。用户表的设计去掉花里胡哨的字段核心字段就这几个字段名类型说明idBIGINT UNSIGNED AUTO_INCREMENT主键自增phoneVARCHAR(20)手机号唯一索引usernameVARCHAR(50)用户名/昵称可空password_hashVARCHAR(100)bcrypt 哈希后的密码cityVARCHAR(50)常去城市可空created_atDATETIME注册时间updated_atDATETIME更新时间初始化脚本可以直接用 SQLCREATE DATABASE IF NOT EXISTS movie_ticket DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci; USE movie_ticket; CREATE TABLE IF NOT EXISTS users ( id BIGINT UNSIGNED AUTO_INCREMENT PRIMARY KEY, phone VARCHAR(20) NOT NULL UNIQUE, username VARCHAR(50) DEFAULT NULL, password_hash VARCHAR(100) NOT NULL, city VARCHAR(50) DEFAULT NULL, created_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, updated_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, INDEX idx_phone (phone) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COLLATEutf8mb4_unicode_ci;这里有两个细节值得注意。第一数据库字符集一定要用 utf8mb4而不是 utf8因为 utf8mb4 才能完整支持中文和特殊表情符号。第二phone 字段加了唯一索引这是数据库层面的唯一性兜底即使后端代码防重逻辑有遗漏数据库也能拦住重复注册。3.2 后端接口实现校验、加盐哈希、入库、返回初始化 Node 项目并安装依赖用 npm 是标准操作npm init -y npm install express mysql2 bcryptjs dotenv接着在.env文件里配置服务端口和数据库连接信息注意不要提交到代码仓库这是基本的工程素养PORT3000 DB_HOSTlocalhost DB_USERroot DB_PASSWORDyourpassword DB_NAMEmovie_ticket数据库连接模块src/db.js用连接池而不是单连接避免并发注册时连接不够用const mysql require(mysql2/promise); const dotenv require(dotenv); dotenv.config(); const pool mysql.createPool({ host: process.env.DB_HOST, user: process.env.DB_USER, password: process.env.DB_PASSWORD, database: process.env.DB_NAME, waitForConnections: true, connectionLimit: 10, }); module.exports pool;然后是注册接口的核心逻辑。这里我把流程写成四个步骤检查手机号格式、检查验证码、检查用户是否存在、加密后入库。const bcrypt require(bcryptjs); async function register(req, res) { const { phone, password, confirmPassword, verifyCode, username, city } req.body; // 1. 基础格式校验 if (!/^1[3-9]\d{9}$/.test(phone)) { return res.status(400).json({ code: 40001, message: 手机号格式不正确 }); } if (!password || password.length 6 || password.length 20) { return res.status(400).json({ code: 40002, message: 密码长度需为6到20位 }); } if (password ! confirmPassword) { return res.status(400).json({ code: 40003, message: 两次输入的密码不一致 }); } // 2. 验证码校验这里用内存存储演示 const capturedCode verifyCodeStore[phone]; if (!capturedCode || capturedCode ! verifyCode) { return res.status(400).json({ code: 40004, message: 验证码错误或已过期 }); } delete verifyCodeStore[phone]; // 3. 查询用户是否已存在 const pool require(../db); const [rows] await pool.execute( SELECT id FROM users WHERE phone ?, [phone] ); if (rows.length 0) { return res.status(409).json({ code: 40005, message: 该手机号已注册请直接登录 }); } // 4. 密码哈希并写入数据库 const saltRounds 10; const passwordHash await bcrypt.hash(password, saltRounds); const [result] await pool.execute( INSERT INTO users (phone, username, password_hash, city) VALUES (?, ?, ?, ?), [phone, username || null, passwordHash, city || null] ); return res.status(201).json({ code: 0, message: 注册成功, data: { id: result.insertId, phone, username: username || , }, }); }你可以看到密码写入数据库前经过 bcrypt 加盐哈希数据库里永远不出现原始密码。saltRounds 设为 10 是安全性和性能之间的平衡太大会让注册响应明显变慢太小则抗暴力破解能力不足。有一点我需要专门提醒业务逻辑不要写在路由里。很多作业代码习惯直接在app.post(/register, (req, res) { ... })后面接一大坨逻辑调试起来非常痛苦。把逻辑拆到 controller 和 service 层哪怕代码只多出十几行也会让后续维护变得轻松。3.3 前端页面与交互逻辑后端接口写完接下来是前端页面。注册页的布局不用复杂但交互上要照顾真实用户的使用习惯。一个合格的电影票务注册页至少要有手机号输入框、密码输入框、确认密码输入框、图形验证码输入框、短信验证码输入框、获取验证码按钮、注册按钮。有心思的话加一个常用城市下拉框。前端有两个容易出彩的地方。第一个是“获取验证码”按钮的倒计时效果。用户点击后按钮变成灰色显示“60秒后重新获取”防止重复点击也让交互更贴近真实产品。实现方式不复杂就是 setInterval 控制剩余秒数一旦倒计时归零则恢复可点击状态。第二个是输入框的失焦校验。用户填完手机号光标移走后就立刻校验格式不对的话输入框下方显示红色提示如果用户还没填完就开始打红叉会非常烦人所以要用失焦事件而不是输入事件。核心的注册请求用 fetch 发送这里给一个简化示例async function handleRegister(event) { event.preventDefault(); const payload { phone: document.getElementById(phone).value.trim(), password: document.getElementById(password).value, confirmPassword: document.getElementById(confirmPassword).value, verifyCode: document.getElementById(smsCode).value.trim(), username: document.getElementById(username).value.trim(), city: document.getElementById(city).value, }; // 前端第一层校验 if (payload.password ! payload.confirmPassword) { alert(两次密码不一致); return; } try { const response await fetch(/api/register, { method: POST, headers: { Content-Type: application/json }, body: JSON.stringify(payload), }); const result await response.json(); if (result.code 0) { alert(注册成功即将跳转到个人中心); // 跳转到个人中心或登录页 window.location.href /login.html; } else { alert(result.message); } } catch (error) { console.error(注册请求失败, error); } }这种写法把后端返回的 message 直接显示给用户后端说什么前端弹什么逻辑非常透明不会出现“前端提示一个意思后端返回另一个意思”的拧巴情况。3.4 用李白这个测试账号跑通全流程作业里既然出现了“李白”这个名字那就一定要让“李白”这个用户真实注册成功。这里我建议你写一个简单的幂等测试思路而不是每次测试都临时用手机号注册。比如用 13800138001 作为“李白”的手机号先把注册接口调通然后跑到数据库里看一眼数据SELECT id, phone, username, created_at FROM users;理想情况下你应该看到类似这样的结果------------------------------------------------ | id | phone | username | created_at | ------------------------------------------------ | 1 | 13800138001 | 李白 | 2024-06-01 10:23:45 | ------------------------------------------------用户 id 是 1说明是第一个用户username 是“李白”注册时间正确。这个信息量非常关键它是整个作业“能交付”的直接证据。接下来再用同一个手机号注册一次接口应该返回“该手机号已注册请直接登录”。这一步是在验证唯一性约束是否生效。我自己带新人做作业时最常看到的情况是重复注册没有拦截数据库里出现两条一模一样的手机号记录。这个问题在后端逻辑和数据库唯一索引双层防护下是可以彻底避免的。4. 注册模块的常见问题与排查经验这部分是我最想分享的内容。以下问题几乎在所有写注册模块的新手里反复出现而且很多是面试或答辩时老师特别喜欢追问的点。4.1 密码相关的常见坑密码相关的坑第一是忘记哈希。有人会把密码直接明文存进数据库理由是“反正作业而已又不上线”。这个习惯一定要改掉安全意识和编码习惯是从作业阶段开始养成的。就算作业不要求我也会把 bcrypt 哈希写上多两行代码的事。第二是密码校验的边界。密码长度为空、密码里带空格、全是数字的弱密码这些情况要不要拦截作业里最好统一处理去空格后判断长度范围定在 6 到 20 位特殊情况在报错信息里说清楚。前端要校验后端更要校验前端的校验可以被绕过后端的校验才是真正的防线。第三是“确认密码”字段的处理。确认密码只是前端交互层面的校验不应该出现在后端存储逻辑里也不应该持久化到数据库。代码里可以接收这个字段做比对但比对完就丢不要存。4.2 验证码相关的问题先说明一句这里说的全是注册流程自带的短信验证码实现不涉及任何代理工具。如果你没有真实的短信服务供应商可以自己实现一个模拟的验证码仓储用 Map 以手机号为 key验证码为 value存储时设置 5 分钟有效期。注意生产环境要使用 Redis 之类的缓存服务并设置过期时间内存 Map 只适合作业演示。实际作业中验证码常见问题有三个。第一个是验证码有效期不生效用户 5 分钟前获取的验证码还能继续使用。解决办法是在存储验证码时附带过期时间戳校验时先判断Date.now()是否超过过期时间。第二个是同一手机号 1 分钟内可以重复获取验证码容易被脚本刷爆。解决办法是记录上一次发送时间间隔不足 60 秒时直接拒绝并提示“请勿频繁获取”。第三个是验证码不分大小写导致用户反复输错。解决办法是生成时统一用大写字母校验时统一转大写再比较。4.3 数据库中文乱码与编码问题注册模块写入中文用户名比如“李白”结果库里看到的是一串乱码或者???这基本是字符集问题。解决要点有三个数据库表指定 utf8mb4、连接字符串带上charsetutf8mb4、页面文件保存为 UTF-8 编码。三处缺一不可任何一个环节用错编码中文写入就会出问题。另外如果你在 Windows 上开发还有一个小坑默认终端代码页可能是 GBK导致在命令行里查看数据时中文显示异常这不一定是数据真的有问题可以先在数据库客户端里确认。遇到乱码不要慌先把表的字符集查出来再检查连接配置逐层排查。4.4 注册模块的安全底线作业可以不完美但安全底线不能丢。这里列几个我用来自查的问题清单每一个都值得你对照检查密码是否经过加盐哈希后再入库答案是必须建议使用 bcrypt。接口是否限制了验证码的获取频率答案是必须否则会被刷到短信欠费。手机号是否做了正则校验答案是必须否则abc也能注册成功后续做登录和订单关联时全乱套。后端是否验证了手机号唯一性答案是必须不能只依赖前端提醒。是否对 SQL 注入做了防护答案是必须数据库操作要使用参数化查询不能字符串拼接 SQL。错误信息是否暴露了敏感信息答案是不能比如不要直接返回“数据库连接失败”这种内部错误应该统一包装成友好提示。还有一个容易被忽略的点注册接口要限制请求体大小。Express 的express.json()默认限制 100kb你可以指定更小的限制防止有人传一个超大 JSON 把服务拖垮。这种并发攻击对注册接口来说非常真实因为它不需要登录就能调用。5. 把作业做成作品三个值得扩展的方向注册模块做完、验收通过并不是终点。如果时间允许我建议你在原始作业基础上继续加料扩展三个方向让这个作业从“能用”变成“有想法”。第一个方向是登录功能的预留对接。注册成功后返回用户 id你可以在前端做一些登录态的模拟处理比如把用户 id 存在 localStorage 里个人中心页根据这个 id 显示不同的用户名。这样等于给下一份作业打了地基也让老师看到你具备全局思维。第二个方向是注册数据可视化。把用户表里的注册人数按天聚合前端用简单的柱状图展示新增用户趋势。这不需要引入重型图表库用 CSS 画柱子都行但展示出的“数据分析”思维在作业汇报时是加分的。第三个方向是模拟电影票务场景的完整链路。注册成功后给新用户发一张零门槛观影券数据存到一张券表里。这一步直击“票务、电影”场景的本质注册不再是孤立的表单填写而是营销转化漏斗的第一环节。这样的扩展会让你的作业明显区别于其他同学。最后说一点个人体会。很多人在做作业时追求“跑通就算成功”但如果你愿意在每个环节多想一层“为什么”收获会完全不同。注册这个功能看起来简单它却是几乎所有互联网产品的第一道门面背后涉及格式校验、数据安全、唯一约束、频率控制、状态管理这些基础知识。把这道门面做好后面做什么功能都会顺手很多。 
长河君 · 2026/10/7 3:13:46 · 阅读 1.2k 电影票务用户注册全流程：手机号主键、验证码与密码加密实践
1. 先读懂题目电影票务场景下的“用户注册”到底要交什么拿到作业清单的时候大多数人看到“用户注册”四个字第一反应是这不是最基础的功能吗前端放一个表单后端接一下数据往数据库里插一条记录结束。但这次作业的标题里带了两个关键词一个是“李白”一个是“票务、电影”。如果只是做一个通用注册模块为什么题目要特别强调电影票务场景我建议你先别急着写代码把自己代入一个真实的产品经理视角看看这个注册模块要解决什么问题。1.1 从作业标题拆出三条线索“作业1用户注册李白票务电影”严格来说这不是一个规范的标题更像是随手记的备忘。“作业1”说明这是系列任务的第一关后面大概率还有登录、选座、下单、支付等一系列模块要陆续做“用户注册”是本次要交付的核心功能“李白”大概率是评测时使用的测试账号用来模拟一个真实用户完成注册“票务、电影”则限定了业务场景意味着你做的不是通用用户系统而是一个在线电影购票平台的注册入口。把这三条线索拼起来可以还原出一个相对完整的作业需求做一个面向电影购票业务的用户注册功能让一个名叫“李白”的用户能顺利注册成功并且数据要能落到数据库里供后续登录、购票使用。这里有一条很关键的判断既然有后续作业你的注册模块就不能只是“能存一条数据”它要能被后面的登录模块、订单模块正常调用。也就是说数据表结构、接口返回值、用户唯一标识的设计都要为后面的功能留好接口。1.2 电影票务场景对注册模块的真实业务要求通用注册只需要采集账号、密码最多加个邮箱或手机号。但电影票务平台有一个明显特点用户购票后会生成电子票需要凭二维码或取票码到影院取票票上关联观影人信息另外电影票的退改签、会员折扣、影城优惠券都要绑定到具体账号上。这就决定了注册模块在采集信息时需要比通用场景多考虑几件事。第一手机号是核心主键选项。国内用户去电影院看电影取票、接收观影通知最通用的通讯方式就是手机号所以电影票务平台几乎都采用“手机号即账号”的模式。用户在注册时填手机号系统通过短信验证码确认号码归属后续忘记密码、找回账号也依赖这个手机号。用容器化的例子来类比手机号相当于一辆车的VIN码是车辆的唯一识别号而用户名更像车牌可以更换。第二可能需要预留实名信息。部分影院在购买特定场次或限制级影片时需要实名制虽然注册阶段不一定强制要求填身份证但接口设计里要给用户表的扩展字段留好余地后面做观影人管理时才能挂靠上去。第三营销属性。电影票务平台的注册页通常不会真的只放两三个输入框它还会顺手采集用户的常去城市或者发一张新人观影券诱导注册。这些属于运营向的需求不是作业必做项但如果你在页面里放一个“常用城市”选择框并把它和后端字段对应起来交代作业时就能明显多一个亮点。1.3 账号体系选型手机号为主键还是用户名为主键作业如果只要求注册很多人会习惯性地设计一张 user 表主键叫 id再加 username 和 password 两个字段。这里我给你一个建议主键用自增 id但逻辑唯一键用手机号。用户名可以填但不是必需的甚至可以允许用户不填等注册完成后再引导完善昵称。为什么不要直接用用户名做主键因为用户名无法约束唯一性你无法保证“李白”这个名字不被别人抢注而且用户改名很常见今天叫“李白”明天想叫“白也”如果用户名是主键改名的代价就是级联修改所有关联表的外键。手机号作为逻辑唯一键则稳定得多一个人可以换用户名但手机号很少换。接口设计上也要提前定好规范。注册成功后返回的 JSON 里不仅仅要返回“注册成功”的提示还应该返回用户的唯一标识比如 id 或 token这样前端才能带着这个标识进入后续流程。有的同学喜欢只返回一个布尔值 true这是给自己埋坑——下一节作业做登录时前端没有用户标识根本不知道当前操作的是谁。2. 注册模块的整体设计与技术选型很多教程讲注册功能时会把全部注意力放在“后端怎么把数据存进数据库”这一件事上但真实项目里的用户注册是一个完整的链路任何一个环节断掉注册都跑不通。2.1 一条注册请求在前后端要经历哪些环节我习惯把注册流程拆成七个环节写作业的时候逐个对照缺哪个补哪个用户在注册页填写手机号、密码、确认密码、图形验证码可能还有昵称和常用城市前端做基础格式校验重点是手机号格式、密码长度、两次密码是否一致用户点击获取短信验证码后端先校验图形验证码防止机器刷接口再调用短信服务发送验证码并把验证码以加密形式存到缓存设置有效期前端把手机号、密码、短信验证码提交到注册接口后端先校验验证码是否匹配且未过期再校验手机号是否已被注册通过校验后对密码做哈希加密生成唯一用户记录写入数据库接口返回注册成功状态、用户 id、token或写入 Session前端跳转到首页或登录页。第七个环节不是必须的但建议做。如果作业要求只做注册不做登录那么注册成功后直接跳到一个个人中心占位页也能体现流程完整性。2.2 技术栈选择与目录结构参考作业本身没有限定语言这意味着你可以选自己最熟悉的栈。我见过用 Java Spring Boot 写的有用 Python Flask 写的也有用 Node.js Express 写的甚至有人用 PHP 写原生接口。从作业完成度和后续可扩展性来看我推荐 Node.js Express MySQL 的组合理由很直接前后端都是 JavaScript表达能力强代码量少适合短时间交付MySQL 是作业和面试中最常见的关系型数据库后续做订单、场次、影院这些关联查询时也更自然。如果你有精力可以再加上一个轻量级前端比如 Vue 或 React。但如果时间紧写一个静态的 HTML 原生 JavaScript 页面也完全够用重点是把交互细节做好老师验收时主要看功能是否完整而不是框架有多花哨。目录结构可以参考下面的分层方式不要把所有代码堆在一个文件里project/ ├── public/ │ ├── register.html │ ├── register.js │ └── register.css ├── src/ │ ├── controllers/ │ │ └── userController.js │ ├── services/ │ │ └── userService.js │ ├── routes/ │ │ └── userRoutes.js │ ├── utils/ │ │ └── validate.js │ └── db.js ├── .env └── app.js这个结构看着简单却把表现层、路由层、业务层、数据层都分开了。后面做登录、订票功能时直接往对应目录里加文件就行不需要推翻重来。2.3 关键设计决策背后的理由关于密码存储这是我反复强调的一点绝对不要明文存储也绝对不要只用 MD5。明文存储意味着数据库一旦泄露所有用户的密码直接暴露MD5 虽然看起来是“加密”但彩虹表太多几分钟就能反查出弱密码。正确做法是使用加盐哈希推荐 bcrypt它内置盐值和可调工作因子运算速度天然较慢能有效抵抗暴力破解。关于短信验证码如果你没有短信服务商账号作业阶段可以用一个模拟实现后端生成验证码在控制台打印出来同时存到内存缓存里。为了防止刷接口同一个手机号要加 60 秒发送冷却。关于 Session 还是 JWT这个阶段我建议用 Session。Session 的服务端实现简单逻辑直观符合课程作业通常要求的“登录态保持”需求JWT 虽然更适合前后端分离但对新手来说密钥管理、过期时间、客户端存储位置localStorage 还是 cookie这些坑会分散你对注册主流程的注意力。3. 从零实现用户注册全流程思路理清了选型也定下来了接下来就是动手环节。我会以 Node.js Express MySQL 为例把整个过程走一遍。你不用照着抄重点是理解每一步在做什么、为什么这么做。3.1 数据库表设计与初始化脚本注册模块涉及的核心表就是用户表但为了让“票务、电影”这个业务场景落地我建议至少建两张表用户表和观影人表。注册阶段只操作用户表观影人表先建好后面做实名购票时直接关联。用户表的设计去掉花里胡哨的字段核心字段就这几个字段名类型说明idBIGINT UNSIGNED AUTO_INCREMENT主键自增phoneVARCHAR(20)手机号唯一索引usernameVARCHAR(50)用户名/昵称可空password_hashVARCHAR(100)bcrypt 哈希后的密码cityVARCHAR(50)常去城市可空created_atDATETIME注册时间updated_atDATETIME更新时间初始化脚本可以直接用 SQLCREATE DATABASE IF NOT EXISTS movie_ticket DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci; USE movie_ticket; CREATE TABLE IF NOT EXISTS users ( id BIGINT UNSIGNED AUTO_INCREMENT PRIMARY KEY, phone VARCHAR(20) NOT NULL UNIQUE, username VARCHAR(50) DEFAULT NULL, password_hash VARCHAR(100) NOT NULL, city VARCHAR(50) DEFAULT NULL, created_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, updated_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, INDEX idx_phone (phone) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COLLATEutf8mb4_unicode_ci;这里有两个细节值得注意。第一数据库字符集一定要用 utf8mb4而不是 utf8因为 utf8mb4 才能完整支持中文和特殊表情符号。第二phone 字段加了唯一索引这是数据库层面的唯一性兜底即使后端代码防重逻辑有遗漏数据库也能拦住重复注册。3.2 后端接口实现校验、加盐哈希、入库、返回初始化 Node 项目并安装依赖用 npm 是标准操作npm init -y npm install express mysql2 bcryptjs dotenv接着在.env文件里配置服务端口和数据库连接信息注意不要提交到代码仓库这是基本的工程素养PORT3000 DB_HOSTlocalhost DB_USERroot DB_PASSWORDyourpassword DB_NAMEmovie_ticket数据库连接模块src/db.js用连接池而不是单连接避免并发注册时连接不够用const mysql require(mysql2/promise); const dotenv require(dotenv); dotenv.config(); const pool mysql.createPool({ host: process.env.DB_HOST, user: process.env.DB_USER, password: process.env.DB_PASSWORD, database: process.env.DB_NAME, waitForConnections: true, connectionLimit: 10, }); module.exports pool;然后是注册接口的核心逻辑。这里我把流程写成四个步骤检查手机号格式、检查验证码、检查用户是否存在、加密后入库。const bcrypt require(bcryptjs); async function register(req, res) { const { phone, password, confirmPassword, verifyCode, username, city } req.body; // 1. 基础格式校验 if (!/^1[3-9]\d{9}$/.test(phone)) { return res.status(400).json({ code: 40001, message: 手机号格式不正确 }); } if (!password || password.length 6 || password.length 20) { return res.status(400).json({ code: 40002, message: 密码长度需为6到20位 }); } if (password ! confirmPassword) { return res.status(400).json({ code: 40003, message: 两次输入的密码不一致 }); } // 2. 验证码校验这里用内存存储演示 const capturedCode verifyCodeStore[phone]; if (!capturedCode || capturedCode ! verifyCode) { return res.status(400).json({ code: 40004, message: 验证码错误或已过期 }); } delete verifyCodeStore[phone]; // 3. 查询用户是否已存在 const pool require(../db); const [rows] await pool.execute( SELECT id FROM users WHERE phone ?, [phone] ); if (rows.length 0) { return res.status(409).json({ code: 40005, message: 该手机号已注册请直接登录 }); } // 4. 密码哈希并写入数据库 const saltRounds 10; const passwordHash await bcrypt.hash(password, saltRounds); const [result] await pool.execute( INSERT INTO users (phone, username, password_hash, city) VALUES (?, ?, ?, ?), [phone, username || null, passwordHash, city || null] ); return res.status(201).json({ code: 0, message: 注册成功, data: { id: result.insertId, phone, username: username || , }, }); }你可以看到密码写入数据库前经过 bcrypt 加盐哈希数据库里永远不出现原始密码。saltRounds 设为 10 是安全性和性能之间的平衡太大会让注册响应明显变慢太小则抗暴力破解能力不足。有一点我需要专门提醒业务逻辑不要写在路由里。很多作业代码习惯直接在app.post(/register, (req, res) { ... })后面接一大坨逻辑调试起来非常痛苦。把逻辑拆到 controller 和 service 层哪怕代码只多出十几行也会让后续维护变得轻松。3.3 前端页面与交互逻辑后端接口写完接下来是前端页面。注册页的布局不用复杂但交互上要照顾真实用户的使用习惯。一个合格的电影票务注册页至少要有手机号输入框、密码输入框、确认密码输入框、图形验证码输入框、短信验证码输入框、获取验证码按钮、注册按钮。有心思的话加一个常用城市下拉框。前端有两个容易出彩的地方。第一个是“获取验证码”按钮的倒计时效果。用户点击后按钮变成灰色显示“60秒后重新获取”防止重复点击也让交互更贴近真实产品。实现方式不复杂就是 setInterval 控制剩余秒数一旦倒计时归零则恢复可点击状态。第二个是输入框的失焦校验。用户填完手机号光标移走后就立刻校验格式不对的话输入框下方显示红色提示如果用户还没填完就开始打红叉会非常烦人所以要用失焦事件而不是输入事件。核心的注册请求用 fetch 发送这里给一个简化示例async function handleRegister(event) { event.preventDefault(); const payload { phone: document.getElementById(phone).value.trim(), password: document.getElementById(password).value, confirmPassword: document.getElementById(confirmPassword).value, verifyCode: document.getElementById(smsCode).value.trim(), username: document.getElementById(username).value.trim(), city: document.getElementById(city).value, }; // 前端第一层校验 if (payload.password ! payload.confirmPassword) { alert(两次密码不一致); return; } try { const response await fetch(/api/register, { method: POST, headers: { Content-Type: application/json }, body: JSON.stringify(payload), }); const result await response.json(); if (result.code 0) { alert(注册成功即将跳转到个人中心); // 跳转到个人中心或登录页 window.location.href /login.html; } else { alert(result.message); } } catch (error) { console.error(注册请求失败, error); } }这种写法把后端返回的 message 直接显示给用户后端说什么前端弹什么逻辑非常透明不会出现“前端提示一个意思后端返回另一个意思”的拧巴情况。3.4 用李白这个测试账号跑通全流程作业里既然出现了“李白”这个名字那就一定要让“李白”这个用户真实注册成功。这里我建议你写一个简单的幂等测试思路而不是每次测试都临时用手机号注册。比如用 13800138001 作为“李白”的手机号先把注册接口调通然后跑到数据库里看一眼数据SELECT id, phone, username, created_at FROM users;理想情况下你应该看到类似这样的结果------------------------------------------------ | id | phone | username | created_at | ------------------------------------------------ | 1 | 13800138001 | 李白 | 2024-06-01 10:23:45 | ------------------------------------------------用户 id 是 1说明是第一个用户username 是“李白”注册时间正确。这个信息量非常关键它是整个作业“能交付”的直接证据。接下来再用同一个手机号注册一次接口应该返回“该手机号已注册请直接登录”。这一步是在验证唯一性约束是否生效。我自己带新人做作业时最常看到的情况是重复注册没有拦截数据库里出现两条一模一样的手机号记录。这个问题在后端逻辑和数据库唯一索引双层防护下是可以彻底避免的。4. 注册模块的常见问题与排查经验这部分是我最想分享的内容。以下问题几乎在所有写注册模块的新手里反复出现而且很多是面试或答辩时老师特别喜欢追问的点。4.1 密码相关的常见坑密码相关的坑第一是忘记哈希。有人会把密码直接明文存进数据库理由是“反正作业而已又不上线”。这个习惯一定要改掉安全意识和编码习惯是从作业阶段开始养成的。就算作业不要求我也会把 bcrypt 哈希写上多两行代码的事。第二是密码校验的边界。密码长度为空、密码里带空格、全是数字的弱密码这些情况要不要拦截作业里最好统一处理去空格后判断长度范围定在 6 到 20 位特殊情况在报错信息里说清楚。前端要校验后端更要校验前端的校验可以被绕过后端的校验才是真正的防线。第三是“确认密码”字段的处理。确认密码只是前端交互层面的校验不应该出现在后端存储逻辑里也不应该持久化到数据库。代码里可以接收这个字段做比对但比对完就丢不要存。4.2 验证码相关的问题先说明一句这里说的全是注册流程自带的短信验证码实现不涉及任何代理工具。如果你没有真实的短信服务供应商可以自己实现一个模拟的验证码仓储用 Map 以手机号为 key验证码为 value存储时设置 5 分钟有效期。注意生产环境要使用 Redis 之类的缓存服务并设置过期时间内存 Map 只适合作业演示。实际作业中验证码常见问题有三个。第一个是验证码有效期不生效用户 5 分钟前获取的验证码还能继续使用。解决办法是在存储验证码时附带过期时间戳校验时先判断Date.now()是否超过过期时间。第二个是同一手机号 1 分钟内可以重复获取验证码容易被脚本刷爆。解决办法是记录上一次发送时间间隔不足 60 秒时直接拒绝并提示“请勿频繁获取”。第三个是验证码不分大小写导致用户反复输错。解决办法是生成时统一用大写字母校验时统一转大写再比较。4.3 数据库中文乱码与编码问题注册模块写入中文用户名比如“李白”结果库里看到的是一串乱码或者???这基本是字符集问题。解决要点有三个数据库表指定 utf8mb4、连接字符串带上charsetutf8mb4、页面文件保存为 UTF-8 编码。三处缺一不可任何一个环节用错编码中文写入就会出问题。另外如果你在 Windows 上开发还有一个小坑默认终端代码页可能是 GBK导致在命令行里查看数据时中文显示异常这不一定是数据真的有问题可以先在数据库客户端里确认。遇到乱码不要慌先把表的字符集查出来再检查连接配置逐层排查。4.4 注册模块的安全底线作业可以不完美但安全底线不能丢。这里列几个我用来自查的问题清单每一个都值得你对照检查密码是否经过加盐哈希后再入库答案是必须建议使用 bcrypt。接口是否限制了验证码的获取频率答案是必须否则会被刷到短信欠费。手机号是否做了正则校验答案是必须否则abc也能注册成功后续做登录和订单关联时全乱套。后端是否验证了手机号唯一性答案是必须不能只依赖前端提醒。是否对 SQL 注入做了防护答案是必须数据库操作要使用参数化查询不能字符串拼接 SQL。错误信息是否暴露了敏感信息答案是不能比如不要直接返回“数据库连接失败”这种内部错误应该统一包装成友好提示。还有一个容易被忽略的点注册接口要限制请求体大小。Express 的express.json()默认限制 100kb你可以指定更小的限制防止有人传一个超大 JSON 把服务拖垮。这种并发攻击对注册接口来说非常真实因为它不需要登录就能调用。5. 把作业做成作品三个值得扩展的方向注册模块做完、验收通过并不是终点。如果时间允许我建议你在原始作业基础上继续加料扩展三个方向让这个作业从“能用”变成“有想法”。第一个方向是登录功能的预留对接。注册成功后返回用户 id你可以在前端做一些登录态的模拟处理比如把用户 id 存在 localStorage 里个人中心页根据这个 id 显示不同的用户名。这样等于给下一份作业打了地基也让老师看到你具备全局思维。第二个方向是注册数据可视化。把用户表里的注册人数按天聚合前端用简单的柱状图展示新增用户趋势。这不需要引入重型图表库用 CSS 画柱子都行但展示出的“数据分析”思维在作业汇报时是加分的。第三个方向是模拟电影票务场景的完整链路。注册成功后给新用户发一张零门槛观影券数据存到一张券表里。这一步直击“票务、电影”场景的本质注册不再是孤立的表单填写而是营销转化漏斗的第一环节。这样的扩展会让你的作业明显区别于其他同学。最后说一点个人体会。很多人在做作业时追求“跑通就算成功”但如果你愿意在每个环节多想一层“为什么”收获会完全不同。注册这个功能看起来简单它却是几乎所有互联网产品的第一道门面背后涉及格式校验、数据安全、唯一约束、频率控制、状态管理这些基础知识。把这道门面做好后面做什么功能都会顺手很多。