Mapping complex keys to usable values
Strings and compound keys are not naturally array indexes. A hash function transforms them into numbers that can be mapped to valid buckets, narrowing lookup to candidate locations. Equal keys need consistent results under the same function parameters.
A limited output space generally cannot give a distinct result to every member of a larger input space. Different keys can collide, so matching hashes do not prove equal inputs. A hash table still compares candidate keys and resolves collisions through its chosen structure.
References: [1]
Distribution and computation cost both matter
Using only a small part of a key can concentrate similar inputs in one location. Ignoring the portion that actually varies creates avoidable collisions. A practical design balances inexpensive computation with useful distribution over the expected keys.
Uniformity is an analytical assumption or design objective, not an automatic guarantee for every input collection. Reading a long string also costs work. A fixed-width result does not make the computation independent of input length.
References: [1]
Seeds and security require distinct contracts
Some functions also use a seed, allowing different mappings for the same input. Go maphash recommends separate seeds for separate tables or structures. Reproducibility therefore depends on seed and interface conventions as well as the input text.
A function suitable for hash tables need not be cryptographically secure; maphash explicitly disclaims that property. Fast bucket selection and consistency with key equality are different requirements from cryptographic collision resistance or other security properties. The word hash alone guarantees none of these collectively.
References: [2]