Servlet+JSP打造非遗电商：织金砂锅推广平台项目实战解析

1. 织金砂锅推广平台到底在推广什么：需求分析先于代码

很多人一看到"Servlet + 家乡特产 + 推广平台"的组合，第一反应是：这不就是一个课设级别的Java Web项目吗？能有什么含金量？说实话，我一开始也是这么想的。但真正把这个项目从里到外捋了一遍之后，我得承认，这个项目最值得借鉴的地方反而不是那几行Servlet代码，而是它背后对"推广"二字的理解——它没有做成一个简单的商品列表页，而是把非物质文化遗产的展示逻辑、手工艺品的信任背书、地域文化的沉浸感全部揉进了一个传统Java Web项目里。

织金砂锅这个东西，懂的人知道它是贵州织金县的传统手工艺品，用当地特有的无烟煤和粘土烧制，耐高温、不裂不炸，煮出来的东西有独特的风味。但它和普通的工业锅具不一样的地方在于——它没有标准化的外观，每一口锅的纹路、色泽都是手工烧制的结果。这就带来一个非常现实的问题：用户隔着屏幕凭什么信任你？这就不是单纯的技术问题了，而是产品运营和内容设计的问题。这个项目在需求层面其实暗含了几条隐藏主线：

• 用户端要能直观感受到织金砂锅的"手工感"和"文化感"，不能把它做成一个冷冰冰的工业品超市；
• 商品展示要有足够的细节维度，比如工艺介绍、材质说明、使用场景，甚至要有历史渊源；
• 管理端要能灵活维护这些内容，毕竟产品信息和图文资料是动态变化的，不可能每次更新都找开发改代码；
• 整个项目要轻量、可部署、易演示，毕竟很多场景下它是一个教学样例或者课程设计，不能依赖复杂的中间件和分布式组件。

如果把需求只停留在"商品增删改查 + 购物车 + 订单"这个层面，那这个项目就只是一个玩具。但一旦把"推广"两个字真正落到功能设计上，你会发现，它其实是一个带有内容管理属性的展示型电商系统。前端页面需要有品牌故事的承载位，商品详情页需要有文化栏，首页不能只是横幅加商品瀑布流，还要有工艺流程图、历史传承的叙述段落。这些需求看起来不复杂，但放在Servlet这种传统技术栈里实现，对代码组织能力的要求其实比想象中要高得多。

2. 为什么还在用Servlet写这种平台：技术选型的现实逻辑

我知道很多人看到"Servlet"三个字就想划走。2024年了，Spring Boot都卷到3.x了，谁还用Servlet？这里我想说一个可能不太讨喜但非常真实的观点：对于一个以学习和演示为核心目标的项目，Servlet恰恰是最合适的选择之一，前提是你知道自己在做什么。

先看基础技术栈，这套项目通常是这样的组合：

这套组合放在今天确实"复古"，但它的好处也非常直接：没有自动配置、没有约定优于配置、没有AOP和IoC那一套魔法。每一个请求从Tomcat接收到Servlet的doGet/doPost，再经过DAO层到数据库，链路完全透明。你在学习这个项目的时候，能把HTTP协议、Servlet生命周期、Session机制、JDBC事务这些东西看得一清二楚。这些东西如果你直接在Spring Boot里写，框架帮你屏蔽掉了，出了问题你反而不知道底层发生了什么。

再说项目本身的特点。织金砂锅推广平台的核心业务并不复杂，用户注册登录、商品展示、购物车、下单、后台管理，这些功能用Servlet手动写，代码量完全可控。相反，如果强行上一个Spring Cloud微服务架构，那才叫杀鸡用牛刀，光服务拆分和配置中心就够把人绕晕。所以这个项目的技术选型并不是落后，而是匹配了它的业务复杂度和部署场景——你只需要一个Tomcat加一个MySQL就能跑起来，没有任何Docker、Kubernetes、Redis、消息队列，这对一台普通学习机或者本地虚拟机来说太友好了。

还有一个很多人会忽略的点：Servlet项目的调试过程能锻炼人。写Controller的时候遇到问题，你第一反应可能是看日志、打断点、检查注解有没有写对；写Servlet的时候遇到问题，你得手动检查web.xml的映射、请求路径的匹配、表单字段名和getParameter是否一致、响应编码是不是UTF-8。这些都是最基础但最容易出错的细节，踩过一遍以后，你再去学Spring MVC，会突然理解很多"框架替你做的事"到底是怎么回事。

