1. 从注册这个动作说起为什么逆向思维值得聊做Web开发的人对注册功能再熟悉不过了。一个表单几个输入框提交按钮后端写库完事。但如果你把视角倒过来——不是站在我要实现注册功能的角度而是站在我要理解一个注册功能是怎么被设计出来的角度——你会发现很多平时忽略的东西。JSP逆向思维之注册篇这个标题核心不在于教你写一个注册页面。写注册页面太简单了一个刚学JSP的人半小时就能搞定。它真正想说的是通过逆向拆解一个已有的注册功能去理解JSP在整个请求链路中扮演的角色、它的设计边界在哪里、以及为什么很多看起来能跑的代码其实埋着坑。这篇文章适合谁看如果你正在学JSP或者工作中需要维护一些基于JSP的老系统再或者你单纯想搞清楚一个注册请求从浏览器发出到数据库落盘中间到底经历了什么那这篇内容会对你有帮助。我会从一个注册功能的完整链路出发逆向拆解每个环节的设计意图补充实操中容易踩的坑以及一些教科书上不会写的经验。需要提前说明的是这里讨论的JSP指的是经典的JavaServer Pages技术栈配合Servlet容器比如Tomcat运行的传统Web应用模式。虽然现在前后端分离是主流但大量存量系统仍然跑在这套架构上理解它的运作逻辑对于维护和改造这些系统非常关键。2. 逆向拆解注册功能从结果倒推设计2.1 先看注册成功这个结果包含哪些信息大部分人学JSP的时候老师会直接告诉你建一个register.jsp写表单再建一个RegisterServlet在doPost里拿参数、写数据库。这是正向思维——从零开始搭。逆向思维反过来先假设系统里已经有一个能正常工作的注册功能然后问自己几个问题。第一个问题用户点击注册按钮之后数据去了哪里表面上看是提交到了一个URL但这个URL背后是谁在处理在JSPServlet的架构里有两种可能一种是直接提交到另一个JSP页面另一种是提交到一个Servlet。这两种方式看起来都能跑但设计含义完全不同。提交到JSP页面处理意味着业务逻辑和页面渲染混在一起。你会在JSP里看到% request.getParameter(username) %这样的代码然后直接调JDBC写库。这种方式在早期JSP教程里非常常见因为上手快。但它的问题是JSP本质上是一个视图技术它的职责应该是渲染输出而不是处理业务逻辑。把注册逻辑写在JSP里等于让前台接待员去干后厨的活——能干但迟早出乱子。提交到Servlet处理是更合理的分工。Servlet负责接收请求、校验参数、调用业务层、写数据库然后根据结果决定是重定向到成功页面还是转发回注册页并附带错误信息。JSP只负责把结果展示出来。第二个问题注册成功之后服务器怎么知道这个用户已经登录了答案通常是Session。但Session是什么时候创建的是在注册成功之后手动创建还是在用户第一次访问网站时就自动创建了这个细节很多人没注意过。默认情况下JSP页面会自动创建Session除非显式设置sessionfalse也就是说用户可能还没注册服务器就已经给他分配了一个Session对象。这本身不是问题但如果你在注册逻辑里依赖Session来判断是否已登录就要小心Session的创建时机。第三个问题如果注册失败用户看到的错误信息是怎么传回来的常见做法是在Servlet里把错误信息塞进request作用域然后forward回注册页面页面上用c:if或者脚本片段来判断并显示。但这里有个容易忽略的点forward和redirect的区别。forward是服务器内部跳转浏览器地址栏不变request作用域里的数据可以传递redirect是告诉浏览器重新请求另一个地址request作用域数据丢失需要借助Session或者URL参数来传递信息。2.2 为什么选择逆向拆解而不是正向搭建正向搭建的问题是你很容易陷入能跑就行的思维定式。代码跑通了注册成功了就觉得学会了。但一旦遇到问题——比如中文乱码、重复注册、SQL注入——就不知道从哪下手。逆向拆解的好处是你会被迫去思考每个环节为什么这么设计。比如为什么表单的method要用POST而不是GET因为注册涉及密码等敏感信息GET会把参数暴露在URL里而且URL长度有限制。为什么要在前端做校验之后后端还要再做一次因为前端校验可以被绕过后端校验才是最后一道防线。为什么密码不能明文存数据库因为一旦数据库泄露用户的密码就全完了。即使你觉得我这个系统没人会攻击也不应该明文存密码——这是职业底线。这些问题正向搭建的时候你可能根本不会想。但逆向拆解的时候每一个设计决策都会浮出水面。3. 注册链路中的核心技术点拆解3.1 表单提交GET和POST的选择不是随便定的先看一个典型的注册表单长什么样form actionregister methodpost input typetext nameusername / input typepassword namepassword / input typepassword nameconfirmPassword / input typesubmit value注册 / /form这个表单里action指向的是registermethod是post。看起来很简单但每个属性都有讲究。action的值可以是相对路径也可以是绝对路径。相对路径的情况下浏览器会根据当前页面的URL来拼接。比如当前页面是/app/register.jspactionregister提交的地址就是/app/register。这个细节在部署到不同上下文路径的时候容易出问题。我见过不少项目在本地跑得好好的部署到服务器上就404了原因就是action写的是相对路径但页面URL的层级变了。更稳妥的做法是用c:url标签或者request.getContextPath()来拼接绝对路径form action${pageContext.request.contextPath}/register methodpost这样不管页面在哪个层级提交的地址都是正确的。method的选择前面提过了注册必须用POST。但这里还有一个容易被忽略的点如果表单里包含文件上传比如上传头像enctype必须设置为multipart/form-data否则文件内容传不过去。而且一旦设置了这个enctype后端就不能用request.getParameter()直接拿普通字段了需要用文件上传组件比如Apache Commons FileUpload来解析请求体。3.2 中文乱码一个老生常谈但总有人踩的坑中文乱码是JSP开发中最经典的问题之一。注册功能里用户名、昵称、地址这些字段都可能包含中文。乱码的根源在于字符编码不一致。浏览器发送请求时会根据页面的编码来决定参数的编码方式。如果页面是UTF-8浏览器就会用UTF-8编码参数。但Tomcat默认的请求体解码方式是ISO-8859-1这就导致中文变成乱码。解决办法是在读取任何参数之前先设置请求的编码request.setCharacterEncoding(UTF-8);注意这行代码必须在调用request.getParameter()之前执行否则无效。因为一旦调用了getParameter()请求体就已经被解析了再设置编码也来不及了。对于GET请求的参数setCharacterEncoding是不起作用的。GET请求的参数在URL里Tomcat对URL的解码方式由server.xml里的Connector配置决定。可以在Connector标签里加上URIEncodingUTF-8来解决。还有一个更省事的办法在web.xml里配置一个字符编码过滤器统一处理所有请求的编码filter filter-nameencodingFilter/filter-name filter-classorg.springframework.web.filter.CharacterEncodingFilter/filter-class init-param param-nameencoding/param-name param-valueUTF-8/param-value /init-param init-param param-nameforceEncoding/param-name param-valuetrue/param-value /init-param /filter filter-mapping filter-nameencodingFilter/filter-name url-pattern/*/url-pattern /filter-mapping如果不用Spring自己写一个Filter也很简单核心就是request.setCharacterEncoding(UTF-8)和response.setContentType(text/html;charsetUTF-8)。注意response.setCharacterEncoding和request.setCharacterEncoding是两回事。前者影响的是服务器往浏览器写数据时的编码后者影响的是服务器读取浏览器请求数据时的编码。两个都要设置才能保证双向都不乱码。3.3 参数校验前端是体验后端是底线注册表单的校验分前端和后端两层。前端校验用JavaScript或者HTML5的表单属性比如required、pattern、minlength目的是让用户在提交之前就能发现错误提升体验。后端校验用Java代码目的是防止恶意用户绕过前端直接提交非法数据。前端校验的常见做法input typetext nameusername required minlength3 maxlength20 pattern[a-zA-Z0-9_] /这段HTML5代码会在浏览器层面做基本校验必填、长度3到20、只允许字母数字和下划线。但用户完全可以打开开发者工具删掉这些属性或者直接用工具构造请求。所以后端必须再校验一遍。后端校验的内容包括但不限于用户名是否为空、长度是否在允许范围内、是否包含非法字符密码是否符合复杂度要求两次输入的密码是否一致用户名是否已经被注册邮箱格式是否正确如果注册需要邮箱这里有一个实操中容易忽略的点校验的顺序。应该先做格式校验非空、长度、格式再做业务校验用户名是否已存在。因为格式校验不需要查数据库速度快业务校验需要查库相对慢。如果格式都不对就没必要去查库了。另外校验失败后的处理方式也值得注意。如果是在Servlet里校验失败后应该把错误信息和一个标记比如hasError放进request作用域然后forward回注册页面。注册页面根据这个标记来决定是否显示错误提示。不要用response.sendRedirect因为重定向会丢失request作用域的数据。3.4 密码处理明文存储是不可接受的密码处理是注册功能里最需要认真对待的部分。明文存储密码是绝对不可接受的即使你觉得这只是个练习项目。因为习惯一旦养成到了真实项目里就会出大问题。正确的做法是存储密码的哈希值。但简单的MD5或SHA-1已经不够安全了因为这些算法计算速度太快容易被暴力破解。现在推荐的做法是用专门为密码存储设计的算法比如bcrypt、scrypt或者Argon2。以bcrypt为例Java里可以用BCryptPasswordEncoderSpring Security提供或者jBCrypt库String hashedPassword BCrypt.hashpw(plainPassword, BCrypt.gensalt());bcrypt的特点是计算速度慢而且可以调整工作因子来控制慢的程度。慢对于正常登录来说影响不大几百毫秒但对于暴力破解来说就是灾难——尝试成本成倍增加。还有一个细节bcrypt每次生成的盐值都是随机的所以同一个密码每次哈希的结果都不一样。验证的时候需要用BCrypt.checkpw方法它会从存储的哈希值里提取盐值然后对输入的密码做同样的哈希运算再比较。实操心得如果你在维护一个老系统发现密码是MD5存储的不要直接改成bcrypt——因为老用户的密码是MD5值你没法反向算出明文再哈希。常见的做法是渐进式迁移用户下次登录时用MD5验证通过后把密码升级为bcrypt存储。这样老用户无感知新用户直接用bcrypt。3.5 防重复提交不只是前端禁用按钮那么简单注册功能里用户可能会因为网络慢而多次点击提交按钮导致同一份数据被插入多次。前端的做法是提交后禁用按钮document.querySelector(form).addEventListener(submit, function() { document.querySelector(input[typesubmit]).disabled true; });但这只能防住正常用户的手抖防不住恶意请求。后端的防重复提交通常有两种思路第一种是在数据库层面加唯一约束。比如用户名字段加UNIQUE索引这样即使多次插入也只有第一次会成功后面的会抛异常。这是最可靠的兜底方案。第二种是在应用层面做令牌校验。页面渲染时生成一个随机令牌存在Session里同时放在表单的隐藏字段里。提交时比较两个令牌是否一致一致则处理并删除Session里的令牌不一致则拒绝。这样同一个令牌只能用一次。// 生成令牌 String token UUID.randomUUID().toString(); session.setAttribute(registerToken, token); // 页面隐藏字段 // input typehidden nametoken value${registerToken} / // 提交时校验 String sessionToken (String) session.getAttribute(registerToken); String requestToken request.getParameter(token); if (sessionToken null || !sessionToken.equals(requestToken)) { // 重复提交或非法请求 } session.removeAttribute(registerToken);两种方案可以结合使用数据库唯一约束是最后一道防线令牌校验则能在应用层提前拦截。4. 完整实操从零搭一个可用的注册模块4.1 项目结构和依赖准备先明确项目结构。一个典型的JSPServlet项目非Maven的Web项目目录结构大致如下webapp/ ├── WEB-INF/ │ ├── web.xml │ └── lib/ 放jar包 ├── register.jsp ├── register-success.jsp └── css/ └── style.css如果用Maven管理依赖pom.xml里需要加上Servlet API和JSTLdependency groupIdjavax.servlet/groupId artifactIdjavax.servlet-api/artifactId version4.0.1/version scopeprovided/scope /dependency dependency groupIdjavax.servlet/groupId artifactIdjstl/artifactId version1.2/version /dependency数据库驱动根据你用的数据库来选MySQL的话加上mysql-connector-java。连接池推荐用HikariCP或者Druid不要每次请求都DriverManager.getConnection那样性能很差。4.2 注册页面的JSP写法注册页面本身不复杂但有几个细节值得注意。下面是一个相对完整的示例% page contentTypetext/html;charsetUTF-8 languagejava % % taglib prefixc urihttp://java.sun.com/jsp/jstl/core % !DOCTYPE html html head meta charsetUTF-8 title用户注册/title /head body h2注册新账号/h2 c:if test${not empty errorMsg} div classerror${errorMsg}/div /c:if form action${pageContext.request.contextPath}/register methodpost div label用户名/label input typetext nameusername value${param.username} required / /div div label密码/label input typepassword namepassword required / /div div label确认密码/label input typepassword nameconfirmPassword required / /div div label邮箱/label input typeemail nameemail value${param.email} / /div button typesubmit注册/button /form /body /html几个关键点第一contentTypetext/html;charsetUTF-8必须写在页面指令里这样浏览器才知道用UTF-8来解析页面。第二错误信息的显示用了JSTL的c:if比脚本片段% if (...) { %更干净。${param.username}和${param.email}的作用是回显用户上次输入的内容避免用户重新填写。注意密码字段不要回显这是安全考虑。第三表单的action用了${pageContext.request.contextPath}保证上下文路径正确。4.3 Servlet端的处理逻辑Servlet是注册功能的核心。下面是一个完整的doPost方法示例包含了参数获取、校验、密码哈希、写库、跳转等环节protected void doPost(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException { request.setCharacterEncoding(UTF-8); String username request.getParameter(username); String password request.getParameter(password); String confirmPassword request.getParameter(confirmPassword); String email request.getParameter(email); // 格式校验 if (username null || username.trim().isEmpty()) { forwardError(request, response, 用户名不能为空, username, email); return; } if (username.length() 3 || username.length() 20) { forwardError(request, response, 用户名长度必须在3到20之间, username, email); return; } if (!username.matches([a-zA-Z0-9_])) { forwardError(request, response, 用户名只能包含字母、数字和下划线, username, email); return; } if (password null || password.length() 6) { forwardError(request, response, 密码长度不能少于6位, username, email); return; } if (!password.equals(confirmPassword)) { forwardError(request, response, 两次输入的密码不一致, username, email); return; } // 业务校验用户名是否已存在 UserDao userDao new UserDao(); if (userDao.findByUsername(username) ! null) { forwardError(request, response, 该用户名已被注册, username, email); return; } // 密码哈希 String hashedPassword BCrypt.hashpw(password, BCrypt.gensalt()); // 写库 User user new User(); user.setUsername(username); user.setPassword(hashedPassword); user.setEmail(email); user.setCreateTime(new Date()); try { userDao.insert(user); } catch (Exception e) { forwardError(request, response, 注册失败请稍后重试, username, email); return; } // 注册成功重定向到成功页面 response.sendRedirect(request.getContextPath() /register-success.jsp); } private void forwardError(HttpServletRequest request, HttpServletResponse response, String errorMsg, String username, String email) throws ServletException, IOException { request.setAttribute(errorMsg, errorMsg); request.setAttribute(username, username); request.setAttribute(email, email); request.getRequestDispatcher(/register.jsp).forward(request, response); }这段代码里有几个设计决策值得解释。为什么用forward而不是redirect来返回错误因为forward可以保留request作用域里的数据错误信息和回显内容而redirect会丢失这些数据。如果非要用redirect就得把错误信息放到Session里用完再删比较麻烦。为什么注册成功用redirect而不是forward因为注册成功后用户看到的应该是成功页面而不是注册页面的URL。如果用forward浏览器地址栏还是/register用户刷新页面会重新提交表单虽然此时可能因为用户名已存在而失败但体验不好。redirect让浏览器重新请求成功页面地址栏变成/register-success.jsp刷新也不会重复提交。为什么密码哈希放在业务校验之后因为哈希计算相对耗时bcrypt故意设计得慢如果用户名已经被占用就没必要做哈希计算了。先做便宜的校验再做昂贵的操作这是一个通用的性能优化原则。4.4 数据库表设计用户表的设计看起来简单但有几个字段值得仔细考虑CREATE TABLE user ( id BIGINT AUTO_INCREMENT PRIMARY KEY, username VARCHAR(50) NOT NULL UNIQUE, password VARCHAR(100) NOT NULL, email VARCHAR(100), create_time DATETIME NOT NULL, status TINYINT DEFAULT 1 ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;username加了UNIQUE约束这是防重复注册的最后一道防线。password字段长度给到100因为bcrypt哈希后的字符串长度是60留一些余量。charsetutf8mb4而不是utf8因为utf8在MySQL里最多只支持3字节的字符存不了emoji等4字节字符。status字段用于标记用户状态正常、禁用等虽然注册时用不到但后续扩展会需要。实操心得create_time字段建议在应用层设置而不是用数据库的DEFAULT CURRENT_TIMESTAMP。因为应用层设置更灵活而且不同数据库的默认时间函数不一样应用层设置可以保持代码的可移植性。4.5 连接池配置前面提到不要每次请求都新建数据库连接。连接池的配置通常放在context.xml或者通过代码初始化。以HikariCP为例HikariConfig config new HikariConfig(); config.setJdbcUrl(jdbc:mysql://localhost:3306/mydb?useUnicodetruecharacterEncodingutf8mb4); config.setUsername(dbuser); config.setPassword(dbpass); config.setMaximumPoolSize(10); config.setMinimumIdle(2); config.setConnectionTimeout(30000); HikariDataSource dataSource new HikariDataSource(config);maximumPoolSize设置为10是一个保守值适合小型应用。设置太大的话数据库连接数会成为瓶颈。connectionTimeout设置为30秒超过这个时间拿不到连接就抛异常避免请求无限等待。连接池的初始化应该放在ServletContextListener里应用启动时执行一次而不是每次请求都初始化public class AppInitializer implements ServletContextListener { Override public void contextInitialized(ServletContextEvent sce) { HikariDataSource ds createDataSource(); sce.getServletContext().setAttribute(dataSource, ds); } Override public void contextDestroyed(ServletContextEvent sce) { HikariDataSource ds (HikariDataSource) sce.getServletContext().getAttribute(dataSource); if (ds ! null) ds.close(); } }5. 常见问题与排查技巧实录5.1 注册请求返回404路径问题排查404是注册功能最常见的错误之一。可能的原因有几种第一种action路径写错了。如果表单的action是/register但Servlet的url-pattern是/registerServlet就会404。检查web.xml或者WebServlet注解里的路径配置。第二种上下文路径问题。如果应用部署在/myapp下表单提交到/register实际请求的是http://localhost:8080/register而不是http://localhost:8080/myapp/register。解决办法是用${pageContext.request.contextPath}/register。第三种Servlet没有正确注册。如果用WebServlet注解确认web.xml的metadata-complete没有设置为true设置为true会忽略注解。如果用web.xml配置确认servlet和servlet-mapping都写了而且servlet-name一致。5.2 中文乱码分场景排查中文乱码的排查要看乱码出现在哪个环节乱码场景可能原因解决办法页面显示乱码JSP页面编码与浏览器解析编码不一致页面指令加contentTypetext/html;charsetUTF-8POST参数乱码请求体解码编码不是UTF-8request.setCharacterEncoding(UTF-8)GET参数乱码URL解码编码不是UTF-8Connector加URIEncodingUTF-8数据库存储乱码数据库或表的字符集不是utf8mb4建库建表时指定CHARSETutf8mb4数据库连接乱码JDBC URL没有指定编码URL加characterEncodingutf8mb4排查的时候从源头开始先确认浏览器发送的编码是什么看页面的meta标签和contentType再确认服务器读取的编码是什么看setCharacterEncoding再确认数据库存储的编码是什么看表的字符集最后确认数据库连接使用的编码是什么看JDBC URL。5.3 重复注册从现象到根因用户反映我注册了一次但数据库里出现了两条记录。排查思路先看是不是用户多次点击了提交按钮。如果是前端加禁用按钮的逻辑后端加令牌校验。再看是不是网络重试导致的。有些浏览器或者代理在请求超时后会重试导致同一份数据提交两次。这种情况令牌校验也能解决。最后看是不是代码逻辑有问题。比如在Servlet里先查用户名是否存在不存在则插入。但如果两个请求同时到达都查到了不存在然后都执行了插入就会产生两条记录。这是典型的竞态条件。解决办法是依赖数据库的唯一约束捕获唯一约束冲突异常而不是先查后插。try { userDao.insert(user); } catch (DuplicateKeyException e) { forwardError(request, response, 该用户名已被注册, username, email); return; }5.4 密码验证失败哈希算法的坑用户注册成功但登录时提示密码错误。可能的原因第一种注册时存的是明文登录时比较的是哈希值。检查注册和登录的代码是否用了同样的哈希逻辑。第二种bcrypt的盐值问题。bcrypt每次哈希都会生成新的盐值所以不能用hash1.equals(hash2)来比较。必须用BCrypt.checkpw(plainPassword, hashedPassword)。第三种数据库字段长度不够。bcrypt哈希值是60个字符如果password字段定义的是VARCHAR(50)存进去会被截断导致验证失败。把字段长度改成VARCHAR(100)或更长。5.5 常见问题速查表问题现象排查方向快速修复404 Not Found检查Servlet路径、上下文路径用${pageContext.request.contextPath}拼接405 Method Not Allowed表单method与Servlet的doGet/doPost不匹配确认表单用POSTServlet重写doPost中文乱码检查请求编码、响应编码、数据库编码统一设置为UTF-8重复插入检查是否有唯一约束、是否有防重令牌加唯一索引令牌校验密码验证失败检查哈希算法、字段长度用bcrypt字段长度100数据库连接耗尽检查是否用了连接池、连接是否关闭用HikariCP确保连接归还页面报500看服务器日志的异常堆栈根据堆栈定位具体行实操心得排查问题时养成看日志的习惯。Tomcat的日志在logs/catalina.out或者logs/localhost.yyyy-mm-dd.log里。不要只看浏览器上的错误页面那只是冰山一角。真正的错误信息在服务器日志里。6. 一些教科书上不会写的经验6.1 关于JSP的脚本片段JSP里可以写Java代码用% %包裹。但现代JSP开发中应该尽量避免在JSP里写Java代码。原因有三一是违反MVC分层二是难以测试三是容易引入XSS漏洞。如果确实需要在页面上做逻辑判断用JSTL和EL表达式。比如判断用户是否登录c:if test${not empty sessionScope.user} 欢迎${sessionScope.user.username} /c:if而不是% if (session.getAttribute(user) ! null) { % 欢迎% ((User)session.getAttribute(user)).getUsername() % % } %后者不仅难看而且如果username包含HTML特殊字符还会导致XSS。EL表达式默认会对输出进行HTML转义在JSP 2.0中更安全。6.2 关于Session的使用注册功能本身不一定需要Session但注册成功后的自动登录通常需要。这里有一个容易忽略的点Session Fixation攻击。如果用户在未登录时就有一个Session ID登录后服务器没有更换Session ID攻击者就可以利用这个已知的Session ID来劫持用户会话。解决办法是在登录成功后注册自动登录也算调用request.changeSessionId()或者先invalidate()再新建Sessionrequest.getSession().invalidate(); HttpSession newSession request.getSession(true); newSession.setAttribute(user, user);6.3 关于SQL注入如果用JDBC拼接SQL字符串就会有SQL注入风险// 危险写法 String sql INSERT INTO user (username, password) VALUES ( username , password );如果用户输入的用户名是admin); DROP TABLE user; --拼接后的SQL就变成了INSERT INTO user (username, password) VALUES (admin); DROP TABLE user; --, ...)后果不堪设想。正确的做法是用PreparedStatementString sql INSERT INTO user (username, password, email, create_time) VALUES (?, ?, ?, ?); PreparedStatement ps connection.prepareStatement(sql); ps.setString(1, username); ps.setString(2, hashedPassword); ps.setString(3, email); ps.setTimestamp(4, new Timestamp(System.currentTimeMillis())); ps.executeUpdate();PreparedStatement会对参数进行转义从根本上杜绝SQL注入。6.4 关于错误信息的暴露注册失败时错误信息应该尽量模糊。比如用户名或密码错误而不是用户名不存在或密码错误。因为后者会帮助攻击者枚举系统里存在哪些用户名。对于注册功能如果用户名已存在提示该用户名已被注册是合理的因为注册场景下用户需要知道这个信息。但在登录场景下就不应该区分用户名不存在和密码错误。6.5 关于验证码如果注册接口被恶意批量调用可以考虑加验证码。验证码的实现方式有很多简单的有算术验证码复杂的有行为验证码。核心逻辑是生成验证码图片把答案存到Session里提交时比较用户输入和Session里的答案。// 生成验证码 String code generateRandomCode(4); session.setAttribute(captcha, code); // 校验 String inputCode request.getParameter(captcha); String sessionCode (String) session.getAttribute(captcha); if (!code.equalsIgnoreCase(inputCode)) { // 验证码错误 } session.removeAttribute(captcha);验证码的答案存在Session里用完就删防止重复使用。验证码的有效期也应该限制比如5分钟过期。6.6 关于前后端分离的过渡现在很多项目在从JSP向前后端分离过渡。注册功能可以改造成后端提供RESTful接口前端用AJAX调用。后端返回JSON而不是HTMLresponse.setContentType(application/json;charsetUTF-8); MapString, Object result new HashMap(); result.put(success, true); result.put(message, 注册成功); response.getWriter().write(new Gson().toJson(result));前端用fetch或者axios调用fetch(/api/register, { method: POST, headers: {Content-Type: application/json}, body: JSON.stringify({username, password, email}) }).then(res res.json()).then(data { if (data.success) { location.href /login.html; } else { alert(data.message); } });这种改造的好处是前后端职责更清晰JSP只负责渲染静态页面或者干脆不用JSP。但改造过程中要注意兼容老接口避免影响已有用户。6.7 关于测试注册功能的测试不能只测正常流程。至少要覆盖以下场景正常注册所有字段合法注册成功用户名为空提示错误用户名过短或过长提示错误用户名包含非法字符提示错误密码过短提示错误两次密码不一致提示错误用户名已存在提示错误邮箱格式错误提示错误如果校验邮箱重复提交只插入一条记录SQL注入尝试不产生异常不破坏数据XSS尝试用户名包含script页面上不执行脚本这些测试可以用JUnit加Mockito来做单元测试也可以用Selenium做集成测试。手工测试的话至少要把上面这些场景过一遍。6.8 关于代码组织注册功能的代码不应该全部堆在Servlet里。合理的分层是Servlet层接收请求、调用Service、控制跳转Service层业务逻辑、事务控制DAO层数据库操作Model层数据对象// Servlet protected void doPost(...) { RegisterRequest req new RegisterRequest(username, password, confirmPassword, email); RegisterResult result userService.register(req); if (result.isSuccess()) { response.sendRedirect(success.jsp); } else { request.setAttribute(errorMsg, result.getMessage()); request.getRequestDispatcher(register.jsp).forward(request, response); } }这样分层的好处是业务逻辑可以独立测试Servlet只负责请求调度代码更清晰也更容易维护。6.9 关于日志记录注册功能应该记录关键操作的日志比如注册成功、注册失败以及失败原因、异常情况。日志用SLF4J加Logback或者Log4j2private static final Logger logger LoggerFactory.getLogger(RegisterServlet.class); logger.info(用户注册成功: username{}, username); logger.warn(用户注册失败: username{}, reason{}, username, reason); logger.error(注册异常, e);日志里不要记录密码等敏感信息。用户名可以记录但密码绝对不能出现在日志里。6.10 关于性能注册功能的性能瓶颈通常在数据库写入和密码哈希上。bcrypt的哈希计算是故意设计得慢的工作因子越高越慢。默认的工作因子是10大约需要100毫秒。如果注册量很大可以考虑降低工作因子到8或者用异步方式处理哈希计算。数据库写入方面确保username字段有索引唯一约束自带索引这样查询用户名是否存在会很快。批量注册的场景下可以考虑批量插入但注册通常是单条插入批量优化的意义不大。连接池的大小要根据并发量来调整。一般来说maximumPoolSize设置为CPU核数的2倍加磁盘数是一个经验公式。但更准确的做法是通过压测来确定。
