append(slice, vals...) returns a possibly-new slice header; if the backing array still has capacity it reuses it, otherwise it allocates a new one (typically doubling). Always reassign the result, since otherwise the new header is dropped on the floor. The capacity-vs-length distinction matters when chains of slices share the same backing array (next accordion). Pre-allocate with make([]T, 0, capacity) when you know roughly how many elements you will append; this is one of the easiest performance wins in Go.

Go slices share the backing array of whatever they were derived from. view := src[1:3] creates a header pointing into src's array, so view[i] = x writes into src too. This is one of Go's most common surprises and the cause of many subtle bugs in libraries that hand out subslices to callers. To genuinely copy the elements, use copy(dst, src) into a freshly allocated slice or append([]T(nil), src...) for a one-liner that allocates and copies. The full-slice expression src[1:3:3] also limits the capacity, preventing later appends on the subslice from clobbering src.

Slices have no built-in delete; you splice with append(s[:i], s[i+1:]...) to remove index i while preserving order. That copies the entire tail, so it is O(n). When order does not matter, swap-and-pop is O(1): move the last element into position i and truncate. Reach for swap-and-pop in hot paths over unordered collections (free-lists, contention queues, expired-entry pruning); use the order-preserving form whenever the callers see the slice. Both forms reslice the same backing array, so previous slice headers may now reference 'deleted' values that are still in memory; nil out elements containing pointers if you care about garbage collection.