实况：老菜鸟自力更生从零开始重学spring目标是画出一张唬人大图（一、起步阶段）

互联网公司当螺丝几年后我掌握的东西

1. 用学习版IDEA写java，用git管理版本。jar包依赖管理工具用的是maven，业务场景基本是web服务端。
2. 写完之后代码push到git上大功告成。自动化集成工具会自动从git上拉代码、打包、发布到服务器上。
3. 打包成war的代码，是运行在已经部署了Tomcat的docker服务器上，从而可以接收http请求并进一步处理。
4. IDEA里的代码结构（目录）基本上就下面这种：

--src\
	--main\
		--java\
		--resources\
		--webapp\
			--WEB-INF\
				--web.xml
	--test
	

显然，tomcat能够监听http请求并转交给war包进行处理，和webapp这个目录下的东西有关。

5. 在写服务端代码基本就是三板斧maven+spring+mybatis，调试的时候就是用idea自带的本地tomcat。
6. 对spring的了解非常皮毛：一堆xml配置文件，spring启动时扫描配置文件和注解，解析出一堆bean definition并生成最终的bean，核心思想是依赖注入和控制反转（懵懵懂懂，别人都这么说）。至于spring aop的了解更是连皮毛都算不上。
7. springboot本质上就是spring，但是使用更简单的spring，不再需要那么多xml的配置。

首先搞清楚我写的java代码是怎么运行在服务器上的？

1. 我写的代码是*.java，经过编译器编译后生成了*.class文件，对于这个*.class文件其实我也懂得不多，我只知道它可以被JVM运行。正准备百度一番，突然想到时代变了，可以直接问一下AI：
   

哦这下就比较清楚了（AI牛逼！），.class又叫字节码文件，只依赖于JVM，不依赖于计算机硬件和操作系统，我的.java代码必须先经过javac编译成*.class之后才可被JVM运行。

2. 但是我部署在服务器上的东西是war包，而不是一堆*.class文件，那么war包和*.class又是什么关系呢？再问下AI：
   
   原来如此，我项目里除了*.java，确实还有一大堆*.xml文件，可能还有图片啥乱七八糟的，都打包在一起就是war包了.
3. 不过，我清楚的记得，我写的代码只有业务代码，其它过程例如过如何拦截一个http请求，请求怎么解析的，如何“转发”给我的代码，这些我从来没有关心过，因此这些东西不是我的war包处理的。还好作为一个老菜鸟我已经知道了，这些过程是tomcat帮忙完成的，我需要做的只是把war包交给tomcat就行了，不过具体细节还是问一下老软：
   
   原来我只需把war包放在tomcat的webapp/路径下，tomcat就会自己解析war包中的/WEB_INF/web.xml文件，添加一些listener、filter之类的配置，从而帮忙解析和拦截http请求，交给war包中的*.class文件完成业务逻辑。讲到这里，我找台线上的服务器看看验证一下，果然还是发现了不小区别，因为没找到war包，也没在tomcat目录下找到webapp目录，不过问题不大，应该是我司进行了一些定制化配置，问问老软怎么看：
   
   那么，应该是server.xml的配置问题，关于tomcat的部署和配置这里就不再深究了。

spring是如何在tomcat上运行的？——>如何用IDEA调试spring

要回答这个问题，首先要搞明白spring是做什么工作的：

  个人简单理解，spring是一个为软件开发（对我来讲就是java web后端）提供便利的框架，例如数据库访问、依赖管理，又或者处理web请求等等。平时在进行项目开发的时候，只需要在mavan的pom文件中配置一下spring的依赖就行了，结果尝尝忽视了一个问题：spring本身也是一段java代码，而且毫无疑问要比99%以上的业务代码都要精妙和优雅。所以让我们抛开困扰，无需惧怕，大名鼎鼎的spring，也是从一个平平无奇的main方法开始的。
  于是新问题产生了，如何调试spring的源码？为什么很多人要亲自下载spring的源码，并编译后再调试？在集成了spring框架的业务代码里，用IDEA直接调试不行吗？——当然可行，而且省事。不过这种调试也有缺点：调试的是spring编译之后的*.class文件（即通过pom引入的jar包），因此无法编辑，不能加注释或者修改某段代码（学习过程中必备的）。另外，这种调试方法其实是依赖IDEA的强大功能。因此调试spring的最佳方法就是下载源码（.java），自行编译，集成到一个简单的项目里，再进行调试。