配置混乱？从镜像开始理清楚
上线一个服务，本地跑得好好的，扔到线上就报错，这种问题在容器化初期太常见了。根本原因往往是镜像构建不规范。比如开发用的 Node.js 版本和生产不一致，或者依赖没锁死，今天装的包明天版本变了。
解决办法是写好 Dockerfile，把环境固化下来。比如：
FROM node:16.14.0-alpine\nWORKDIR /app\nCOPY package*.json ./\nRUN npm ci --only=production\nCOPY . .\nEXPOSE 3000\nCMD ["npm", "start"]这里用了特定 Node 版本，又用 npm ci 确保依赖完全一致，避免“我本地能跑”的尴尬。
容器启了又挂，日志去哪儿看
运行中的容器突然退出，第一反应别急着重启，先查日志。docker logs 命令最直接：
docker logs container_name如果容器已经没了，加 --all 参数也能看到历史记录。有时候日志刷得太快，可以配合 grep 过滤关键字，比如 error 或 timeout。
更进一步，把日志统一收集到 ELK 或 Loki，省得一个个容器翻。特别是业务一多，几十个容器来回切终端，眼睛都花。
资源不够用，到底是哪里卡住了
某个服务响应慢，可能是 CPU 或内存吃紧。docker stats 能实时看资源占用：
docker stats看到哪个容器占了 90% CPU，基本就能锁定目标。但注意，容器里看到的资源使用是相对宿主机的，如果没设 limit，它可能把整台机器拖垮。
建议启动时加上资源限制：
docker run -d --memory=512m --cpus=1.0 myapp这样即使出问题，也不会影响其他服务。
网络不通，别只盯着代码
微服务之间调用失败，不一定代码有 bug。先确认容器之间的网络是否打通。比如两个容器要通信，最好放在同一个自定义网络里：
docker network create mynet\ndocker run -d --network=mynet --name service-a app-a\ndocker run -d --network=mynet --name service-b app-b这样它们可以直接用容器名当域名访问，比如 service-b 调用 http://service-a:3000。如果还通不了，用 docker exec 进去 ping 试试，一步步排查。
频繁部署，怎么避免出错
一天发十几次版本，靠手动 docker build、docker run 肯定扛不住。这时候就得上编排工具，比如 Docker Compose 或 Kubernetes。
一个 docker-compose.yml 就能定义多个服务：
version: '3'\nservices:\n web:\n build: .\n ports:\n - "3000:3000"\n redis:\n image: redis:alpine一条 docker-compose up，全起起来。改配置也不用手动删容器，重载就行。
再往上走，K8s 提供滚动更新、健康检查、自动恢复，哪怕某个 pod 挂了，也会自动拉起来，比人工盯屏靠谱多了。
权限问题别忽视
有些容器启动报错，说是不能写文件或绑定端口，其实是权限没配对。比如挂载宿主机目录时，容器里的进程用户可能没权限读写。
解决方法有两个：一是确保挂载目录的权限开放，二是容器里用合适的用户运行。比如：
docker run -v /data:/app/data --user $(id -u):$(id -g) myapp这样容器进程就用当前用户身份运行，避免权限冲突。
管理容器化应用，说到底就是管好镜像、资源、网络、日志和部署流程。哪块松了，系统就容易抖。把这些细节控住，故障自然少一半。