Go 的 map 非线程安全，并发读写会 panic；sync.Map 适用于高并发读、低频写的场景，但类型受限且 API 不同；需按序遍历、结构体 key、持久化、TTL/LRU 时应选其他方案。

map 是 Go 里最直接的键值存储，但不是线程安全的

Go 的 map 类型天然支持键值对存取，语法简洁，适合单 goroutine 场景。但它在并发读写时会 panic，错误信息是 fatal error: concurrent map reads and map writes。这不是 bug，而是 Go 故意设计的运行时保护机制。

如果你只是做配置缓存、函数内临时映射、或明确单线程逻辑（比如 CLI 工具初始化阶段），直接用 map[string]interface{} 或带具体类型的 map[string]int 完全没问题。

• 声明方式：data := make(map[string]int) 或字面量 data := map[string]bool{"enabled": true}
• 零值是 nil，不能对 nil map 赋值，必须先 make 或用字面量初始化
• 判断键是否存在要靠「双赋值」：if val, ok := data["key"]; ok { ... }，仅用 val := data["key"] 拿不到是否存在信息

需要并发安全？别自己加锁，优先用 sync.Map

Go 标准库的 sync.Map 是为高频读、低频写的并发场景优化的，内部做了读写分离和原子操作，比手动用 sync.RWMutex 包一层普通 map 更轻量（尤其读多时）。

但它有明显限制：键和值类型只能是 interface{}，不支持泛型，且 API 不同于原生 map —— 没有 len()、不支持 range 直接遍历（得用 Range() 方法）、没有「获取并判断存在」的一行写法。

• 写入：m.Store("key", 42)
• 读取：if val, ok := m.Load("key"); ok { ... }
• 删除：m.Delete("key")
• 遍历：m.Range(func(key, value interface{}) bool { ... return true })（return false 可提前退出）

什么时候该换别的方案？

如果需求超出 map 或 sync.Map 能力边界，就该换：

• 需要按插入顺序遍历 → 用 slice + map 组合，或者第三方库如 github.com/elliotchance/orderedmap
• 键不是 string 或基本类型（比如结构体作 key）→ 确保 key 类型可比较（字段都可比较），否则编译报错 invalid map key type
• 数据量大、需持久化或复杂查询 → 别硬扛，上 SQLite（mattn/go-sqlite3）或 BadgerDB 这类嵌入式 KV
• 要 TTL（过期时间）或 LRU 驱逐 → github.com/hashicorp/golang-lru 或 github.com/bluele/gcache 更合适

package main

import "fmt"

func main() {
	// 基础 map 示例
	cfg := make(map[string]string)
	cfg["host"] = "localhost"
	cfg["port"] = "8080"
	if v, ok := cfg["timeout"]; !ok {
		fmt.Println("timeout not set")
	}

	// sync.Map 示例
	var cache sync.Map
	cache.Store("user_123", "Alice")
	if val, ok := cache.Load("user_123"); ok {
		fmt.Printf("found: %s\n", val)
	}
}