企业官网建设流程全解析

不知道你有没有过这种经历：项目在 Windows 上直跑的时候一切正常，你为了更贴近线上环境，装好了 WSL，然后在 IDEA 里把 Project SDK 切到 WSL 中的 Linux 版 JDK，重新加载 Maven，点击运行——结果控制台瞬间抛出一堆莫名其妙的异常：什么找不到 JAVA_HOME、热重载失效、端口明明监听了却访问不到、Maven 构建时 Permission denied。这不是一个人的问题，凡是尝试在 Windows 上用 WSL 做 Spring 开发的人，几乎都要经历这么一段磨合期。

这篇文章就是把我自己这段磨合期的完整过程复盘一遍，把从 WSL 安装、IDEA 识别、Linux 版 JDK/Maven 配置，到 Spring Boot 项目真正跑起来的整个链路讲清楚，并把我踩过的六个典型坑拆开揉碎。适合这样的读者：主力机是 Windows、短期没法换 Linux，但项目最终要部署在 Linux 环境，还想在本地就把“环境差异”尽量抹平的开发者。如果你刚在 IDEA 里配完 WSL，项目起不来，或者想起但跑得心慌，这篇按顺序读基本能帮你排掉九成问题。

1. 为什么绕这么大一圈用 WSL 跑 Spring：真实收益和适用边界

1.1 Windows 直跑与 WSL 的真正差别

很多刚接触这个方案的人会问：我在 Windows 上装个 JDK、用 IDEA 直接跑 Spring Boot，不也能跑吗？为什么要多装一个 WSL？

能跑是真能跑，但问题出在“跑法不一致”上。Spring Boot 项目里最常见的环境差异不是 Java 语言本身，而是三样东西：命令脚本、文件权限、第三方工具的 Linux 行为。举几个我真实遇到过的场景：

• 项目里有startup.sh、healthcheck.sh这类部署脚本，里面大量用了 Linux 的curl、grep、管道和软链接，Windows 的 Git Bash 执行经常行为不一致；
• 某些配置依赖 Linux 下才会生效的路径大小写敏感机制，Windows 下文件系统大小写不敏感，测试时好好的，一上 Linux 服务器就路径对不上；
• 项目依赖的原生库（比如某些 Agent 或加密组件）只有.so版本，Windows 上只能用.dll凑合，行为存在细微差别。

WSL 2 给 Windows 开发者提供了一个真正运行在虚拟化层之上的 Linux 内核，也就是说你得到的不是一个模拟出来的 Linux 外壳，而是一个有真实内核、能跑原生态容器的 Linux 用户态环境。编译、脚本、权限模型都和服务器一致，而 IDEA 这类 IDE 仍然跑在 Windows 侧，享受 Windows 的图形界面和输入法。两全其美，但代价是必须花时间把两套环境的边界线理清楚。

1.2 收益在数据上的体现

我在同一个多模块 Spring Boot 项目上做过对比：在 Windows 侧用 Maven 执行完整构建，大概需要 40 到 50 秒；在 WSL 内部执行同样的构建，大约 25 到 30 秒。主要原因有两层：一是 Linux 文件系统的元数据访问比 NTFS 经由一层转换后更快，二是很多项目的构建脚本本身有 Linux 优化逻辑，比如在.mvn/maven.config里配置了额外的 JVM 参数，在 Windows 下反倒要绕过。

内存方面，WSL 2 的动态内存回收机制也比传统虚拟机舒服。VM 通常是你划给它 4GB 就占用 4GB，WSL 2 会根据负载自动调整，空闲时把内存释放回宿主机，我日常开一个 Spring Boot 服务加一个 Redis，WSL 占用大概在 1.5GB 到 3GB 之间浮动。这让“Windows + WSL + Docker”三件套在 16GB 内存的机器上也能顺畅运转。

1.3 适用边界：什么时候该果断放弃这个方案

WSL 不是万金油，我建议在迁入之前先做一次需求判断。适合用 WSL 的场景：项目要大量使用 Linux 工具链、需要和 Docker 容器协同、开发环境希望尽量贴近生产环境；或者你只是想用一个 Linux 命令行而不想开虚拟机。

不适合的场景主要有三类：

• 项目对磁盘读写有极端要求，比如单次构建要处理海量小文件的场景。WSL 访问 Windows 侧文件系统（即/mnt/c路径）时，跨文件系统的协议开销非常明显；
• 项目强依赖 Windows 专属的工具客户端，比如某些 GUI 客户端、硬件驱动调试工具；
• 你完全不碰命令行，也不想理解“WSL 内”和“Windows 侧”两套世界的关系，那用 WSL 只会增加心智负担。

