企业官网建设流程全解析

做JavaWeb做得时间越长，越觉得参数传递这个基本功特别能看出一个项目的底子。前阵子带两个实习生维护一个基于Servlet + JSP + MySQL的课设项目，我一看代码，DAO接口方法居然长这样：List<User> findUser(HttpServletRequest request)。点进去，里面全是request.getParameter("username")。当时我就问了一句：如果哪天不用Servlet跑这段逻辑，你打算怎么测？两个人沉默了。这篇文章就专门来讲一讲DAO层和Servlet层参数传递的正确姿势，从分层职责、参数封装讲到常见坑和IDEA里的配套配置。正在学JavaWeb、写课设或者写企业项目的人都适合看，核心就一句话：别把Servlet对象往业务层和DAO层传。

1. 先厘清：Servlet层和DAO层到底谁该管什么事

1.1 Servlet层该做的只是“入口翻译”

Servlet本质是HTTP入口，作用是把HTTP请求翻译成Java调用。所以它该做的是处理编码、获取参数、初步校验、决定调用哪个业务方法、把结果转成JSON或转发页面。不是写SQL、不是拼where、不是new Connection，也不是把request一传了之。

出现把request塞进DAO的直接原因，是Servlet层把“翻译参数”这件事省掉了，让下游自己去找参数。短期看少写几行，长期看整个项目就乱了。如果你用一个返回User的DAO方法，调用方希望传入的是username、password这些业务值，而不是一个装着这些值的HttpServletRequest容器。

提示：我在评审代码时有个一眼判断标准：看到DAO或Service方法的参数类型是HttpServletRequest、HttpServletResponse，基本可以直接打回。

1.2 DAO层的“唯一任务”就是访问数据

DAO层就是跟数据库打交道的，它的方法签名要体现业务条件：按谁查、查什么、返回什么。DAO层不该知道“今天是GET还是POST”“前端字段叫name还是username”这种HTTP层面的细节。知道了，就依赖Servlet容器；依赖容器，就不能脱离Tomcat单独测试；不能单独测试，维护成本就上去了。

JavaWeb中很多课设项目没有Service层，这没关系，Servlet直接调用DAO也要守住这条线：DAO方法的参数只能是Java基本类型、String、POJO/DTO/VO，以及少量集合类型，而不是Servlet容器里的对象。

1.3 参数传递绕过Service层？仍要按同一条规则来

如果你的项目是Servlet -> DAO，中间没有Service，不要因为“层少”就让参数乱传，规则不变。Servlet取参，自己把request.getParameterMap()转成UserQuery对象，再传DAO。这才是正确的姿势。而且你可能会发现：把参数封装好之后，即使以后加Service层，DAO接口基本不用改。

// 错误示例：参数绑定Servlet容器 public List<User> selectUser(HttpServletRequest request) { String username = request.getParameter("username"); // ... } // 正确示例：参数是业务值 public List<User> selectUser(UserQuery query) { // 直接使用query.getUsername() }

2. 三种参数传递姿势对比：别迷信某种唯一解

2.1 单参数传递：简单场景的默认选择

如果方法只有一个或者两个查询键，直接传String/Long就可以了。例如findById(Long id)、findByUsername(String username)。这种写法最简单，阅读起来也最直观。

但是超过三个参数，还要考虑组合查询时，方法签名会变得很长，调用方容易把参数顺序搞错。Java里没有命名参数，调用insertUser("张三", "123456", 1, "备注")这类代码，读起来完全是灾难。所以单参数适合“条件明确且数量少”的场景，不适合通用查询。

2.2 Map传参：灵活但类型安全几乎为零

用Map<String, Object>传参，DAO实现里可以随手put各种查询条件，看起来万能。我早期也爱写这种，因为加一个筛选条件不用改方法签名。后来被坑了几次：在Service层put了一个key，拼SQL时少写一个字母，编译期完全发现不了，跑到查询时才发现条件没生效。

而且Map把类型的约束也拿掉了，明明需要Integer的pageNo，put进去一个String "1"，DAO里还得做转换。你把这个数据拿给同事，他完全不知道里面有哪些key。Map适合给第三方接口、配置类数据、或极少数真正“动态”的场景用，业务查询里我不推荐把它作为唯一参数。

