差异出在架构：Docker Desktop 的引擎跑在 WSL 共享虚拟机里，wslc 则每启一个容器就单独建一台私有虚拟机。好处是每次启动环境完全一致，坏处是内存和管理方式都得重新适应。

一、开启只要一条命令

1. 执行 wsl --update --pre-release 升级到预览版，wslc 命令随之可用。
2. 先记住收尾命令 wslc system session terminate，原因见下一节。

二、先学会清残留虚拟机

1. Docker Desktop 空载时含特权 Windows 服务一起算，占用不到 200 MB 内存；而跑一个 wslc 容器会新建一台以用户名命名的虚拟机，吃掉约 1.5 GB。
2. 微软称容器用完即消失——容器确实消失了，但托着内存的虚拟机不会，手动执行 WSL 关机也杀不掉。唯一解法是 wslc system session terminate，这条命令藏在三层子命令之下，wslc 自己也不会提示。
3. 更费内存的是连带效应：启动一个 wslc 容器会同时唤起一份全新的 WSL 共享虚拟机，并把已装的 Ubuntu 重新标记为运行中，一个空闲的命令行提示符合计吃掉 3.4 GB 内存。

三、速度实测：差距小到感觉不到

1. 早期报道称 wslc 启动容器不到一秒，Docker Desktop 要三到八秒。用 alpine 镜像配合计时脚本冷热各跑一轮，结果是热启动 wslc 357 至 384 毫秒、Docker Desktop 426 至 463 毫秒；冷启动（会话已终止或应用已退出）wslc 2387 至 2611 毫秒、Docker Desktop 2629 至 2973 毫秒。
2. 只有 Docker 非正常退出才拉开差距：强制结束进程后冷启动要 6667 毫秒，连辅助进程一起杀掉则是 9108 毫秒，其中包含一次权限确认弹窗。
3. 真正的优势是稳定：六次 wslc 启动全部落在 224 毫秒区间内，因为私有虚拟机不继承任何状态，无论怎么被强行拆掉都没有残留需要修复。

四、显卡能用，端口有坑

1. GPU 加速开箱可用：一个标准的 CUDA 12.4 镜像立刻认出 RTX 5090，只需加 --gpus-all 参数，不必在容器里折腾驱动，宿主机装 CUDA 13.3 驱动同样正常。注意这是显卡半虚拟化而非独占直通，显存和 Windows 桌面共用，规划时要留余量。
2. 网络默认绑定 127.0.0.1，而不是 Docker 习惯的 0.0.0.0。测试 nginx 时必须显式发布到 0.0.0.0 才通，且会弹出一条归属于 COM Surrogate 的防火墙提示——正是很多人误当成病毒的那种弹窗。

五、Compose 目前靠社区补丁

1. 截至 2.9.3 版本，wslc compose 仍然不可用。社区项目 wslc-compose 用一层轻量 Python 转译补上了这个缺口，通过 pipx（Python 命令行工具的隔离安装器）装好即可。
2. 实测拿 nginx 加 Postgres 两个服务、配置里写上依赖顺序，结果正常跑通：生成项目独立网络、数据库先于 Web 容器启动、两容器共用去重后的 Alpine 基础层，down -v 也能连网络一起清干净。

注意事项

1. 参数还不全：没有特权模式、设备直通和重启策略，会话一断里面的东西全没，常驻服务不适合搬过来。
2. 可见性是短板：Docker 的容器摆在图形界面里，wslc 得靠命令行才能看清有什么在跑，目前还没有对应的管理界面。

来源：XDA Developers

在 Kubernetes 集群中给容器设置 limits.cpu 是很多团队的标准操作。但一项基于真实集群的对照测试表明：CPU 限制不仅不能保护邻居 Pod，反而会让被限制的应用频繁冻结、尾延迟飙升、启动时间翻倍。

CPU 请求与限制是两回事

Kubernetes 中每个 Pod 可以声明两种 CPU 参数：

– request（请求）：告诉调度器「这个 Pod 至少需要多少算力」。调度器按 request 总和放置 Pod，确保节点容量不被超卖。 – limit（限制）：一个硬性天花板。一旦 Pod 在某个时间窗口内用完配额，Linux 内核会直接冻结整个容器。

测试在同一台 4 核节点上部署了两个完全相同的 .NET 10 API 服务。两者都请求 250m（四分之一核）CPU，唯一的区别是一个设了 500m 的 limit，另一个不设。

内核如何执行限制

Linux 以 100 毫秒为周期执行 CPU 配额管理。500m 的 limit 意味着每个窗口只有 50 毫秒的实际 CPU 时间可用。预算耗尽后，内核冻结整个容器的所有线程——包括 HTTP 处理器、后台消费者和垃圾回收器。

一个运行 8 个繁忙线程的服务可以在约 12.5 毫秒内耗尽全部配额。这意味着每秒最多发生 10 次冻结。

更隐蔽的是：如果只看 1 分钟平均 CPU 使用率，仪表盘看起来一切正常——平均值远低于 limit，但应用实际上整天都在被节流。正确的监控指标是 container_cpu_cfs_throttled_periods_total。