说到底，WSL 解决的是“开发行为一致性”的问题，不是“性能提升”的问题。抱着“迁过去能变快”的心态来，大概率会失望；抱着“环境更接近生产、踩坑更少”的心态来，才会真正觉得值。

2. 环境准备：WSL 子系统安装与 IDEA 的基础识别链路

2.1 发行版与 WSL 版本的选型

第一步其实没太多技术含量，但我见过太多人在这里给自己埋坑。有些教程建议装 Debian、openSUSE 甚至多发行版同时开，对普通 Spring 项目来说完全没必要。选一个长期支持版的 Ubuntu 就够，它社区用户最多，出了问题一搜就有答案，而且 IDEA 对 Ubuntu 路径的默认识别率也最高。

版本层面务必确认你用的是 WSL 2 而不是 WSL 1。两者的差别很大：WSL 1 是一个 API 翻译层，很多 Linux 系统调用不支持，跑 Spring Boot、Docker 之类的东西会遇到不少隐形问题；WSL 2 才是真正的虚拟化内核。用wsl --status能查看当前默认版本，用wsl --set-version <发行版名称> 2能把已有发行版切到 WSL 2。如果你还在用旧版 WSL，先跑wsl --update把内核组件更新到新版本，很多端口转发、文件监听问题其实是旧内核的毛病。

2.2 早期最关键的决策：项目代码放 Windows 侧还是 WSL 内部

这个问题我希望你能在动手前就想清楚，因为中途反复横跳很浪费时间。两种放法各有代价，我直接用一个对比表格说清楚：

我个人的建议是：普通单体 Spring Boot 项目优先放 Windows 侧。因为日常你至少在 IDEA 里打开文件、搜索、版本变更比较多，Windows 侧文件系统对 IDEA 的支持性能最好；WSL 内编译慢一点，但可以通过把target目录忽略掉来缓解。反过来，如果是大规模多模块 Maven 项目、构建动作频繁，那就放 WSL 内部，牺牲一点 IDEA 索引体验，换构建速度。记住一个判断标准：你操作最频繁的行为发生在哪一侧，就把代码放在哪一侧。

2.3 IDEA 识别 WSL 的入口与提前检查

新版 IDEA 对 WSL 的支持是内建的，不需要额外装什么插件。打开 Settings（或 File → Settings），进入 Tools → WSL，能看到当前可用的发行版列表，并把“Enable WSL integration”勾上。如果这里列表是空的，最可能是 IDEA 本身没有探测到 WSL 环境，先回到命令行确认：

> wsl --list --verbose

正常会输出类似这样的信息：

NAME STATE VERSION * Ubuntu Stopped 2

确认发行版没问题后，在 IDEA 里重启一次，通常就能识别出来。这里我要提醒一个细节：IDEA 的 WSL 集成和“Remote Development”是两种不同模式。我们这里用的是 Windows 版 IDEA 连接本机 WSL 工具链（JDK、Maven、终端都在 WSL 里），而不是在 WSL 里跑一个远程 IDEA 后端。后者是另一套操作逻辑，不要搞混。

环境准备最后一步，建议在 Windows 命令行里执行一个探测命令，确认 WSL 内的基础环境可用：

> wsl -d Ubuntu -- bash -lc "java -version; javac -version; which java; ls /usr/lib/jvm"

如果这个命令报错，说明 WSL 内部连 JDK 都还没装好，后面 IDEA 这边怎么配置都是白搭。

3. Spring 环境三板斧：Linux 版 JDK、Maven 与容器运行时

3.1 在 WSL 内部安装 JDK，别用 Windows 那套

WSL 内不能直接跑 Windows 版 JDK，这是很多人第一个没想明白的点。IDEA 的 WSL 集成本质上是wsl.exe去执行 Linux 命令，你必须给 WSL 准备一套 Linux 二进制版本的 JDK。在 WSL 终端里执行：

sudo apt update sudo apt install openjdk-17-jdk -y

项目需要什么版本就装什么版本，Spring Boot 3.x 系列一般要求 Java 17 或 21，直接用 apt 安装最省事。装完后建议再手动确认一下：

java -version which java ls /usr/lib/jvm

