我来帮你分析这个问题的根源和解决办法：

问题原因 #

你遇到的核心矛盾是：手动docker run容器能成功，但docker compose up失败，本质是Docker Compose里的volume挂载覆盖了容器构建阶段生成的关键文件。

看你的docker-compose.yml，给app服务配置了：

volumes:
  - .:/code

这会把你本地的当前工作目录直接挂载到容器的/code目录下，完全覆盖了Dockerfile构建时在/code下生成的所有内容（包括sbt dist生成的target目录，以及解压后的simplestocks-0.0.1程序）。

• 手动docker run时没有挂载这个volume，容器使用的是构建阶段完整的文件系统，所以能找到bin/simplestocks；
• 而docker compose up启动时，容器的/code被替换成你本地的目录，如果你本地没有提前执行sbt dist并完成解压，容器里自然找不到这个可执行文件。

解决方法 #

方法一：移除不必要的volume挂载（推荐，适用于生产/非开发场景）

如果你的应用不需要在运行时同步本地代码（比如不需要热重载、这是最终部署镜像），直接删掉app服务里的volumes配置即可。这样Compose启动时会使用容器构建时生成的完整文件，和手动docker run的环境完全一致。

修改后的app服务配置：

services:
  app:
    container_name: simple-stocks
    image: simple-stocks:1.0.0
    build: .
    ports:
      - '9000:9000'
    links:
      - pgdb1
    # 移除了覆盖/code的volume挂载

方法二：调整挂载路径（适用于需要本地代码同步的开发场景）

如果你确实需要挂载本地代码进行开发（比如热重载），不要直接挂载整个.到/code，而是只挂载需要同步的代码目录，避免覆盖构建生成的target目录。

比如，只挂载你的源代码目录./SimpleStocks到容器的对应路径：

services:
  app:
    # ... 其他配置不变
    volumes:
      - ./SimpleStocks:/code/SimpleStocks

同时，你需要先在本地执行以下命令，确保本地生成了可执行文件：

sbt dist
cd target/universal
unzip simplestocks-0.0.1.zip

排查验证步骤 #

你可以通过以下命令确认问题：

1. 查看Compose启动的容器内的文件结构（挂载本地目录后的状态）：

docker compose run app ls -l /code/SimpleStocks/target/universal/simplestocks-0.0.1/bin

如果返回No such file or directory，说明本地目录没有对应的文件，验证了挂载覆盖的问题。

2. 对比手动运行的容器内的文件结构（无挂载的状态）：

docker run -it --rm {imageId} ls -l /code/SimpleStocks/target/universal/simplestocks-0.0.1/bin

这里应该能看到simplestocks可执行文件，证明构建阶段是成功的。

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