wsl2是运行docker和systemd的必要条件，wsl1不支持dockerd、systemd及跨系统文件性能差；需用wsl --set-version升级并配置wsl.conf启用systemd。
WSL2 与 WSL1 的选择直接影响 docker 和 systemd 能否正常工作
WSL2 是必须的，不是可选项。WSL1 不支持 dockerd 守护进程、无法运行 systemd（导致 sudo service mysql start 类命令失败），且文件系统性能在跨 Windows/Linux 边界时更差。安装后务必运行 wsl --set-version <em>distro-name</em> 2 升级现有发行版。
常见错误现象：在 WSL 中执行 docker ps 报错 Cannot connect to the Docker daemon，或 systemctl status 提示 Failed to connect to bus——基本可断定是 WSL1 或未启用 systemd 支持。
实操建议：
- 安装前先执行
wsl --install（Windows 11 22H2+）或手动启用VirtualMachinePlatform并设为默认版本 2 - 若已有 WSL1 发行版，用
wsl --list --verbose查看当前版本，再用wsl --set-version Ubuntu-22.04 2升级（替换为你自己的发行版名） - 如需
systemd，在/etc/wsl.conf中添加：[boot] systemd=true
，然后退出并运行wsl --shutdown重启
VSCode 连接 WSL 的本质是远程插件 + code 命令注入
VSCode 并不“运行在 WSL 里”，而是 Windows 版本通过 Remote - WSL 插件，在 WSL 中拉起一个轻量服务端（vscode-server），再把编辑器 UI 映射回 Windows 端。关键动作是：在 WSL 终端中执行 code .，而非在 Windows 的 PowerShell 里执行。
容易踩的坑：
- 在 Windows 终端中执行
code .→ 打开的是 Windows 文件系统路径，不是 WSL 根文件系统 - 未安装 Remote - WSL 插件 →
code .无响应或报错command 'code' not found - WSL 中
code命令不可用 → 需先在 VSCode 的 Command Palette（Ctrl+Shift+P）中运行Remote-WSL: Install Code Command in PATH
验证是否成功：打开 VSCode 后左下角状态栏应显示 WSL: Ubuntu-22.04（或你使用的发行版），且资源管理器中路径以 \wsl$Ubuntu-22.04homeuser... 开头。
git、node、python 等工具链必须装在 WSL 内部
Windows 上装的 git、node、python 对 WSL 环境完全不可见。VSCode 的终端、调试器、任务运行器全部调用的是 WSL 的 $PATH，不是 Windows 的。
典型问题场景：
- 在 VSCode 中按
F5调试 Python 脚本，提示ModuleNotFoundError: No module named 'requests'→ 因为pip install requests是在 Windows 上执行的，WSL 的 Python 环境里根本没有 - 终端中
git status正常，但 VSCode 源码管理视图空白 → 可能是 Git 配置了 Windows 路径的core.autocrlf，而 WSL 的 Git 未配置，导致文件状态不一致
实操建议：
- 所有开发依赖统一在 WSL 中安装：用
apt install git nodejs npm python3-pip，再用pip3 install --user或npm install -g补充工具 - 检查 VSCode 设置中
terminal.integrated.defaultProfile.linux是否为"bash"（非"zsh"或空），避免终端启动失败 - Git 用户名/邮箱必须在 WSL 中单独配置：
git config --global user.name "xxx"，否则提交记录会显示unknown
Windows 和 WSL 的文件系统互通有陷阱，/mnt/c/ 不是你的工作区
WSL 可以访问 Windows 盘符（如 /mnt/c/Users/xxx/project），但这只是挂载点，底层仍是 NTFS。直接在此路径下开发会导致：
-
chmod失效、符号链接损坏、文件权限混乱（尤其影响npm install和 Python virtualenv） - Git 提交时自动转换换行符（CRLF ↔ LF），引发 diff 泛滥和合并冲突
- 某些工具（如
rsync、find -exec）对 NTFS 挂载路径行为异常
正确做法是：把项目放在 WSL 的原生路径下（如 ~/projects/myapp），需要从 Windows 访问时，用 \wsl$Ubuntu-22.04homeuserprojects 映射网络驱动器，或用 VSCode 的 Remote Explorer 直接打开。
如果必须跨系统协作（例如共享文档、构建产物），建议：
- 仅将输出目录（如
dist/、build/）放在/mnt/c/下，源码始终留在 WSL 原生路径 - 禁用 WSL 的自动挂载：在
/etc/wsl.conf中加[automount] enabled = false
，然后wsl --shutdown，避免意外写入 Windows 分区
文件系统边界比看起来更硬。哪怕只在一个 chmod 上出错，后续的 npm run dev 就可能静默失败——这种问题不会报错，只会让你花两小时查为什么热更新不触发。
