What makes something a "real" DI framework? Wouldn't go.uber.org/fx qualify?
fx doesn't do that. It is primarily just a convenience way for tying things together in the single intended way. You can provide some configuration but it is not via a DSL; it is by making calls to the fx library.
Realistically to do the sort of DI I am referring to with Golang there would need to be a preprocessing step during compilation that generates Golang code.
The closest thing that comes to mind is writing software with some sort of global configuration. i.e.: the user provides some options (CLI flags, environment variables, configuration files, etc.) to change the runtime behavior of the software (e.g. use filesystem storage vs S3 storage, etc.).
In Go, I've always solved this pretty straightforwardly by combining Fx and functional options [1].
[1] https://dave.cheney.net/2014/10/17/functional-options-for-fr...