第一次在IDEA里配置Tomcat的时候我差不多折腾了一下午。明明按照网上的教程一步步点最后启动却总是报错不是ClassNotFound就是端口被占用要么就是启动成功但浏览器里面404。后来把两种方式都摸透了才发现问题不是出在IDEA难用而是大多数教程只讲了“怎么点”没讲“为什么这么点”。这篇就把我在IDEA里使用Tomcat的两种主流方式——集成本地Tomcat和使用Tomcat Maven插件——完整拆开来讲包括具体步骤、关键参数、版本兼容、常见报错和排查思路。不管你是刚学Java Web、第一次在IDEA里启动Tomcat找不着北还是被各种奇奇怪怪的启动报错折磨了很久这篇都值得你花十分钟看完。看完之后你不仅能跑通项目还能知道两种方式各自适合什么场景选型的时候不再纠结。1. 动手前先理清两个关键概念1.1 本地Tomcat和Maven插件到底差在哪很多人刚开始接触IDEA配置Tomcat时都有一个困惑网上教程一会儿让我去下载Tomcat压缩包一会儿又让我在pom.xml里加一段插件配置到底哪个才是对的其实两种方式都是对的只是思路完全不同。集成本地Tomcat的意思是你先去Apache官网下载一个完整的Tomcat把它解压到本地某个目录然后告诉IDEA“我的Tomcat在这个位置你启动项目的时候用它来跑”。这种方式本质上是让IDEA去调用外部程序IDEA负责把编译好的项目打包成war包、扔到Tomcat的webapps目录里然后启动Tomcat进程。你的项目跑在真实、完整的Tomcat容器里行为最接近生产环境。Tomcat Maven插件则完全不一样。这个插件会把Tomcat的核心模块以依赖库的形式引入你的项目然后在执行mvn tomcat7:run这类命令时直接在JVM进程里“内嵌”一个Tomcat实例项目就运行在这个嵌入式容器里。整个过程完全不需要去下载、解压、配置外部Tomcat一条命令就能把项目跑起来。Spring Boot项目的内嵌服务器也是类似思路你可以理解成“把服务器打包进你的项目里”。两者对比下来本地Tomcat更像“把你的车开进4S店的维修车间里检测”Maven插件则像“在手机里装一个驾驶模拟App”。前者用的是真实环境后者追求的是轻量和方便。1.2 版本兼容关系先对号入座不管选哪种方式版本兼容都是第一道门槛。很多启动报错表面上莫名其妙根子上就是Tomcat版本和JDK版本不匹配。目前的对应关系大致是这样的Tomcat版本最低JDK要求Servlet/JSP规范特点Tomcat 8.5JDK 7Servlet 3.1 / JSP 2.3老项目常用稳定Tomcat 9JDK 8Servlet 4.0 / JSP 2.3集成方式最稳的选择Tomcat 10.0JDK 8Servlet 5.0jakarta.*包名从javax换成jakarta大坑Tomcat 10.1JDK 11Servlet 6.0jakarta.*较新需要对应新版依赖Tomcat 11JDK 17Servlet 6.1jakarta.*最新版本不建议新手直接用这里最容易踩的坑是包名问题。Tomcat 10开始Java EE迁移到了Jakarta EE原来的javax.servlet.*全部换成了jakarta.servlet.*。如果你用Tomcat 10及以上版本而项目依赖里用的还是老版本的Servlet API编译时可能没问题一启动就会报ClassNotFoundException: javax.servlet.Filter之类。遇到这种问题要么把Tomcat降级回去要么把依赖替换成jakarta.servlet-api两边版本必须对齐。如果你的项目比较老直接选Tomcat 8.5或9是最省心的。如果是从零开始的新项目我建议先用Tomcat 9把链路跑通后面有需要再升级。2. 方式一IDEA里配好本地Tomcat2.1 先把Tomcat下载好、放对位置集成本地Tomcat的第一步自然是准备一个能用的Tomcat。下载时去Apache官网就行页面上一堆版本选个稳定版本点进去然后根据操作系统下载对应压缩包。Windows机器选64-bit Windows zipMac或Linux用tar.gz包。这里提醒一句不要下载带src或deployer标签的包那分别是源码和部署工具普通开发下载纯二进制发行版Binary Distributions里的Core包就够了。下载完解压后把目录放在一个你能记住、路径里不要有中文和空格的位置比如Windows下就放D:\tomcat9Mac下放~/dev/tomcat9。目录结构里应该有bin、conf、lib、logs、webapps这几个关键文件夹。bin目录存启动脚本conf目录存配置文件webapps目录将来会被IDEA用来投放编译好的war包。解压完可以先验证一下Tomcat本身能不能跑进入bin目录Windows下双击startup.batMac/Linux下运行./startup.sh然后浏览器打开http://localhost:8080能看到Tomcat默认首页就代表基础环境没问题。如果启动一闪而过或报错大概率是JAVA_HOME环境变量没配对先把这个问题解决再继续。我见过太多人跳过这一验证步骤后面项目起不来时根本分不清是Tomcat问题还是IDEA配置问题。另外提一句本地Tomcat不一定非要配置CATALINA_HOME环境变量。如果你只在IDEA里用不打算在命令行里手动启停不配也完全没关系。2.2 在IDEA中注册本地TomcatTomcat准备好了接下来让IDEA认识它。打开IDEA进入File - SettingsWindows或IntelliJ IDEA - PreferencesMac找到Build, Execution, Deployment - Application Servers点左边加号选Tomcat Server弹出的窗口里指定Tomcat安装目录也就是刚才解压的路径。IDEA会自动识别版本号并列出Tomcat的lib目录。把路径填好后点OK右下角显示“D:\tomcat9 (14.0.0)”之类的信息说明IDEA已经把这个Tomcat纳入管理了。不同IDEA版本的菜单位置会有细微差别有些版本里是Build, Execution, Deployment - Application Servers有些老版本叫Build Tools下面但大致方向一致。如果你用的是2023年以后的版本搜索框里直接搜Application Servers更快。这步配置本质上只是在IDEA里注册一个“Tomcat实例”的引用并不会真的启动Tomcat也不会影响系统其他程序。哪怕你以后卸载IDEATomcat本身还是独立存在的。2.3 新建运行配置把Web项目挂上去注册完Tomcat之后重点是新建一个运行配置Run Configuration。点击顶部工具栏的下拉框默认显示项目名的地方选择Edit Configurations左侧列表里点加号找到Tomcat Server - Local。注意这里有两个选项一个是Local一个是Remote初学者一律选Local。Remote是用于远程调试生产环境Tomcat的配置复杂暂时用不上。新建后主要填这几个地方第一个是Server标签页。Application server下拉框里选择刚才注册好的Tomcat。HTTP port默认8080如果你的电脑上8080被占用了就改一个比如8081、8088都行JMX port随便给一个不冲突的端口比如1099。这两个端口尽量固定下来别每次新建配置都随机换不然到最后你自己都记不清项目到底跑在哪个端口上。第二个是Deployment标签页。这是最容易漏的一步。点右下角的加号选Artifact然后选择项目的war包。很多人在IDEA里跑Web项目启动之后访问不到页面、报404八成就是这里没加Artifact。这个Artifact的意思是“要部署的产物”它的类型一定要选war或war exploded。war exploded的意思是解压后的war目录开发阶段用它有好处后面讲热部署的时候细说。如果你的项目没有出现可选的Artifact说明你的web项目结构不对需要在项目设置里先把Web模块和Artifact定义出来。第三处是底部的Before launch区域。IDEA默认会有Build操作别把它删了但也不要额外去勾Build Artifacts不然每次启动会重复打包效率反而低。保持默认的Build就行IDEA会在启动前自动编译并部署。配置完成后点右上角的绿色三角形启动控制台里如果能观察到Tomcat启动日志并且最后出现Server startup in [xxx] milliseconds就说明启动成功了。这时候打开浏览器访问http://localhost:8080/项目路径如果看到页面内容整个链路就算彻底通了。2.4 热部署到底怎么开本地Tomcat方式最大的一个好处就是热部署相对成熟代码改了不用频繁重启整个服务器。但热部署不是默认拉到最满的需要手动调一下。在刚才的Run Configuration里Server标签页底部有两个关键选项Update resources和Update classes and resources旁边可以选触发时机一般是On frame deactivation意思是IDEA窗口失去焦点时自动执行。实际操作中比较顺手的配置是把On frame deactivation设为Update classes and resourcesOn update action设为Rerun。这样你写代码时切回浏览器刷新页面IDEA检测到窗口失焦就会自动把修改过的类和静态资源推送到Tomcat里。改Java代码时大多数情况下IDEA会尝试热替换class文件如果改动不涉及方法签名或大范围结构不需要重启就生效。改JSP、HTML、CSS、JS这些则基本是即时生效的。这里要明确一点热部署不是万能的。改配置文件比如web.xml或者改了Spring的Bean定义、新增Controller方法时还是建议重启一下。硬撑着不重启的话等系统抛出各种诡异状态时排查更浪费时间。我把这种策略叫“快改快生效大改动就老实重启”既能享受热部署的便利又不会掉进它的陷阱。至于上面提到的war和war exploded的选择也跟热部署有关。如果Artifact选的是warIDE会先把项目打成war包再部署每次改动都要重新打一次包开发效率低。而war exploded是直接把解压后的目录和项目资源关联起来IDEA可以增量更新文件所以开发模式下强烈建议选war exploded。2.5 方式一的高频报错速览本地Tomcat方式最大的问题常常出现在环境匹配上我把最常见的几个报错原因和解决办法放这里后面再展开细说这算是一份速查。现象典型原因快速处理办法启动时提示端口占用8080被其他进程占用换HTTP端口或使用lsof -i:8080Macnetstat -ano启动后立刻停止或“Process finished with exit code 1”JAVA_HOME未配置或JDK版本不匹配检查环境变量确认Tomcat指定了正确JDK版本浏览器访问出现404Deployment里没有添加Artifact或Application context不对进入Run Configuration在Deployment里添加项目war/exploded项目能启动但ClassNotFound依赖冲突或lib目录缺失检查Tomcat的lib目录里是否有同名老版本jar清理项目依赖重复引用控制台中文乱码编码不一致见后续第5.2节统一UTF-8编码这些坑不算复杂但确实能让人反复折腾很久。核心逻辑是先把环境变量、端口、依赖范围这几个维度排查清楚再考虑更深入的问题。3. 方式二Tomcat Maven插件一条命令起服务3.1 为什么我推荐新手也试试插件方式刚才方式一讲完可能有些人会觉得既然本地Tomcat这么成熟为什么还要折腾Maven插件我的回答是插件方式解决了一个非常现实的痛点——团队协作时不需要每个人都装一份Tomcat。你想一个场景新同事入职从Git上拉下项目本地装好JDK和Maven只要IDEA能识别Maven项目在命令行执行mvn tomcat7:run就能把项目跑起来整个过程完全不依赖本地有没有Tomcat。这对于快速熟悉代码、调试模块、跑单测来说太方便了。而且插件方式本质上就是嵌入式Tomcat天然的轻量级不用管部署目录、不占额外端口启动速度也更快。当然插件方式也有使用限制后面会讲。但从“先让项目能跑起来”这个目标看它确实是最快路径。3.2 在pom.xml里写插件使用Tomcat Maven插件核心只需要在pom.xml文件的build - plugins节点下加一段坐标。最常见的写法是build plugins plugin groupIdorg.apache.tomcat.maven/groupId artifactIdtomcat7-maven-plugin/artifactId version2.2/version configuration port8080/port path/hello/path uriEncodingUTF-8/uriEncoding /configuration /plugin /plugins /build这里有一点很容易让人误解明明叫tomcat7-maven-plugin但现在很多人已经在用Tomcat 9或更高版本这个插件还咬得住吗实话说tomcat7-maven-plugin内部封装的是Tomcat 7的内核对应的Servlet规范是3.0JSP规范是2.2。如果你的项目用的是Spring MVC、Servlet API版本在3.0以内它完全够用这也是很多老项目一直在使用它的原因。但如果你用到了Servlet 4.0、WebSocket新特性之类它就不行了。社区里也有更新的插件尝试解决这个问题比如org.cyberelf10.maven.plugins:tomcat9-maven-plugin这类第三方实现但稳定性和文档完整度都不如老牌的tomcat7插件用起来要谨慎。如果你只想快速跑通一个普通Web项目、学习Servlet和JSP基础不用纠结版本号直接使用tomcat7-maven-plugin 2.2完全没问题。我就一直用它给初学者演示简单、稳、坑少。3.3 启动服务的几种姿势配置好pom之后启动项目的方式取决于你用的IDE。第一种方式在IDEA右侧的Maven工具窗口里找到当前项目展开Plugins - tomcat7看到tomcat7:run双击即可启动。这种方式会直接在IDEA控制台打印Tomcat日志和运行本地Tomcat时没什么区别。第二种方式在IDEA终端或者命令行工具里进入项目根目录执行mvn tomcat7:run。效果和第一种一样但如果你同时开着多个项目终端可以更方便地观察日志。调试场景下还有个命令叫mvn tomcat7:debug启动后会监听8000端口等待远程调试器接入这时候你在IDEA里配置一个Remote JVM Debug连接8000端口就能打断点调试。这个命令说是远程调试但实际就是本地开发里调试Web应用时很好使的一个技巧。还有一种姿势是绑定到Maven生命周期里。比如在插件里加一行配置executions execution goals goalrun/goal /goals phasepackage/phase /execution /executions这样执行mvn package时自动启动Tomcat。不过我的经验是这个配置只适合特殊场景平时还是直接tomcat7:run最灵活绑定在生命周期里反而会让打包动作变慢。启动成功后控制台会输出类似INFO: Starting ProtocolHandler [http-bio-8080]的日志然后访问http://localhost:8080/配置好的path就能看到项目页面。这里的path如果不配置默认访问的是/根路径配置成/hello后URL就是http://localhost:8080/hello。3.4 插件核心参数逐项拆解刚接触插件的人可能对configuration里的参数很懵这里把它们剥开来看。port很好理解就是Tomcat的HTTP监听端口默认8080和本地Tomcat一样。如果端口冲突改这里就行不用去动Tomcat配置文件。path是应用上下文路径也就是浏览器访问时的那段根路径。它对应本地Tomcat部署时的Application context。设置了path/hello/path之后你项目的所有Servlet映射都会自动挂在这个路径下。uriEncoding能影响到GET请求里中文参数的解码方式统一设置成UTF-8可以避免大部分乱码。注意这个参数只对URI解析有效POST请求的编码主要是靠项目代码里设置request.setCharacterEncoding(UTF-8)或者Spring的CharacterEncodingFilter别指望一个参数搞定所有编码问题。contextFile可以指定一个自定义的context.xml路径需要在不太常见的情况下才用比如要配置JNDI数据源时。说到JNDI就引出插件的另一个短板嵌入式Tomcat默认不读取conf/server.xml里你配置的全局数据源。你如果代码里有InitialContext.lookup(java:comp/env/jdbc/xxx)这种逻辑用插件方式启动时大概率拿不到数据源。这种情况要么检查项目里有没有独立的context.xml文件要么直接放弃插件方式改用本地Tomcat去模拟生产的容器配置。除了这几个常用参数插件还暴露了ajpPort、sslPort、maxThreads等参数跟Tomcat本身的配置项含义一致需要时再去查官方文档就行。从新手角度先掌握port、path、uriEncoding三个参数足够应付绝大多数场景。3.5 插件方式绕不开的两个硬伤上面算夸奖了插件方式不少但它也有硬伤我展开说一下。第一内嵌容器与真实Tomcat的环境差异。真实Tomcat里有完整的管理后台、默认的web.xml全局配置、server.xml各种连接器调优参数这些在嵌入式Tomcat里不一定忠实还原。如果一个项目在生产环境部署时依赖了Tomcat管理端的某些配置开发期用插件方式往往是发现不了问题的等上了生产环境再暴雷就很麻烦。所以我一般建议写代码调试可以用插件涉及部署配置、环境对齐的生产环境准备务必用本地Tomcat完整验证一遍。第二tomcat7-maven-plugin版本老旧导致的功能天花板。它最多支持到Servlet 3.0如果你正在使用Spring Boot 2.x或Spring 5.x它们底层的Servlet版本要求已经超过3.0插件方式就没法胜任。这种项目要么继续用本地Tomcat要么干脆直接用Spring Boot自带的内嵌服务器别硬塞给tomcat7插件。另外这个插件的停止维护时间比较久遇到跟新版Maven的兼容性问题也正常比如Maven 3.9在某些环境下执行tomcat7:run会抛Unknown lifecycle phase的怪问题需要额外配置。所以插件方式的定位很明确用来做开发期的快速启动、轻量调试做不了生产环境的完全模拟也不是所有Java Web项目的万能钥匙。4. 两种方式怎么选更舒服4.1 场景对照谁适合本地Tomcat本地Tomcat的优势在于完整和真实。如果你需要开发的是传统Java Web项目使用Servlet、JSP、Filter、Listener这些原始技术栈需要模拟生产环境的行为本地Tomcat是首选。以下是建议优先使用本地Tomcat的场景场景原因项目部署到独立的Tomcat实例war包部署本地Tomcat最接近生产环境能看到真实容器行为使用JNDI数据源或全局配置完全兼容conf/server.xml、context.xml里的配置需要Tomcat管理后台本地Tomcat自带Manager App插件方式没有调试容器相关Bug本地Tomcat的日志和行为更完整前端与后端联调页面较多部署exploded war后静态资源更新迅速、路径清晰团队里如果已经约定好“开发环境都用同一个Tomcat版本”那本地Tomcat方式几乎就是标准答案。毕竟每个开发者的机器上装同一个版本的Tomcat出现诡异兼容性问题的概率会大大降低。4.2 场景对照谁适合Maven插件Maven插件方式的最大优势是零安装和快启动。你不需要单独管理一个Tomcat目录也不关心它占不占用系统服务项目级别完全自包含。推荐优先用插件方式的场景是场景原因新人快速上手、快速看效果不用下载安装Tomcat一条命令起服务持续集成环境/CI构建可在构建阶段一键启动服务做冒烟测试代码片段测试、Servlet教学Demo简单项目不需要复杂容器配置想快速验证某个功能模块启动时间比启动本地Tomcat短不少不想把本地环境搞得太乱的个人机器项目隔离不依赖全局Tomcat但注意如果你用的是Spring Boot项目其实最推荐的既不是这两种而是直接用Spring Boot内嵌Tomcatmvn spring-boot:run就能搞定你根本不需要额外配置Tomcat插件。这个话题大家可以去查Spring Boot文档这里不多扩展。4.3 我自己的选择逻辑聊了这么多场景直接分享我自己的选择逻辑不一定对所有人都适用但至少能帮你少走弯路。我的个人习惯是新项目或小项目优先用Tomcat Maven插件跑通逻辑省心需要对生产环境做部署验证、调连接池参数或者跟运维扯皮时再切到本地Tomcat完整模拟一遍。有一个很常见的问题项目里确实配好了本地Tomcat的Run Configuration但是切换到Maven插件方式后原来的IDE运行配置还在启动时选哪个我的做法是给不同场景建不同配置比如Tomcat Local和Tomcat Plugin对应不同启动方式。不要试图把它们合并成一个配置否则两个方案互相打架你会更迷糊。另外不管是本地Tomcat还是插件方式有一个习惯我从一开始就坚持到现在永远用war exploded方式部署并且把Application context路径固定成一个有意义的业务名。比如项目名叫shop那context path也固定成/shop。这样团队成员沟通URL时大家心里都有数不会出现一个人访问/、一个人访问/shop的情况。5. 实战踩坑记录常见问题与排查办法5.1 启动秒退或端口占用新手遇到“启动后控制台输出几行就没动静了”的情况多半是端口占用。Windows下可以执行netstat -ano | findstr 8080看到占用8080的进程PID后再去任务管理器里结束对应进程。Mac/Linux下用lsof -i :8080配合kill -9 PID处理。如果8080被系统服务占用不想强杀那就直接换个端口。这里有个小技巧IDEA里配置Tomcat的HTTP端口时不要只用8080而是结合项目名选一个比如8088、8090这样多个项目并行时不互相打架。还有个隐蔽情况是JMX port被占用。你每次新建Run Configuration时IDEA会自动分配一个JMX端口如果之前启动过多个Tomcat配置可能残留一些僵尸端口。解决办法是故意把JMX端口固定成不常用且不冲突的值比如10000开头的段这样排查问题时会少一个干扰源。5.2 控制台中文乱码Tomcat乱码是搜索榜上的常客其实本质就是“编码不一致”四个字。Windows上Tomcat日志乱码最常见的原因是Tomcat的logging.properties里默认使用了UTF-8而Windows控制台的代码页是GBK。解决办法是在IDEA的Help - Edit Custom VM Options里加上-Dfile.encodingUTF-8并把IDEA控制台编码也设为UTF-8。如果是本地Tomcat方式还可在Run Configuration的VM options里加一行-Dfile.encodingutf-8。这三步做完绝大多数乱码问题能解决。如果乱码还出现在浏览器页面上那就是项目响应编码的问题。JSP页面头部要设置pageEncodingUTF-8Servlet里设置response.setCharacterEncoding(UTF-8)同时确保数据库连接串里带上了characterEncodingutf8参数。每一步都别偷懒编码问题是链式的一个环节断了整个链路乱码。5.3 启动成功但页面404Tomcat正常启动但浏览器访问不到页面属于最让人崩溃的问题之一因为服务器日志里看不出任何报错。本地Tomcat方式下先检查Run Configuration的Deployment标签页里有没有Artifact。如果没有重新添加Artifact如果Artifact存在再看Application context和浏览器里访问的路径是否一致。比如Application context设成了/shop却访问http://localhost:8080/那自然404。还有一种情况是Artifact类型选错如果选成了war部署目录其实是个压缩包结构也会导致资源找不到改成war exploded后问题就消失了。Maven插件方式下出现404先检查path配置。如果你希望项目直接跑在http://localhost:8080/就把path设成/如果你想用http://localhost:8080/demo那path就填/demo。系统提示404时必须看一下Tomcat的webapps目录如果是本地Tomcat或者内嵌目录里到底有没有你index.jsp的复制品有时候是编译输出目录没刷新clean一下再重新打包就好。5.4 找不到Artifact或依赖冲突如果IDEA项目里没有可部署的Artifact选项说明当前项目还没被识别成Web项目。手动在File - Project Structure - Facets里加上Web添加Web模块描述文件web.xml的路径和Web资源目录然后在Artifacts里新建一个Web Application: Exploded类型的Artifact这样配置里才能看到它。依赖冲突则更多发生在本地Tomcat方式下。Tomcat自带了一套javax.servlet-api之类的库你的项目pom.xml里又引入了同一个依赖的不同版本就可能出现NoSuchMethodError或ClassCastException。解决思路是把项目里Servlet API相关依赖的scope设为provided意思是“交给容器提供”这样既不会和Tomcat内置库重复也不影响编译。类似地如果项目里引了一些比较大的通用库比如commons-logging也要注意和Tomcat自带的版本是否冲突。5.5 插件下载慢或拉不下来Maven插件本质上是依赖首次运行时需要从Maven仓库下载网络不好时特别容易卡住。tomcat7-maven-plugin有一个比较经典的毛病它会依赖一个叫tomcat-embed-core的jar如果仓库里这个jar下载不完整后续执行mvn tomcat7:run会一直报各种ClassNotFound。解决办法是检查Maven本地仓库的org/apache/tomcat目录把下载不完整或者损坏的目录删掉然后重新执行下载。如果公司内网有私服配置好镜像地址后再试。另外tomcat7-maven-plugin默认坐标在Maven中央仓库如果你配置了阿里云镜像下载速度会快很多这一点在大陆地区尤其明显。6. 最后分享一点个人配置习惯整体思路说完了最后絮叨几句我自己的配置习惯算不上什么大道理但长期用下来确实能让日常开发省不少事。我现在同时维护着好几个Java Web项目有的老项目还在用JSP有的新项目早就上了Spring Boot。每个项目里我都会在pom.xml保留一套tomcat7-maven-plugin的配置命名的path都跟项目名一致。这样哪怕本地没装任何Tomcat拉下来项目立刻能跑起来看效果。真到了需要严格模拟生产环境的时候我再切回IDEA里的本地Tomcat配置跑一遍完整的部署验证。还有一个每天都用得上的细节IDEA底部工具栏的“Services”窗口可以直接管理Tomcat实例启动、停止、重启都比在Run面板里点来点去更快。你配置好一次之后Tomcat服务会留在Services里后面调试时直接操作体验会顺滑很多。工具这东西没有绝对的好与坏只有适不适合你当前的状态。集成本地Tomcat和Tomcat Maven插件我都踩过不少坑最终沉淀下来的判断标准很简单你追求的是更贴近生产的真实环境还是更便捷的调试效率。想清楚这点配置方案自然就出来了。希望这篇整理能让你少走几个弯路把时间花在写代码上而不是和IDE较劲上。