/usr/lib/jvm这个路径很有用，后面在 IDEA 里配置 Project SDK 时，通常需要手动跳转到这个目录去选择 JDK 根路径，而不是简单填一个 JAVA_HOME 环境变量。如果你对 JDK 版本有特殊要求，也可以通过下载 OpenJDK 发行包解压到/opt目录的方式来安装，但一定要把解压后的目录权限处理好，否则 IDEA 读取时可能遇到权限不够的问题。

这里顺便说一个容易让人混乱的点：WSL 里的JAVA_HOME和 Windows 里的JAVA_HOME是两个独立的环境变量。IDEA 在 WSL 模式下，会优先读取 WSL 内的环境。我之前见过同事在 Windows 里配了 JAVA_HOME 指向 1.8，在 WSL 里也顺手配了同样的变量，结果项目在 IDEA 里显示 1.8，在 WSL 命令行里又是 17，两边行为不一致，排查了半天。建议 WSL 内部不要靠修改.bashrc里的 JAVA_HOME 来管理，直接用系统包管理器安装并让命令自动找到 JDK，最省心。

3.2 Maven 与 Gradle：工具链必须指向 Linux 版本

Spring 项目构建工具无外乎 Maven 或 Gradle。Maven 这边，apt install maven虽然能装，但版本往往偏旧，我更推荐直接下载官方二进制包解压到 WSL 内部：

sudo mkdir -p /opt/maven sudo tar -xzf apache-maven-3.9.x-bin.tar.gz -C /opt/maven echo 'export PATH=/opt/maven/apache-maven-3.9.x/bin:$PATH' >> ~/.bashrc source ~/.bashrc mvn -version

这里真正的关键不在于你在 WSL 里装没装 Maven，而在于IDEA 的 Maven runner 到底调用的是哪个 mvn。默认情况下，IDEA 会使用 Windows 侧配置的 Maven 路径，这会导致一条非常诡异的链路：IDEA 用 Windows 的 mvn 启动构建，然后这个 mvn 在 Windows 上下文里又尝试调用你指定的 JDK——如果你把 Project SDK 设成了 WSL 里的 JDK，某些 API 调用就可能出错。最典型的表现是控制台报 NoClassDefFoundError、注解处理器失败，或者构建目标和 IDEA 的误判不一致。

正确做法是在 IDEA 的 Settings → Build Tools → Maven 里，把 Maven home path 切换成 WSL 内的路径。IDEA 通常会自动探测到，如果没有，就手动选择\\wsl$\Ubuntu\home\你的用户名\apache-maven-3.9.x这种 UNC 路径。Gradle 项目则简单一些，直接用项目根目录的gradlew包装器，双击运行即可，IDEA 会自动识别包装器并使用 WSL 环境去执行。

3.3 Docker 在 WSL 2 模式下的协同

Spring Boot 项目开发基本离不开中间件，MySQL、Redis、RabbitMQ 这些服务，在 WSL 环境最常见两种搭配：一是用 Docker Desktop 并开启 WSL 2 后端，二是直接在 WSL 发行版内部安装 Docker Engine。

我个人推荐第一种。Docker Desktop 启用 WSL 2 后端后，它的服务容器和你自己的 WSL 之间天然处于同一网络域，Windows 侧访问容器端口也很顺畅。第二种方案自由度更大，但每次 WSL 重启后需要手动启动 docker 守护进程，而且端口暴露规则经常要自己折腾防火墙，对普通开发来说性价比不高。

需要注意的一个联动问题：如果 Spring Boot 项目里配置了docker相关的插件（比如 Spring Boot Maven 插件里的docker-compose子任务），请留意它执行的 Docker 命令是在 Windows 侧还是 WSL 侧发起。为避免歧义，我一般直接在 WSL 内手工管理中间件容器，项目代码里不依赖任何构建插件去启停 Docker。这也是减少踩坑的一个习惯。

4. 我从崩溃中总结的六类典型踩坑现象和真正原因

4.1 现象一：IDEA 明明选了 WSL JDK，启动却报找不到 JAVA_HOME 或 NoClassDefFoundError

这是我被问过最多的问题，而且它很隐蔽。你的 Project SDK 的确切到了 WSL JDK，但 Maven 的 Runner 配置还停留在 Windows JDK。想象这条链路：

• IDEA 项目编译依赖的 JDK 是 WSL 里的 Linux 二进制；
• 但 Maven 插件在 Runner 里选择的 JRE 还是 Windows 的 JDK；
• Maven 构建脚本在 Windows 上下文里拿不到 WSL 的 Java 环境，于是报各种类加载失败；
• 如果你打开的是命令行启动的进程，IDEA 的终端默认又切入了 WSL，绕一圈后环境不一致，错误就变得五花八门。

