这个问题的核心原因其实很好理解：Docker容器的可写文件系统是临时分层的——你直接在容器内安装的依赖，只会存在于当前容器实例的可写层中。一旦容器停止销毁，这层临时数据就会被清除，所以重启后依赖自然就没了。

下面给你两个无需重建容器就能持久化依赖的可行方案：

方案一：用Docker卷挂载Pipenv虚拟环境目录 #

Pipenv默认会把虚拟环境存放在容器内的~/.local/share/virtualenvs/路径下（可以通过在容器内执行pipenv --venv确认具体路径）。我们可以通过Docker卷将这个目录挂载到Docker的命名卷中，让依赖数据脱离容器生命周期独立存储。

操作步骤： #

1. 修改你的docker-compose.yml，给web服务添加卷配置：

services:
  web:
    # 保留你原有的镜像、端口、命令等配置
    volumes:
      - ./your_django_project:/app  # 如果你已经挂载了项目目录，保留这行
      - pipenv_venv:/root/.local/share/virtualenvs/  # 新增这行，挂载虚拟环境目录
# 在文件末尾定义命名卷
volumes:
  pipenv_venv:

2. 重启容器使配置生效：

docker-compose down && docker-compose up -d

3. 现在再安装依赖：

docker-compose exec web pipenv install package_name_here

这次安装的依赖会被存储在pipenv_venv命名卷中，无论容器重启、重建，依赖都会保留。

注意：第一次挂载卷后，容器内原有的虚拟环境会被卷覆盖，所以如果之前有已安装的依赖，需要重新执行一次pipenv install来恢复。

方案二：挂载项目内的虚拟环境（可选） #

如果你习惯把虚拟环境放在项目目录下（比如创建venv文件夹），也可以直接挂载这个目录：
在docker-compose.yml的volumes里添加：

- ./your_django_project/venv:/app/venv

这样依赖会直接存在宿主机的项目目录里，同样能实现持久化。

额外的最佳实践建议 #

虽然你要求不重建容器，但从Docker的设计理念来说，把依赖固化在镜像里才是更规范的做法：每次新增依赖后，更新你的Pipfile和Pipfile.lock，然后执行docker-compose build web重新构建镜像。这样容器启动时就自带所有依赖，无需手动安装，也能避免环境不一致的问题。

内容的提问来源于stack exchange，提问作者hmaina