实测数据：延迟与吞吐量

测试向两个服务发送相同负载：

– 慢请求变慢 2.4 倍：即使平均负载只需 320m（远低于 500m 的 limit），受限服务的慢请求延迟仍是不受限版本的 2.4 倍。 – 尖峰吸收能力归零：流量突增时，受限服务在 89% 的时间窗口内处于冻结状态；无限制服务则轻松吸收了 12 倍的突发流量，零降速。 – 启动时间缩短约一半：CPU 密集型的编译/初始化工作完成速度提升近一倍（具体倍数取决于服务启动阶段 I/O 占比）。

「吵闹邻居」真的存在吗？

最常见的担忧是：不加限制的 Pod 会抢光整台机器的资源。测试专门验证了这个场景——在同一节点上放了一个持续吃满 CPU 的「吵闹邻居」Pod：

– 无限制受害者的 P99 延迟变化不到 7 毫米，且从未触发节流。CPU request 本身就是保护伞——CFS 调度器按权重分配资源，空闲份额会被借走，工作一来立刻归还。 – 有 500m 限制的受害者反而被节流了 0.29% 的时间窗口，P99 延迟并未改善。

结论很明确：限制保护不了邻居，只能伤害自己。

为什么内存限制应该保留

CPU 和内存有本质区别：

• CPU | 应用变慢，稍后补上 | 去掉 limit，保留 request
• 内存 | 应用直接崩溃（OOM Kill） | 保留 limit

成本影响：多数集群预留了大量闲置算力

测试提供了一个说明性的成本模型：去掉不必要的 CPU 限制并重新调整 request 后，单个集群每年可节省数万美元的硬件开支。大多数集群的实际 CPU 利用率长期停留在个位数或低两位数，而限制让本可借用的空闲算力白白浪费。

正确的做法

1. 保留 CPU request：它是真正的资源保障，也是 CFS 权重的来源。 2. 去掉 CPU limit：除非使用 Guaranteed QoS + 静态 CPU Manager 绑核这一特定场景。 3. 先加 LimitRange：给未显式声明 request 的 Pod 设定默认值，一条清单即可生效。 4. 再补 ResourceQuota：按命名空间控制总 request 上限，守护成本而非稳定性。

重要提醒：不能用被节流状态下测到的 CPU 用量来设定新的 limit 值——那个数字反映的是 limit 允许了多少，而不是应用真正需要多少。

来源：GitHub 项目 k8s-cpu-limits-analyzed（inevolin）

第一次接触 Docker 的人，往往被镜像、容器、卷、端口、Compose 文件和满屏命令劝退，以为必须懂开发才能上手。镜像（image）可以理解成打包好的应用「蓝图」，容器（container）则是照蓝图跑起来的运行实例，二者并不相同。MakeUseOf 一位撰稿人分享，他真正跑起几个自托管应用后才发现，日常反复用的其实就是那么七八条命令。先把这七条记熟，Docker 就不再难懂。

二、七条核心命令

1. docker pull nginx：从镜像仓库下载名为 nginx 的镜像，相当于把「原材料」备好；
2. docker run -d –name myserver -p 8080:80 nginx：把镜像变成运行中的容器；-d 后台运行，–name 起名，-p 把本机 8080 端口映射到容器内 80 端口；
3. docker ps：查看正在运行的容器名称、状态、镜像与端口；加 -a（docker ps -a）可看已停止的；
4. docker logs myserver：查看容器输出日志，定位启动报错、配置或连接问题；加 -f 实时跟踪；
5. docker exec -it myserver sh：进入容器内部开一个交互终端，像在本机一样查文件、跑命令；
6. docker stop myserver：用完先停而非删，容器保留在系统里，下次一条命令就能再起；
7. docker rm myserver：确定不再需要时彻底删除容器（镜像仍在）。

一个最小流程就是：pull 拉镜像、run 起容器、ps 确认在跑、logs 排错、stop 收工。

三、理解工作流就不慌

镜像像图纸，容器是照图纸跑起来的实体。端口映射（-p 8080:80）的意思是：在浏览器访问本机 8080，流量会被转进容器里的 80 端口，这样外面的电脑才能打开容器里的服务。七条命令足以起步，其余等踩坑时现学现用。

注意事项

docker pull 并非每次必用，Docker 在 run 时缺镜像会自动补拉，但理解「镜像与容器」的关系能少走很多弯路。myserver 只是容器名占位符，换成自己实际名字即可；忘了名字就 docker ps 看 NAMES 列。删除容器前若仍在运行，要先 docker stop 再 docker rm，否则会报错。

来源：MakeUseOf

一、适合放在 NAS 上的：数据密集型服务

判断标准很简单：这个服务大部分时间都在读、写、整理或保护 NAS 上的文件。