排查步骤按这个顺序来：

1. File → Project Structure → Project，确认 Project SDK 显示的是带 WSL 标识的 JDK；
2. Settings → Build Tools → Maven → Runner，看 JRE 字段是否选择了“Use Project JDK”或明确的 WSL JDK；
3. Settings → Build Tools → Maven → Maven home path，确认路径指向 WSL 内的 Maven；
4. 重新 Reload All Maven Projects，执行一次mvn clean。

多数情况下走到第 3 步就能解决问题。如果还不行，打开 IDEA 自带终端，确认它是否已经自动进入 WSL 模式，再执行java -version对比一下两边版本。IDEA 终端默认可能开在 Windows Shell，那你就得手动配置 Terminal 的 shell path 为wsl.exe。

4.2 现象二：DevTools 热重载失效，改了代码却不自动重启

Spring Boot 的依赖里加上 spring-boot-devtools 后，开发时最有价值的功能就是改了代码自动重启。但在 WSL 模式下，这个功能经常失灵，而且不是配置错，是文件系统监听机制本身就出了问题。

DevTools 在 Linux 上依赖inotify来监听目录变化。当你的项目位于/mnt/c（即 Windows 侧磁盘）时，WSL 2 通过 9P 协议访问 Windows 文件系统，这个协议对文件变更事件的传递支持并不完整。你在 IDEA 里按 Ctrl+S 保存文件，Windows 文件系统认为文件变了，但 WSL 内的监听器不一定能及时收到通知，于是 DevTools 就“睡”过去了。

有三种可行的应对方式，按推荐程度排序：

• 项目放 WSL 内部文件系统（/home/...），inotify 正常，DevTools 恢复工作；
• 项目保留在 Windows 侧，但关闭 DevTools 的自动重启，改用 IDEA 的 Build 操作：改了代码后按 Ctrl+F9 手动构建一次，再手动重启服务。这个操作习惯了其实比自动重启更稳定；
• 在application.properties里显式声明额外的监听路径，比如spring.devtools.restart.additional-paths=file:src/main/java，但实测在/mnt/c下效果有限。

我自己最后选择了第二种方案。原因很实在：DevTools 自动重启本身要触发增量编译，加上 WSL 跨文件系统开销，一次重启动辄十几二十秒，手动构建干脆利落，还能避免“改了配置没热重载、排队重启乱套”的情况。

4.3 现象三：WSL 里服务明明监听了，Windows 浏览器却访问不到

Spring Boot 默认绑定的端口是8080，在 WSL 里启动后，控制台也显示 Tomcat started on port 8080，但你在 Windows 浏览器里敲http://localhost:8080却连接被拒。这个问题分两层原因。

早期 WSL 2 默认网络模式是 NAT，Windows 和 WSL 各有独立的 IP 地址。WSL 内启动的服务默认监听的可能是*:8080（对所有网卡），也可能是127.0.0.1:8080。前者通常能被 Windows 访问到，但 Windows 防火墙可能拦住入口流量。后者呢，WSL 内部的 127.0.0.1 是 WSL 自己的回环地址，Windows 的 localhost 不会自动映射过去。近几个 WSL 版本默认启用了 localhost 转发，所以很多新装用户没这个烦恼，但如果你用的是旧版本内核，或者改了.wslconfig里的网络设置，问题就来了。

排查链路我整理成一张表：

如果确实搞不定，还有一个简单粗暴的方法：在.wslconfig里配置networkingMode=mirrored，让 WSL 共享 Windows 的网络接口，这样 WSL 里监听的端口在 Windows 侧可以直接访问，代价是网络行为有所变化，新版本 WSL 支持，老版本可能需要先升级。

4.4 现象四：Maven 构建报 Permission denied，或 Git 提示文件权限异常

当项目代码放在 Windows 侧（/mnt/c/...）时，WSL 里的文件权限模型和 Windows 的 ACL 是两套体系。默认情况下，WSL 把挂载的 Windows 目录里所有文件都表现为drwxrwxrwx，也就是每个文件都对所有人开放读写执行。这看起来没问题，但实际构建时，某些依赖exec权限位的脚本会误报，Git 也会在git status里频繁提示 file mode 变化，因为 Windows 文件系统没有 Linux 权限位信息，Git 把权限当成“无权限”处理。

解决办法是在 WSL 的配置文件/etc/wsl.conf里开启 metadata 选项。编辑这个文件：

