WSL2 + Docker 本地微服务环境配置踩坑实录：一次惊心动魄的排雷指南

最近接手了一个客户的微服务核心业务系统，需要在本地搭建基于 WSL2 加上 Docker Compose 的开发环境。本来以为只是简单的 docker-compose up 就能搞定的事情，结果却硬生生变成了一场“排雷大作战”。

从 WSL 的内存泄漏、DNS 解析异常，到 Maven 私有仓库权限报错，再到微服务之间的本地路由配置，每一个环节都踩了个遍。今天就把这套完整的排雷过程记录下来，希望能帮到同样在配置复杂本地环境的打工人。

坑一：被 VmmemWSL 吃掉的内存（内存与 Swap 调优）
坑二：诡异的 DNS 解析与网络断连
坑三：Maven 拉取 GitHub 私有包报 401 Unauthorized
坑四：微服务本地路由与 AWS Parameter Store 冲突
总结

坑一：被 VmmemWSL 吃掉的内存（内存与 Swap 调优）

刚把几个核心服务跑起来，电脑风扇就开始狂转。打开任务管理器一看，好家伙，VmmemWSL 这个进程直接吃掉了十几个 G 的内存，系统直接卡成 PPT。

这是 WSL2 臭名昭著的“内存吞噬”特性。如果不加限制，它会无休止地占用宿主机的物理内存。

💡 解决办法：配置 .wslconfig

按下 Win + R，输入 %USERPROFILE% 进入用户主目录，新建或编辑 .wslconfig 文件，强行给 WSL2 定下规矩：

ini [wsl2] memory=8GB # 限制最大内存占用（根据你的物理内存调整） swap=2GB # 设置虚拟内存 localhostForwarding=true # 允许宿主机直接通过 localhost 访问 WSL 内部服务

配置完成后，在 PowerShell 中执行 wsl --shutdown 重启 WSL，世界终于清静了。

坑二：诡异的 DNS 解析与网络断连

环境跑起来没多久，容器内部就开始报错 Temporary failure in name resolution，连不上外网，也拉不下镜像。WSL 的网络稳定性一直是个玄学问题。

💡 解决办法：固定 DNS

我们需要干预 WSL 的网络配置，防止它每次重启都重置 DNS。

进入 WSL 终端，编辑 /etc/wsl.conf：
ini [network] generateResolvConf = false # 禁止 WSL 自动生成 DNS 配置
删除旧的链接并重新创建 /etc/resolv.conf：
bash sudo rm /etc/resolv.conf sudo nano /etc/resolv.conf
写入公共 DNS（比如 Google 的 8.8.8.8 或是 AWS 的内部 DNS，视你项目网络环境而定），保存退出后重启 WSL。网络彻底稳定。

坑三：Maven 拉取 GitHub 私有包报 401 Unauthorized

由于项目依赖了一些托管在 GitHub Packages 上的私有依赖，在执行 Maven Build 时，控制台红了一片，全是 401 Unauthorized。

一开始以为是 SSH Key 没挂载好，排查了半天才发现是 GitHub Personal Access Token (PAT) 过期或配置有误。

💡 解决办法：更新 settings.xml

登录 GitHub，重新生成一个拥有 read:packages 权限的 Classic Token。
找到本机的 Maven 配置文件（通常在 ~/.m2/settings.xml）。
在 <servers> 节点下配置正确的凭证：

xml <server> <id>github</id> <username>你的GitHub用户名</username> <password>你的新Token</password> </server>
4. 强制刷新依赖：mvn clean install -U。顺利 Build 成功！

坑四：微服务本地路由与 AWS Parameter Store 冲突

这是最耗时间的一个坑。主应用启动后，一直无法连接到 Order-Service 和 User-Service 这两个下游微服务。看日志发现，主应用默认去请求 localhost:8083 和 localhost:8081，但实际上在我们的测试环境中，应该走 AWS 内部的 ALB（应用负载均衡）地址。

此外，Auth-Service 鉴权服务启动直接崩溃，因为它在本地尝试去连接 AWS Parameter Store 获取配置，但缺失了 Region（区域）信息。

💡 解决办法：利用 SPRING_APPLICATION_JSON 覆盖配置

为了不污染代码库里的 application.yml，我选择直接在 docker-compose.yml 中通过环境变量强行覆盖 Spring Boot 的配置。

在对应的服务节点下添加 environment：

yaml
environment:
# 强制禁用 AWS Parameter Store
- aws.paramstore.enabled=false
# 显式指定 Region
- cloud.aws.region.static=ap-northeast-1
# 覆盖微服务的路由地址，指向正确的 ALB
- SPRING_APPLICATION_JSON={"microservices":{"order-service":{"url":"[http://internal-order-alb-xxx.ap-northeast-1.elb.amazonaws.com](http://internal-order-alb-xxx.ap-northeast-1.elb.amazonaws.com)"},"user-service":{"url":"[http://internal-user-alb-xxx.ap-northeast-1.elb.amazonaws.com](http://internal-user-alb-xxx.ap-northeast-1.elb.amazonaws.com)"}}}

重新 docker-compose up -d，所有微服务顺利握手，前端页面终于成功加载出数据。