2.3 DTO / QueryObject 封装：JavaWeb里最稳的做法

我推荐的做法是：每个业务场景定义自己的参数对象。前端提交用户信息，就定义UserCreateDTO；后台按条件查用户列表，就定义UserQuery；新增文章后要返回详情，可能还需要ArticleVO。这些名字看起来多，但带来的收益非常实在：方法签名能说清楚参数是什么，IDE有提示，对象内部可以加校验逻辑，后续加参数不会破坏调用方。类型安全、可读性、可测试性都好很多。

2.4 为什么不能把HttpServletRequest当DTO用

有人会想：反正request里有所有参数，传给DAO不是更方便？麻烦在于DAO需要知道HTTP接口的数据结构，比如“从request.getParameterMap里拿”，这会让DAO和Tomcat强耦合。比如你后面想用SpringMVC改造，把相同逻辑写成一个定时任务，原来的DAO代码就不能用了，必须把所有request.getParameter都清理掉。

更隐性问题：request对象的生命周期是由容器管理的，如果在DAO里把它存进成员变量、放进缓存，可能造成内存占用和线程安全问题。所以传HttpServletRequest到DAO，是一条我强烈建议不要碰的红线。

3. Servlet层组装参数的完整实操：从request到对象

3.1 拿到request后先处理编码和默认值

Servlet里一开始要做两件事：解决中文乱码，设置请求编码；处理默认值。示例：