2.1 项目目录结构与分层思路

这套项目的典型包名结构是这样的：

com.example.sandpot ├── entity // 对应数据库表的实体类 ├── dao // 数据访问层，JDBC操作 ├── service // 业务逻辑层 ├── servlet // Web控制层 ├── util // 工具类（DBUtil、MD5工具等） ├── filter // 编码过滤器、登录过滤器 └── listener // 启动监听，加载基础数据

这个分层是标准的MVC变体，Entity对应Model，Servlet对应Controller，JSP对应View。有人会问，Service层在Servlet项目里是不是多余的？我的看法是，哪怕业务再简单，Service层也值得保留。比如下单这个动作，涉及库存校验、订单生成、购物车清空三个操作，如果全部写在Servlet里，代码会越来越臃肿。拆一个Service层出来，不只是为了让代码好看，更重要的是：你可以单独对业务逻辑做单元测试，而不需要启动整个Web容器。在这个项目里，Service层还承担了一个特殊任务——很多非遗文化内容的默认排序和展示规则，就是放在Service层统一处理的，这样页面层不需要关心数据怎么取，只负责渲染。

3. 从登录到下单：核心功能代码的落地过程

这一章我们直接进代码，把这个平台最关键的几个功能链路拆开看。不追求把每个类完整贴出来，那样篇幅太长，重点讲清楚每个环节的设计思路和关键实现。

3.1 用户注册与登录：Session管理不能只看能不能用

登录功能是几乎所有Web项目的入口，但Servlet项目里它的细节特别多。用户提交用户名和密码后，Servlet首先要处理的是编码问题，否则中文用户名会乱码。这个项目通常会在web.xml里配置一个编码过滤器：

