不能。sublime text 不解析 pom.xml 的 结构，不理解 maven 继承与依赖传递，也无法识别跨模块类引用，仅能通过插件辅助执行 maven 命令、高亮配置文件和补全路径，但无法校验模块定义、依赖声明或 classpath 有效性，所有构建逻辑需开发者手动把控。
Sublime Text 能不能直接构建 Spring Boot 多模块项目
不能。Sublime Text 本身不解析 pom.xml 中的 <modules></modules> 结构，也不理解 Maven 的继承与依赖传递机制，更无法自动识别跨模块的类引用（比如从 demo-web 调用 demo-service 中的 UserService）。你写完代码、改完 pom.xml，Sublime 不会帮你校验模块是否被正确定义，也不会提示 “demo-dao 没有声明为 demo-service 的依赖” 这类问题。
哪些操作 Sublime Text 可以安全辅助完成
它适合做「编辑器层」的轻量任务，前提是你知道每一步在 Maven 层面意味着什么：
- 用
Package Control安装Maven Plugin后，可执行mvn clean compile或mvn install -pl demo-boot -am（只编译启动模块及其依赖）——但命令输错、路径不对、模块名拼错，Sublime 不报错，只返回[ERROR] The project com.example:demo-boot:0.0.1-SNAPSHOT has 1 error这种泛型提示 - 配合
YAML和Java Properties插件，能高亮application.yml里的spring.profiles.active或server.port，但不会告诉你demo-common模块里定义的@ConfigurationProperties类没被扫描到 - 用
AutoFileName插件补全资源路径（如classpath:static/js/），但无法跳转到demo-utils模块中定义的StringUtils类——因为 Sublime 没有 classpath 解析能力
最容易踩的坑：你以为在写 Spring Boot，其实只是在写文本
常见翻车点集中在三个地方：
-
mvn install成功，但demo-boot启动时报ClassNotFoundException：实际是demo-service的<dependency></dependency>没写对 groupId 或 version，Sublime 不检查 XML 标签嵌套或变量引用（如${project.parent.version}是否被父 pom 正确声明） - 修改了
demo-common里的工具类，重启demo-boot却没生效：因为demo-boot的pom.xml里依赖的是已安装到本地仓库的旧版 jar，而你没执行mvn install更新它；Sublime 不会提醒你“这个模块需要重装” - 在
demo-web的 controller 里注入Service，IDEA 会标红并提示 “Unresolved dependency”，Sublime 则完全静默——你得靠mvn compile输出的[ERROR] /xxx/Controller.java:[12,34] cannot find symbol才知道哪一行炸了
如果坚持用 Sublime，必须手动盯住的关键节点
每次增删模块或改依赖时，务必确认这四件事：
- 父 pom 的
<packaging>pom</packaging>已设置，且<modules></modules>列表和实际目录名严格一致（大小写、连字符、无多余空格） - 每个子模块的
<parent></parent>中<groupid></groupid>、<artifactid></artifactid>、<version></version>必须和父 pom 完全匹配，不能残留org.springframework.boot:spring-boot-starter-parent - 启动模块（如
demo-boot）的pom.xml中，必须显式声明对其他模块的<dependency></dependency>，不能指望 “同父就自动可见” - 运行前先执行
mvn clean install -Dmaven.test.skip=true全局安装一遍，确保所有模块都进了~/.m2/repository，再单独跑mvn spring-boot:run -pl demo-boot
Sublime 不会替你记住这些链条，它只管显示字，不管字背后有没有 Maven 节点支撑。一旦漏掉其中一环，失败不是报错，而是静默不可用——这才是最耗时间的地方。