[automount] enabled = true options = "metadata,umask=22,uid=1000,gid=1000"

metadata让 WSL 给挂载的文件记录一套 Linux 元数据（权限位等），umask=22保证生成的权限对用户可写、对组和其他人可读，uid/gid指定默认属主。保存后执行wsl --shutdown再重新进入，重新挂载后生效。这个改动能解决大部分和 Git、权限相关的诡异问题。

4.5 现象五：构建时内存不足，WSL 被 OOM 干掉

WSL 2 的默认内存配置是宿主机内存的 50%。如果你是 16GB 内存的机器，那 WSL 最多用 8GB。一个大型 Spring 项目构建起来，IDEA 本身可能占掉 2-3GB，WSL 内 Maven 加 Docker 加多个中间件，8GB 很快就不够。表现是什么？构建到一半，终端突然输出 Killed，或者 Spring Boot 进程消失，dmesg里能看到 OOM killer 的记录。

这时需要在 Windows 用户主目录下建一个.wslconfig文件（不是 WSL 内部，是 Windows 侧的C:\Users\你的用户名\.wslconfig），内容类似：

[wsl2] memory=8GB processors=8 swap=8GB localhostForwarding=true

注意不要把 memory 直接填到宿主机上限，否则 Windows 桌面自己会卡死。建议给 WSL 分配物理内存的 50%-60%，给足 swap，这样构建高峰期不至于立刻被杀。改完同样要wsl --shutdown再重启发行版。

4.6 现象六：IDEA 索引慢、卡顿，尤其是项目在 WSL 目录时

项目放在 WSL 内部（/home/...）后，IDEA 通过\\wsl$\Ubuntu\home\...这个 UNC 路径来访问文件。VirtIO 9P 协议在连续读大文件时还行，但 IDE 索引是海量小文件的元数据遍历，每次文件变更都要走过一层协议栈，延迟攒起来就是肉眼可见的卡。

优化手段有三条，可以组合使用：

• 在 IDEA 的 Project Structure → Modules → Mark as excluded 里把target、.git、.idea等目录排除掉，让索引器不要碰这些变化频繁或内容庞大的目录；
• 把.m2本地仓库路径也排除出索引范围，它动辄几个 GB，纯属浪费扫描时间；
• 如果项目里子模块特别多，考虑把共享代码模块单独抽取到一个独立的 IDEA 模块，而不是全部塞进同一个大项目。

说到底这是跨文件系统访问的固有代价，能缓解但很难根除。如果你特别在意 IDEA 的手感，回到第 2 节说的：项目放 Windows 侧，接受 WSL 内编译稍慢；项目放 WSL 内部，接受 IDEA 偶尔卡顿。想两头都完美，除非你完全用远程开发模式，那就是另一个话题了。

5. 一套能稳定跑 Spring Boot 的 IDEA 配置是如何联动起来的

5.1 以 Project SDK 为中心做一次完整配置

我花了很多篇幅讲各个部分，但真正让整套环境稳定运行的关键是“让 IDEA 以 WSL 为整个项目的统一运行底座”。这里给出一个按次配置、一劳永逸的操作路径：

第一步，File → Project Structure → Project → SDK → Add SDK → 选择你的 WSL 发行版（例如 WSL: Ubuntu）。IDEA 会打开一个 Linux 文件浏览窗口，定位到/usr/lib/jvm/java-17-openjdk-amd64，选中后它会自动识别为一个 Linux JDK。

第二步，Project 选项卡里把 Project SDK 切换为刚才新增的 WSL JDK，Language Level 根据项目需要选 17 或 21。

第三步，进入 Settings → Build Tools → Maven → Maven home path，把它改为 WSL 内的 Maven 路径。Runner 选项卡里 JRE 选择“Use Project JDK”。

第四步，回到项目根目录，执行一次 Maven Reload，确保 IDE 里的依赖树和 WSL 内一致。这时你再看 IDEA 右下角的状态栏，JDK 信息里应该多出 WSL 的标识。

这个配置链路里，最容易跳过去的第三、第四步一定要检查。Project SDK 只是告诉 IDEA“源码编译用哪个 JDK”，Maven runner 则是“构建脚本执行时用哪个环境”，两者不同步，前文第一个坑就会出现。

5.2 运行配置的实际参数要点

Spring Boot 项目在 IDEA 里通常对应一个 Application 类型的运行配置。正确配置后，它长这样：

