我之前也碰到过几乎一模一样的问题——Tomcat启动耗时十几秒，禁用TLD扫描又直接导致JSF控制器加载失败，换台机器启动却快得离谱。结合我的排查经验，给你几个可行的解决方向：

1. 不要全盘禁用TLD扫描，改用精准白名单配置 #

直接禁用TLD Scanner会让Tomcat跳过JSF核心依赖里的关键TLD文件（比如javax.faces.webapp.FacesServlet依赖的faces-config.tld），这必然导致上下文加载异常。正确的做法是缩小扫描范围，只让Tomcat扫描JSF和必要依赖的JAR：

在Tomcat的conf/context.xml中添加JarScanner配置，示例如下：

<Context>
    <!-- 配置TLD扫描白名单，只扫JSF核心JAR -->
    <JarScanner>
        <JarScanFilter
            scanClassPath="false"
            scanAllFiles="false"
            scanAllDirectories="false"
            <!-- 根据你用的JSF实现调整：Mojarra用javax.faces-*.jar，MyFaces用myfaces-api-*.jar/myfaces-impl-*.jar -->
            includes="javax.faces-*.jar, myfaces-api-*.jar, myfaces-impl-*.jar"
            excludes="*"
        />
    </JarScanner>
</Context>

这样既砍掉了90%以上的无用扫描，又保证JSF所需的TLD文件能被正确识别。

2. 检查本地Maven仓库的依赖状态 #

其他机器启动快，大概率是你的本地Maven仓库存在问题：

• 可能有损坏的JSF依赖JAR，导致Tomcat扫描时反复重试或解析出错；
• 可能引入了重复的JSF依赖（比如同时加了Mojarra和MyFaces），引发扫描逻辑混乱。

解决方法：

• 删除本地仓库中JSF相关的依赖目录（比如~/.m2/repository/javax/faces或org/apache/myfaces），然后执行mvn clean install重新拉取完整依赖；
• 用mvn dependency:tree检查依赖树，排除重复或不必要的依赖。

3. 开启DEBUG日志定位具体耗时点 #

如果上面的方法还没解决，建议开启Tomcat的扫描日志，看看到底是哪些JAR在拖慢速度：

修改Tomcat的conf/logging.properties，添加：

# 开启TLD扫描的DEBUG日志
org.apache.tomcat.util.scan.level = FINE

启动Tomcat后，日志会详细输出每个被扫描的JAR及其耗时，找到那些耗时特别长的冗余JAR，直接在JarScanFilter的excludes里排除它们。

4. 调整JSF的项目阶段配置 #

如果你的web.xml里把JSF的项目阶段设为Development，Tomcat启动时会做大量的校验和资源检查，这也会显著拖慢速度。可以改成Production阶段：

<context-param>
    <param-name>javax.faces.PROJECT_STAGE</param-name>
    <param-value>Production</param-value>
</context-param>

Production阶段会跳过很多开发时的调试检查，启动速度会快不少。

内容的提问来源于stack exchange，提问作者Tiago Duque