NET应用Docker部署中v指令参数详解
记录Docker的-v指令使用
前言
之前接触Docker，主要是为了解决.NET项目的部署问题——具体来说，是部署打包编译后的产物。当时用的Dockerfile大致长这样：
免费影视、动漫、音乐、游戏、小说资源长期稳定更新！ 👉 点此立即查看 👈
FROM mcr.microsoft.com/dotnet/aspnet:6.0 AS base WORKDIR /app EXPOSE 5031 EXPOSE 7031 FROM mcr.microsoft.com/dotnet/sdk:6.0 AS build WORKDIR /src COPY . . ENTRYPOINT ["dotnet", "Personalblog.dll"]
接下来便是常规操作：构建镜像、创建容器。用的命令也很直接：
docker build -t app . docker run -d -p 80:80 --name app app
问题出现
如果只是按上面的流程走，项目确实能跑起来。但很快就会发现一个麻烦：一旦项目代码有更新，就得先把容器删掉，接着再把镜像也删了，才能重新部署。如果只删除容器而不动镜像，你会发现，新创建的容器里跑的依然是老代码。
为什么会这样？
根本原因在于没有主动挂载目录。Docker默认会用一个随机生成的名称来挂载一个数据卷。如果不删除镜像，这个默认的卷就会一直存在，导致无论创建多少个新容器，它们读取的都是同一份旧数据。
问题解决
解决办法其实很简单，用上 -v 指令就能搞定。
具体命令调整如下：
docker run -d -p 80:80 -v 项目路径:/src --name app app
这样部署后，容器内的 /src 目录就会直接指向你本地的项目路径。之后项目再有更新，只需删除旧容器，然后用上面的命令重新创建一个新的就行，镜像完全无需动。
需要注意的是，这个挂载路径 /src 是针对.NET项目Dockerfile里 WORKDIR /src 这个设置来的。其他类型的项目挂载点可能不同。尝试过修改这个路径，但容器启动时似乎会自动生成一个src目录，具体机制还有待深究。如果哪位有更优雅的解决方案，欢迎分享探讨。
扩展
如果想查看一个容器具体的挂载详情，可以用这个命令：docker inspect 容器名。在输出的JSON信息里，找到 Mounts 字段，就能看到完整的挂载源和目标路径了。
热门专题
热门推荐
2026年，Bitget在交易所排行榜上展现出强劲的竞争力。其表现主要体现在用户资产安全体系的持续加固、多元化产品矩阵的成熟与创新，以及在合规与全球化布局上的显著进展。平台通过优化现货与衍生品交易体验，并深化Web3生态建设，巩固了其在行业中的领先地位，获得了市场与用户的广泛认可。
HttpClient的7个常见陷阱与规避指南 在 NET 生态里进行项目开发，HttpClient 几乎是调用外部 API 绕不开的一个工具。它的上手门槛很低，用起来很顺手，但恰恰是这份“简单”，让不少开发者放松了警惕。如果不清楚它内部的运作机制，一不小心就可能掉进坑里，轻则请求失败，重则引发服务
如何解决 NET Core项目与Linux服务器之间的时间同步问题 导语 搞分布式系统的开发者，多少都踩过时间不同步的“坑”。这事说大不大，说小不小——日志对不上、订单乱取消、交易出岔子，追根溯源，往往是几台机器的时间“各走各的”。尤其是在 NET Core应用遇上Linux服务器的场景，时区、格式
1 首先安装必要的NuGet包 第一步，咱们得把项目里需要的“砖瓦”——也就是那几个关键的NuGet包——给准备好。具体是下面这几个： NLog：日志记录的核心库。 NLog Config (可选)：如果你想让配置文件自动生成，可以加上这个。 当然，别忘了根据你用的数据库类型，安装对应的提供程序。
在 NET Core 中玩转 RabbitMQ：从零搭建可靠的消息队列 消息队列是现代应用解耦和异步通信的基石，而 RabbitMQ 无疑是这个领域的明星选手。它基于 AMQP 协议，为不同应用程序间的可靠消息传递提供了强大支持。今天，我们就来深入聊聊，如何在 NET Core 环境中，亲手搭建