<filter> <filter-name>CharacterEncodingFilter</filter-name> <filter-class>com.example.sandpot.filter.CharacterEncodingFilter</filter-class> <init-param> <param-name>encoding</param-name> <param-value>UTF-8</param-value> </init-param> </filter> <filter-mapping> <filter-name>CharacterEncodingFilter</filter-name> <url-pattern>/*</url-pattern> </filter-mapping>

或者在代码里手动设置request.setCharacterEncoding("UTF-8")。密码存储方面，原项目如果直接用明文，建议你自己做一次升级，用MD5加盐处理。比如用户注册时生成一个随机盐值，存储MD5(password + salt)，这样即使数据库泄露，也不会直接暴露明文密码。

登录成功后的Session处理是一个容易出问题的地方。正确做法是登录成功之后重新生成Session，防止Session Fixation攻击：

req.getSession().invalidate(); HttpSession session = req.getSession(true); session.setAttribute("userId", user.getId()); session.setAttribute("nickname", user.getNickname());

很多初学者图省事，直接session.setAttribute完事，实际上存在会话安全问题。这个项目因为要面向公众演示，安全这块不能太糊弄。但也要注意，Servlet项目的登录检查过滤器一定要把静态资源和登录接口排除掉，否则CSS都加载不出来，页面会变得惨不忍睹。有一种常见的错误写法是把所有路径都拦截，然后白名单里放过/login、/register，但忘了静态资源，结果整个页面没有样式，愣是看不出是登录页还是博客。

3.2 商品展示：分页查询和详情页的SEO意识

织金砂锅的商品展示，不能简单走一个List<Product>全量查询。这个平台的商品数量虽然不会太多，但推广平台的核心诉求是让用户尽快找到感兴趣的内容，所以分类过滤和分页是关键。DAO层最常见的写法是：

public List<Product> findByCategoryAndPage(int categoryId, int offset, int limit) throws SQLException { String sql = "SELECT * FROM products WHERE category_id = ? LIMIT ?, ?"; // 使用PreparedStatement预编译，防止SQL注入 try (PreparedStatement ps = conn.prepareStatement(sql)) { ps.setInt(1, categoryId); ps.setInt(2, offset); ps.setInt(3, limit); try (ResultSet rs = ps.executeQuery()) { // 遍历结果集，封装List<Product> } } }

注意这里LIMIT ?, ?在MySQL里占位符类型要特别小心，JDBC里setInt和setInteger混用会导致类型不匹配的报错，而且这个错在MySQL 5.7和8.0中的表现还不一样。实测下来，8.0对类型更严格，报错更早，反而更好排查。

商品详情页在这个项目里有特殊的意义。织金砂锅不是普通标准品，用户打开详情页不只是看价格，更想看工艺、材质、产地故事。所以详情页的数据并不仅仅来自商品表，还要联合查询工艺介绍表和文化故事表。这种设计看起来是"过度建模"，但恰恰是这套系统的灵魂——它让每个商品详情页都有内容可看，而不是三两行参数加一个购买按钮。从SEO角度看，每个详情页有独立的、丰富的文字描述，也更容易被搜索引擎收录。一个推广平台最怕的就是页面内容太薄，用户进来逛一圈就走，停留时间短、跳出率高。

3.3 购物车与下单：事务边界是底线

购物车有两种常见实现方案：存Session和存数据库。存Session实现简单，但用户换设备就丢失；存数据库体验更好，但需要额外的购物车表。对于一个以推广为主要目的的平台，我建议折中——游客用Session购物车，登录后用数据库购物车，下单时合并。不过考虑到代码复杂度，原项目往往直接在登录状态下使用数据库购物车，这样订单生成、库存扣减、购物车清除可以放在同一个JDBC事务里。

下单流程的事务边界是这样的：

Connection conn = null; try { conn = DBUtil.getConnection(); conn.setAutoCommit(false); orderDAO.createOrder(conn, order); // 插入订单表 orderItemDAO.batchInsert(conn, orderItems); // 插入订单明细 productDAO.deductStock(conn, productId, quantity); // 扣减库存 cartDAO.clearCart(conn, userId); // 清空购物车 conn.commit(); } catch (SQLException e) { if (conn != null) { conn.rollback(); } throw new RuntimeException("下单失败", e); } finally { if (conn != null) { conn.setAutoCommit(true); conn.close(); } }

这段代码的核心在于：所有关于订单的操作要么全部成功，要么全部回滚，绝不能出现订单生成了但库存没有扣减的情况。很多初学者写的下单代码是每个DAO方法内部自己取连接、自己关闭，这样事务天然就是割裂的，订单表有数据但库存没动，后面对账就会出大问题。在这个项目里，我强烈建议把DBUtil改成能传外部连接进去的方式，而不是每个DAO方法内部都getConnection()。这是从"能跑"到"会正确跑"的关键一步。

3.4 购物车的Session化：前后台分离思路的雏形

虽然下单用数据库购物车，但购物车的Session化方案还是值得一说。假设用户未登录，他想先看看砂锅、把喜欢的款式加进购物车，等他注册登录后再合并。这个场景在这个推广平台上非常常见——很多人第一次来就是随便逛逛，不可能一上来就注册。实现Session购物车时，CartItem比实体类更灵活：

public class CartItem { private int productId; private String productName; private double price; private int quantity; private double subtotal; // getters and setters }

用户登录时，把Session购物车的数据合并进数据库购物车，然后清空Session。这个逻辑说起来简单，但真正实现时要注意商品价格应该以后端查询为准，不能直接用Session里存的快照价格，否则用户在页面停留很久后管理员改了价格，订单还是按旧价格算，这就说不清了。合并购物车的最佳时机是登录认证成功后的第一时间，而不是用户主动点"去结算"的时候。

4. 让非遗特产"活"起来：内容运营模块的设计与用户留存

一个纯粹卖商品的电商页面，很难让用户对织金砂锅产生购买欲望。毕竟，一口手工砂锅的价格不低，而且替代品很多，用户凭什么要选它？这个项目的聪明之处在于，它在商品之外设计了一套内容运营模块，把非遗文化变成了无形的"商品包装"。这也是我认为整个项目中最值得单独拿出来讲的部分。

4.1 栏目的两级结构：品牌故事与工艺百科

后台管理里通常设置两类栏目，一类是品牌故事，另一类是工艺百科。品牌故事讲的是织金砂锅的历史渊源、传承谱系、匠人精神；工艺百科则是更偏知识性的内容，比如砂锅为什么耐高温、为什么要用无烟煤、怎么开锅养锅。

这两类内容需要的数据结构完全不同。品牌故事需要大篇幅图文，工艺百科则需要条目式、分类式的组织。所以在设计数据库时，不建议共用一张文章表，而是分成两张：

• brand_stories：标题、正文、封面图、发布时间、作者；
• craft_articles：标题、分类、摘要、正文、关联商品ID、排序、是否置顶。

为什么要把关联商品ID放进工艺百科？因为用户在阅读"如何开锅"的文章时，最自然的行为是看看有没有配套的砂锅可以买。这两种内容之间如果建立了关联关系，每一次内容阅读都可能成为一次进入商品页的入口。

4.2 后台管理的细节设计：富文本与图片上传是硬需求

内容运营不可能只靠手工在数据库里写HTML，所以后台管理必须支持富文本编辑器和图片上传。在Servlet技术栈里，文件上传通常用Commons FileUpload，配置一个上传Servlet：

ServletFileUpload upload = new ServletFileUpload(new DiskFileItemFactory()); List<FileItem> items = upload.parseRequest(request); for (FileItem item : items) { if (!item.isFormField()) { String fileName = System.currentTimeMillis() + "_" + item.getName(); File file = new File(uploadDir, fileName); item.write(file); // 将访问路径存入数据库 } }

这里有一个很关键的坑：上传目录不能放在项目部署目录内部（比如webapps/项目名/upload），因为Tomcat重启或者重新部署时会把旧文件清理掉。正确做法是在服务器上分一个独立的uploadDir，比如/data/sandpot/upload，然后通过Tomcat的虚拟目录映射或者项目里写一个下载Servlet来访问这些图片。很多在校学生做完项目交上去的时候，图片能显示，结果一重新部署就全丢了，就是这个原因。

富文本内容本身要注意存储编码，MySQL表的字段类型建议用LONGTEXT，并且表的字符集统一为utf8mb4。很多情怀故事里会有一些生僻字，或者特殊标点，用utf8在某些字符上是存不进去的，会直接报错或者变成问号。

4.3 内容推荐位：把文化流量导向商品

首页的设计是另一个细节密集区。这个项目通常会在首页放几个推荐位：

• 轮播图：放匠人工作场景、烧窑过程、成品特写；
• 推荐商品：标记精选工艺的商品列表；
• 最新故事：从品牌故事表里取最近发布的两篇；
• 热门工艺文章：按浏览量排序的工艺百科Top 5。

这些数据在首页一次性查出来，如果每个模块都单独写DAO，性能不一定差，但代码会很碎。实际项目中更常见的做法是写一个HomeAggregationService，专门负责聚合首页所有模块的数据，返回一个HomeData对象。这个对象里有商品列表、故事列表、热门文章列表，JSP直接用EL表达式渲染。这种聚合Service的思想非常重要，它让你看不到一堆零散的getXXX()调用散落在页面标签里，而是把"首页需要什么"这件事在Java代码里表达清楚了。

5. 源码下载后的环境准备：从JDK版本到部署的完整链路

拿到源码之后，最痛苦的往往不是读代码，而是把环境跑起来。这里我把整套弄链路的步骤和坑按顺序捋一遍，照着走基本一次过。

5.1 数据库脚本导入的常见坑

SQL脚本导入时有几个非常容易翻车的点。第一个是MySQL 8.0的认证方式，如果你的驱动版本太旧，连接时会报Unable to load authentication plugin 'caching_sha2_password'，解决办法是换用8.x的驱动或者把用户密码改回mysql_native_password。第二个是时区问题，JDBC连接串里建议加上serverTimezone=Asia/Shanghai&useSSL=false&characterEncoding=utf8。第三个是MySQL 5.7和8.0对分页语法LIMIT ?, ?的行为差异，JDBC里的占位符类型不能搞混，否则会报TypeError。

5.2 在IDEA里部署Tomcat的方式

现在的IDE基本都内置了Smart Tomcat插件，或者直接用官方Tomcat集成。要注意的是，Deployment选项卡里要把这个项目的war包或者exploded目录配到Tomcat的webapps下，Context Path建议设成/sandpot，不要设成/，否则和Tomcat自带的管理界面路由冲突。另外，Application context设置决定了你访问时的URL前缀，比如http://localhost:8080/sandpot/index，这个路径和web.xml以及项目内部页面的跳转路径必须保持一致，否则点着点着就404。

5.3 部署到远程服务器的注意点

如果要把系统部署到云服务器上给更多人访问，有几点要特别注意。MySQL不能只监听localhost，需要开放3306端口，但不管怎么开放，密码一定要够强。backup目录要单独建立，定期把数据库dump出来，因为你永远不知道哪次重启会丢数据。Tomcat的启动内存要给够，默认的128MB可能不够跑多个JSP会话，修改catalina.sh里JAVA_OPTS加一行-Xms256m -Xmx512m基本就稳定了。

5.4 项目演示时容易被追问的细节

课程设计答辩或者项目展示时，评委大概率会问这些问题，得提前准备：

• 购物车存在Session里还是数据库里？为什么这么选择？
• 用户密码是怎么加密的？有没有加盐？
• 下单时数据库事务是怎么控制的？
• 如果库存不足，系统会怎么处理？
• 商品图片上传后存在哪里？重新部署会不会丢？
• 有没有做过防SQL注入处理？

每一个问题背后都对应着一段代码，你只要能定位到具体文件并且说清楚设计意图，这个项目的含金量就完全不一样了。怕就怕只是把代码跑起来但一问三不知，那就真的浪费了。

6. 实战经验集中营：我在复现这个项目时踩过的问题

接下来分享几个我在本地复现和改造这个项目时实际踩过的坑。这些问题的报错信息五花八门，但根因逻辑都很有代表性。

6.1 getParameter中文乱码的前世今生

在中文字符处理上，Servlet项目的坑是最经典的。情况一：表单用POST提交，未设置编码，request.getParameter("username")读出来乱码。解决方法是设置请求编码：

request.setCharacterEncoding("UTF-8");

这个要在getParameter之前调用，否则不会生效。情况二：URL直接带中文参数，那是GET方式，上面的方法无效，必须修改Tomcat的server.xml，在 Connector 里加URIEncoding="UTF-8"。推荐的做法是两者都做，双保险。

6.2 JSP页面EL表达式不生效的坑

如果JSP页面直接写出了${product.name}而不是显示值，多半是web.xml里的Servlet版本声明太低。Servlet 2.3及之前的web.xml默认EL是关闭的，需要把web-app的version改成3.1或更高。这种情况在把Tomcat 7的项目往Tomcat 9迁移时特别常见。

6.3 图片路径404的排查思路

图片上传后在页面上显示为404，第一反应不要去看代码逻辑，先确认图片文件到底存到哪里了。用浏览器直接访问图片地址，看Tomcat控制台有没有输出FileNotFound。如果Tomcat控制台没有异常信息，但浏览器就是404，那多半是虚拟目录映射没有生效。解决方法是Tomcat的server.xml里加一个Context，或者在项目的web.xml里配置静态资源映射。

还有一种更隐蔽的情况：你用了request.getServletContext().getRealPath("/upload")来获取上传目录，但Tomcat部署时用的是war包，这个realPath指向的目录在Tomcat重启后会清空。这就是为什么我一直强调不要在项目内部目录存用户数据。

6.4 密码加密的进化路径

源码里如果直接存明文密码，演示时容易显得不专业。建议改造方向：先做一个MD5Util，然后引入加盐机制。盐值可以直接用用户ID或注册时生成的UUID，存库时把盐和哈希密码存成两个字段。这样改起来工作量不大，但明显提升了项目的完成度。

7. 给正在学习和二次开发的人的建议

这套项目可以继续扩展的方向真的不少，而且难度递增，适合不同水平的人选择：

• 初级扩展：整合富文本编辑器、增加商品多图画廊、使用缓存优化商品列表页；
• 中级扩展：引入Maven的WebFilter做一个防XSS过滤，把JDBC切换成MyBatis或Spring JDBC Template，增加一个搜索功能，可以按商品名或工艺特色模糊查询；
• 高级扩展：把项目重构成Spring Boot，前端改成Vue，但保留原有的业务逻辑不变，这样你会惊讶于我原来的Servlet代码到底帮Spring Boot省了多少事。

我在实际摸索这个项目时的最大感受是：越是用这种"裸"技术栈，越能理解Web应用的本质。织金砂锅这个选题也很有意思，它让我第一次意识到，技术项目的感染力不完全来自技术本身，也来自它承载的内容，把传统文化和电商逻辑结合好，代码的价值就不再只是一份课设作业，而是一个真正有可能被当地人用起来的工具。

有动手条件的，建议你在本地把项目跑起来，然后尝试自己做一次"升级"。把某个底层实现换掉，然后对比前后代码量、维护难度和运行效率的差异。这个过程中的收获，绝对比只读十篇教程都大。