最近跑Docker容器的时候，突然发现电脑风扇狂转，打开任务管理器一看，某个容器的CPU占用直接飙到80%以上。这种情况并不少见，尤其在本地开发环境或部署服务时，一个“吃CPU”的容器会让整个系统变得卡顿。
先确认是哪个容器在“作妖”
第一步不是急着调配置，而是找出罪魁祸首。用下面这条命令可以实时查看所有容器的资源占用情况：
docker stats运行后你会看到每个容器的CPU、内存、网络等使用情况。重点关注CPU那一列，一眼就能看出哪个容器异常。
常见原因一：应用本身逻辑问题
有时候不是容器的问题，而是你跑的应用写得“太拼命”。比如有个Node.js服务在死循环处理数据，或者Python脚本没加sleep一直在轮询，这种代码丢进容器里，自然会把CPU拉满。
解决办法很简单：进容器看看日志。
docker logs <容器名或ID>看看有没有报错反复刷屏，或者某些操作被无限触发。改代码比调参数更治本。
常见原因二：容器资源没限制
Docker默认是“能吃多少吃多少”。如果你的主机有8核，那一个容器理论上能占满全部CPU。这在多服务共存时很危险。
启动容器时可以用--cpus限制使用核心数，比如只给1.5个核心：
docker run -d --cpus=1.5 myapp也可以用--cpu-shares来设置相对权重，适合多个容器公平分配资源的场景。
监控+压测，提前发现问题
别等到风扇响了才查问题。在开发阶段就可以用docker-compose配合资源限制，模拟低配环境：
services:
app:
image: myapp
deploy:
resources:
limits:
cpus: '0.8'
memory: 512M这样即使代码有问题，也能在测试阶段暴露出来。
别忘了检查宿主机状态
有时候你以为是容器的问题，其实是宿主机本身就负载高。比如Windows上WSL2跑Docker，Linux子系统整体资源紧张，所有容器都会受影响。
可以进WSL里执行top或htop看看整体负载。如果多个发行版或服务挤在一起，考虑调整WSL的内存和CPU分配。
小技巧：临时降负载
遇到突发高占用，又不能马上重启容器，可以用renice降低进程优先级：
docker exec -it <容器ID> renice 19 $(pgrep your_process)虽然不能减少CPU使用量，但能让系统其他任务更流畅，至少浏览器不会卡到打字延迟。
容器CPU占用高不是啥大病，但得学会看症状、找根源。与其盲目重启，不如花十分钟查清楚到底是代码问题、配置问题，还是环境问题。毕竟，谁也不想半夜被机箱风扇吵醒吧。