第一次打开实验指导书的验报时候，我盯着“配置Tomcat服务器”这几个字看了半天，告心心里想的得体全是：这玩意儿到底跟我平时写的那些静态页面有什么关系？结果第一次部署就给我来了个下马威——web.xml里一个servlet映射路径写错了，浏览器直接甩了个404，验报连个错误提示都不给。告心我对着Eclipse的得体Console面板翻了十几分钟，才在一个不起眼的验报warning里找到线索。这种“报错不报因”的告心体验，贯穿了整个web实验。得体

做用户登录模块那次，验报我算是告心真正理解了session和cookie的区别。课本上讲得清清楚楚，得体什么“session存储在服务器端，验报cookie存储在客户端”，告心背都能背下来。得体但当我真正写代码的时候，问题来了：用户勾选“记住我”之后，关掉浏览器再打开，登录状态还在，但session里的用户信息却丢了。我一开始以为是session超时设置的问题，改了半天web.xml里的<session-timeout>，没用。后来才反应过来，session本来就依赖cookie来传递JSESSIONID，浏览器一关，会话cookie没了，session自然找不回来。要持久化登录，得自己写cookie，把token存进去，下次请求时再拿token去数据库或者缓存里换用户信息。这个逻辑绕了一圈，但想通了之后，再看那些“session和cookie的区别”的面试题，感觉完全不一样了。

数据库连接池那块也踩了坑。实验要求用DBCP配置连接池，我照着文档把context.xml写好了，测试的时候单次请求没问题，但用JMeter模拟20个并发用户的时候，系统直接卡死。查了半天，发现是连接泄漏——我在DAO层里拿了Connection之后，某个分支里忘记close了。平时单用户测试根本看不出来，因为连接池里空闲连接够用。但并发一上来，连接被耗尽，后面的请求全在等。这件事让我养成了一个习惯：不管代码逻辑多简单，Connection、Statement、ResultSet这三个东西，必须写在try-with-resources里。省事，也省心。

前端那边也不是省油的灯。Ajax请求跨域的时候，浏览器控制台报CORS错误，我一开始以为是后端没加Access-Control-Allow-Origin头，加了之后还是不行。后来发现是预检请求（OPTIONS）被Spring Security的过滤器拦了，根本没走到Controller。这个问题的排查过程挺有意思：我先用Postman发请求，没问题；再用curl，也没问题；一到浏览器就挂。最后在Chrome的Network面板里看到，浏览器先发了个OPTIONS请求，返回403，然后真正的POST请求压根没发出去。解决方式是在Security配置里放行OPTIONS请求。这种“浏览器和工具行为不一致”的情况，在web开发里太常见了，也让我养成了“以浏览器实际行为为准”的调试习惯。

整个实验做下来，最大的感受是：web开发里，很多问题不是“知不知道”的问题，而是“遇没遇到过”的问题。你可以在课本上把HTTP状态码背得滚瓜烂熟，但只有真正被302重定向绕晕过、被304缓存坑过、被502网关错误搞到怀疑人生，那些数字才会变成你的直觉。实验报告写到最后，我没怎么堆砌技术名词，反而把每个bug的排查过程记了下来。这些东西，比任何标准答案都值钱。