Buffered vs. unbuffered channels for a latency-sensitive Go pipeline

I am designing a producer-consumer pipeline in Go where a single producer hands work items to a small pool of consumer goroutines. The documented semantics are clear: an unbuffered channel forces a synchronous handoff (the sender blocks until a receiver is ready), while a buffered channel decouples the two sides until the buffer fills.

My constraint is strict per-item latency with a hard requirement that the producer must know an item was actually received before moving on. That points to an unbuffered channel, but I am concerned about the context-switching overhead under load. A buffered channel would improve throughput, yet a successful send would no longer prove the item was picked up — only that it entered the buffer.

I am also weighing the leak risk: with either type, a sender can block indefinitely if all receivers exit, and sizing a buffer incorrectly can hide bottlenecks or cause hard-to-reproduce stalls.

Given these constraints:

• Is there a documented pattern that preserves the delivery guarantee of an unbuffered channel while recovering some of the throughput of a buffered one (for example, a separate acknowledgment channel)?
• How should buffer size be chosen empirically, and is measuring handoff latency with the time package plus go run -race a sufficient verification approach?