在基于Spring框架开发Web应用时，部署阶段常常会遇到一系列问题，如配置错误、依赖冲突、启动失败等。深入理解Spring源码，可以帮助我们快速定位并解决这些问题。本文将从源码角度，解析几个常见的部署问题及其背后的原理。

1. 应用上下文（ApplicationContext）初始化失败

问题现象：项目启动时，控制台报错ApplicationContext初始化失败，通常伴随着BeanCreationException或BeanDefinitionStoreException。

源码追踪与解析：
Spring Web应用（如Spring MVC）通常通过ContextLoaderListener（传统Servlet）或SpringApplication.run()（Spring Boot）来初始化应用上下文。核心过程在AbstractApplicationContext.refresh()方法中。

• 配置扫描路径错误：如果配置的@ComponentScan基包路径不正确，或XML中<context:component-scan>的base-package有误，会导致无法扫描到Bean。源码中，ClassPathBeanDefinitionScanner.doScan()会遍历指定包，未找到类时会默默跳过，但若关键Bean（如@Controller）未被扫描，后续依赖注入会失败。
• Bean定义冲突：当同一Bean被多次定义（如XML与注解重复），在DefaultListableBeanFactory.registerBeanDefinition()中，会根据allowBeanDefinitionOverriding配置决定是否覆盖，默认可能抛出异常。

解决方案：检查扫描路径是否覆盖所有注解类；确保Bean定义唯一；查看异常堆栈，定位到具体Bean和配置文件。

2. 静态资源访问404

问题现象：部署后，CSS、JS等静态资源无法加载，返回404错误。

源码追踪与解析：
在Spring MVC中，静态资源处理由DispatcherServlet和资源处理器（如ResourceHttpRequestHandler）负责。默认情况下，DispatcherServlet会拦截所有请求（/），包括静态资源。

• 资源处理器配置缺失：若未配置<mvc:resources>或实现WebMvcConfigurer.addResourceHandlers()，静态资源请求会因无对应处理器而失败。源码中，RequestMappingHandlerMapping会优先匹配控制器方法，未匹配时才会交给SimpleUrlHandlerMapping（负责静态资源）。
• Servlet容器配置冲突：在外部Tomcat等容器中，若web.xml中DispatcherServlet的映射为/，且未设置<mvc:default-servlet-handler/>，容器默认Servlet（处理静态资源）可能被覆盖。

解决方案：显式配置静态资源路径；或启用defaultServletHandler，将未匹配请求交回容器处理。

3. 事务管理器不生效

问题现象：在Service层使用@Transactional注解，但数据库操作未回滚。

源码追踪与解析：
事务管理依赖于AOP代理。Spring通过BeanPostProcessor（如InfrastructureAdvisorAutoProxyCreator）在Bean初始化后创建代理。

• 代理模式问题：默认使用JDK动态代理（要求接口），若类未实现接口且未强制使用CGLIB，代理可能失败。在AbstractAutoProxyCreator.createProxy()中，会根据条件选择代理方式。
• 异常类型不匹配：@Transactional默认只在抛出RuntimeException时回滚。若代码捕获了异常，或抛出Exception，事务不会回滚。相关逻辑在TransactionAspectSupport.invokeWithinTransaction()中，通过RuleBasedTransactionAttribute.rollbackOn()判断。

解决方案：检查代理配置，如使用@EnableTransactionManagement(proxyTargetClass=true)启用CGLIB；确保异常类型正确传播。

4. 多数据源配置冲突

问题现象：配置多个数据源后，部分DAO操作连接了错误的数据源。

源码追踪与解析：
多数据源的核心是AbstractRoutingDataSource，它通过determineCurrentLookupKey()动态选择数据源。

• 上下文切换失败：若未正确设置lookupKey（如通过DataSourceContextHolder），或线程池中线程上下文被污染，会导致选择错误。源码中，AbstractRoutingDataSource.determineTargetDataSource()会根据key获取具体DataSource实例。
• 事务管理器绑定：每个数据源需对应独立的事务管理器（如DataSourceTransactionManager），否则事务可能关联到默认数据源。在TransactionInterceptor中，事务管理器通过TransactionAspectSupport.determineTransactionManager()解析。

解决方案：确保数据源切换逻辑线程安全；为每个数据源配置独立的事务管理器，并使用@Transactional(value="managerName")指定。

5. Spring Boot Jar包部署端口冲突

问题现象：Spring Boot应用打包为Jar后，运行提示端口被占用。

源码追踪与解析：
Spring Boot通过内嵌Servlet容器（如Tomcat）启动，端口配置在ServerProperties中。

• 端口配置覆盖失败：若在application.properties中设置server.port=8080，但系统环境变量或命令行参数指定了其他端口，可能被覆盖。源码中，SpringApplication.run()会触发Environment属性加载，优先级顺序为：命令行 > 环境变量 > 配置文件。
• 容器初始化异常：内嵌Tomcat在TomcatServletWebServerFactory.getWebServer()中创建Connector，若端口被占用，会抛出PortInUseException。

解决方案：检查端口配置优先级；使用server.port=0随机端口；或通过命令行--server.port指定。

###

部署问题往往源于配置与源码逻辑的脱节。通过深入Spring源码，理解初始化流程、请求处理链、代理机制等核心原理，可以快速定位问题根源。建议在开发中结合日志调试（如开启DEBUG级别日志），并参考官方文档中的配置细节，以提升部署成功率。