一个叫 nsl 的项目在 Linux 上复刻了 WSL 的使用体验。在项目目录里敲一个命令就进入开发机。工作目录还是原来的文件，账号还是原来的用户。做法是把发行版镜像跑成 systemd-nspawn 容器，这些容器共享一个虚拟机。它还没有稳定版。这个设计的第一个正式版本是 0.4.0，更早的版本是已经废弃的原型。理解它的分层，能看清这类工具各自要解决什么问题。
三层结构
最上层是命令行壳。创建、进入、执行单条命令，都归它管。中间是共享虚拟机，容器跑在里面。最下面是镜像，七个发行版可选，每周重建，使用前先验证签名。开发机和宿主之间用 virtiofs 共享目录，图形程序通过 Waypipe 把窗口投到宿主桌面。端口默认转接到宿主的回环地址。开发服务器在开发机里起，宿主上访问同一个端口。差别就在中间那层虚拟机。
上手只要三步。先创建机器，指定发行版标签，首次创建的那台就是默认机。再进入，在项目目录里敲命令，拿一个登录 shell。然后执行，nsl run make test 跑一条命令，退出码带回宿主。退出码能回来，make test 这类判断才能写进脚本。
为什么还要一层虚拟机
直接在本机跑容器也能隔离软件包。隔离的是文件系统，内核接口仍然共享。共享虚拟机先挡掉一层。开发机里改内核参数、加载模块这类动作影响不到宿主。需要更强隔离时加一个参数，这个开发机会拿到自己的虚拟机，访问不到宿主文件、桌面和宿主动作。图形转发和端口映射在这种模式下也没有。
文件属主和归属
开发机使用宿主的用户名、用户编号和组编号。开发机里创建的文件回到宿主还是你的。家目录、可移动介质和挂载点映射进去，内部还带免密 sudo。这套设计避开了容器常见的属主错位。属主不错位，编辑器、构建缓存、权限敏感的脚本才能跨机复用，这也是它能替代在宿主直接装依赖的原因。
信任模型与边界
镜像签名只能证明镜像出自发布流程，证明不了里面的软件包都安全。项目以用户身份运行，不装宿主软件包，不改设备权限、用户组和 sudo 配置，宿主机需要的前置条件自己准备。这些都是刻意的收缩，换来的是卸载之后宿主基本干净。实测环境写得很具体，某个较新的发行版、x86-64、systemd 261.2、QEMU 10.0.13、virtiofsd 1.13.2 和 GNOME Wayland。换成别的组合，先在分支上验证再推广。
什么时候该用，什么时候不必
每天要在多个发行版之间切换、又不想污染宿主的开发者合适。已经习惯容器加开发容器工作区的团队，迁移收益主要在文件属主和图形转发。只想临时跑一条命令的，容器或一次性虚拟机更轻。它替代不了生产环境的容器编排，也不解决持续集成里的一致性问题。宿主是不可变系统的场景下它的价值最大。装依赖这条后路本来就不存在。
常见问题
容器和开发机里的软件会串味吗？
每台机器保留自己的软件包、服务和文件。会话之间不重置。这一点和一次性容器相反。
镜像每周重建，会不会某天起来环境就变了？
镜像是新的，已创建的机器不会自动升级。要新基线就重建，节奏自己定。
不装宿主依赖能用吗？
不行。它明确要求宿主机先具备虚拟化和相关组件，自己不碰这些配置。装之前先核对文档里的前置清单。