在Java里如何实现小型博客发布系统_JavaWeb初级项目说明

Java Web小型博客系统需从请求链路、数据边界、用户动作三层面控制，禁用Servlet堆砌与SQL拼接，强制使用PreparedStatement和DAO层，JSP仅渲染且用JSTL与c:out转义，session只存必要字段并启用HttpOnly，关闭目录浏览与调试模式，URL设计遵循POST变更、ID不可猜原则。

Java Web 小型博客发布系统不是靠“搭个框架就完事”，而是得从请求链路、数据边界和用户动作三个层面控制住——否则很容易写成一堆 Servlet 堆砌，增删改查看似能跑，但加个分类筛选或分页就崩。

用 HttpServlet 处理增删改查，但别直接在 doPost 里拼 SQL

新手常把表单提交逻辑全塞进 doPost：取参数 → 拼 INSERT INTO ... → executeUpdate()。这会导致 SQL 注入风险、事务无法控制、后续难加校验。

• 所有数据库操作必须走 PreparedStatement，哪怕只是单条插入
• 把 DAO 层独立出来，比如 BlogDao.insert(Blog blog)，Blog 是带字段的 JavaBean，不是 Map
• 不要在 Servlet 中调用 System.out.println() 当日志，改用 log.info() 或至少写到 ServletContext.log()

protected void doPost(HttpServletRequest req, HttpServletResponse resp) throws IOException {
    String title = req.getParameter("title");
    Str
ing content = req.getParameter("content");
    Blog blog = new Blog(title, content);
    try {
        new BlogDao().insert(blog); // 走 PreparedStatement，自动处理引号与转义
        resp.sendRedirect("list.jsp");
    } catch (SQLException e) {
        req.setAttribute("error", "保存失败：" + e.getMessage());
        req.getRequestDispatcher("edit.jsp").forward(req, resp);
    }
}

JSP 页面只做展示，禁止在 里写业务逻辑

常见错误是把列表页写成：...，更糟的是在里面调 new UserDao().findByName(...)。

• JSP 只负责渲染，数据必须由 Servlet 提前查好、存进 request.setAttribute("blogs", list)
• 循环一律用 JSTL：${b.title}，禁用脚本片段
• 日期、空值、HTML 特殊字符（如用户输入的 ）必须转义：

登录态用 HttpSession 管理，但别存明文密码或整个 User 对象

有人把 user.setPassword(null) 后放进 session，以为安全了；其实只要 session ID 泄露（比如没设 HttpOnly），攻击者就能冒用。

• session 中只存必要字段：如 userId、username、role，绝不要存 password、email（除非加密且有理由）
• 登录成功后，立刻调用 session.setAttribute("loginId", userId)，并在每个需鉴权的 Servlet 开头检查：if (session.getAttribute("loginId") == null) { resp.sendRedirect("login.jsp"); return; }
• web.xml 中配置 truefalse（开发时 secure=false，上线 Nginx 反代 HTTPS 后改为 true）

部署前必须关掉 web.xml 的目录浏览和调试模式

Tomcat 默认开启 listings=true，如果没写 index.jsp，访问 /blog/ 就会列出 WEB-INF/ 下所有文件——包括 web.xml 和配置文件路径。

• 在 $CATALINA_HOME/conf/web.xml 中找到 default，把 listingsfalse
• 确认项目 web.xml 中没有 1 或类似调试开关
• 检查 WEB-INF/web.xml 是否存在未注释的 ，避免暴露内部结构

最易被忽略的其实是 URL 设计：别让 /delete?id=123 这种裸 GET 请求承担删除职责，也别把用户 ID 直接暴露在路径里（如 /user/7/edit）。哪怕只是初级项目，也要默认按「POST 才变更」「ID 不可猜」来约束接口行为。