1. 媒体服务器：Jellyfin、Plex 本就常读 NAS 里的影音，跑在 NAS 上省掉一台机器和一道网络挂载。只要 NAS 的算力够转码，比另起一台更合理。
2. 照片管理、文档归档、下载工具（如 qBittorrent、Transmission）：它们几乎只跟 NAS 里的文件打交道，放在别处徒增网络往返。
3. 备份软件：NAS 本就是集中存重要副本的地方，让它接收、排程、整理或复制备份，是顺理成章的延伸——当然这不意味着 NAS 就是全部备份策略，尤其当原始数据也在上面时。

二、整合能省下的维护成本

家里每多一台常年开机的设备，就多一份更新、监控、备份和「它啥时候挂了」的心智负担。把媒体服务器、几个下载工具和存储类工具并到 NAS 上，既能减负，又把独立硬件留给真正需要的活儿。排错也更省事：应用主要跟 NAS 数据打交道时，出问题只需在 NAS 一台机器上理清应用、权限、存储，不必先跨三台设备追同一处故障。

三、必须留在 NAS 之外的：需要独立存活的服务

诱惑往往从这开始：媒体服务器装完，又加一个容器，再加一个，NAS 眼看要吞下半个数家庭实验室。硬件能跑，不等于该跑。划线的标准是：NAS 宕机时，你还需不需要它。

1. 基础设施类：比如 DNS。若全屋 DNS 只跑在 NAS 上，一次例行维护就会从「存储问题」升级成「网络问题」。管理、监控类工具同理——你正排查 NAS 故障时，恰恰需要它们还在线。
2. 重计算类：大型虚拟机、开发环境、数据库等会和存储服务抢 CPU、内存与磁盘 I/O；当不得不为这些不相关的程序让路、绕着排期做存储维护时，整合就已经过头了。

四、一条好用的判断口诀

问一句：NAS 要是掉线，这项服务会不会也把「排查网络／恢复系统」所需的能力一起带走？会，就挪到别处；不会，就留下。对多数家庭用户，一台 NAS 配一台小型辅助机，就足以在「存储相关应用」和「基础设施／实验／重计算」之间划出边界——既保留整合的便利，又不让所有鸡蛋落在同一个篮子里。

注意事项

群晖 DSM、威联通或绿联等主流 NAS 都提供容器管理器（套件中心／Container Station／Container Manager），上述思路与具体品牌无关。整合的甜头是省机器、省电、易维护；底线是别让 NAS 变成「牵一发而动全身」的单一依赖。让 NAS 做好它擅长的事，比把它塞成全能服务器更稳妥。

来源：XDA Developers

麻烦的根源在于 Docker 的清理逻辑并不直观：删掉一个容器，并不会同时删掉它的镜像和数据。久而久之，隐藏的构建缓存、残留的持久卷和无人使用的镜像层层堆积，占用的空间远超预期。

第一步：先查清空间到底去哪了

在动手删任何东西之前，应当先看清占用结构。

1. 在终端执行 docker system df，查看镜像、容器、卷和构建缓存各自占用多少空间，以及其中有多少属于”可回收”。
2. 确认存在大量悬空镜像和已停用容器后，再执行 docker system prune --all 进行清理。
3. 如果构建缓存仍然庞大，追加执行 docker builder prune 单独清掉缓存。

需要特别提醒的是，docker system prune --all 会删除所有已停止的容器、没有被任何容器使用的网络，以及全部未使用的镜像。这条命令不能盲目执行——原文作者正是吃过这个亏才总结出经验。清理完成后，再逐个回看哪些容器仍在日常使用，把长期闲置的手动移除即可，需要时重新拉取并不困难。

第二步：把日常管理交给容器面板

命令行清理虽然可行，却既繁琐又容易误伤。更省心的做法是加装一个容器管理器，例如 Portainer。装好之后，日常操作基本都能在网页界面里完成：

1. 打开容器列表，直接查看每个容器占用的端口。容器超过六个时，这一项能有效避免端口冲突。
2. 查看运行状态与健康状况。运行/停止状态一目了然，可以避免在执行清理命令时误删处于停止状态但仍需保留的容器。
3. 点开日志排查故障，无需再敲一长串命令。
4. 进入 Stacks 视图管理编排。该视图本质上是 Docker Compose 文件的图形界面，可直观判断各套编排是否正常运行。
5. 在卷管理页面增删数据卷。列表形式能看清哪些卷还在使用、哪些可以安全清除，减少误删重要数据的概率。
6. 需要进入容器内部时，直接调用网页终端。

更轻量的替代方案

Portainer 并非唯一选择。另一款常见工具是 Lazydocker，它是终端界面工具而非网页服务，因此资源占用更低，操作路径也更简洁。Portainer 社区版与 Lazydocker 均为开源项目，可按硬件条件自行取舍：家用小主机或树莓派资源紧张时，Lazydocker 更合适；需要多人查看、远程操作时，网页版的 Portainer 更方便。

注意事项

管理面板本身也占用一定资源，但相较于误删数据、排查端口冲突所耗费的时间，这点开销通常划算。清理命令与面板操作可以配合使用：先在面板中确认容器状态，再决定是否执行批量清理，比直接在终端里”一把梭”稳妥得多。

来源：How-To Geek