docker-compose使用bind mount时如何保留容器内node_modules目录

报错由Docker挂载机制的权限规则直接导致：

• 本地项目根目录以只读（ro）模式bind挂载到容器/app后，该路径所在文件系统层为完全只读状态
• 后续匿名卷要挂载到/app/node_modules时，Docker必须先在/app路径下创建node_modules目录作为挂载锚点
• 只读层禁止写入新目录，直接抛出read-only file system错误

方案1：零源码结构改动（最贴合现有使用习惯） #

不需要调整现有源码目录结构，不需要新增环境变量，本地不会存放实际的node_modules依赖，生产镜像可直接启动，仅需2个极小调整：

1. 在本地项目根目录创建一个空的node_modules文件夹作为挂载锚点，执行命令：

   mkdir node_modules
   

   将这个空目录加入.gitignore。这个空目录不会存储任何npm依赖文件：容器启动后/app/node_modules路径会被匿名卷完全覆盖，镜像构建时安装的所有依赖都存在Docker管理的匿名卷中，本地空目录仅作为挂载锚点使用，磁盘占用为0，不会有依赖冗余或冲突问题。
2. 保留原有docker-compose.yml配置即可：

   services:
     node-app:
       build:
         context: .
         args:
           - NODE_ENV=development
       environment:
         - NODE_ENV=development
       volumes:
         - ./:/app:ro
         - /app/node_modules
       command: npm run dev
   

3. Dockerfile保持生产可用的标准写法，无需额外改动：

   FROM node:20-alpine
   WORKDIR /app
   # 先复制依赖文件安装，充分利用构建缓存
   COPY package*.json ./
   RUN npm ci
   # 复制剩余业务源码
   COPY . .
   # 生产默认启动命令
   CMD ["node", "index.js"]
   

方案2：业界标准分层方案（长期维护更推荐） #

如果不介意极简的目录调整，这是Node.js容器化开发的通用最佳实践，不存在目录混乱问题，反而文件职责更清晰：

1. 调整目录结构：所有业务源码（包括原根目录的index.js）全部放入src子目录，根目录仅保留package.json、Dockerfile、docker-compose.yml、项目配置文件等构建/配置类文件。这个结构是Node.js生态的通用规范，并非为适配Docker做的特殊改动，绝大多数开源Node.js项目均采用该结构。
2. 修改Dockerfile中生产启动命令为CMD ["node", "src/index.js"]，不需要新增任何环境变量。
3. docker-compose.yml配置调整为：

   services:
     node-app:
       build:
         context: .
         args:
           - NODE_ENV=development
       environment:
         - NODE_ENV=development
       volumes:
         - ./src:/app/src:ro
         - /app/node_modules
       command: npm run dev
   

该方案完全不需要在本地创建空的node_modules目录，挂载./src到/app/src时不会覆盖镜像中/app下已有的node_modules目录，Docker挂载匿名卷时直接在可写的容器层创建锚点即可，不会触发只读报错。

• 两种方案均满足需求：本地无node_modules依赖文件、生产镜像可直接启动、不需要额外配置大量环境变量、开发状态下源码修改可实时同步到容器
• 不要为了临时规避报错移除bind挂载的ro参数，否则容器内进程拥有本地项目目录的写入权限，存在误改本地文件、写入垃圾文件的风险
• 记得将本地调试用的.env、日志目录、空node_modules目录（方案1）加入.dockerignore，避免无关文件被打入生产镜像

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