GoLand and Docker: which debug workflow should target the image you ship?

The goal is to standardize one debugging workflow for a Go service whose production artifact is a container image, using GoLand's bundled Docker integration: a daemon connection over a Unix socket, Windows named pipe, or TLS-secured TCP, plus the Services tool window and Docker Compose support. Assuming a recent GoLand release (2024.x or newer); behavior varies by version and platform.

The documented options trade fidelity against setup cost:

• Go Remote attach: the container runs Delve headless with an exposed port, and GoLand attaches to that host/port pair; breakpoints depend on stable source path mappings between host and container.
• Docker Compose targets: GoLand starts and stops multi-service stacks and shows logs, but the extent to which the Go toolchain runs inside the services rather than on the host SDK varies by release.
• Host-side debugging: the binary runs locally against containerized dependencies, which is simplest but never exercises the image that ships.

Architecture and toolchain matching between host and image add further constraints.

Which approach gives the closest parity with the production image at acceptable setup cost? Can Go test and coverage runs be directed into a Compose service in current GoLand releases, or do they remain host-SDK only? And is there a documented convention for keeping host-to-container path mappings stable so Go Remote breakpoints bind?