This may be hard in general. It is true that recover is only useful in a deferred function, but that deferred function doesn't need to be a function literal. It can be a top-level function, like https://go.dev/play/p/YjT5mHT0wLl . The function definition and the defer statement can be far from each other, even in different packages. Or it could be a dynamic func value.

@cherrymui's point is well taken. Solving this is roughly the same as a pointer/may-escape analysis in the limit. This example will be much harder:

func harder() {
    f := func() {
        if r := recover(); r != nil { ... }
    }
    go f()
}

func evenHarderA(){
    f := func() {
        if r := recover(); r != nil { ... }
    }
    evenHarderB(f)
}
func evenHarderB(f func()) {
    go f()
}

The reason is that a warning should probably only be given if a recover() cannot be directly called by some defer statement. So off the bat, exported functions cannot be warned on in vet. Some cases should not be too hard though, like #64116 (comment) , or unexported functions that are never stored. FWIW something useful would be simpler in x/tools/go/ssa.

I do not have a good sense for how frequent these issues are. Getting a good grasp might be hard without an Analyzer implementation to test.

I also don't have any intuition for whether this would meet the "frequency" requirement for cmd/vet. @justpretending have you seen this frequently in practice?

In the absence of data supporting that this is a significant problem I think we should decline this.

In the absence of evidence that this is a common mistake it seems like this is headed for likely decline.

In general literally the only time we could issue a definitive positive would be 'go func() { ... }()'. There's no evidence people accidentally write defer instead of go, and even if they did, we'd only catch it when they happened to call recover.

This proposal has been added to the active column of the proposals project
and will now be reviewed at the weekly proposal review meetings.
— rsc for the proposal review group

Based on the discussion above, this proposal seems like a likely decline.
— rsc for the proposal review group

No change in consensus, so declined.
— rsc for the proposal review group