这取决于你想要构建和部署它的方式。在我的公司，我们使用一个mono repo，在cmd文件夹中使用相同的go.mod文件来提供不同的服务。

# Accept the Go version for the image to be set as a build argument.
ARG GO_VERSION=1.19

# First stage: build the executable.
FROM golang:${GO_VERSION}-alpine

# Install the Certificate-Authority certificates for the app to be able to make
# calls to HTTPS endpoints.
# Git is required for fetching the dependencies.
RUN apk add --no-cache bash ca-certificates openssh build-base curl

RUN go env -w GO111MODULE=on && \
    go env -w GOFLAGS=-buildvcs=false

# Set the working directory outside $GOPATH to enable the support for modules.
WORKDIR /src

RUN go install github.com/jteeuwen/go-bindata/... && \
    go install github.com/cortesi/modd/cmd/modd@latest

Docker合成文件：

version: "2.4"

x-build:
  &build
  build:
    context: .
    dockerfile: <your-docker-folder>>/Dockerfile
  entrypoint: modd
  command: -f modd.conf
  volumes:
    - gopath:/go
    - ./:/<your-source-folder>
  environment:
    <<: *env
  networks:
    - your-network

services: 
  fast-api:
    <<: *build
    container_name: your-service-name
    ports:
      - "8080:8080"

这个项目使用的是https://github.com/cortesi/modd，它是一个灵活的开发工具，可以运行进程并响应文件系统的更改，当使用docker进行本地开发时，您可以受益于热加载，但我们正在为新项目使用https://github.com/cosmtrek/air。
我希望我能帮助你。我会继续寻找这个线程，看看你是否可以解决你的问题。
祝你好运

您可以使用单个go.mod文件，并且仍然为docker构建不同的服务可执行文件。如果服务更像单个项目而不是独立的可发布模块，那么单个go.mod就有意义了。
通过指定主文件名而不是.或./...，您将能够为不同的服务构建可执行文件
例如，对于服务目录为

├── go.mod
├── go.sum
├── m1
│   ├── m1_code.go
│   └── cmd
│       └── m1_main.go
├── m2
    ├── m2_code.go
    └── cmd
        └── m2_main.go

m1的Dockerfile可以如下所示，m2的Dockerfile也是如此。

FROM golang:alpine AS builder

RUN mkdir /app
WORKDIR /app

COPY go.mod . 
COPY go.sum .
RUN go mod download

ADD . /app
RUN go build -o main_m1 ./m1/cmd/main.go  

FROM alpine:latest AS production 
COPY --from=builder /app/main_m1 .
ENTRYPOINT [ "./main_m1" ]

Dockerfile可以在m1、m2文件夹中，或者您可以使用带有构建参数的公共Dockerfile来指定main.go路径和输出文件名。