Docker绑定挂载不适用于服务端Web应用本地开发？求深度解析

我遇到的问题始于Stack Overflow上的提问《Why bcrypt (Node.js) package causes "Docker Failed - bcrypt_lib.node: Exec format error" while many other packages are not in the same conditions?》——表面看是Node.js bcrypt包的执行格式错误，但实际根源指向Docker项目结构的不合理性。

现有评论与疑问 #

• 有评论指出：不要把宿主机的node_modules复制到Docker容器内，这会增加构建时间，还能避免这类跨平台架构不兼容的错误。
• 还有评论认为我当前使用Docker容器的方式不推荐，说既然用stock docker container，不如直接在宿主机运行Node。

这里明确：stock docker container指的是官方提供的、未经过自定义修改的基础镜像容器，比如Docker Hub上官方发布的node镜像，没有额外添加自定义配置或依赖的版本。

我的项目现状 #

我愿意重新规划Docker项目结构，但不会只因“惯例”就调整，需要彻底搞清楚问题所在：

• 我用的**binding mounting（绑定挂载）**是向Docker容器暴露文件的合法方式，不清楚哪里不合理。
• 当前Docker Compose配置仅用于本地开发模式，和生产模式的核心区别是支持增量构建：
  • 03-LocalDevelopmentBuild目录是完全自动生成的，没有手动添加的内容
  • 必须保证增量构建正常运行：基于Gulp+Webpack的构建工具，在源码变更时无需手动重启服务
• 本地开发选择用Docker里的FrontServer服务而非宿主机Node.js，是因为本地Node版本可能和VPS上的不一致，而Docker的核心作用就是解决这类环境一致性问题；宿主机的Node.js仅用于项目构建环节。

核心疑问 #

1. 绑定挂载用于服务端Web应用的本地开发是否属于不推荐的做法？
2. 我的Docker配置到底存在哪些不合理的地方？

内容的提问来源于stack exchange，提问作者Takeshi Tokugawa YD