有个细节值得单独说明：如果项目在 Windows 侧，Working directory 保持C:\...没问题，但如果项目在 WSL 内部，这里应该填\\wsl$\Ubuntu\home\你的用户名\项目名。有些配置工具会把这个路径自动转成 WSL 风格，但 IDEA 偶尔会读错，导致工作目录定位失败，启动时出现资源文件找不到的怪问题。

5.3 一次“干净重建”的标准流程

环境跑一阵子后，容易出现玄学问题：依赖明明在，代码就是编译不过；之前好好的，突然启动报错。这种时候别一个个点按钮试，直接走一次干净重建流程，按顺序执行：

# 1. 在 WSL 内清掉编译产物和旧依赖缓存 cd /mnt/c/Users/<用户名>/IdeaProjects/<项目名> # 取决于项目存放位置 mvn clean mvn dependency:resolve # 2. 回到 IDEA，Reload All Maven Projects # 3. Build -> Rebuild Project # 4. 启动应用

这套流程我称为“洗环境”，它能消除绝大多数由于 IDEA 缓存与 WSL 内依赖状态不一致导致的问题。特别要说明的是，mvn dependency:resolve这一步很多人会跳过，但它能强制把 WSL 内 Maven 的本地仓库和项目 POM 里声明的依赖重新对齐，避免 IDEA 私有的依赖缓存和 mvn 的仓库不一致。

6. 形成日常习惯：一套可以在几分钟内恢复工作流的检查顺序

6.1 日常操作顺序

当整套环境稳定之后，日常操作其实很简单，但顺序千万别乱。我现在的固定流程是：

1. 打开 WSL 终端，执行cd /mnt/c/Users/.../项目名（或~/项目名）；
2. 先跑一次mvn clean compile，确认 WSL 里源码本身没有编译问题；
3. 回到 IDEA，Reload All Maven Projects；
4. 配置好 Application 运行配置，点击启动。

之所以坚持先跑命令再开 IDEA，是因为命令行输出的错误信息往往比 IDEA 的弹窗更直白。如果 IDEA 里有一堆红色波浪线，但命令行编译通过，那问题基本出在 IDEA 索引或缓存上，清除缓存比改代码有效。

6.2 遇到诡异问题时的排查顺序

如果真出了问题，不要乱点一通，按这个顺序排查，稳定且高效：

1. 看 JDK：Project SDK 和 Maven Runner 的 JRE 是否都指向 WSL JDK；
2. 看 Maven 路径：Maven home path 是否指向 WSL 内 mvn；
3. 看端口监听：ss -tlnp确认服务监听地址符合预期；
4. 看内存：free -h检查 WSL 内存是否充足；
5. 看进程状态：WSL 里是否有残留的 java 进程占着端口或锁文件；
6. 终极手段：wsl --shutdown重启 WSL 服务，再走一遍“干净重建”流程。

最后一步看起来粗暴，但真的能解决很多因为 WSL 长期运行的网络栈、套接字残留问题。我遇到过几次服务启动后连接不上数据库，排查半天无果，重启 WSL 后一切恢复正常。WSL 的虚拟网络栈长时间运行后偶尔会进入诡异状态，这不丢人，直接重启就是最有效的解法。

6.3 几个顺手技巧与个人体会

最后分享几个我用下来觉得非常顺手的小技巧，不花哨，但很实用：

• 给 WSL 里的长命令起个别名，比如alias mvnw='./mvnw'，日常进出项目目录更舒服；
• 在 IDEA 的 Settings → Tools → Terminal 里把 Shell path 设为wsl.exe --distribution Ubuntu -- bash，这样打开内嵌终端就直接进入 WSL，不用每次手动切换；
• 如果经常需要备份 WSL 环境，用wsl --export和wsl --import导出导入整个发行版镜像，比重新配置一遍环境快得多；
• 项目里统一用.mvn/maven.config和.mvn/jvm.config固定 Maven 的 JVM 参数，这样不管 Windows 还是 WSL 里跑构建，参数行为都是一致的。

踩过这么多坑，我最大的体会是：WSL 模式下开发 Spring 项目，核心矛盾永远是 Windows 与 Linux 两套环境的衔接点——JDK 选哪套、Maven 跑在哪、文件放哪里、端口怎么通。把这些衔接点统一到“以 WSL 为运行底座、以 IDEA 为编辑前端”的原则上，问题自然消散。很多配置做完之后是可以长期稳定的，不需要反复折腾。如果你第一次配置后还是觉得怪，先别急着怀疑工具，回到这篇文章的检查顺序，把每一步都过一遍，大概率能找到那个被忽略的衔接点。