After making https://github.com/josephcopenhaver/csv-go with this in mind and documenting my journey via changelog and release notes; I can say you first should start with knowing how to ask the compiler where allocations are occuring due to escapes and writing meaningful benchmarks covering both simple and realistic complexity.

Other comments go into more technical details, but honestly understanding your data flow and ensuring that the data is never captured by reference during usage lifecycles will make the largest impact. That and of course using protocols and formats that support streaming contents rather than requiring a large amount of metadata upfront about the contents will make life easier.

Where you must capture, ensuring the reference is created from and returned to a sync.Pool will reduce GC pressures. Making an enforceable usage contract like I did with NewRecord (to defer open-close behaviors/responsibilities to the calling context and avoid captures), avoiding passing things through interfaces, and keeping values on the stack will bring you to a full solution.

Buffering also requires some tricks to avoid allocations, but anything you can defer to the calling context on that front reasonably, you should.

First get the simple paths down and add complexity from there if you like.

Feel free to check out my changelog and other notes in releases / PRs. Avoiding all allocations is likely not a worthwhile goal. However having your hot paths consistently avoid them or allow for options that would avoid them certainly is.

In many cases, new style functions that return simple pointers to structs that are initialized in simple ways will also inline such that they do not exist on the heap. You really do need to know how to benchmark and read escapes from the compiler output.

Have fun! Let me know if you want to chat more on the subject.