在 Go 开发里，map 是最常见的数据结构之一，但很多人都是在写到一半时报错，才意识到某些类型根本不能拿来做键。要避免这类问题，关键不是死记硬背，而是抓住 Go 对 map key 的底层要求：类型必须可比较。顺着这个标准往下看，你就能快速判断哪些类型能用、哪些会直接编译失败，以及哪些虽然能用但仍然有运行时风险。
判断 map key 的核心规则
Go 里的 map 是由一组无序键值对组成的内置关联数据结构，每个键都必须唯一，并且要能稳定地找到对应的值。要做到这一点，Go 必须能够判断两个键是否相等，所以并不是所有类型都适合做键。
可以作为 map 键的类型，至少要满足一个核心条件：可比较。也就是说，这个类型必须支持 == 和 != 运算。很多文章会顺带提到“不可变性”，虽然 Go 规范没有把它单独写成硬性语法条件，但从使用效果看，适合做键的类型通常也应该是值语义稳定、比较结果明确的类型。
实际判断时，可以先记住这三条：
- 这个类型是否支持
==和!=； - 如果它是
slice、map、function，那就一定不能作为键； - 如果它是
struct或数组，要继续检查内部字段或元素是否都可比较。
哪些类型可以作为 map 的 key
只要类型本身可比较，就可以作为 map 的键。Go 里常见的可用类型主要有下面几类。
基本类型
大多数基本类型都支持相等性比较，因此可以直接作为键，包括：
- 布尔型：
bool - 整型：
int、int8、int16、int32、int64 - 无符号整型：
uint、uint8、uint16、uint32、uint64、uintptr - 浮点型：
float32、float64 - 复数型：
complex64、complex128 - 字符串型：
string
// 整数作为键
mapInt := map[int]string{
1: "one",
2: "two",
3: "three",
}
// 字符串作为键
mapString := map[string]int{
"Alice": 25,
"Bob": 30,
"Eve": 22,
}这也是日常开发里最常见、最稳妥的一类用法。
指针、通道和接口类型
除了基本类型，pointer、chan、interface 也都可能成为合法的 map key，但它们的比较规则需要单独理解。
指针类型可以比较，因此可以作为键：
m := make(map[*int]string)通道类型同样可比较。两个通道值相等，当且仅当它们来自同一个 make 调用，或者两个值都为 nil。
ci1 := make(chan int, 1)
ci2 := ci1
ci3 := make(chan int, 1)
fmt.Println(ci1 == ci2) // 输出: true
fmt.Println(ci1 == ci3) // 输出: false接口类型本身也可以比较，所以类似下面的声明在语法上是合法的：
var m map[interface{}]string不过这里要格外小心。接口能不能安全作为键，不只看接口类型本身，还要看它实际装进去的动态值是否可比较。也就是说，interface{} 看起来很宽松，实际却可能把问题推迟到运行时。
结构体和数组类型
struct 和数组能不能作为键，不是看类型名，而是看它们的组成部分是否全部可比较。
对于结构体来说，只要所有字段都可比较，这个结构体就能作为键：
type Point struct {
X, Y int
}
m := make(map[Point]string) // ✅ 合法数组的规则也是一样：当数组元素类型可比较时，数组值就可比较，因此也能作为键。
// 只包含前述可比较类型的数组也可以作为key
m := make(map[[2]int]string)这类规则在自定义数据结构时尤其有用。很多时候你不必把多字段组合手动拼成字符串，只要结构体字段本身满足条件，就可以直接把结构体作为键使用，代码会更清晰。
哪些类型不能作为 map 的 key
不可作为键的类型，本质上都是因为它们不支持稳定的相等性比较。Go 中最典型的三类是：slice、map 和 function。
slice、map、func 为什么不行
切片（slice） 是引用语义类型，底层元素可变，Go 不允许它参与恒等比较，因此不能做键：
m := make(map[[]int]string) // ❌ 编译错误：invalid map key type []int映射（map） 本身也是可变的引用类型，同样不可比较：
m := make(map[map[string]int]string) // ❌ 编译错误函数类型（function） 也不可比较，因此不能作为键：
m := make(map[func() string]string) // ❌ 编译错误如果记不住所有细节，先把这三类记牢，已经能避开大多数编译错误。
包含不可比较字段的结构体也不行
结构体是否能做键，经常容易误判。很多人看到 struct 就默认可以，实际上只要其中有一个字段不可比较，这个结构体整体就不能作为键。
type Person struct {
Name string
Tags []string // ❌ slice 是不可比较的
}
m := make(map[Person]int) // ❌ 编译错误这个规则很严格，没有“部分字段可比较就放行”的说法。只要混入一个 slice、map 或函数字段，整个结构体都会失去作为键的资格。
实践中的几个高频陷阱
语法层面的“能不能做键”只是第一步，真正写业务代码时，还有几类情况虽然合法，却容易埋坑。
浮点数可以做键，但要警惕精度问题
float32 和 float64 都是可比较类型，所以语法上完全可以作为 map key。但浮点数的精度问题不会因为它能比较就消失，像 0.1 + 0.2 != 0.3 这样的情况，可能直接导致你以为“相同”的键实际上查不到。
如果键值来自金额、统计值、计算结果这类场景，通常要先做归一化处理，或者改用整数、字符串等更稳定的表示方式。
interface 作为键的风险在运行时
interface 最大的问题不是声明时报错，而是看起来能编译通过，真正写入值时才出问题。只要接口里装入的是不可比较类型，就可能在运行时触发 panic。
因此，map[interface{}]... 更适合非常明确、可控的数据边界；一旦值来源复杂，排查成本会明显上升。
想用 slice 做键，可以先转换
很多场景下，开发者想把一个切片内容当成“复合标识”。因为 slice 不能直接做键，常见替代方案是先把它转换成稳定的可比较类型，比如字符串。
原文给出的思路包括：将 slice 转成 string，例如通过 JSON 序列化，或者使用 strings.Join 拼接后再作为键。核心原则只有一个：先把可变结构转换成可比较、可复用、含义稳定的表示。
并发访问问题和 key 类型无关，但同样常见
map key 类型合法，不代表这个 map 的使用方式就一定安全。Go 的 map 本身不是并发安全的，多个 goroutine 不能同时读写同一个 map。
如果需要跨 goroutine 共享 map，应该使用 sync.Map，或者通过互斥锁等同步机制保护访问。这一点和键类型不是一回事，但经常和 map 使用问题一起出现，值得顺手一起排查。
一张表快速记住结论
如果只想快速回顾，可以直接看下面这组结论：
| 类型 | 是否可作为 key | 说明 |
|---|---|---|
| int / string / bool | ✅ | 内建可比较类型 |
| float / complex | ✅ | 虽可比较，但要注意精度陷阱 |
| pointer / chan | ✅ | 可比较，可直接作为键 |
| interface | ✅ | 动态值也必须可比较，否则可能 panic |
| array | ✅ | 前提是所有元素类型都可比较 |
| struct | ✅ / ❌ | 取决于字段是否都可比较 |
| slice / map / func | ❌ | 天然不可比较 |
归根结底，判断 Go 的 map key 是否可用，不用背一长串清单，抓住“是否可比较”就够了。能比较，就有资格参与键的唯一性判断；不能比较，编译器通常会直接拦下。再往前一步，在浮点数、接口和值转换这些边角处多留意，基本就能避开大多数与 map key 相关的坑。