protected void doGet(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException { request.setCharacterEncoding("UTF-8"); response.setCharacterEncoding("UTF-8"); response.setContentType("application/json;charset=UTF-8"); // ... }

注意：request.setCharacterEncoding("UTF-8")必须在第一次读取参数之前调用，否则Tomcat已经按默认编码解析过，设置不会生效。另外，Tomcat 8.0以上版本GET请求的URI编码默认是UTF-8，但POST表单编码仍然要在代码里指定。

3.2 用BeanUtils把request参数映射到DTO

如果字段不多，手写setter没有问题；字段多时，用BeanUtils.populate能省很多事。Servlet里最常出现的一段代码：

UserCreateDTO dto = new UserCreateDTO(); Map<String, String[]> params = request.getParameterMap(); try { org.apache.commons.beanutils.BeanUtils.populate(dto, params); } catch (IllegalAccessException | InvocationTargetException e) { // 记录日志，返回400 }

这里有个坑：BeanUtils.populate会自动把String "1"转成Integer 1，但转换失败时会包一层InvocationTargetException，必须自行处理。如果你的DTO里有一个timestamp字段，而前端传了"2024-01-01T12:00:00"，要保证DTO的这个属性类型是String或java.time.LocalDateTime并注册对应的转换器，否则会抛异常。

3.3 手写参数工具，让数字解析更可控

BeanUtils虽然方便，但它是“全部自动转换”，业务上有些默认值和边界控制没法覆盖。所以我习惯同时做一个简单的ParamUtil：

public final class ParamUtil { public static int getInt(HttpServletRequest request, String name, int defaultValue) { String v = request.getParameter(name); if (v == null || v.trim().isEmpty()) { return defaultValue; } try { return Integer.parseInt(v); } catch (NumberFormatException e) { return defaultValue; } } }

然后Servlet里这样用：

UserQuery query = new UserQuery(); query.setUsername(ParamUtil.getString(request, "username")); query.setStatus(ParamUtil.getInt(request, "status", 0)); query.setPageNo(ParamUtil.getInt(request, "pageNo", 1)); query.setPageSize(ParamUtil.getInt(request, "pageSize", 10));

用这种方式，前端传pageNo=abc时不会让程序崩掉，会落到默认值，接口更健壮。不过要注意：不是所有字段都能给默认值，比如修改用户状态的status传了非法值，宁可校验失败也不要悄悄改成0。默认值只对分页、排序这类非关键参数用，业务关键参数必须显式校验。

3.4 真正关键的一步：Servlet只调Service，不碰DAO

组装完对象后，Servlet的逻辑应该很薄：

UserService userService = new UserService(); UserQuery query = ParamUtil.buildUserQuery(request); PageResult<User> page = userService.pageQuery(query); writeJson(response, page);

这里没有request.getParameter的散落，也没有SQL。参数对象在Servlet入口被构造好，Service层校验补充，DAO层消费。如果一定要让DAO直接暴露给Servlet，至少也要是DAO.pageQuery(query)这种写法。

3.5 分页参数与排序参数怎么封装

很多JavaWeb项目把pageNo、pageSize、sortField、orderBy散着传，DAO里再拼SQL。更好的姿势是定义PageQuery。例如：

public class PageQuery { private int pageNo = 1; private int pageSize = 10; private String keyword; private String sortField; private String order = "desc"; public int getOffset() { return (pageNo - 1) * pageSize; } }

这样传进DAO后，可以统一处理limit offset和排序白名单。后面要加“按分类筛选”“按时间筛选”，只需要在PageQuery里加字段，方法签名不用变，调用方也不会因为参数顺序错了找半天。分页返回结果也可以封装成PageResult ：

public class PageResult<T> { private long total; private List<T> list; private int pageNo; private int pageSize; }

DAO只负责查total和list，封装交给上层。很多初学者会在DAO里把total算出来再放到某个Map里返回，这不好，返回值描述不清晰。

4. DAO层接收参数的细节与底层原理

4.1 DAO方法签名设计：参数越少，耦合越低

数据访问方法最好满足“单一职责”。查询用户列表和统计用户总数的DAO方法，不要合成一个“返回Map自己看”。同样，参数能用一个对象表达的，就不要拆成五个散参数。如果我们写这样一个接口：

public interface UserDao { User findById(Long id); User findByUsername(String username); List<User> selectList(UserQuery query); int insert(User user); int update(User user); int deleteById(Long id); }

这个签名基本就是数据表的操作面。调用方不用管DAO内部是JDBC还是MyBatis，只需要把业务对象传进去。

4.2 MyBatis下多参数和参数对象怎么用

用MyBatis时，常见的误区是接口方法里写多个参数却不加@Param。比如：

// 错误：MyBatis找不到参数名 List<Article> selectByCondition(String keyword, Long categoryId);

如果你没加@Param，即使编译时带 -parameters，不同的MyBatis版本也可能报“There is no getter for property named 'arg0'”。正确写法是：

List<Article> selectByCondition(@Param("keyword") String keyword, @Param("categoryId") Long categoryId);

或者直接用对象：

List<Article> selectByCondition(ArticleQuery query);

XML里写：

<select id="selectByCondition" resultType="com.example.entity.Article"> SELECT * FROM article <where> <if test="keyword != null and keyword != ''"> AND title LIKE CONCAT('%', #{keyword}, '%') </if> <if test="categoryId != null"> AND category_id = #{categoryId} </if> </where> ORDER BY create_time DESC </select>

这里顺便说一个#{}和${}的选择：查询参数和写入值，全部用#{}，它是PreparedStatement的占位符，能防止SQL注入；${}是字符串拼接，只有动态表名、排序字段这种没法预编译的场景才考虑，而且要严格做白名单校验。

4.3 原生JDBC下怎么接收参数对象

如果你的项目还是最经典的Servlet + JDBC，DAO实现里应该怎么写？核心是PreparedStatement：

public User findByCondition(UserQuery query) { String sql = "SELECT * FROM user WHERE username = ? AND status = ? LIMIT 1"; try (Connection conn = dataSource.getConnection(); PreparedStatement ps = conn.prepareStatement(sql)) { ps.setString(1, query.getUsername()); ps.setInt(2, query.getStatus()); try (ResultSet rs = ps.executeQuery()) { if (rs.next()) { User user = new User(); user.setId(rs.getLong("id")); user.setUsername(rs.getString("username")); return user; } } } catch (SQLException e) { throw new RuntimeException("查询用户失败", e); } return null; }

注意，这里dataSource是一个DataSource对象，不是Servlet里new的Connection，也不是藏在request attribute里的连接。用数据源的好处是连接生命周期由连接池管理，DAO方法本身不关心事务边界。

4.4 insert之后怎么回填自增主键

新增操作中，经常需要拿到数据库生成的自增id。如果你用JDBC原生写法，可以这样做：

String sql = "INSERT INTO user(username, password) VALUES(?, ?)"; try (PreparedStatement ps = conn.prepareStatement(sql, Statement.RETURN_GENERATED_KEYS)) { ps.setString(1, user.getUsername()); ps.setString(2, user.getPassword()); ps.executeUpdate(); try (ResultSet rs = ps.getGeneratedKeys()) { if (rs.next()) { user.setId(rs.getLong(1)); } } }

如果你的DAO方法参数是User对象，这里直接给user.setId(...)回填即可，调用方拿到同一个对象，就能看到id。这就是对象引用的好处：你传递的是对象本身，而不是把属性复制一份。如果用MyBatis，在insert标签上写useGeneratedKeys="true" keyProperty="id"，效果一样。这个问题经常被忽略，很多人insert完想再执行一次select max(id)，这个做法在高并发下会拿到错误数据，别用。

4.5 为什么不能把Connection传进DAO方法

有些自己写JDBC课设的人会写出这种代码：DAO方法接收Connection conn参数，然后在Servlet或Service层统一创建Connection，传给所有DAO方法“共享事务”。比如：

public UserDao(Connection conn) { this.conn = conn; }

这在只有一两个表的课设里跑得通，但一旦接上连接池、换成多环境部署，问题就来了：Connection不是线程安全的，不能跨请求长期持有；把Connection当作参数在方法间传递，方法一多就会有人忘了关闭，连接泄漏只是时间问题。正确做法是让DAO内部通过DataSource获取连接，事务边界通过Service层的统一管理来完成。如果坚持原生JDBC，可以用ThreadLocal绑定一个连接实现简单事务，但不要把Connection写进每一个DAO方法签名。

5. 常见问题排查与避坑经验实录

5.1 POST中文乱码导致查询条件不一致

最常见的乱码根因是请求编码设置晚了。如果你的doPost里第一行就是String username = request.getParameter("username")，然后才设置setCharacterEncoding，这已经晚了。应该在Servlet入口最前面做编码处理，或者写一个CharacterEncodingFilter，让所有请求先过一遍filter。检查方法也简单：在前端输出接收到的参数，打印到控制台，看到“中文变成？？？”就把编码统一到UTF-8。

5.2 空字符串和null在动态SQL里造成的“条件失效”

前端输入框为空时，提交过来的常常是空字符串""，而数据库里是NULL。如果DAO里拼SQL只判断了if (query.getUsername() != null)，那空字符串也会参与查询，导致查不到数据。MyBatis里的标准写法是：

<if test="username != null and username != ''"> AND username = #{username} </if>

如果你用原生JDBC拼SQL，也要在Java里统一判断空字符串。我习惯用一个StringUtils.hasText()方法，它同时排除null、""和纯空格字符串。这一点细节能避免很多“明明有数据却查不出来”的诡异问题。

5.3 参数对象在多层之间被改得面目全非

Service层拿到DTO后，往往要补充一些DAO需要的字段，比如ip、operatorId、createTime，如果直接往DTO里塞业务字段，DTO就慢慢变成了“大杂烩”。我见过一个UserDTO里面20多个字段，既有页面传入的，也有后端计算的，还有数据库返回的。这个偏差怎么破？我的经验是：入参用DTO/Query，出参用VO/Entity，DAO返回值尽量和表结构对应。如果一定要复用同一个对象，至少让对象名能看出来是“入参”还是“出参”，例如UserDTO是入参，UserVO是出参。否则参数传递时，调用方根本不知道哪些字段需要填。

5.4 MyBatis报“There is no getter for property named...”

这种报错十有八九是从接口的多参数没加@Param开始的。记住这条规律：

• 单个参数（POJO或基础类型）不需要@Param；
• 多个参数必须加@Param；
• 参数超过三个，更建议用一个Query对象包起来。

加了@Param之后，XML里写#{username}就对应@Param("username")，不要再写#{param1}。

5.5 调试参数传递：把日志打到每层入口

我之前排查过一个Bug：前端传的status是"0"，但是查询结果没有按0过滤。最后发现是DAO里没有对Integer做null判断，直接把0当成了false拼条件。定位这种问题最快的方法是：Servlet入口打印一次参数对象，DAO入口再打印一次参数对象。看看对象是不是在中间被改过。甚至有项目里在DAO里打印request.getParameter，这种就真的很难查，因为你不知道request来自哪个请求。参数对象是透明的，打日志会清楚很多。用工具类统一打印：

log.debug("UserQuery: pageNo={}, pageSize={}, keyword={}", query.getPageNo(), query.getPageSize(), query.getKeyword());

6. 配套配置：让Servlet+DAO参数传递真正跑通的环境细节

6.1 IDEA里运行JavaWeb项目前要配好的几个地方

很多新手写Servlet+DAO时，问题不是代码，而是环境。我这里说几个我实测过有效的点，主要针对IDEA+Tomcat。第一，IDEA里一定要用“Web Application”类型的模块，或者Maven的war包，别建普通Java工程硬塞Web代码。第二，项目里的lib目录或者Maven依赖一定要把servlet-api、MySQL驱动、连接池加进去。如果用的是本地Tomcat，还要在Run Configuration里把Application server选成本地Tomcat，Deployment里挂上artifact：exploded。第三，经常会遇到404或找不到类的情况，多半是Artifact没有包含lib。右键项目打开Open Module Settings，在Artifacts下面把Available Elements里的依赖双击Add to WEB-INF/lib，这一步别漏。

6.2 不启动Tomcat也能测DAO：写一个main方法

参数传递是否正确，最直接的办法是脱离Servlet测试。我的习惯是给关键DAO写一个本地测试入口，比如：

public class UserDaoTest { public static void main(String[] args) { UserQuery query = new UserQuery(); query.setUsername("admin"); query.setStatus(1); UserDao dao = new UserDao(); List<User> list = dao.selectList(query); for (User user : list) { System.out.println(user.getUsername()); } } }

这个测试入口能证明“参数从对象到SQL语句”这一段是通的。如果这里都查不到数据，再去怀疑Servlet那边的编码和参数映射，不然你分不清问题到底在哪一层。这种“切分测试面”的思路，在做大项目时尤其重要。

6.3 顺手做一个参数装配助手类

如果你不想每个Servlet都写一堆parseInt和默认值，可以封装一个参数装配的小助手。它只处理“从request到业务对象”这一步，不涉及业务：

public class RequestParams { public static String getString(HttpServletRequest request, String name) { return trimToNull(request.getParameter(name)); } public static Integer getInteger(HttpServletRequest request, String name) { return getInteger(request, name, null); } public static Integer getInteger(HttpServletRequest request, String name, Integer def) { String v = trimToNull(request.getParameter(name)); if (v == null) return def; try { return Integer.valueOf(v); } catch (NumberFormatException e) { return def; } } }

这套工具本身也是一个“参数传递正确姿势”的落地：Servlet把原始字符串转成有类型的业务值，再把业务值封装进对象里，剩下的就是对象传参。不要小看这些辅助类，它能让Servlet层保持干净，也能让DAO层不碰HTTP细节。

7. 我的一点个人体会

写JavaWeb项目，参数传递这个环节往往最考验一个人的分层意识。我在实际改项目里见过太多“能跑但很脆”的代码，多半都是因为早期图省事：直接把request往下扔，用Map接参数，把DAO方法写成万能查询。这些代码单看都不致命，坏就坏在它们让每一层都在重复猜测参数结构。如果你试着在维护阶段往这种代码里加一个“按时间范围查询”，你会发现要从Servlet开始，把request.getParameter("startTime")逐个往下传，传到DAO再拼SQL，中间每一层都要跟着改，这就是参数没有用对象封装带来的连锁代价。

如果你正在写课程设计，或者刚开始接触项目分层，我的建议很朴素：从现在开始，把所有跨层参数都走“对象”这条路。DTO、QueryObject、VO这三个名字不复杂，用熟了之后，你会发现自己代码的可读性、可测试性都会上一个台阶。不用追求一步到位，哪怕只是先给查询条件建一个Query类，把pageNo、pageSize和筛选条件装进去，紧急程度就已经好过散参数一大截。这比提前研究会架构更实际。

最后再分享一个小习惯：每写完一个功能，问自己一句“删掉Servlet，这套DAO还能不能单独跑起来？”如果答案是不能，多半就是参数传递姿势出了问题，建议回炉重造。这个习惯我用了很多年，省下的调试时间比写那些DTO的时间多得多。项目这东西，功能多做几个月总能做完，但代码要是从底层开始就拧巴，后面每一个新需求都会额外收费。