正文

JavaWeb网站源码_JavaWeb项目完整源码结构与解析

haitao
haitao V管理员 /130阅读/0评论
0320
此篇文章发布距今已超过112天，您需要注意文章的内容或图片是否可用！

是不是还在调试着那种十年前样子项目的结构所出现的放在今日的报错，不要再那么不厌疲惫地去翻教程，这儿直接就给你条理清晰地拆解明白。

Maven项目目录到底该怎么放

讲一下最关键的src/main/java，此目录是放置你全部Java类的仅有位置，controller放于此，service放于此，dao也放于此，别自作聪明在其他地方新建什么source文件夹。到了2025年，仍在用Eclipse手动创建项目的人应该不多了，不过用IDEA生成Maven项目时，有人还是会选错选项致使目录不完整。

再一个关键的目录是src/main/resources ，所有的配置文件全都是归这里来管理的。传统的那种项目会将web.xml放置在src/main/webapp/WEB-INF之下 ，然而Spring Boot项目却是直接在resources里面放置application.yml ，甚至连webapp文件夹都是可以不需要的。要是你发觉自己项目当中的WEB-INF跑到src的下面去了 ，那就表明要么是在项目创建的时候选错了骨架 ，要么是有别人手动胡乱移动文件了。

诸多报错诸如404找不到页面，或者配置未生效，追根溯源其根本原因，乃是web.xml所处位置并非其应在之处。于外部容器进行部署之际，务必要确保WEB-INF处于项目根目录之下，不然容器便无法读取配置，如此一来，你所写的servlet映射就全然白费了。

web.xml里哪些代码可以放心删除

去翻看那些老旧教程之中的web.xml，动不动就有几十行的配置，从字符过滤器一直到Servlet映射，满满当当地写满了一篇。然而在Spring Boot 2.0以上的版本里面，许多配置已然变成了自动装配的内容。比如说CharacterEncodingFilter，Boot早就借助ServerProperties帮你配置好了，要是再手动去写一遍，反倒有可能和默认配置产生冲突。

同样，采用@WebServlet以及@ServletComponentScan去替换掉web.xml之中的Servlet声明已然属于主流的做法，如果你运用的是Spring Boot所内嵌的Tomcat，那么完全能够将整个web.xml都删去，仅仅保留注解扫描。除非你所维护的是一个在2015年之前的老旧项目，不然要是留着那些手动映射的话，只会导致维护成本有所增加。

处于另外一种情形下，是从复制粘贴而来的配置之中，留存着旧版本的DTD声明，举例呈现为web-app_2_3.dtd ，这般状况会致使容器运用老标准对文件予以解析，使得注解扫描之类的功能径直失效。在升级到Servlet 4.0或者5.0的声明之后，老配置应当删除就要删除。

JSP页面返回源码是什么原因

2023年往后，新建的Spring Boot项目，默认连JSP支持都没有了。若你把JSP文件放置在src/main/webapp下，接着用内嵌Tomcat直接启动，访问页面时看到的极有可能是JSP源码。这是由于Boot 2.3之后的内嵌容器默认不加载JSP引擎，需要手动添加依赖并配置路径。


  encodingFilter
  org.springframework.web.filter.CharacterEncodingFilter
  
    encoding
    UTF-8
  


  encodingFilter
  /*

还有一个常见的错误情形是，将JSP放置在了并非/WEB-INF/views之外而非其他特定位置的地方，而是直接放置在了webapp根目录之下。当进行访问的时候，如果容器没有配置JspServlet，那么该文件会被当作静态资源予以返回。应当检查一下你所使用的访问URL，要是直接访问/hello.jsp却返回的是纯文本，这就表明容器根本没有把jsp后缀交付给Jasper引擎去进行处理。

将其部署至外在的Tomcat之际，务必要保证在打包成为war之后，WEB-INF/lib这个目录之下存在着与jsp-api以及jasper相关的jar包。有好多人于使用Maven进行打包之时，把依赖scope配置成为了provided，最终在部署之后出现缺少包的情况，致使JSP无法进行解析，这同样也是返回源码的重灾区所在。

MySQL连接时用localhost为啥报错

JDBC连接之中，localhost和127.0.0.1并非同一回事。于Linux或者macOS之上，localhost默认借助Unix socket文件开展连接，然而127.0.0.1则强制通过 TCP/IP进行连接。要是你的MySQL仅仅绑定了127.0.0.1，并没有监听socket，那么使用localhost便无论如何都连接不上，可是使用127.0.0.1却能够正常连接。

在WSL 2这种环境状况下，此问题显得格外突出，众多人于Windows上运行IDEA，而MySQL安装于WSL的Ubuntu之中，此时运用localhost进行跨环境socket通信会遭遇失败情形，必须将其改成127.0.0.1方可实现TCP连接，在排查的时候不要仅仅把目光聚焦于用户名密码此处，要先尝试一下IP是否能够连通。

又有一个被坑得稀烂的参数是useSSL=false，MySQL 8.0往后默认要求SSL连接，要是不添加这个参数并且没有配置证书，驱动就会抛出异常，而且异常信息当中根本不会提及SSL的情况，仅仅只会说“Communications link failure”，你查找半天防火墙以及端口，最终发觉添加一个参数便能够解决。

项目标准结构对新手有多重要

我曾见识过一个项目，存在这样的情况，有人将Java类放置于src/main/java，这倒并无问题，然而却把application.yml置于了src/main/java/config之下。在这种状况下，当Spring启动之时，无论如何都无法成功加载配置，进而报错声称数据源未进行配置。为此折腾了两日，最终才发觉是配置文件的位置出现了错误，将其移回resources目录后，立刻就恢复正常了。

居然还有更离谱的情况，那就是把web.xml放置在src/main/resources里面，随后声称容器启动的时候报错，提示找不到监听器。这种结构犯错的状况在接手他人代码之际格外常见，特别是那种从网上东拼西凑而来的项目，其目录混乱得一塌糊涂。你只需牢记一项铁定的规则：Java类必定要在java之下，配置文件必定要在resources之下，页面文件必定要在webapp之下，如此便能节省80%的调试用时。

此时此刻，诸多IDE于创建项目之际，会自动生成正确的结构，然而，要是你把Maven Archetype勾选错误，举例而言，选择了quickstart而非webapp，那么webapp文件夹根本就不会予以生成，必须得手动去创建。

配置错误的排查思路其实很简单

如果你碰到404这种情况或者配置出现失效此种状况时，首先的反应别去查看代码逻辑，而是先去确认文件所处位置是否正确。要检查war包解压之后的情形，看看其目录结构是咋样的，瞧瞧web.xml是不是放置于叫做WEB-INF的里面，瞅瞅class文件是不是处于WEB-INF/classes这个下面。要是这些基础位置出错了，即便代码编写得再好都没办法运行起来。

在Spring Boot项目启动阶段，若添加--debug参数，能够输出自动配置报告，以此查看哪些配置类处于生效状态。举例而言，倘若你已然编写了字符过滤器，然而报告中却呈现未生效的情况，那么大概率是自身所写的配置与自动装配产生了冲突，此时将手动配置删除即可。

在此最后问你一回问题：你最近遭逢的那回项目启动之际出现报错的情况，究竟是源于代码逻辑方面的问题，还是起因于文件放置在了错误的位置？在评论区域把你的踩过坑的经历讲一讲，给这一篇点赞并收藏起来，下次配置项目的时候直接依照着去检查一番。